1 Raindrop

Vordel FTW!

I think security is about the only area of computing where the east coast has an advantage over the west coast, and if you keep going east from the eastern seaboard you wind up in Ireland, home of Web services company Vordel. I have used their tool Soapbox many times over the years and always recommend it to clients, it has many uses, and now its free!

Soapbox is essentially a tool that builds Web services clients, takes in message (e.g. XML) and the URL you are calling which is similar to Soapui and a number of other tools like curl, but Soapbox does several security-related things that make it very valuable.

First thing is that Soapbox supports a variety keystores, so you can use Openssl or your favorite tool to set up the keys, keystores and certs that you need. Then you can take a vanilla soap message

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<tns:Cities xmlns:tns="http://euro2008.dataaccess.eu" />
</soap:Body>
</soap:Envelope>

and add a signature and timestamp to it for authentication purposes

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
  <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
    <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Id="Id-0000012282ebfbbb-00000000002eb6e9-4"><dsig:SignedInfo><dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><dsig:Reference URI="#Id-0000012282ebfbbb-00000000002eb6e9-3"><dsig:Transforms><dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><dsig:DigestValue>bAfOw4sLP/PD/Fe/5VRkrJXnZiI=</dsig:DigestValue></dsig:Reference></dsig:SignedInfo><dsig:SignatureValue>N0VLGWgJDad52fvH7A3saVGc9rusFZlpAedEHh5HVGOnyEPAQy5+HD8OkvxTku+y
Og+M+P8ZY3OeTIZkNhoNzrVoRb1riPSr9znFRXFMImpTInOAncoEmcPtjs4XJ5vp
+e8gw5lr5gsvmcTafvUMfG+HDuyp+ZF8EFdm90bdeZ/2GIZ0WXqzL5yVQAhHlRiH
SLwcY5p5NmQvjimdMTMcPgc5ETfDAa1yKE/2hyFqn26fU6g/c5XYkp4xHULUIVP2
WZQlfkuHiGFSNCrVw68H/QTSOSl/s0lebWC3q+kCuTecQSml+hFbM4cZjvIVKUZJ
f1RUUsg1NGvtpHebx9/YQA==</dsig:SignatureValue><dsig:KeyInfo Id="Id-0000012282ebfbbb-00000000002eb6e9-5"><dsig:X509Data><dsig:X509Certificate>MIIC0TCCAbmgAwIBAgIGARqbOHiZMA0GCSqGSIb3DQEBBQUAMBgxFjAUBgNVBAMTDVNPQVBCb3hDb25maWcwHhcNMDgwNjE4MTAyODAwWhcNMTEwNjE4MTAyODAwWjAYMRYwFAYDVQQDEw1TT0FQQm94Q29uZmlnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApLw4QAWqVmEr+CEo8Fp8WPq9Oo7BdnNOtMT5sUp0IN4NVvKmdI8ju3HsbnXzI7csNDzK6Feo19J/XLZk/Lr3Q4bLmmD+bMLFljiIgQ89+Bwc3mtyT1Rr4WBQUKnF8+8y65m2RebySelzgWIeZM72JoThSw85VBtyHvjlQnTAnfwX0NV7mH+kbQDi0c4Q4UZhKWFfb5L2tbjcknsG0k4De07qIw+RsGipkuNoFyI6BwwC0IERv48sacL30nWAOZMNDkm4S61aAYuzfMZySzPseU6BUdIdYAnITgj4tHRJZ93OYnn6LObEkYxobyGi6SULtBQQYzHKgeeyvru2Z1L7nQIDAQABoyEwHzAdBgNVHQ4EFgQUjq3/y0NF+tlUqwLc8SP4uV4/PK4wDQYJKoZIhvcNAQEFBQADggEBABAkqI4elXT/+1RfJOavOy2sAtnr1XiLp1HYtkJV4BMmoouExG+jiEg9MU18dF3302JvbGk+nVw8g/80Tlx5jpWlU6UwVmuc4RZaWjj+NkUncniaWVdcCmgIsLfeIWrK6bWfQaylpj9t8Vl7q4ocrMg7R8tPizlliIfD+hH3aUVkTgvXsb9GTPYYAfLgHQYimDyXm5w1qqWv7Id7nZfzplP1N+cBbxEMT4SQ4QS72cnShDo+fz+pcjxF81VaYe4ag9DyHrMH1PKDsxO7kEGz9fAFQRfTw50ksnNrVqefAOBCRdvL1s/Awwpt1DPk44jtvY4NZRF2NsbAyLswPyntpAY=</dsig:X509Certificate></dsig:X509Data></dsig:KeyInfo></dsig:Signature><wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="Id-0000012282ebfbbb-00000000002eb6e9-2"><wsu:Created>2009-07-16T09:36:59Z</wsu:Created></wsu:Timestamp>
  </wsse:Security>
  </soap:Header>

