1 Raindrop

Security Architecture Blueprint

The security industry has little strategic cohesiveness, instead the market is comprised of vendors selling an aggregation of tactical one off point solutions. The problem is that security is of strategic concern to the enterprise but the market does not reflect this. This security architecture blueprint shows one way to take a strategic approach to security in the enterprise.

The purpose of the security architecture blueprint is to bring focus to the key areas of concern for the enterprise, highlighting decision criteria and context for each domain. Since security is a system property it can be difficult for Enterprise Security groups to separate the disparate concerns that exist at different system layers and to understand their role in the system as a whole. This blueprint provides a framework for understanding disparate design and process considerations; to organize architecture and actions toward improving enterprise security.

This blueprint distills what I have learned on a number of enterprise security engagements into a generic framework. Enterprises know they have security problems today, and will not be perfect tomorrow, next month or next year -- so the question is how to define a pragmatic way forward?

I was fortunate to get great feedback on drafts from a number of folks including James McGovern, Jim Nelson, and Brian Snow.

Practical SOA - Service Firewall pattern

Arnon Rotem-Gal-Oz published a draft chapter from his book on SOA patterns. SOA runs on a network, we know from Joy, Gosling, and Deutsch that the fourth fallacy of distributed computing is "the network is secure". Since distributed apps, whether REST, SOA, Ajax, whatever, cannot assume a secure network, we need some other ways to deal with this.

One of my issues with common practice of enterprise architecture is that they frequently do not deep dive into security issues, instead focusing scalability, detailed software design, and so on. But here is the thing - the security people don't know enough about software design, and the software people don't know enough about security to really help out. Add to this the reality that many security mechanisms cannot make a business case as a one off project, but need to be part of core infrastructure to be economic, and wel, you get the situation we have today. The architects define the "what", and unless security is one of those whats, it is not feasible to make the case for many specialized security services at a project by project level. This is why, enterprise architects that enable increased integration within and across enterprises, must also invest time and resources in revamping security services that enable this to be done in a reliable fashion.

The security architecture needs to be backed by runtime patterns, so it is nice to see SOA security patterns working their way into enterprise architecture work such as Arnon Rotem-Gl-Oz's Practical SOA book. Basically, he uses a TIDE (subset of STRIDE) threat model for the Service Firewall. The Service firewall brokers the request from unauthorized service requesters and protects against some tampering, information disclosure, denial of service, and elevation of privilege threats. Spoofing is not covered, and this should not be an edge service anyhow. Repudiation is not covered, which also should not be an edge service, in my opinion.

We can all argue about the best places to locate these services and the nature of their implementation, but the overall encouraging sign is to see that these patterns become part of how we build the system and not a one off.

Lastly, he is on the right track in noticing that messages travel in a no man's land. And as such, this highlights the importance for a message level security model.

**************************************************

Upcoming public SOA, Web Services, and XML Security training by Gunnar Peterson, Arctec Group
--- NYC (April 19), Unatek Web Services (May), OWASP App Sec Europe (May), Helsinki (June), DC/Baltimore (July 19).

XML Security Gateway Evaluation Criteria Project

As Richard Bejtlich observed the TCP/IP stack is becoming intertwingled with lots of other things. Certainly, Cisco's purchase of Reactivity should lead us to expect more angle brackets in the stack not less, meaning XML Security is important in infrastructure as well as in distributed apps.

One of the primary, robust ways to deal with XML Secuirty in SOAP, Web services, SOA, and Rest apps is to use a XML Security Gateway. These are very powerful tools, the downside for the enterprise is that they are hard to assess and analyze. I launched the OWASP XML Security Gateway Evaluation Criteria project to:

* Create evaluation criteria supporting a transparent, level playing field for XML Security Gateway solutions to define their solution's key value proposition

* Where practical, attempt to standardize nomenclature and metrics

* Educate the community on the design considerations for XML security

