1 Raindrop

Using Attack Surface in Threat Models

Last week, I blogged about using threat models to identify and locate countermeasures. Now, I would like to add a little more detail and context. Recall, the purpose of the threat model is to map threats to countermeasures, but he catalyst comes through some part(s) of the attack surface. There are several attack surface models out there, I use a simple one where the attack surface is the sum of the data +  method + channel, that entail the ways the system can be attacked. 

So in an example Web services application we would have an attack surface that includes

• Data: XML
• Method: SOAP or HTTP Verbs 
• Channel: HTTP 

Relating the attack surface construct to our threat model yields interesting possibilities for countermeasure combinations and permutations. Let's assume you are doing security design for a REST Web service and are looking at the constraints and capabilities that REST, HTTP, XML and other standards will help you deal with threats. The combination of the attack surface model and threat model gives you a way to be more precise with mapping countermeasures to threats.

 

Threat	Countermeasure Located in Attack Surface
	Data	Method	Channel
Spoofing	XML Signature (response only)	None	TLS/SSL
Tampering	XML Signature (response only)	None	TLS/SSL
Dispute	None	None	None
Information Disclosure	XML Encryption (response only)	None	SSL
Denial of Service	None	None	None
Elevation of Privilege	Oauth	Oauth	None

This is just an example, but the attack surface is a nice refinement for drilling down on the countermeasure side of the threat model ledger. The location context gives the security designer some flexibility in finding cost effective ways to address security in the software design. In a nutshell, the threat model identifies countermeasures and attak surface locates the countermeasures in the software architecture.

Using Threat Models

Threat models are a very good way to make implicit security threats and mechanisms, into explicit threats and mechanisms, so that you can write requirements, build, and test that they do the job you intend. As a starting point, I like to use a modified version of STRIDE, which among other things cleanly maps threat to mechanism. This way when starting a new project, for example with SOA Web services, you can identify where the standards will help you.

 

Threat	Mechanism	Example Standard
Spoofing	Authentication	WS-Security
Tampering	Digital Signature, Hash	WS-Security + XML Signature
Dispute	Audit Logging	None
Information Disclosure	Encryption	WS-Security + XML Encryption
Denial of Service	Availability Services	None
Elevation of Privilege	Authorization	None

Threat models are misunderstood, they are not about modeling threats. As defensive programmers, we have little to no control over threats, our job is to find and fix vulnerabilities. So why bother with threats and threat modeling at all then? It turns out that vulnerabilities are basically passive weaknesses, and the threat is the catalyst that exercises the vulnerability so that we can 1) identify it and 2) deal with it. 

So the end result of threat modeling is not a list of threats, but rather a list of countermeasures. And not just a generic list either. The active ingredient (threat) gives us a way to locate where the countermeasure can/should live in the architecture.

Further, if we are comparing approaches early in architecture/design phases of building software, the threat model is a structured back of the cocktail napkin way to compare/contrast approaches. For example if we are looking to build out a set of Web services and are choosing between SOA style (WS-*) and REST style, we may want to look at the readily available implemented standards that each software security stack supports

 

Threat	Mechanism	Example SOA Standard	Example REST Standard
Spoofing	Authentication	WS-Security	XML Signature (response only)
Tampering	Digital Signature, Hash	WS-Security + XML Signature	XML Signature (response only)
Dispute	Audit Logging	None	None
Information Disclosure	Encryption	WS-Security + XML Encryption	XML Encryption (response only)
Denial of Service	Availability Services	None	None
Elevation of Privilege	Authorization	None	None

Threat modeling gives a concrete structure to a fairly abstract subject like analyzing software security capabilities in services, but as you see its not about the threats its about the security architecture elements. This is just an illustrative example not a complete threat model, but it does give an effective, context-sensitive way to look at tradeoffs in security architecture. In this example, SOA/WS-* has potentially more coverage the security mechanisms work on both the request and response side. In the next series of posts, we'll look slicing and dicing the threat model a layer deeper and how we can use it secure our services.

Update: Using Attack Surface with Threat Models

WS-EncouragingSecurityProgress

Kelvin reports on a finding from Forrester (wow two Forrester links in teh same day), I don't have access to the whole report, but here is the summary

Current use of WS-Security doubled over the past two years: Now 30% of enterprises pursuing service-oriented architecture (SOA) use WS-Security as part of their SOA and Web services security strategy. Forrester believes that this gives WS-Security critical mass to sustain its place in the SOA landscape, especially considering that another 16% plan to adopt WS-Security. This also provides a foundation for adoption of other SOAP-based Web services security specifications. REST-based services still don't have standard profiles for interoperable security, which means that when security requirements are part of the picture, SOA architects should carefully consider where and how they use REST.

