1 Raindrop

STS - Necessary Cloud Condition

Here is a concrete example of capabilities in Web services that explain why the cloud != mainframe or client/server. In the cloud we expect to need different identity tokens and protocols whether its SAML (and several versions of this), oauth, Information Cards, Kerberos, and many other ways that identity is conveyed. To get interoperability, a security token server (STS) is used to exchange tokens and cross domains. Because by definition there are so many players and relationships in the cloud, a STS is simply a requirement to transact identity across these domains.

Cloud is New, Infosec Isn't

Where to start with this?

"Cloud computing isn't anything new, its the old client/server model. You log into a computer that's elsewhere. And over the course of computing this has gone back and forth, computers have been in data centers, they've come out of data centers...now they are going back in again. These are remote data centers that are owned by someone else, but there's not a lot of new here...you have to trust your vendors, and if they don't build their applications securely, you're screwed. So its less a matter of where the data is or where the computer is, but do you trust the people you are buying hardware, software or services from - that's the real issue and that hasn't changed." 
-Bruce Schneier, RSA 2009

Now, as glad as I am that we got a shout out for the importance of app security, and I basically agree with the last sentence, there are many things wrong with the cloud = mainframe statement. If that was the case we would just install "RACF for the Cloud" and call it a day. But that's pretty clearly not going to work.

To begin with, this shows the utter disconnect between Infosec and the rest of the world. I mean The Economist knows that the cloud is different if you are in infosec, ostensibly rolling up to IT shouldn't you know this as well? The reason the Infosec Design Debt Clock is still ticking is that we continue to hear that things are the same and we can use the same oll same ol to "protect".

The real issues are much subtler, the reason I said that Infosec people should spend less time reading Bruce Schneier and start reading Martin Fowler, is that there is plenty of new stuff in software, there is next to nothing new in infosec.

The middle column in the above chart is where Infosec needs to focus not broad brush" Cloud=Mainframe, let's buy some more firewalls and SSL, drinks are on me!" We have two working security mechanisms - 1) access control containers and 2) crypto. Your choices are effectively:

1. Use one of these

2. Use both of these 

3. Use neither of these

Everything else is an integration problem - where do you want to locate the controls, how does the container relate to the system, and so on. So Infosec engineering is really not about security at all, its about integration. It goes without saying you can't integrate when you think the Cloud is a mainframe. The fact that the "data is elsewhere" is interesting but its not the main thing about the cloud, its that we have new relationships across process and technical boundaries. So for example we need to focus on things like federation standards to convey information securely across these boundaries, these are things that are totally foreign to mainframe. 

Security is a service. Infosec's job is to understand that which they are protecting better be it SOA, Web 2.0 or Clouds, and then to build security services that can be virtualized (coverage), interoperate (control) and resuse (cost). 

Metricon 4.0 - The Importance of Context

The CFP for Metricon 4.0 says you have about a month to get your submission in if you want to present. As usual, Metricon 4.0 is co-located with Usenix Security, this time in Montreal, eh?

MetriCon 4.0 is intended as a forum for lively, practical discussion in the area of security metrics. 
It is a forum for quantifiable approaches and results to problems afflicting information security 
today, with a bias towards practical, specific approaches that demonstrate the value of security 
metrics with respect to a security-related goal. 

One thing I do when designing security services is to try and think when I am designing say authZ - how would I measure the success and/or failure of this service? Its not always possible but the discipline of looking at the service objectively has proved a useful exercise. For more info on how to participate in Meitrco check the CFP. 

Web Services Security at OWASP Twin Cities

Speaking tomorrow (Monday 4/27) at OWASP Twin Cities

What do Web apps, Web 2.0, Cloud Computing, SOA, and Rest all have in common? They all use Web services for functionality, data access and integration. Unfortunately, by default Web services also lack a security model. The OWASP Top Ten Web Services goes into the technical details of the vulnerabilities, remediations, and examples of common Web services security issues like authentication and authorization flaws, how sensitive data is disclosed, and why security standards like WS-Security and SAML can be your best friend or your worst nightmare.

RSA Recap - Do Less and Do It Better