I have found Ivan Ristic's work on the Web Application Firewall Evaluation Criteria to be very helpful, and would be happy if we can achieve similar utility in the XML security space.

Bill Gates on Glass House Security

Bill Gates underscores some of the biggest challenges in enterprise security.

"Security should be based on policy not topology"

h/t Mark O'Neill reporting live from RSA, and this article summarizes his speech

Programmers build bigger moats and thicker fortress walls -- but they don't bother to protect the corporate crown jewels when members of their fiefdom exit the castle and leave the drawbridge open.''We used to think of the data center as a glass house that was very isolated,'' Gates said. ''But if we look (at) what actually goes on -- consultants come into your company, employees who are not onsite need full access -- we cannot think of that glass house as the way to define what can connect to what. We need a far more powerful paradigm.''

Sorry folks. Network firewalls that create perimeters that only exist on whiteboard not in reality and are "protected" by SSL don't cut it anymore.

I am hopeful that Microsoft's competitors like Sun, Oracle, IBM, and open source projects will put aside their NIH and learn from the excellent work on security and identity coming out of Redmond. The Microsoft security architecture is far from perfect, but they have made some very creative, and practical improvements.

Making your security architecture match your software architecture

Tim O'Reilly on Web 2.0 -- "data is the Intel Inside", which is exactly why SSL doesn't cut it as your main security mechanism. Security must be applied at the message level to protect the data.

2006 in review

Here is a look back at this blog in 2006

January

Service Oriented Security Architecture - paper published in ISB. This paper deals with a security model for a distirbuted system the assets are separated as Identity, Message, Service, Deployment Environment, and Transaction. This way the risks and countermeasures can be understood and the elements and constraints dealt with in their own domain to the extent possible.

Learning from EAs: The EA Bill of Responsibilities - the role of a useful EA

Phasing Security into the SDLC - a comparison of approaches, top down, bottom up and so on

February

Bugs v. Flaws

April

Governance and Assurance Synthesis

Darwin Lives - Governance Models and the ability to govern

May

SOA security metrics - from my SOA, Web Services security training in Leuven

O, Perimeter Where Art Thou

June

Assertion Federation Assurance - putting strong authN on the wire

July

Intro to Identity Management Risk Metrics - published in IEEE Security & Privacy

August

Notes from MetriCon 1.0 Part 1, 2, 3

September

Laws of Identity and Web Services

October

Decentralization and Good Enough Security - Part 1, 2, 3

J Peterman's Threat Levels - watch out for the Enterman's shim sham

Whatever happened to give 'em enough eyes? - open source security lagging MSFT

Firewall this

November

Defining Misuse in the development process - published in IEEE Security & Privacy

Playing for keep across the board - thumb fingerprints or cut off your opposeable thumbs -- the choice is yours.

December

A series of posts looking at Rest security issues Part 1, 2, 3

Security Concepts, Challenges, and Design Considerations for Web Services Integration - published the DHS/ CERT Build Security In portal

Current State - Empowering Developers and Attackers Alike

Larry O'Brien says WS-* is too hard

I’ve advocated REST and POX in this column over the years, but never at the expense of WS-*, for which I always gave a “to be sure, complex scenarios may call…” deferral. No more. The final straw came when I found myself tracing a WS-* service call with a network sniffer. A network sniffer! In order to see why my multihundred-dollar, best-in-breed tool wasn’t able to interact with my “simple” Web service! What is this, NetWare in 1992? With REST, the URI endpoint for the communication is universally reachable—point a browser at it to see the client view, toss a server page in there to see the server view. With POX, you’re just a cut-and-paste away from parameter and response validation and automation.

Fair enough, but the problem is that attackers are programmers too. Basically, when you empower your developers you are likely to empower attackers. The same week that the above article was posted we had a Hell of a Week for Online Crime including

• 40 million credit cards reported stolen
• Half a million Canadians pesonal information breached
• Russian hackers steal €800,000 from Sweden's largest bank