or perhaps you are more worried about confidentiality, taking the same vanilla soap message you can use XML encryption in Soapbox to generate

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
  <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
    <enc:EncryptedKey xmlns:enc="http://www.w3.org/2001/04/xmlenc#" Id="Id-0000012282eedda3-00000000002eb6e9-12"><enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/><dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Id="Id-0000012282eedda3-00000000002eb6e9-13"><dsig:X509Data><dsig:X509Certificate>MIIC0TCCAbmgAwIBAgIGARqbOHiZMA0GCSqGSIb3DQEBBQUAMBgxFjAUBgNVBAMTDVNPQVBCb3hDb25maWcwHhcNMDgwNjE4MTAyODAwWhcNMTEwNjE4MTAyODAwWjAYMRYwFAYDVQQDEw1TT0FQQm94Q29uZmlnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApLw4QAWqVmEr+CEo8Fp8WPq9Oo7BdnNOtMT5sUp0IN4NVvKmdI8ju3HsbnXzI7csNDzK6Feo19J/XLZk/Lr3Q4bLmmD+bMLFljiIgQ89+Bwc3mtyT1Rr4WBQUKnF8+8y65m2RebySelzgWIeZM72JoThSw85VBtyHvjlQnTAnfwX0NV7mH+kbQDi0c4Q4UZhKWFfb5L2tbjcknsG0k4De07qIw+RsGipkuNoFyI6BwwC0IERv48sacL30nWAOZMNDkm4S61aAYuzfMZySzPseU6BUdIdYAnITgj4tHRJZ93OYnn6LObEkYxobyGi6SULtBQQYzHKgeeyvru2Z1L7nQIDAQABoyEwHzAdBgNVHQ4EFgQUjq3/y0NF+tlUqwLc8SP4uV4/PK4wDQYJKoZIhvcNAQEFBQADggEBABAkqI4elXT/+1RfJOavOy2sAtnr1XiLp1HYtkJV4BMmoouExG+jiEg9MU18dF3302JvbGk+nVw8g/80Tlx5jpWlU6UwVmuc4RZaWjj+NkUncniaWVdcCmgIsLfeIWrK6bWfQaylpj9t8Vl7q4ocrMg7R8tPizlliIfD+hH3aUVkTgvXsb9GTPYYAfLgHQYimDyXm5w1qqWv7Id7nZfzplP1N+cBbxEMT4SQ4QS72cnShDo+fz+pcjxF81VaYe4ag9DyHrMH1PKDsxO7kEGz9fAFQRfTw50ksnNrVqefAOBCRdvL1s/Awwpt1DPk44jtvY4NZRF2NsbAyLswPyntpAY=</dsig:X509Certificate></dsig:X509Data></dsig:KeyInfo><enc:CipherData><enc:CipherValue>H2oySdBYPuYhoaWbVfuQzQWyZ9eMRylzGHF5LzWCSNrX90hBFjyzg3ufxUfAbRBS