A couple of points on this, this number matches my overall experiences. I see a lot of SOA and Web services that start with weak or no security relying on SSL and a prayer. WS-Security, SAML and friends are often added in Phase 2 and Phase 3 so it speaks to the overall maturity. So that is some good news. Mark O'Neill had a good post recently on this as well.

Next, unfortunately saying you are using WS-Security doesn't mean all that much. As Brian Chess and I talked about in our RSA talk last year, the spec leaves ample room to shoot yourself in the foot at design time and that's even before you get to implementation. You can use weak token types, lack integrity, open up information disclosure, replay and a host of other vulns, all while still being WS-Security compliant, depending on the profile.

This is not necessarily a critique of WS-Security just putting some more specifics around what is allowable behavior. Our ask at RSA was to add more constraints and not leave so much up to the designer.

Finally, to the point on REST security, REST requires that you build your own message level security from scratch and implement it on both ends. Not impossible but you are reinventing the WS-Security wheel.

More on Fallacy #4

Steve Jones on Rest and Distributed Computing Fallacies

One of the objections I've had about REST for a while is that it appears to ignore Deutsch's fallacies of network computing

1. The network is reliable.

2. Latency is zero.

3. Bandwidth is infinite.

4. The network is secure.

5. Topology doesn't change.

6. There is one administrator.

7. Transport cost is zero.

8. The network is homogeneous.

Now REST specifies 8, assumes 1, 2 and 3 and takes 4 to mean HTTP/S with Basic Authentication. Now to be clear I've seen people doing Web Services who believe in pretty much all 8 of these fallacies and they create crap systems. But with things like WS-RM and WS-Security at least there are answers to a few elements.