So the state of the 1995 security model, aka network firewall, SSL, and a prayer, that most developers use for app "security" is not cutting it. Larry O'Brien makes legitimate points about the usability of some elements of the WS-* stack. What is missing from this conversation is that the decisions are left up to developers to choose what is easiest to work with, without consideration for what is at risk. Were the developers' personal info or money stolen in the above cases? Probably not. So why not just say WS-* is too hard and rely on your network firewalls, SSL, and prayers, right?

My mantra when developers say it is ok to use personal info for interop because it is protected by SSL is to say "ok, can we use your SSN for testing then?"

Instead of punting message level security away as too hard, how about we

a) Look at WS-* as a stack that still requires more engineering to get right. I seem to recall Apache was not perfect at 1.0 either.

b) Continue to identify and develop Restful message level security solutions

c) Both of the above

Protect the transaction

Its not cost effective (or realistic for that matter) to protect everything. Instead put your risk management chips on the assets you really need to protect - identity, transactions, and data in most cases. Dave Kilcullen blogs at Small Wars Journal on Two Schools of Classical CounterInsurgency contrasts two models in a way that is instructive to secuity architects

Discussion of the new Iraq strategy, and General Petraeus’s recent Congressional testimony have raised the somewhat obvious point that the word “counterinsurgency” means very different things to different people. So it may be worth sketching in brief outline the two basic philosophical approaches to counterinsurgency that developed over the 20th century (a period which I have written about elsewhere as "Classical Counterinsurgency"). These two contrasting schools of thought about counterinsurgency might be labeled as “enemy-centric” and “population-centric”.

The enemy-centric approach basically understands counter-insurgency as a variant of conventional warfare. It sees counterinsurgency as a contest with an organized enemy, and believes that we must defeat that enemy as our primary task. There are many variants within this approach, including "soft line" and "hard line" approaches, kinetic and non-kinetic methods of defeating the enemy, decapitation versus marginalization strategies, and so on. Many of these strategic concepts are shared with the population-centric school of counterinsurgency, but the philosophy differs. In a nut-shell, it could be summarized as "first defeat the enemy, and all else will follow".

The population-centric approach understands counter-insurgency as fundamentally a control problem, or even an armed variant of government administration. It believes that establishing control over the population, and the environment (physical, human and informational) in which that population lives, is the essential task. Again, there are many variants within this approach, including some very hard-line methods and some softer approaches, but the underlying philosophy is "first control the population, and all else will follow".

...

As an example of the need to read the battle and adapt, I hope you will forgive a brief personal anecdote. In Timor in 1999 I worked closely with village elders in the border districts. I sat down with several of them one afternoon to discuss their perception of how the campaign was progressing, and they complained that the Australians weren't securing them in the fields and villages, that they felt unsafe because of the militia (the local term for cross-border guerrillas) and that we needed to do more to protect them. In actual fact, we were out in large numbers, securing the border against infiltration, patrolling by night, conducting 14 to 21-day patrols in the jungle to deny the militias a chance to build sanctuaries, and working in close in the villages to maintain popular support. There had not been a single successful attack by the insurgents on the population for more than two months. So, "objectively", they were secure. But -- and this is the critical point -- because our troops were sneaking around in the jungle and at night, staying out of the villagers' way and focusing on defeating enemy attempts to target the population, they did not see us about, and hence did not feel “subjectively” secure. This was exacerbated by the fact that they had just experienced a major psychological trauma (occupation, insurgency, mass destruction and international intervention) and as a society they needed time and support for a degree of "mental reconstruction". Based on their feedback (and that of lots of other meetings and observations) we changed our operational approach, became a bit more visible to the population and focused on giving them the feeling, as well as the reality, of safety. Once we did that, it was fine.

