“System” view security vs. “Application” view security
One key failing that limits an organisations ability to develop an enterprise/holistic view of their overall security position is assessing security solely on an application by application basis. Links, dependencies, information flows (relationships) between applications in a “system” (applications working and linked to each other) are rarely assessed (from our experience). A “system-level” perspective on security is vital in providing an organisation with a more thorough assessment of potential risks (direct and indirect) in a specific application and the corporate environment as a whole. Read on….
Whether you are an internal IT security specialist or an external consultant, the issues are the same when trying to confirm some level of confidence in an application for an organisation. Unless you are able to review the “system” and unless the application is truly stand-alone with no other links and relations to other applications (and that is rare), you are limited in what you can confidently state as that application’s level of security. (Taking into consideration snap-shot in time limitations and the always present potential for undetected vulnerabilities). “Disclaimers” and statements of the limitations of any such assessments must be made clear to the client. That should go without saying.
If I’m not clear, let me provide a couple of small examples:
Example 1: Bank X Internet Banking application is tested and found to be “secure”. Bank X also has a static site that promotes Bank X services. Static site has link to Bank X Internet Banking login. Static site has vulnerable CMS which allows hackers to redirect that login to an Internet Banking site they have created that replicates the Internet Banking site of Bank X. Security broken!…..regardless of how secure Bank X Internet Banking site itself is.
Example 2: Trading application is tested and the application itself is “secure”. But, how secure is the whole system given this application has direct links to numerous MO and BO applications/systems, business and third party connections (eg; market data feeds), extranet for direct B2B services, web applications for Internet ebusiness etc etc? Issues of data “integrity”, (one of the less focused upon CIA definitions of Information Security)? Where do you start when a system starts to get as complex as this?
Scoping a security assessment of an application is key, and at all times, the limitations of the results of any assessment need to be understood and taken into consideration against the “system” within which that application exists.
When a security breach of an organisation happens, the blame game begins (as recent examples like Heartland showed). As I said before, was the auditor to blame?….I don’t know in that case. But even good auditors can be and will be in the firing line for anything that does go wrong. Is that fair? Well it depends upon what scope they were allowed to work within, whether they guided the organisation well enough to understand the limitations of the work they were doing, whether they were thorough enough, and importantly, whether they were competent enough themselves.
You just cannot address Enterprise Security in silos and this, (the topic of this post), is just one example of why you cannot. This is a topic that you could write about for days, but I hope I have gotten the gist of the intended message across.
Other readings:
The 7 Reasons why Businesses are Insecure
February 5th, 2009 at 1:32 pm
AWESOME!
And it’s totally one of those “no duh!” posts because it is so logical, and yet so overlooked.
One would assume that an enterprise security architect would probably have this as one of their items.
February 5th, 2009 at 7:20 pm
Well in a sense I think we have our selves to blame a little for this. The IT Sec industry has been saying that security must be built into everything on a project level SDLC etc etc…
and organizations look notice. Projects started to budget for security.. which came at the expense of operational security budgets…
so now we have new projects which are getting secured but without any context to the business as a whole.
And unfortunately context is everything with security.
I could go on with but Oh jesus is it that hard… can’t we just sit down and think about this and get it right ? Risk management must cover all tangible risks or it is useless. saying you manage risk by pushing it out to the ‘project’ and ‘line manager’ level sounds great when you puff your chest up at conferences but it actually is short sighted and does little to increase the actual security of your organization.
Now before people jump in and say “oh oh Mr Ministry Representative are you saying that project and line managers should not re responsible ?? If so you are a silly silly man!” I’m not. not at all.
They are responsible for the security of their projects NOT the entire organization.
And if I have to sit in one more meeting were there is a critical vulnerability that threatens the entire foundation of the organization and it doesn’t get fixed because no one wants to pay for the ‘resources’ out of their budget I’m going to stab myself.
But thanks DD for bringing this up as it has been a pain in my ______ for some time.
February 5th, 2009 at 8:37 pm
Transitive trust
functions, modules, systems, flows etc.
http://bsdosx.blogspot.com/2008/08/request-for-flows.html
February 5th, 2009 at 8:52 pm
D2 chuckles @ old post with commentary from DD. It’s a bit like the ‘IT Crowd’ Series 3 when she unveils the internet and no one is shocked coz’ they have no clue… sometimes it shits me that it’s so simple yet so hard….
http://bsdosx.blogspot.com/2007/05/infosec-whats-fuss.html
February 6th, 2009 at 12:44 pm
Christian, re: Enterprise Security Architects – yes, you’d think this would be within scope of their role. I’ve met so many frustrated though by a lack of buy-in and support for their work – their role essentially then just being a project by project thing with little “enterprise” focus. Typical though. More the norm than the exception sadly.
@Mosp, thanks for the comments. “Context” is everything. Well put.
@D2, dude, love your work. Thanks for reminding me of that post. Funny times!
February 6th, 2009 at 5:42 pm
Drazen
Good points – solid post. Couple of thoughts:
. I definitely agree its very important to scope the assessment clearly – and that in itself is challenging (often for both sides) in complex environments. However, the disclaimer language is what gets my goat (even from companies I admire & respect). In some cases its probably a case ‘revenge of the lawyers’, in others it may indicate they’ve been burnt in the past. For me its just a language issue. I would rather see a clearly defined scope and then a covering statement saying ‘All items not included in-scope are by definition out-of-scope and consequently those areas will not be considered. All findings relate to in-scope items only.’ Its when I read the half page disclaimer that sounds like layer of ass covering upon layer of ass covering (normally with a preachy part included), I start rolling my eyes 
. From previous posts I know you tell it as you see it, so I’m looking forward to your reaction on this 
) [hint: I don't see this as window dressing - its about the relationship with the client and mutual respect].
- the disclaimers by security companies wind me up sometimes
- to the meat of your post: for me this comes back to a mix of organisational alignment and oversight. If all projects are run as discrete projects from dispersed functions and there is an oversight group (e.g. a security function) that is not considering the linkages and assessing the risks as part of the design phase then there is a miss IMHO. If there is no oversight group then its FUBAR time. If the oversignt has failed to either get visibility of the project groups or failed to onboard the project teams to the internal application security process then its fail again. From experience and talking with peers, this takes years to get in place (and even then you’ll see occasional misses).
- I always hoped for a data flow modelling tool that optionally integrates with an asset inventory system, a data classification system and risk system. You could then map the interactions and assign risk based on asset value, data classification and trust boundaries. Of course, this is complete pie in the sky as orgs struggle to even track assets properly, let alone get data classification down. For orgs that are a little further along on their “security journey” (whats the shortcut for expressing someone throwing up?) that would have real value…
Sorry for the verbage – obviously haven’t had enough sleep
.
Cheers mate,
Craig
February 10th, 2009 at 2:18 pm
Hey Craig,
Thanks for posting. Re: Disclaimers. (Printing out our own that we (Securus Global) include in our proposals to re-familiarise myself with our exact wording before I go off and say something)
I’m not sure there’s any other way. Sure, the agreement on scope is important but there’s a heap of things around the job itself that needs to be covered off. And yes, it’s “ass covering” on both sides. Just from our perspective, a few notes:
- Certain type of work we undertake for example could potentially impact a “system” so client needs to understand this if they want that type of work done.
- It’s not an exact science as we know so we are up front and honest and hopefully claims we make are in-line with the realities of what is achievable to best efforts.
- The rest is pretty much standard “services agreement” stuff and whether client accepts ours or we work under theirs, they are all pretty much the same.
Having been burnt a few times on people’s / company’s “word” (leaving more on this for another time), you also become somewhat cynical about things over time and more yourself insist on ensuring your business is covered. Dealing with larger clients, they’ve obviously also got an obligation to protect their interests and so it goes. Luckily it is rare to have to refer to the paperwork in our case as we do work hard with our clients to get that full scope and understanding agreed to up front. Trust is key with the people you deal with.
Totally agree with your second point. Re: the third point; “pie in the sky”? Yeah…it is for most organisations but why should it be? How did it get to that and why is it so hard to right things? In scenarios like the following:
http://beastorbuddha.com/2009/01/29/maybe-i-find-pci-dss-so-much-easier-than-other-thingsits-all-relative/
I have seen things start to head down this path quickly when someone (read: regulator for example) starts to demand it. It just needs support and ongoing commitment. Longer version:
http://beastorbuddha.com/2007/11/10/the-7-reasons-why-businesses-are-insecure/
DD
March 23rd, 2009 at 7:05 am
[...] reading: – Metl on Risky.Biz: The Infosec Industry is a Fraud – Cyber security at the Crossroads – “System” view security vs. “Application” view security – Sucking corporate security budgets dry – Have we made any real and measurable progress in 2008? – [...]
May 24th, 2009 at 6:55 pm
[...] Is this organisation’s dilemma unique/different to those in other organisations? From our experience, no, and the larger the organisation and the more complex the environment(s), the worse it is. (As I talked about here). [...]