pPdgCfd5edH63DFsiMnYBe4vY5010sLwvHP78M4uEZlA9tb8C2rXlvs7KJeUhhAa
XAXvexwD86UDk0ir6Gn0uhsvpbZndzVPuTSBhrB5kkaxuFyCnZZby1eZPuTOWWl3
/abt0fsGJjkB7xhkOEFDBwpU8VOBVX3NjEISiTX7MbKskNWNqI5vY7tAWqMqrB5g
kIxK8O8p+WjB4i9yQmMJiR63j3gKPXlgN0/wTtCDxe+AZwSv/jW2ORd0b+9w2Rq+
LqEZ0jcE33w5YrcmxgdsJQ==</enc:CipherValue></enc:CipherData><enc:ReferenceList><enc:DataReference URI="#Id-0000012282eedda3-00000000002eb6e9-11"/></enc:ReferenceList><enc:CarriedKeyName>Id-0000012282eedda3-00000000002eb6e9-10</enc:CarriedKeyName></enc:EncryptedKey>
  </wsse:Security>
  </soap:Header>
<soap:Body><enc:EncryptedData xmlns:enc="http://www.w3.org/2001/04/xmlenc#" Id="Id-0000012282eedda3-00000000002eb6e9-11" Type="http://www.w3.org/2001/04/xmlenc#Content" Encoding="UTF-8" MimeType="text/xml"><enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/><dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><wsse:SecurityTokenReference xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" wsu:Id="Id-0000012282eedda3-00000000002eb6e9-14"><wsse:Reference URI="#Id-0000012282eedda3-00000000002eb6e9-12" ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#EncryptedKey"/></wsse:SecurityTokenReference></dsig:KeyInfo><enc:CipherData><enc:CipherValue>7omm3jasigXF6qd0jlhivSq5wxW0hA1YORHNV386euQBeAO5gksbbBfBIKSHlYHJ
SbgU/gY28Snmh5JAPxpHSjzRfCTEjwJ5/C3j1iD0yN8=</enc:CipherValue></enc:CipherData></enc:EncryptedData></soap:Body>
</soap:Envelope>

<soap:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="Id-0000012282ebfbbb-00000000002eb6e9-3">
<tns:Cities xmlns:tns="http://euro2008.dataaccess.eu"/>
</soap:Body>
</soap:Envelope>

Soapbox can also be used for REST and other types of web services, if you are building or supporting web services its invaluable to have a testing tool that allows you to swap out different security mechanisms, encoding types, and data quickly and easily. It took about 2 minutes 30 seconds for me to generate the above from a standing start (including Eclipse start up time ;-P). Grab a copy of Soapbox and see what you think, I will blog more about some other features later.

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

Logging in the Age of Web Services

Here is the paper I co-wrote with Anton Chuvakin for IEEE Security & Privacy Journal. Among other things we look at the impact of the eventually consistent model's impact on our ability to record and review audit log events. We also use some of Anton's work on event logs and apply them to how to think about security events in Web services. Hopefully there are some ideas that you can apply to building an audit log system for your Web services.

It was a lot of fun to work with someone with thinks as strategically and futuristically as Anton.

SOA Security architecture at EBS Building Society

From CSO interview with David Yeates, IT Head for EBS Building Society on why they use Vordel for Web services & XML Security services (emphasis added):

Dive deeper into how you reached the conclusion that the security architecture was needed. 
Yeates: Service-oriented applications are fundamentally different from traditional monolithic applications. Web services are dynamic, they look up, discover and bind to each other at run time. This means that the internal network has also to be considered a dirty environment. A process-driven development creates dynamic applications where business processes can be easily created and changed. This presents major change management, service management and compliance challenges for an organization. Transactional security becomes very complex, very fast.

If you run a Java application you can rely on the java security model, if you run a J2EE application or .Net application you can rely on those application containers for security services. However, if you are doing Web services, then you have no container to rely on. You must use something else for security policy enforcement and security policy decision making, so the XML Gateway architecture really buys you two things. First, you get a measure of protection from the internal dirty environment, and second you get a place to enforce policies, which you otherwise lack. 

One of the best architects I worked with made the case and bought a XML Gateway as a runtime API. Meaning a way to leverage the simplified APIs for SAML and WS-Security, so his developers didn't need to write them themselves. In other words the cost of the XML Gateway hardware was much less than the developers time to write it. Not to mention the opportunity cost, because it would need to be his best developers to write security standards wrappers. So he got the APIs at 50 cents on the dollar and got the accelerated hardware runtime for free. 