In other words, we had to shift from a more enemy-centric approach to a more population-centric approach to adjust to the developing situation. My personal lesson from this experience was that the correct approach is situation-dependent, and the situation changes over time. Therefore the key is to develop mechanisms that allow you to read the environment, to be agile and to adapt, as John Nagl showed so brilliantly in Learning to Eat Soup with a Knife.

So, in summary, two broad philosophical approaches in classical counterinsurgency (and remember it's classical 20th century counterinsurgency we're discussing here) -- population-centric, and enemy-centric. Both have merit, but the key is to first diagnose the environment, then design a tailor-made approach to counter the insurgency, and - most critically - have a system for generating continuous, real-time feedback from the environment that allows you to know what effect you are having, and adapt as needed.

These enemy-centric approach is very reminiscent of the firewall/dmz style of security architecture. In this enemy-centric approach we use firewalls to keep the bad guys "outside" and the good guys "inside" forgetting that the world is not neatly divided into good guys and bad guys. We may actually employ bad guys inside the firewall, for one thing. For another, who cares about dividing the world into good and bad, what we need to do is to protect our populace. In enterprise security our populace means our user's identity, the transactions and data. Message level security is one good way to do this, use WS-Security or SAML to protect the message, do not assume that you can rid the environment of malice. Protect your assets so they are operable in a malicious environment. Some examples of message level security in web services are here at the DHS Build Security In paper I wrote with Howard Lipson at CERT - Security Concepts, Challenges, and Design Considerations for Web Services Integration.

Its diseconomic to try and divide the whole world into good and bad (in consulting we call this boiling the ocean), instead focus on what you know - your users, your transactions, your data. If you have not read Dan Geer's Shrinking Perimeter this is a good time to do so -- trust but verify, y'all.

I'll Take Transactions in Distributed Systems for $200, Alex

A single transaction in a standard enterprise architecture traverses multiple policy domains, namespaces, and technologies. Part of the problem to be solved by the security architecture is how to deal with authentication and authorization. At a high level there are subjects making requests objects and the communication is mediated by a Policy Enforcement Point (PEP).

Now the role of authentication services is verify and bind some set credentials onto token(s) that are used to make other decisions. The role of authorization is granting access, but where and where do you need to authenticate in a distributed system? In a single transaction lifecycle such as the one below, the user traverses a half dozen different technologies, namespaces, and so on. In addition,each system may rely on its own proprietary security mechanisms.

This is a very common scenario and far simpler than many architectures. So one question, is how far do you propagae the user's credentials? Do you keep a record on each user in all six systems? What abotu Oracle and SAP who (hypothetically of course) are charging you by the user? From a security standpoint do you really want to propagate identity hazmat (aka authentication credentials) throughout more than one system? Probably not. From a IDM standpoint how compelx do you want your provisioning to be? So in general, from an economic, risk, and compelxity standpoint, you probably want to limit all this to the extent you can. And instead push authentication to the edge of the system. The PEP (along with the PDP) has to map all its access control decisions to all its objects, so these will always, by necessity has some locality with the object it is protecting.

The best documentation I have seen in the open literature of the possible variants here is in Bob Blakley and Craig Heath's Security Design Patterns. This book contains the genesis of the problem we face

Security properties, especially authentication, often do not compose. Nevertheless, information systems are often built on composition.

They define a simple interaction with two possible guards

A secure proxy patterns deals with the following forces:

• The user would like to sign on only once.
• Both guards would like to authenticate the user.
• Both guards would like to enforce a policy based on the user’s identity.
• The authentication protocol may not authenticate the user to more than one partner.
• The user may not want (or be allowed, or be able) to divulge a passwordor other
authentication data to Guard1.

And they enumerate the following choices