That basic auth is bypassable has been known for some time, thanks to Amit Klein. It would be nice to Restafarians move the conversation towards better security models like SAML and WS-Security. The current state for Rest is both disappointing and weak. The response side is pretty solveable using XML Signature and XML Encryption to sign and encrypt the responses (of course someone will need to tell the "you just leverage the existing infrastructure types" that we'll need to be deploying keys and certs to all the endpoints but at least the primitives are there on the response side), the request side remains problematic.

More on the Fallacies by Arnon Rotem-Gal-Oz, who incidentally if you are interested in building a secure service has an interesting Service Firewall pattern, which I refer to as a TIDE firewall - dealing with Tampering, Information Disclosure, Denial of Service, and Elevation of Privilege threats at the edge. I understand why Arnon left Spoofing off his list, but would like to see him add audit logging to deal with Dispute.

A claim by any other name is still a claim even if its Restful

I am really enjoying this wonderful new world of Claims-based access control (CBAC), and I think the way that the encryption and signatures have been packaged up into claims (if you like your coffee with WS-*) or assertions (if you like a dab of SAML) is allowing us to deploy security architectures that solve a lot of age old problems. I call 'em claims even though MS/IBM hijacked the term from the SAML people it is shorter.

Rest application need claims too. As Don Box says the rest authentication story blows chunks. Now, you see people reinventing WS-Security in Rest (because they realize they need stronger claims) and unfortunately choosing the weakest token the Username token, which in turn encourages bad programming practice. Piers Cawley on the Rest authentication tarpit:

The problem with implementing the Atom Publishing Protocol is that one of the client apps that we want to support, Nokia’s LifeBlog mobile app, only supports the adaptation of the WSSE UserToken authentication protocol recommended by Marc Pilgrim. There’s lots to like about this protocol, especially the way it allows CGI based servers to take control of authentication without needing access to Apache’s .htaccess or requiring mod_digest to be installed. However, the design of the protocol is such that there’s no way to avoid storing the user’s password in plain text on the server. Which we really, really, really don’t want to have to do.

This would not be a big deal if it was just a one off, but your authentication story is the key to your access control and while authentication can never be perfect, there is a lot of evidence that good ol' username and password isn't that good any more. The problem is not with WS-Security, the problem is the token. While Rest people are reinventing WS-Security they should feel free to not use the username token and instead graduate to Kerberos, X.509, and SAML tokens.

A claim by any other name is still a claim, but some claims are stronger than others.

My larger problem with how I see Rest applications doing authentication is that they still after all these years rely on the old school approach where the server authenticates everything. Umm...are we on a mainframe or something? Why not separate the identity provider from the service provider like the rest of the world? Why send your authN creds across the wire every time? I have not tried but I assume an adapter to some of the SAML profiles would yield this separation quite nicely and give back an address to talk to, and the authN/authZ negotiation could be handled by the IdP and SP allowing the Rest client to talk directly to HTTP verbs served by the server...

You Got Chocolate in My Peanut Butter! Rilke weighs in on Rest and SOAP

Rest and SOAP are supposed to be about interoperability, it is fascinating that they are at each other's throats. I don't see the same level of malice from Rest or SOAP towards say J2EE or Corba. Wonder why this is? Either way it is ironic that proponents of interoperability technologies would want to vanquish each other. Rilke [1] says we need to let go of irony, and not be governed by it. So too must we let go of SOAP v REST. They actually can play nicely *together*, Mark O’Neill gave a good “real world” Web services security talk last week at OWASP (at eBay where I believe these two *do* play nicely together in actual fact), in the case studies section he describes some security considerations for SOAP-Rest integration

The simple fact is that you may need/want to rely on Rest on the edge, but you may also want to leverage SOAP's security mechanisms as you get closer to your enterprise foo (ERP, CRM, etc.). From a security perspective it is hard to do much useful without authentication and integrity, so an STS plays an important role. The example below shows one way, this is similar to the approach that Ping Identity uses in their Ping Federate Web Services.

You got Rest in my SOAP, oh wait, it can work together...and thither irony never descends.

[1] Rainer Maria Rilke:
Irony: Do not let yourself be governed by it, especially not in uncreative moments. In creative moments try to make use of it as one more means of grasping life. Cleanly used, it too is clean, and one need not be ashamed of it; and if you feel you are getting too familiar with it, if you fear this growing intimacy with it, then turn to great and serious objects, before which it becomes small and helpless. Seek the depth of things: thither irony never descends—and when you come thus close to the edge of greatness, test out at the same time whether this ironic attitude springs from a necessity of your nature. For under the influence of serious things either it will fall from you (if it is something fortuitous), or else it will (if it really innately belongs to you) strengthen into a stern instrument and take its place in the series of tools with which you will have to shape your art.

Letters to a Young Poet
(translated by M. D. Herter)

Message is the center

Tim Bray on REST:

Messages All The Way Down · HTTP is a decent and under-appreciated protocol, but in the end maybe the most important thing is that it forces you to think about the messages and how you exchange them. There’s no pretense that Remote Procedures are being called, or Object Models are being shared; I send you some bits and some metadata about them, and you respond with the same. It turns out that in the HTTP universe, at that point our conversation is over, and that turns out to be a good basis for building applications, but the key thing is putting the messages, rather than what they allegedly stand for, at the center

That's great - the message is the center - now REST just needs message level security model and mechanisms like WS-Security. SSL is what is usually bandied about as a security model by Restafarians, but we know from Deutsch, Gosling, and Joy that "the network is secure" is the fourth fallacy of distributed computing.

Two States

James Clark, Technical Lead of the original XML Working Group, neatly summarizes why defense in depth is mandatory not optional in Web services, be they Rest, SOAP, whatever:

XML is fundamentally not OO: XML is all about separating data from processing, whereas OO is all about combining data and processing. Functional programming is a much better fit for XML: the problem is making it usable by the average programmer, for whom the functional programming mindset is very foreign.

The lack of tooling for secure coding is a real problem, the WS-Security people are ahead here for sure, but there is a lot that needs to be done in all camps. Bottom line: We need a defense in depth security model that composes elements of both the security of the processing state (service security if you will) and the data itself (for example message level security), or as some great American Poets called Pavement put it:

two states
we want two states
north and south
two, two states
forty million daggers ...
two states
we want two states
there's no culture
there's no spies
forty million daggers ...

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

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).

Question of Risk

Eric Newcomer, as is his wont, gets right to the heart of the issue in WS-* vs. REST is not the question.

The big question isn't whether WS-* is too complex, or REST is better. The question is "for what?" In the context of this workshop, the "what" is enterprise software standardization.

My context in looking at these technologies is security. Security is generally practiced as a subset of overall risk management. The risks are comprised of threats and vulnerabilities against some set of assets. In security architecture, countermeasures are selectively deployed to deal with the threats and vulnerabilites. This is very subjective terrain. The problem I have with the way REST security is generally described is that SSL and firewalls were good enough in 1995 so they are good enough now (certainly not all RESTians say this, but a very high percentage do), and the problem I have is when a REST programmer makes these tradeoffs and decides "heck, I don't need message level security", they are making that tradeoff on someone else's behalf, specifically their identity credentials. At what point does developer productivity intersect with responsibility and due care of users identity credentials?

