The implication of these techniques is that bolt-on security controls like WAFs can be evaded using obfuscation techniques. Similarly, simple-minded input validation can also be bypassed.

You can get a copy of the book at Amazon. I highly recommend this book for software security practioners and developers.

Remember to click on the link to tell the publisher that I want the book on my Kindle.

The implication of this book (IMO) is that simple input validation is a less compelling mitigation as the sole control for malicious input. So, WAFs and regex-based input validation frameworks are going to need to either become much smarter (unlikely) or adding output encoding is going to be required.

The “Cloud Computing Roundtable” hits this “lawyering” topic pretty well. As long as you read the discussion with the “these guys mostly represent the perspective of service providers,” you’ll get good understanding of the macro issues involved: lack of technological sophistication of regulations, cross-border/jurisdiction regulation, and standards are still evolving to catch up. These are my macro takeaways. One perspective that I have had and was glad to have “confirmed” was Eric Grosse’s comment on the insider threat, “We [Google] have zero tolerance for the insiders abusing that trust…”. I’ve felt that for a XaaS vendor, they have a lot riding on protecting against the insider threat in their data centers.

Mom wanted me to be a lawyer, but I became an engineer, so I’m more interested in some of the more technical aspects that we not talked about. These interests have been keeping me too busy to write about them. But here are some of the perspectives that are a bit more technical in nature. Each probably deserves a longer discussion. I guess that should be my first 2011 resolution.

1. Cloud Security is more than worrying about your XaaS platform. See points 2 and 4. Many times Cloud = AWS and it’s the mere mention of AWS that sends chills up and down peoples’ spines.
2. Application architectures are using Cloud as a component in an overall solution.
1. The security problems from other parts of the application are often just as bad (if not worse) the ones in the Cloud components.
2. The potential problems of “finger pointing” between the multiple organizations scares me more than the technical vulnerabilities.
3. The application architectures are starting to be Cloud+Mobile and not Cloud and/or Mobile.
4. The integration of “Security from Cloud” (SaaS security services) creates new security challenges – they are not “plug and play” for their traditional counterparts in all cases. One example is that cloud-based intermediaries necessitate the need to implement WS-SecureConversation rather than just WS-Security alone.

The history lesson here is that around the time that database management systems were becoming commercialized (1980s) there were products called data dictionaries or data repositories. The idea was that metadata should be kept outside of the DBMS and shared by all of the application code. In the data dictionary nirvana, there would be ONE definition of EmployeeID for the entire enterprise and all applications and database would share this one definition.

Fast forward to 2010. Where are these products today? Just about every client I walk into has a commercial DBMS (Oracle, Microsoft or IBM), but nowhere do we encounter data dictionaries. Why? Because they never got deployed. What enterprises found out is that no one could agree on what an EmployeeID (or any other piece of data) looked like. Sometime it was politics; sometimes it was acquisitions; sometimes it was I18n. Whatever the reason, the bottom line is the same – there are precious few common data definitions in any enterprise.

So, how in the world does one expect to do input validation against data when there are only a precious few data definition that accurately describe data? This seems like a path that will only lead to the same quagmire that data dictionaries fell into.

For the curious, the regex for email addresses is:

(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|”(?:[x01-x08x0bx0cx0e-x1fx21x23-x5bx5d-x7f]|\[x01-x09x0bx0cx0e-x7f])*”)@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?).){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[x01-x08x0bx0cx0e-x1fx21-x5ax53-x7f]|\[x01-x09x0bx0cx0e-x7f])+)])