Now the ideal scenario describes authentication (froma user standpoint_ occuring in only location so this resolves some of the aforementioned economic, risk, and compelxity issues. SSO (and SLO) which could be accomplsihed using SAML or other federation implementation. This is the ideal scenario, but none of the patterns individually give you exactly what you need. A combination of the patterns needs to limit the amount of authentication and instead use previously authenticated attributes to authorize access. Federation, then, is an enabling technology for these systems to work together.

Gerry Gebel raises some other salient authorization design considerations, which I will explore in the next post.

I blogged earlier about the ATM puzzle that Robert Morris Sr. gave at Blackhat awhile back. And as usual, we can learn a lot from ATMs. We have relatively strong 2 factor authentication at the edge, now there are many paritcipants between me and my bank, but my PIN code should not be revealed to all of them, right?

Update: Mark O'Neill weighs in on authorization in general, XACML in particular and how Vordel's products help you deal with it. Mark nails the importance of portability:

This is a big advantage XACML gives you. Your AuthZ requests suddenly are XML messages which can be routed, logged, monitored, and managed using standards-based infrastructure. I put this in bold type because it really is a big deal. AuthZ requests are no longer some piece of invisible "internal security plumbing". It means you can bring XML infrastructure (such as Vordel's :-) ) to bear on it.

So in a nutshell, step 1 is to decouple authN and authZ, step 2 is to use technologies and standards that enable you to use attributes that have already been authenticated to perform authorization.

Authorization: Standards and Granularity

James McGovern, whose questions in blog comments usually take me a whole additional blog post to answer appropriately, responding to an earlier post on security for Integrated Transactions asks

Would you agree that enterprises need to go beyond just building better authentication mechanisms such as support for SAML and go deeper in terms of authorization? What would it take to get security folks to also add XACML to their list of frequently mentioned acroynms...

I definitely agree with this. Enterprises need to look at authentication, and also authorization, and auditing as well. Plus they need to realize that these security landscapes have fundamentally changed 2 or 3 times in the past decades (OO, web apps, and SOA/Web Services) all require different types of security mechanisms, but many enterprises try in vain to find one silver bullet.

So it is definitely not just about authentication, but the larger point I think (and the one that SAML, WS-Security, WS-Trust, and XACML all to varying degrees help you solve) is how do you get interoperability for security tokens at runtime. A transaction can span dozens of namespaces, technical runtimes, governance and policy zones, etc. So job 1 is to be able to move the tokens and recognize them on the other end (vetting them in the process).

When it comes to authorization, I agree with Butler Lampson that "all trust is local". The aforementioned standards should be able to port the tokens (subjects) used for authorization across domains so that enforcement (which may be authorization) can be done at the endpoint (mediating the subjects access to the object). Part of this is coarse grained versus fine grained authorization.

Now there are some different nuances to how WS-* vs. SAML/XACML accomplishes this. WS-* format is more or less neutral -- a claim by any other name is still a claim. Whereas SAML differentiates authentication, attribute, and authorization authorities. But I don't see this as a big deal, because the endpoint can still enforce how it wants. My take is that SAML/XACML's approach could allow for tool vendors to support (and optimize) their assertions at a more granular level through decomposing authentication, authorization, and attributes. This relates to a point discussed by James and Mark O'Neill way back in 2006.

To James' other point, XACML does some things fundamentally different in describing policy for resources, which makes this really interesting esp. for high value resources. Earlier I made the point that for cases where you need higher assurances, the policy is mapped down to the object level:

The XACML mapping of the subject to authorized resources, conditions, and actions allows for the security policy to be applied to the subject as well as the representation of the object. One example of this in the real world at railroad crossings, normal cars pass straight over the tracks as long as the gate is open and the light is not flashing. School buses, because of their cargo, stop and perform additional visual checks before proceeding

The parents of the kids drive their cars right over the railroad tracks without stopping, other buses (containing presumably less precious cargo) sail right over the railroard tracks, but school buses stop and check - resource, condition, action.

So XACML has great utility for things like this, it would be great if there was more momentum in the tool space so that we could see XACML being built into as many stacks as WS-* and SAML already are. On the plus side all of the aforementioned standards work at the message level, so we are already moving in a more secure direction than relying on network firewalls, SSL, and a prayer.