By the way, the article discusses the XML Gateway in the context of an SOA security architecture, but the same thins apply to REST which is usually deployed without security.

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.  

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.

Mark O'Neill on PKI and SOA

+1 for Mark O'Neill on this post:

...SOA is Dead... reminds me of another Three letter Acronym which 
Was declared dead. Back then, eight years ago, it was PKI which was declared dead. There are similarities with SOA. In the case of PKI, there was a tendency towards what in France are called "grands projects", ie large complex deployments. The "full blown PKI", with its CA, RA, hardware stores, etc etc, was a classic example of this. Banks and governments were seduced by this, and often built out architecture for the sake of architecture. What was missing from PKI? The focussed applications. It is hard not to see the analogy with SOA "grands projects", complete with UDDI, etc.

In the meantime while PKI was being declared dead, VeriSign had created their own PKI in the "cloud", (which they never called a PKI). Savvy organizations started to focus on the applications (chiefly SSL) and outsourced the PKI itself to the Cloud (VeriSign) to deal with key issuance, certificate expiry management, etc. VeriSign did very well out of this. While "PKI" became a dirty word, VeriSign prospered with a cloud PKI. Who is the VeriSign in the SOA analogy? Amazon. Without ever calling their services, or indeed their services hosting platform, an "SOA", they have build the successful SOA in the cloud.

And what is the equivalent of SSL, ie the simple and useful application of the techhology? The answer this time is REST, SaaS, and the direct EDI-style XML messaging which we have seen many Vordel customers successfully use. 

By the way, whatever about SOA, I don't agree that SOAP (and the many WS-* technologies) is dead. *building it from scratch* is dead, but any glance under the hood of Microsoft .NET shows it is very much alive and is becoming more and more a core part of Windows (just as Microsoft build PKI into Windows server products quite successfully and quietly). And it is not a case or "either / or" SOAP or REST: XML Gateways (such as Vordel's) do a very successful job of mediating between the two.

We know Microsoft is light years ahead of the Java community on security, I wonder when we will see the Java folks at Sun and IBM catch up to where Microsoft is now on message level security?

Like PKI, the "grands projects" approach to SOA is dead. But that opens up the opportunity for focussed applications, for cloud providers, and for XML Gateways which, through protocol mediation, make the "SOAP vs REST" debate moot.

Heck, Mark I don't care for grand projects either, I am a bottom up guy 98% of the time, I am not picky and would be happy with people put in authN and authZ whichever service style they choose. 

I guess the thing I come back to is that people built out web apps for 5 or more years before people finally started thinking about XSS, SQL Injection and stuff, so we are on about 5 or 6 years of people building Web services, maybe soon the herd (outside of Redmond) will start figure out where the vulns are at?

SOA Security in Real Life

I started off my last article on SOA Security this way:

When I park my car in the garage, I lock it. Why? Well, although I would hate for someone to steal my snow shovel and hockey sticks, my car is much more valuable to me. Security is about managing risk, specifically protecting valuable assets like my car. I have a higher level of protection on my car than on my garage. In dollar terms, the contents of my garage are orders of magnitude less valuable than my car. I could spend a lot of money fortifying my garage, and that would add some security to my car while it is parked there, but it is not a cost-effective investment. First, my car is the asset of value, and second the garage - no matter how well protected it is - doesn't move. 

Car manufacturers know this, insurance companies know this, consumers know this. Even media publishers know, yet in the common enterprise, programmers and architects seem to roam in ignorance. Your average download of a Michael Bolton song carries a far higher level of security than valuable user data, like passwords, social security numbers, and credit card details. Why do we keep protecting critical data with point-to-point security solutions (like SSL) that protect the transmission channel, but leave the valuable assets being transported wide open everywhere else? This is a critical question that needs to be answered in order to successfully add an effective layer of security to an SOA.

