A6 becomes Cloud Audit

Chris Hoff and the intrepid A6 working group (which I'm proud to say I get to participate in) have rebranded A6 to Cloud Audit. The working group will remain known as the A6 working group and will congregate on Google groups here.

Given the work that's happened to date inside the working group, I've retired the documents on scribd.

(as an aside I hope to start posting again in the next month or so)

The HitchHiker's Guide to Security Con's Networks

JJ over at Security Uncorked wrote a thoughtful piece on SecTor 2009's Wall of Shame. JJ's explanation of the whole issue and the technical details is well worth the read, but to summarize it's a common feature at security conferences with the purpose of demonstrating that password and other sensitive information transmitted in plaintext (not encrypted) can be easily intercepted.

The point of the Wall of Shame is that it's never safe to transmit sensitive information in the clear and really if you're a security professional you should know better.

I'll say that again, if you're a security professional you should know better.

So here are some suggested rules if you're at a security conference:

1. Don't use the wireless network
2. Always assume someone is intercepting traffic and displaying it on a big screen somewhere
3. Always assume that someone with less than noble intent is intercepting traffic
4. Always assume that some wannabe is sniffing traffic for some reason
5. Use a VPN, SSL or properly encrypted cellular network

To be fair though, if you've configured your software to transmit over an encrypted channel or assume that the traffic is encrypted, you might be in for a surprise as one of the conference organizers was when they learnt that there software did not work as expected.

My data centre is in your cloud, your cloud is in my data centre

Amazon announces VPC (EC2 instances on a private network) and this interesting article on ReadWrite about Zoho putting their SaaS offering behind the corporate firewall via vSphere (on what I assume is a VMWare).

Both solutions bring a piece of the cloud inside your environment and a first I was wondering if the connectivity or embedding increased security risks. I ran through the gamut of concerns such as:

• Unknown vulnerabilities hidden in the stack
• Immutable vulnerabilities in the solution that can't be patched
• Malware/Malmachines

However, all of these can be addressed using existing controls we already deploy in our corporate environments, case in point:

"...and to extend their existing management capabilities such as security services, firewalls, and intrusion detection systems to include their AWS resources."

So now I've got IPS, internal firewalls (you have those right) and network anti-X to monitor and contain anything these external assets could throw at me. These controls are also useful if I choose to expose my pieces of the cloud to the outside world.

In reality though, Zoho's solution is just software-in-a-virtual-box based on popular software normally found in the cloud; while Amazon's VPC is just collocation with a point-to-point VPN (IBM and CGI have offered this forever, so does my employer for that matter). Most businesses are already comfortable with both of the former, so if the biggest objection to going Cloud is around governance, then maybe this is the compromise answer. If the biggest concern is data location, then this provides a nice compromise as well (keep the database inside the corporation).

Note the key assumptions for EC2 VPC integrity are:

1. EC2 admins can't disengage the network isolation controls
2. The network isolations control are some orthogonal mechanism that cannot be directly accessed from any EC2 instances (either inside or outside the VPC zone)
3. The EC2 VPN endpoint is strictly bound to isolated network

I don't think these are unreasonable assumptions to make, not independently testable nor inviolable by any means but still reasonable.

XSRL Compliance drafted

Just finished draft 0.1 of the XSRL-compliance schema, a sub-namespace of XSRL (eXtensible Security Reporting Language).

The draft schema looks like this:

The draft XSD file is located on Box.net.

Auto-generated schema documentation is up on scribd.

XSRLCompliance_0.1

An updated version of XSRL-Policy has also been uploaded.

Starting XSRL

A brief announcement, I've temporarily paused documenting A6 to put together a draft set of XML schema for XSRL (eXtensible Security Reporting Language).

Draft 0.1 of the XSRL-Policy is the first release, to be followed by:

• XSRL-events - for reporting on events such as breaches or virus outbreaks

• XSRL-compliance - for reporting compliance with stated XSRL-Policy or external XSRL-Policy such as PCI-DSS (my lazy example)

• XSRL-state - for reporting on the security state of your environment, systems and applications - will leverage SCAP

The schema looks like this (some child elements not shown):

The draft XSD file is on box.net.

Auto-generated documentation is below on Scribd iPaper below.

XSRLPolicy_0.1

BTW Just got listed on AllTop

Cloud Security Pundits Pledge

Raise your EC2 key and repeat after me:

I, <insert twitter handle here>, do solemnly affirm that when tweeting, blogging or retweeting about cloud security, I will never:

• cite twitter-gate as a reason to stay out of the cloud
• confuse IaaS, PaaS or SaaS and the security responsibilities for each
• insist on the right to audit
• blame cloud providers for common software security flaws
• debate on private versus public clouds

I commit to always:

• recommend positive approaches to achieve security in the cloud
• advocate the implementation of A6 and XSRL
• diffuse twitter-gate debates
• clarify on the difference between common security flaws and cloud specific issues

;-)

Closing the gaps on A6 (not the Audi)

I've started writing the A6 API document and I'm bothered by two areas of incompleteness (voids, gaping voids):

1. No Assurance function (specifically my treatment of the assurance function as either emergent or orthogonal)
2. The unconnected dots that each URI represents

I think I can close both of these gaps by cheating a little bit, I'm going to repurpose /ssapi/ISO27002/ to serve as the Assurance function, then use it as the point that we ultimately tie everything together.

This won't be as good as an independent and trusted third party standing up and saying everything is kosher and I still hold that Assurance is best described as follows:

"a validated statement, specifically validated by a trusted third party (like an audit firm) reviews the supporting facts behind an assertion and confirms they are true, have integrity and have the correct scope (or completeness)"

However, I don't believe A6 was supposed to be the cure for all that ails our security world, its purpose it to provide transparency, so let's work on sharing security state information and we can circle back to the golden standard in a future standard.

By modifying the return of /ssapi/ISO27002/ method we can not only use it to expose policy information, but also expose the level of compliance with the policy by providing references back to the /ssapi/environment/ results or the existence of control elements (the latter will need to be self-asserted by a given element, as in "I do this")

There are two sticky bits:

• avoiding exposing sensitive information as follows: "our policy is to have firewalls" followed by "the following elements have very bad scores" and because they're referenced by that policy the intelligent attacker can conclude "their firewalls are poorly configured, let me attack"
• there's a missing input covering the procedural/non-technical elements that we can't use /ssapi/element/xccdf/ to collect (which is my ever-so-clever way of circling back to the need for an eXtensible Security Reporting Language)

Here's version 0.11 of the A6 API documentation - it's showing off a bit more structure, only a page more of content though.

A6 API Documentation - Draft 0.11