(from http://www.regular-expressions.info/email.html)

Thanks to David Lindsay for the reference.

Cloud Security: Don’t Be Late to the Party

Cloud computing is here to stay. No amount of security whining will stop the cloud, and yet as the cloud revolution sweeps IT it behooves us to pay close attention to security and privacy concerns. If, as everyone says, security is a process and not a thing, what processes and procedures do we need to put in place to secure cloud computing? How do you build security in to something that you don’t entirely control? These and other important questions are the focus of this talk. I will discuss: how cloud computing changes the nature of software design and development, the cloud security threat-scape, different flavors of cloud implementation and their security ramifications. Whether your organization is just kicking the tires or moving into more serious pilot projects, it’s never too early to begin addressing the changes cloud computing will impose. I will discuss what can be done today in terms of both technical and contractual mechanisms.

At RSA, the Cloud Security Alliance announced the Trust Cloud Initiative (TCI). The purpose of the TCI is to take the CSA guidance a couple of steps forward in defining trust by defining both a reference architecture as well as a way to certify cloud services.

There are three sub-groups working on the distinct areas of trust we believe are needed:

• Architecture – definition of the required security controls as well as the relationships, constraints and patterns of usage
• Certification – ways of discovering the security controls provided by particular cloud computing environment and measuring their ongoing usage
• Reference Implementation – working prototypes and demos of the architecture to prove out the architecture

More information the TCI can be found on the CSA website.

Anyone interested in volunteering their time to work in one of the subgroups can contact me and I’ll help you get hooked into TCI effort.

HIPAA and PCI protect the consumer, but who/what is protecting the business that must comply?

I was thinking about all of the audit controls that get put in place to comply with these regulations. The controls are generating data that is going to be used to in one of these lawsuits someday. How is this going to look to a judge?

I suspect that there are fair number of judges that can figure out that any digital asset can be tampered with. Today, they can look at the people in an organization that have access to the data to determine the validity of the data. That may pass muster with today’s judges, but what happens when judges (in their youth) have doctored photos in Photoshop? Will such judges be willing accept that people working for a company didn’t tamper with the digital asset? Somehow, I don’t think Log4J is going to cut it.

And what happens when we factor in all of this cloud computing stuff? Where’s the chain of custody then?

At some point, the audit logs from IT are going to be presented as evidence and some judge is point out that there is reason to doubt their authenticity. At that point, I suspect that corporate attorneys are going to want to focus on meeting the letter of the regulation and also ensure that all of the work done to comply is admissible in a court of law.

Regulatory compliance, such as HIPAA and PCI, are strong business drivers for improving software security for many of our clients. The focus for most groups is to meet some audit deadline. Getting passed the auditors to ensure compliance is the first hurdle, providing audit logs that can pass legal muster can’t be far off.

You can reply the webcast and get copies of the slides here.

The jist of the presentation is that SOA Security often gets equated to WS-Security (or perhaps devolves into WS-Security). The problem with WS-Security is that it’s often applied at the wrong level, so there needs to be a better architectural approach to addressing security within an SOA. By combining SDL, ARA and SAE, we’ve found that it’s possible to look at a layered approach to security based on trust zones and SOA governance tooling.

I’ve been continuing to work on documenting the details of the SDL, ARA and SAE integration with John Butler from Everware-CBDI. We’ll be doing something more formal when we have something that can be published.

If you’re consuming a SaaS, it would seem like the service will support N protocols and you can either support one of those N. It seems like the big SaaS vendors will have some set of standards in place and it will take a couple of big customers to get them to expand that set. What’s it going to take for Force.com to implement something other than SAML?

For PaaS and SaaS, your organization is in control of the application, so you can handle authentication by whatever scheme you choose. If you’re working with some business partners, then you implement whatever protocol you both can agree to.

The protocols/mechanisms so far is only for user authentication. What would be helpful is if there were some way to enable authentication to include the cloud service itself. Cloud services all require some form of account information to do anything. If it’s a service like Amazon, there are also the private keys that have to be maintained, managed and passed to just gain access to the infrastructure. What all of the different delivery models have in common is the problem of authenticating to the cloud service. Is this a problem for identity management or just a (not so) simple credential management problem?

So, the question is not which one protocol wins, but which ones lose since you can only hurt yourself by implementing something that dies off. Then you can turn your attention to the problem of securing the authentication to the cloud service itself.

Some of the difference in these two reports has to do with hype versus reality. I recall in “the naughts” that SOA was touted as a way for IT to bring business agility. Then all of the vendors got on the SOA band-wagon. Now it seems like Cloud has taken up where SOA left off in terms of hype. On the reality side, I wish I could tell whether the lag is because of people’s increased awareness of security (the optimist) or whether it’s a reflection of the sorry state of storage implementations (the pessimist).