Here is an example of Tim Bray comparing PHP, Rails, and Java frameworks for web application building. The comparison criteria are Scaling, Dev Speed, Dev Tools, and Maintainability. We are talking web apps and security is not even a first class member yet two classes of developers' concerns are. I am not picking on Tim Bray, this is just a good example of how many development organizations prioritize - what is easiest/best for me, not what is protects my user's assets/identity/data the best. I absolutely think dev tools and speed are important and should be first class members in an evaluation, I am just arguing for security to be there too especially for web apps.And there are real differentiators in security between these two. But it all starts with developers looking not just inward but also outward and protecting their users. The young identity himself, Andre Durand, noted:

• When GM was recently asked, "...are you worried about losing the #1 spot as the worlds largest car manufacturer?" the answer was, "...we're very concerned about maintaining our #1 position as the largest manufacturer of cars."
• When the same question was asked of Toyota, "...are you focused on becoming the #1 car manufacturer in the world," the response was, "we're concerned quality is slipping."

Part of the quality that developers need to consider is not whether or not cars are easier or harder to build if they do or don't have airbags; but rather under what conditions do you want your car to have air bags, ABS, and so on, and then what frameworks has the best airbags and ABS support.

The Impossible Becomes Real: REST "security" understanding reaches new lows

This is genuinely amusing, Pete Lacey tells us that we have all been missing the boat on message level security, it turns out that we security people were just whiners, we already had what we needed with SSL and Kerberos!

To try and put a positive spin on the WSF, one can look on it as the XML-ification of a number of existing technologies. For instance:

Standard/Spec	maps to
WS-Security	SSL (partly)
WS-SecureConversation	SSL (the rest)
WS-Trust	Kerberos

I have to admit I had a brief flicker of hope when I saw Pete's "partly" after SSL, but that hope was shattered when I saw that "the rest" is covered by SSL's ample "ability" to manage the same use cases as WS-SecureConversation!

One last time: WS-Security is message level security, SSL is transport level. There is a vast ocean of space between where enterprises terminate SSL and where your app is. Go ahead and ask your infrastructure team where SSL is terminated.

Dan Pritchett commented on a previous post on REST's lack of message level security:

Great post. The separation of SSL from security of the message is a concept that is often lost on SOAP developers as well. The need to move to more intelligent routers to handle a variety of QoS tasks is pushing SSL termination further from the application server. Assuming that your SSL connection is getting anywhere near your application is a fallacy.

No question that many (approx. 72%) SOAP developers miss this distinction as well. But the point is that SSL in no way provides what WS-Security does, which is end to end not point to point security, or more specificallly end to end message level confidentiality and integrity. "Hey did my "SSL-protected" message get altered after SSL was terminated?" Good question, boss, I have no idea.

Now there are actually some analogs to how SSL and WS-SecureConversation behave, but again one works at the message level and one doesn't. Oh, and WS-SecureConversation supports a wide variety of token types like SAML, X.509, and Kerberos.

Which brings us to WS-Trust and Kerberos. Sorry but this is just laughable. WS-Trust lets you deal with multiple token types one of which is Kerberos, and Kerberos is fine and all (and yes there are analogs to the WS-Trust behaviors and Kerberos TGTs), but what about domains whose access control depends on X.509, legacy username/passwords (cough, cough mainframe), or SAML? The whole purpose of WS-Trust is that we live in an heterogeneous world, and need to mesh together multiple token types for a given transaction -- in an integrated enterprise any one single token type is not going to be sufficient to traverse all the domains.

There are a lot of really smart people in the REST camp, and a lot of good ideas, but 1995 security models aren't good enough any more than muskets are sufficient for the USMC. The big ask on the REST side is for simplicity. Fine. But let's find simple ways to do message level security in REST not SSL and a prayer.

According to the Viridian Principles 1.0

"Eat What You Kill"

It's perfectly acceptable to supersede some time-honored tool or practice. However, you should take pains to fully comprehend the thing you have rendered obsolescent. You are removing some part, however modest, of the infrastructure of civilization. You are destroying the work of previous designers; you should offer them the respect you yourself would hope for, under similar circumstances. This is for your own good. You can't comprehend your own accomplishment until you have fully internalized and understood the accomplishment that you are undoing.

Of all the Web 1.0 technologies, Web 1.0 security (aka firewalls and SSL) is the least suited to a Web 2.0 world.