Back to work today, but seeing lots of folks IRL yesterday was fun. Panel with Hoff and Mogull was a great discussion, not the same old same old, but lots of thoughtful stuff from those two and the Jericho Forum audience as well. One point I made about the infosec industry in general was around governance, in reading Barnett's  Great Powers book was his exploration of governance from Fukuyama. You can measure governance by the scope of the efforts (how much visibility/reach do you have) and the strength of the efforts (how effective). 

An anti-pattern is a 5th world tinpot dictator where you have tons of scope (hands in everything from garbage pickup to police to retail) but you have very weak institutional strength (garbage pickup is unreliable, the cops are corrupt, retail is micromanaged). It struck me immediately that is a common F500 infosec anti-pattern, the security architecture of many companies consists mainly of a list of products - "yeah, we've got an IDM, Access Mgr, UTM, GRC, ..." but yet when you ask 

"how many directories do you have?"

"we don't know?"

"ok, how many do you know about?"

"35"

"how many are served by IDM?"

"3"

and so on through the list of many of the products. Like I have said previously, Infosec needs to spend much less time in infosec echo chambers and more time learning to integrate what they already have. In a nutshell making the solutions strong and effective. Do better by doing less.

When your hand is in everyone's pie, and you frighten them into thinking they can't deliver on the projects they are tasked with and yet your own solutions are weak, its hard to avoid the tinpot dictator appearance. It erodes trust with your stakeholders who are building apps, maintaining databases, optimizing business processes and so on, when you hold them to an unreasonably high standard like your 129 page infosec policy, and yet your own solutions don't deliver reliably. You will also need to be able to work with these same people to integrate your solutions, do security in SDLC and a whole host of everything. 

So I am arguing for less of the "we have a product in every checkbox category" school of architecture and more for let's look at what we have maximize its utility and integration. Read my lips - no new products.

Don't forget to mention that cyberwarfare was first explained by Sun Tzu

Just in time for RSA and Budget season here is 10 easy steps to writing the scariest cyberwar article ever. Catchy title, begin story in Estonia, copious Chinese hacker references, and so on. Great piece.

Jericho Forum Panel @ RSA

Doing a panel at Jericho Forum tomorrow with Hoff and Mogull, should be a hoot. Or as the invite says "miss the event at your peril" (typical security-speak lead with the threats ;-P).

Imagine if you will...

IBM claims that Websphere has 35% market share. Let's assume you are one of the 2 million Websphere developers in the world, and you want to build some Web services to connect up your apps and data. Since you probably didn't take any secure coding training, where do you go to learn about how to secure your spanking new Websphere 6.1 Web service? Why the IBM Redbook of course. In there, here are some things you will find (emphasis added):

In the username token profile, the digest of the password is specified as a password type, but the password digest is not supported in WebSphere Application Server 6.1. Only the clear-text password can be inserted in a username token and should not be transferred over a non-secure network. Basic authentication should be used over the secure network, such as HTTPS or  intranet, or encryption should be applied to hide the user information. 

Clear-text password over the wire in the message - say it ain't so! One of the exercises we do in training is to examine 8 different SOAP messages with various security properties. We start with no security, just vanilla SOAP, then we do Username token with password hash, then Username token with cleartext password, then message encryption, and so on. The trend is that each message is stronger than the last but there is a trick the third message username token with cleartext password is less secure than the previous one Username token with password hash and arguably less secure than the first one vanilla SOAP with no token at all. 

let's look at the XML

Example 1. vanilla SOAP

<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<param0>Hello world</param0>

...

Example 2.  SOAP + WS-Security Username token password hash

<?xml version='1.0' encoding='UTF-8'?>
   <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
      <soapenv:Header>
         <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="1">
            <wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="Timestamp-8533528">
               <wsu:Created>2008-03-18T19:01:21.710Z</wsu:Created>
               <wsu:Expires>2008-03-18T19:06:21.710Z</wsu:Expires>
            </wsu:Timestamp>
            <wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="UsernameToken-3692614">
               <wsse:Username>bob</wsse:Username>
               <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">E9rKWg/JSBzmaQufwyf0BRjcu3w=</wsse:Password>
               <wsse:Nonce>hpfLxX/d+VxD0qxfyX2uIA==</wsse:Nonce>
               <wsu:Created>2008-03-18T19:01:21.705Z</wsu:Created>
            </wsse:UsernameToken>
         </wsse:Security>
      </soapenv:Header>
      <soapenv:Body>