Well guess what happened last weekend? I always do lock my car in the garage, but last week I came home with an armful of holiday cheer and forgot. I went out to the garage over the weekend and noticed that a local knucklehead who could see that the car was unlocked tried to jimmy the lock on my garage door, and busted off a piece of wood before giving up (probably when they saw the sign that said the garage was monitored).

The response of the police actually further supports my assertion that security is about assets not threats. I called the police and said someone tried to jimmy my garage door. They said its a holiday weekend, call back on Monday and get a case number. This disturbed me not at all. All they are going to do is record a threat (or security event) metric anyway.

Now in a hypothetical scenario if my car was compromised it would have been a completely different response from both me and the police; why is it different urgency? Not because of the threat and intent which  were similar in both scenarios, but its the fact that the asset was put into motion that's what makes it important.

For infosec what do we learn? Infosec is spending waaayyyy too much time and money protecting garages and not enough protecting assets.

Web services talk at OWASP

The video from my OWASP AppSec Conference talk on OWASP Top Ten for  Web services  is online here.

OWASP is consistently the most interesting and practical security conference, its probably the closest thing we have to a true software security conference. Sure, we could use a few more builders, but I still think its the best we have right now.

It Was Sposed to Be So Eaaasy

Earlier this year, I gave a talk with on Breaking Web Services with Brian Chess at RSA. We pointed out that adding security into Web services is an exercise left to the implementer, the standards bodies and vendors give you some primitives, but it is still up to you to figure out all of the items on the Web services security checklist should work together in a cohesive system. Needless to say, there are many ways to shoot yourself in the foot.

So during our talk, someone from Oracle stands up and says, "hey, you guys are making this stuff sound hard. Its not hard we support WS-Security..." etc. Again, the whole point of our presentation was *not* that there are not very interesting general purpose security capabilities in Web services, our point was that you need to figure out the architecture yourself, and then bend the tools to your will. Oh, and deliver on time.

So imagine my surprise, when I read this article "Digitally Signing and Verifying Messages in Web Services" which talks about using Oracle's WSM tools to sign Web service messages and verify signatures in Web service messages, but only addresses integrity - absolutely nowt on authenticity! Integrity is important, but there are lots of times when it is not enough. Many times your service needs to be concerned with replay attacks, authentication policies and so on. To deal with those things, we would typically add policies and capabilities for timestamps, nonces and other primitives into the signature block, but the article is silent on those things. (Rad Mark O'Neill's post on this as well)

Its not about _can_ the standards do something or other, I mean given the right resources the standards can put a monkey on the moon, its about what use cases have they engineered in and what is supported in the tools today. I firmly believe SAML has such great adoption across the industry because they have a use case centric view and so gave the vendors something to engineer and optimize for. I think we'll still get there in WS-Security and other areas as well, but the use cases are not built into the spec (as with SAML) and so its taking longer.

One of our points in the talk was - we want you vendors to do your job better and instead of shipping a box Legos, ship a Lego gas station, a Lego airport, and so on. Connect some dots for your customers. 

What I see in training on this topic, is sort of the following - 1) Do I need Web service security? 2) Oh ok, well can I get by with SSL? 3) Oh wait that doesn't actually protect my assets, can I just use WS-Security? 4) Oh wait, WS-Security isn't just a checkbox for security, I need to figure out timestamps, nonces, signatures, encryption policies and so on. And finally 5) How do I accomplish this?

Once we get to step 5 then the real work can begin. Its not easy to get a lot of developers through all of this, and again this is before the real work begins. Even once the lead developers and architects figure this out, there is still the little matter of transitioning it to the rest of the team.

I remember I was working with an enterprise architect several years ago, and he bought a Web service XML gateway like Vordel to add WS-Security support into his Web services apps, but he didn't even buy it as a runtime tool, he bought it as Security API, the runtime enforcement in his opinion was a bonus! He said in effect, well I know I need to do this, but I can't expose all these security primitives directly to my developers.

So yeah, I wish it was easier, but in my experience its not right now. Its not about raw capabilities its about use case realization. I think learning from what has worked well is the way to go. SAML's use case centric approach is one that has.