...

Example 3. SOAP + WS-Security USername token with cleartext password

<?xml version='1.0' encoding='UTF-8'?>
   <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
      <soapenv:Header>
         <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="1">
            <wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="UsernameToken-15828664">
               <wsse:Username>bob</wsse:Username>
               <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">bobpassword</wsse:Password>
            </wsse:UsernameToken>
         </wsse:Security>
      </soapenv:Header>
      <soapenv:Body>

...

In example 1, we have a payload but really no way to offer AAA services, in example 2, we have a shot at authN, in example 3 we pass the password in cleartext, in effect shipping the dynamite and detonator in the same truck! Now we are not only vulnerable to replay attacks as in the previous 2, but have introduced a spoofing risk for anyone who can read the message to impersonate the service identity that was used throughout the system and at best we gain a very weak authN method username/password. That's why in my view its worse than example 1, vanilla SOAP doesn't give you much for AAA but at least its not adding huge identity risks in your system through non-protection of both the credential and the secret!

But the Websphere story doesn't stop there.

As described in “Authentication” on page596, identity assertion (IDAssertion) is available in WebSphere Application Server 6.1. In a secure environment, such as an intranet or SSL, it is useful to only send the client (caller) identity without credentials (such as password) together with other trusted credentials (such as the intermediary server identity). 

Inranet and SSL - Ladies and Gentlemen - your 2009 Security Architecture! I really don't want to bash IBM, and in fairness WAS supports X.509 and other strong standards if you are serious, no question that in certain areas they have done excellent work, but come on people this 2009, this kind of guidance has got to stop.

Hacking things together to work is fine and all, developers have been doing it forever, but let's not do it under the rubric of "security" and oh while we are at it, let's revisit our risk assumptions about tokens, identity, SSL and the "intranet" (which seems a whole lot more like the Internet to me these days). Misuse of Web services security standards was precisely the focus of the talk Brian Chess and I gave at RSA last year.  

Evolution of Access Control Models

HP Labs has published a joint paper - From ABAC to ZBAC: Evolution of Access Control Models

Controlling access to resources and services is fundamental to security.  A variety of access 
control models have been developed over the years, each designed to address different aspects of 
the problem.  This report will examine the strengths and weaknesses of the various approaches as 
applied in a cross domain services and as implemented in common SOA frameworks.  Please 
note, the access control mechanisms are discussed in this context and the comments are not 
general critiques of the advantages and disadvantages of the various systems. Our primary use 
case comes from an example investigated by the US Navy, which is examined for illustrative 
purposes since it is easy to understand (For more additional applicability please refer to the 
Department of Defense and Intelligence Community Service-Oriented Architecture Security 
Reference Architecture, Version 1.0 and the discussion of hierarchical policy enforcement 
frameworks and the section 4.2 Advanced SOAP Interaction Patterns).  That discussion also 
extends the enclosed use case slightly to address issues it doesn’t cover.    Recognizing those 
issues led to the development of an access control model that uses authorizations presented with 
the request to make an access decision, an approach we call authoriZation Based Access Control 
(ZBAC). This paper is intended to stimulate a structured technical dialogue within the IA&A 
community on potential alternative enterprise approaches and possible security risks with current 
approaches.  The KEY implementation details are in the appendices, so be sure to read them too! 

I commented on an earlier draft of this paper- there are a lot of ideas for people building out SOA, Rest, and Cloud applications. One thing about this work is that it factors in some of the knock on effects of managing the security policy enforcement points and policy decision points.

Pittsburgh Trip and a new talk

Heading out to CMU where I begin work as a Visiting Scientist. Giving tal k on cloud security (what else?). Looking forward to seeing Howard Lipson at CERT. We wrote several papers together for DHS Build Security In projects The cloud talk will be on how to keep your head in the cloud and your feet on the ground.