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.

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

Documenting the A6 REST API

So after a week off (filled with good things like finishing Season 4 of Galactica), I decided I needed to actually document the A6 API. I'm doing this for two reasons:

1. The blog posts are fragmented and make it harder for any potential implementers to follow
2. I like detailed documentation

So here's section 1.0 of draft 0.1 - the three salient elements are the introduction, the license and design philosophy.

A6 API Documentation - Draft 0.1

Be wary of rating agencies

Ruv Cohen, over at Elastic Vapor, proposed an interesting idea for a Cloud Service Rating Agency. The idea was further defined as a "Cloud Performance Ability (CPA) that estimates it's ability to meet certain service levels"; similar in intent to Standard & Poor's Claims-Paying Ability rating for an insurance provider explained as the "financial capacity to meet its insurance obligations".

I love the concept of some standard, some metric that allows us all to look at a complex issue and agree what we're looking at, but there are a few problems:

• Metrics and ratings hide nuance, by design, which may be a relevant factor in your personal evaluation of a provider
• Every single rating agency has shown themselves vulnerable to the introduction of complex artefacts - look at what the introduction of CDO's ushered in and how credit scoring behaved
• Most rating agencies are for-profit entities, which means that while integrity is a priority in their branding, it is almost certainly not the topmost priority in their business objectives

(more issues with credit rating agencies can be found on wikipedia)

Now, before you think I pick on rating agencies unfairly, other public trusts (such as public audit firms) have suffered from conflict of interest problems, that have led to bad decision making (Arthur Andersen's involvement in Enron is a canonical example and one of the reasons for the existence of Sarbanes-Oxley legislation).

So bottom line, if you establish for-profit providing rating services, ultimately the integrity (intentionally or otherwise) will come into question.

Experience has also taught us that self-administered assessments - unless exceptionally detailed - are at best somewhat informative, at worst theatre (the early days of PCI-DSS come to mind).

If we were to build a Cloud Service Rating Agency, what we would really need is an independent, non-profit entity, something like the North American Electric Reliability Corporation (NERC). An entity with claws and a focus on assurance, so while I agree with James Urquhart that data is not electricity, I think it's an interesting industry to draw lessons from.

Some thoughts for addressing the Assurance component of A6

The A6 API is a security stack designed to provide Audit, Assertion, Assessment, and Assurance capabilities. There's one problem, providing assurance can't be done by machines alone - you need a human element, one that stands up and says "these results are true and good". Outside of wild notions about black box mechanisms and trusted computing, I'm hard pressed to find a technology solution to achieve this. What we really need is human participation in the stack, but the difficult part about humans is that we all have our own unique perspective on what is or isn't accurate, what's correct and ultimately how one defines security.

What we need is a standardized way of reporting on complex concepts dealt with in security assessments and audits. If we had a standard security reporting language, we could reduce variation in security reporting and improve interpretability. We can look to financial reporting for an approach.

In financial reporting there are two parts to the process, one is the assertion and the other assurance - one done by the public company and the other done by a public audit company. The public company says, we have X million dollars of this and that, the public audit company confirms that it is indeed true.

Ofcourse, we all know that financial reports are subject to manipulation and there's always some grey area in what a term means, this is further compounded by the various forms financial reporting is published (human readable for sure, but set in any order and dressed up in many different ways).

To address this, the International Accounting Standards Board (IASB) issued a standard known as International Financial Reporting Standards (IFRS) which has a taxonomy defining terms and for situations where a term is not defined, the new term can be described from atomic components and concepts within the taxonomy. There's a standard known as an eXtensible Business Reporting Language (XBRL) which allows for the clear meaning of financial numbers to be articulated in a way that is both machine readable but also IFRS compliant.

Here's a snippet of XBRL (reporting on Operating Income, Administrative Expenses, Operating Expenses):

<ifrs-gp:OtherOperatingIncomeTotalFinancialInstitutions contextRef="J2004" decimals="0" unitRef="EUR">38679000000</ifrs-gp:OtherOperatingIncomeTotalFinancialInstitutions>

   <ifrs-gp:OtherAdministrativeExpenses contextRef="J2004" decimals="0" unitRef="EUR">35996000000</ifrs-gp:OtherAdministrativeExpenses>

   <ifrs-gp:OtherOperatingExpenses contextRef="J2004" decimals="0" unitRef="EUR">870000000</ifrs-gp:OtherOperatingExpenses>

   <ifrs-gp:OtherOperatingIncomeTotalByNature contextRef="J2004" decimals="0" unitRef="EUR">10430000000</ifrs-gp:OtherOperatingIncomeTotalByNature>

If we had an IT Security Reporting standard similar to XBRL, which requires detailed exposure of information and provided clear definitions of terms, cloud providers could self-issue reports that while open to manipulation, become that much harder to subvert - let's call it eXtensible Security Reporting Language (XSRL). With an XSRL report, we'd all use consistent terms and consistent inputs

The three big challenges with the XSRL concept are:

• It's perfectly fine (in fact expected) for a public company to disclose their finances, but the same cannot be said of security vulnerabilities or perimeter defences (even though I'm a strong believer in Shannon's maxim or Kirchoff's principle, it's important to understand that the maxim does not advocate broadcasting details, but rather assuming the enemy will learn them and that the knowledge should not make them a more effective attacker).
• If you lie in a financial statements, you go to jail (usually) - if you lie in a security report (as long you don't breach section 404 of Sarbanes Oxley or equivalent), you'll probably just get your hand slapped (or bad press).
• Most security experts disagree on some aspect of security - financial reporters have IFRS (International Financial Reporting Standards) - so it would be a lot of work to get people to agree on a canonical definition of what constitutes secure and security.

That said, I still think we should try, it's hard, but it will be worth it - A6 could work without it, but I think we need to need to bring a formalism and maturity to security reporting that doesn't exist now, something akin to what financial auditors have today (Lehman Brothers and the like aside).

Can we do the Security Stack API RESTfully (are we there yet?)

I've been working on the A6 API for the past week and I'm certain Mrs IronFog is wondering when I might be done (she's graciously been giving up about two hours of quality time each night - something I am immensely appreciative of).

A6 stands for The Audit, Assertion, Assessment, and Assurance API (a term coined by @CSOAndy via Chris Hoff's Rationale Survivability), so I figured I would know if I was done when I could put a check mark next to each aspect of the 6 A's (this feels like the start of a buffer overflow joke).

So here we go:

• Audit - Check - we have /ssapi/compliance/
• Assertion - Check - we have /ssapi/ISO27002/ and /ssapi/environment/
• Assessment - Check - we have /ssapi/element/xccdf/
• And - Check (for the sake of completeness)
• Assurance - sort-of, it's somewhat of an emergent or external property - I'll explain below
• API - Check - we have /ssapi/

Ok, so 5.0 out of 6 is pretty good, but here's why I think we're complete enough to consider this a first draft. The terms Assertion ad Assurance are financial audit terms:

• Assertion is a self-issued statement made by one party (the provider) to others (end users) about their state - such as "I have a billion dollars in cash" or "we are secure" - they're not validated by anyone else.
• Assurance is 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)

Assertions are easy, anyone can make a statement about anything - that's what our stack does - however, we just have to trust that the statements are true and good.

For assurance, we have three options:

• Have some trusted mechanism (black box software in a tamperproof appliance) validate the information from the stack and issue a signed XML blob;
• Get a third party auditor to validate the assertions issued by the stack and provide a formal sign-off; and
• Review the information ourselves and see if we can spot inconsistencies (and then call "liar-liar-combusting-pants")

Barring perfectly trustable computing, we cannot provide true Assurance functions through technology alone - we can just make it easier to share what we know in an easily interpretable fashion.

So basically, the stack as it stands, is structurally complete enough for a first draft release (which I'll start packaging up shortly). Ofcourse, there's still specifications, nuances, details and documentation to get done; I know other things will emerge as I review and cleanup what I've done, but that will be iterative, not net new.

The value curve for the Cloud and what it means to security

I'm taking a small break from the A6 API work I've been doing. I've been pondering about the business side of security as it applies to the cloud. Indirectly, this is the rationale for something like A6.

This post is meant for business types, not my fellow cloud believers.

Recently my benevolent overlords sent me off for some training at a business school, now being a survivor of another business school, I was rather skeptical of what I might learn, but learn I did (to my surprise quite a few times). One of the topics covered was blue ocean strategy, succinctly described as (see Wikipedia for more details):

"Blue oceans, in contrast, denote all the industries not in existence today—the unknown market space, untainted by competition. In blue oceans, demand is created rather than fought over. There is ample opportunity for growth that is both profitable and rapid. In blue oceans, competition is irrelevant because the rules of the game are waiting to be set. Blue ocean is an analogy to describe the wider, deeper potential of market space that is not yet explored"

In practice this means, take something that exists today and modifying it's parameters to give the customer what they need while eliminating the attributes they don't care about. The canonical examples are Cirque Du Soleil, South Western Airlines and Formule 1 hotels, whom respectively, reinvisioned circus as theatre, airplanes as competing with buses and trains, and hotels being about a place to sleep and nothing more.

The Blue Ocean concept is not without it's flaws, but it provides a number of interesting tools for analysing a market and potential new offerings. One of those tools is a value curve, a visual representation of what's important to the customer and how much the solution or product provides of that value. Here's an analysis of what's important to a consumer of breakfast cereal:

The value curve isn't an analysis of which one is better, but rather what each product provides to a customer:

• Captain Crunch - covered in sugar, low in fibre, sugar equals lots of calories and comes with the standard decoder ring
• All-Bran - taste is acceptable, loaded with fibre, very healthy and comes with a discount coupon for another box of cereal or orange juice - it comes in slightly larger quantities than it's sugar laden competitor.

Most competitors in the breakfast cereal market space will vary around taste, price or caloric content and promotional elements as they attempt to win customers from their competitors.

Now imagine someone came up with a cereal that tastes great, lots of fibre, is healthier than a gym commercial and decided to forego coupons or decoder rings altogether (ok, its a simplified example) - more importantly, it doesn't require milk at all. The value curve would like something like this:

That product, and the market it instantiated (having broken the inverse relationship between taste and healthy eating), would be an example of a blue ocean - they've improved on certain aspects of the product (taste, fibre content and caloric count), got rid of things they don't think the customer values (decoder rings), reduce attributes that aren't as important (quantity) and introduced something completely new (no need for milk). While they are in reality competing with the other cereals, they also created an effectively new market (through technological innovation) that existing players would require a lot of repositioning to participate in, potentially at the cost of their existing customers.

So what's this got to do with security and cloud computing. A few years ago (and still today), enterprise computing power, specifically that in data centres or collocated, looked like this:

The curves shown here are averages for vendors like Dell, HP, Sun and IBM or collocation providers such as Rackspace, IBM, EDS or SunGard and also aggregates in the sense that a data centre includes a number of other vendors (EMC, Cisco, Juniper etc...). While some vendors into the data centre might be more cost effective, others may allow you to do more with less hardware; these are generalized representations.

Then Amazon came along and said, let's compete and do this data centre/collocation thing differently - here's what you get:

The points of the new value curve for Cloud IaaS are:

• improved cost effectiveness (I know the jury is still out on that);
• less control (for example governance) or ability to customize the environment - Amazon or public IaaS just aren't going to negotiate with you;
• extremely fast deployment (minutes not days);
• the flexibility to repurpose assets at will;
• eliminating hardware that you own;
• about the same security - let's assume that Amazon runs a relatively tight shop (they just don't tell us how in any great detail); and
• and a new ability to buy computing power for only when you actually need it

What this means to the business is you're dealing with a new beast, and because you value things like on-demand computing, elimination of CAPEX (the expense of owning assets), improved cost effectiveness and rapid deployment, you have to be willing to give certain things up. That's not to say you shouldn't expect, want or demand great security, it's just not under your control - more importantly, your security officers have to realize the same thing.

That said, even if you don't control something, it's not unreasonable to ask the people that do to tell you what's going on - that way you have a meaningful way to assess the risk you're carrying - which is the reason I think A6 is so important.

(BTW, graphs were done with OmniGraphSketch, quite useful for creating arbitrary graphs).

Can we do the Security Stack API RESTfully? (Part 5)

In part 4 of security stack API series, the /ssapi/element/xccdf/ URI was described, which allows elements in the environment to express their security status via XCCDF (eXtensible Configuration Checklist Description Format). Now that we have a private part of the stack for data collection, we're going to jump back to the public stack to expose an anonymized aspect of the data.

• /ssapi/environment/registered/ - a GET request will return the total number of elements registered with the aggregator, specifically, how many have uploaded a registration payload.
• /ssapi/environment/validated/ - a GET request will return the total number of registered elements that have uploaded.
• /ssapi/environment/freshness/new/ - a GET request will return how many seconds have passed since any element updated their current XCCDF test result.
• /ssapi/environment/freshness/old/ - a GET request will return the age, in seconds, of the oldest current XCCDF test result for any element.
• /ssapi/environment/freshness/mean/ - a GET request will return the mean age, in seconds, for all elements current XCCDF test result.
• /ssapi/environment/freshness/median/ - a GET request will return the median age, in seconds, for all elements current XCCDF test result.
• /ssapi/environment/freshness/@all - a GET request will return an XML blob containing a list of h(UUID4's) (the arbitrary handle that only the aggregator can connect back to a specific element - SHA-2 hashed along with a secret value to reduce likelihood of correlation) along with the age in seconds of the current XCCDF test result.
• /ssapi/environment/score/current/@all - a GET request will return an XML blob containing a list of h(UUID4's) - described immediately above - along with the current XCCDF score value for each element.
• /ssapi/environment/score/trend/@all - a GET request will return an XML blob containing a list of h(UUID4's) - described immediately above - along with a keyword attribute indicating if the score had "improved", "degraded" or "new". The new keyword is used in cases where a new XCCDF test package has been used (may mean the reporting element itself is new or the package has just changed).
• /ssapi/environment/score/count/@all - a GET request will return an XML blob containing a list of h(UUID4's) - described two URI's above - along with a the total count of XCCDF test results uploaded.

Notes:

• While all of the above URI's are public, none of them expose detailed information about the environment that will tell an attacker what defences they're up against or the specific state that any element is in.
• The /ssapi/environment/ URI's provide anonymized data about the environment, that assuming the stack isn't lying about, tell the requester how broad the providers security efforts are, how much coverage they provide and how frequently they're examining or improving their environment and the elements therein. Ultimately though, it's up to the consuming organization to determine if the providers security efforts, as expressed through the stack, are sufficient.
• Administrators with authenticated access to the private part of the stack, specifically the URI /ssapi/element/xccdf/results/ (described in part 4), can view the actual results.

@mhanco suggested we need to address message level security, I completely agree, but want to defer detailed XML payload structures (or other formats) until we've got the broader structure mapped out.

more to come...

Can we do the Security Stack API RESTfully? (Part 4)

(Mrs Iron Fog is awesome - she does my chores for me so I can blog)

(Part 3 is here)

Using the previously described /ssapi/register/ an element can push up information about their security state. This data is considered private and wouldn't be exposed via the public part of the stack - aggregated or sanitized versions of it might be, but not in its as is form, some of the data could result in damaging information leakage.

In this section we start using another SCAP element, The eXtensible Configuration Checklist Description Format (XCCDF)

• /ssapi/element/xccdf/results/?<uuid4> - an element can POST the results of a configuration check with an XML XCCDF result blob.
• /ssapi/element/xccdf/results/ - an administrative entity can GET a list of elements that have provided test results.
• /ssapi/element/xccdf/results/@all - an administrative entity can GET a list of all available test results for all elements (with URI, date and test type).
• /ssapi/element/xccdf/results/?<uuid4> - an administrative entity can GET the list of recent XCCDF test results, an XML blob is returned with enumerated URI, date and test type.
• /ssapi/element/xccdf/results/current/?<uuid4> - an administrative entity can GET the most recent results from a configuration check. If the original element attempts a GET, an error message is returned (prevents information leakage).
• /ssapi/element/xccdf/results/00000001/?<uuid4> - an administrative entity can GET a specific prior result from a configuration check - exact URI will be provided by the /ssapi/element/xccdf/results/?<uuid4> query.
• /ssapi/element/xccdf/results/current/score/?<uuid4> - an administrative entity can GET the XCCDF standard score from the most recent configuration check.
• /ssapi/element/xccdf/results/00000001/score/?<uuid4> - an administrative entity can GET the XCCDF standard score from a specific prior configuration check

Some additional thoughts:

• elements should be able to upload security information, but not read it. This prevents a malicious entity on the element interrogating the stack aggregator for useful information.
• Within the private part of the stack, there should be URI's that are access restricted to all but high privilege users.
• Again, none of the above is published to the outside world

Next, how to express this information to the public stack without giving the game away...

(minor typo fixed - July 31, 2009)

(fixed incorrect escaping on non-HTML tags)

Can we do the Security Stack API RESTfully? (Part 3)

(Part 1 and Part 2 are here respectively)

(a bit of a shorter post tonight as I was on nephew duty)

So far, I've been focusing on organization elements of the stack, by that I mean things about the provider, specifically policies and compliance.

We're going to start moving into the stack space that deals with individual elements, and where we start using bits of SCAP. Before we can start considering individual elements, we need a way to register an element:

• /ssapi/registration/ - invoked by a POST on an XML payload containing Common Platform Enumeration data, IP address and other unique network identifiers (for example a FQDN - thinking MAC addresses are a problem given network segmentation) returns a UUID and new credentials to be cached by the POSTer. The POSTing element was provided with a limited use credential for the initial registration (consider this an authentication boorstrap). If another element tries to register the same IP address or other unique identifier - note, after having examined CPE, I think my comment earlier this morning about self-asserted URI's into a namespace ("I am 10.45.0.34" & "I am http://www.f5.com/products/...") was slightly off, so I'm changing course a little.
• /ssapi/registration/ - invoked by an authenticated DELETE will unregister the element. Invoked by an authenticated PUT will allow the element to update previously provided data including the network identifier, if and only if that identifier hasn't been claimed by anyone else (if it has, an error message is returned).

The registration payload could look like this:

<registration>

<networkID>

<IP address="10.45.0.24" />

<FQDN name="grump1234.xyz.corp" />

</networkID>

<cpe name="cpe:/o:sun:solaris:5.10" />

</registration>

note: I'm being lazy, this is not fully formed XML, pseudo XML at best

A few more thoughts:

• this is a RESTful API, which implies web servers, but I don't think we want to start running embedded web servers all over the place (not a fan of increasing attack surfaces). So most elements in an environment would push information to a purpose built aggregator.
• Much of the data that could be returned by the stack is not for public (or valued customer) consumption. That means part of this stack will be a generalized security information collection and sharing mechanism - I want to avoid repeating the wheel. The other part, and I think this is the most important thing we can accomplish, the stack provides cloud users with a tool and shared meaning to be confident in their cloud providers security.
• I haven't said anything about authenticating access to the stack or access restrictions to parts of the stack - I'm thinking OAuth for the former and something akin to SNMP's public/private for the access restrictions (keep it simple for now, refine in v2.x).
• The unique network identifier used by the element should be strongly bound to the element, that is we need some way to prevent impersonation of one element by a malicious element - client side x509 certs are the easy answer but impose deployment overhead, will need to think more on this. Once registration is complete, the unique network identifier must be bound to the issued credentials and UUID.
• I've avoided discovery for now, you could use a trusted feed from NMAP to populate some of your data set, but you still need to register the element for future conversation, although I suppose one feature implementation could be an agentless aggregator that also provides element security state using remote scanning.

Thanks to @lmacvittie for some thoughts on unique identifiers which led to a discussion on auto-discovery and other goodness - the bad news is that the security stack has a lot more work to be put in, so maybe the squirrel won't get his Friday wish, the goods news is Monday is a public holiday, so lots of thinking time this long weekend.

more to follow...

note: made some minor changes post a reread - removed incorrect reference to shared secret and revised URI to include UUID.

Can we do the Security Stack API RESTfully? (Part 2)

the Uber-Squirrel demanded I be done by TGIF...

part one is here; background detail is here.

This section deals with expressing the actual policies of the provider organization, obviously a complex information set to represent, so this will require a lot more detail and thinking. I think it's best that we use ISO27002 (the next version of ISO17799) given that it's the root standard from which all other compliance standards are derived; additionally

• /ssapi/ISO27002/ - returns a list of sub-elements for the standard, immediate descendants only
• /ssapi/ISO27002/@all - returns an XML payload with values and freshness for all descendants

The following list enumerates the eleven clauses:

• /ssapi/ISO27002/1/ - Security Policy
• /ssapi/ISO27002/2/ - Organizing Information Security
• /ssapi/ISO27002/3/ - Asset Management
• /ssapi/ISO27002/4/ - Human Resources Security
• /ssapi/ISO27002/5/ - Physical and Environmental Security
• /ssapi/ISO27002/6/ - Communications and Operations Management
• /ssapi/ISO27002/7/ - Access Control
• /ssapi/ISO27002/8/ - Information Systems Acquisition, Development and Maintenance
• /ssapi/ISO27002/9/ - Information Security Incident Management
• /ssapi/ISO27002/10/ - Business Continuity Management
• /ssapi/ISO27002/11/ - Compliance

One can iterate through the provider's policies and security behaviours as follows:

• /ssapi/ISO27002/1/ - returns a list of available security categories for the clause, immediate descendants only
• /ssapi/ISO27002/1/1/ - returns a list of available controls within a given category
• /ssapi/ISO27002/1/1/1/ - returns a list of available control statements
• /ssapi/ISO27002/1/1/1/@all - returns an XML payload with values and freshness for the control set
• /ssapi/ISO27002/2/@all - returns an XML payload with values and freshness for all descendants of the clause

An XML fragment from /ssapi/ISO27002/1/1/1/@all might look like this:

<standard name="ISO27002:2005"> <clause number="1"> <category number="1"> <control number="1" freshness="2009-29-02"> <summary>"We are compliant because of..." </summary> <state >implemented</state> <details>

"xyz cloud corp uses a multi-tiered approach to..."

</details> <reference>

http://www.xyz.com/policies/policy1.pdf

</reference> <reference>

http://www.xyz.com/policies/policy2.pdf

</reference> </control> </category> </clause> </standard>

Some additional thoughts on the Security Stack API (or A6):

• this API should be a generic interface for exposing both technical and organizational security information
• the API is a standardized framework for exposing information and while it won't replace existing approaches, it will ease users ability to ask for that information and get an answer that matches their expectations
• vendors will populate data to different parts of the stack, vendors that can't respond to certain parts of the API (for example, a Cisco ASA firewall can't opine on your policy for asset management) shouldn't be considered non-compliant
• there exists a need for an aggregator entity that collects stack information from distributed elements (maybe a firewall here, an IPS there, a compliance system somewhere else)
• the stack should not explicitly disclose information about the security state of system (at least not to guests in the environment or the unwashed masses), that's pointedly unsafe. However, the stack may unintentionally leak information that could be useful to an attacker. For example, the stack should never say - "I'm not patched against CVE-2012-435", but it may say "my patching policy is within 4 hours", which tells an attacker their window of opportunity - we'll have to think about this topic a lot more.

more to come tomorrow...

Can we do the Security Stack API RESTfully? (Part 1)

Been thinking about the Security Stack API (A6), wondering if we can do as a RESTful API, something about the URI structuring appeals to me and I think relates well to the many different sections one would need to cover, here's part the first blob:

• /ssapi/compliance/ - returns a list of compliance regimes the provider operates under and their
• /ssapi/compliance/PCI/ - returns a list of sub-elements for the standard, immediate descendants only
• /ssapi/compliance/PCI/1/ - returns a list of sub-elements for the standard, immediate descendants only
• /ssapi/compliance/PCI/1/@all - returns an XML payload with values and freshness for all descendants
• /ssapi/compliance/PCI/1/1/ - returns a list of sub-elements for the standard, immediate descendants only
• /ssapi/compliance/PCI/1/2/1/ - returns a list of sub-elements for the standard, immediate descendants only
• /ssapi/compliance/PCI/1/2/1/a - returns answer and freshness attribute
• /ssapi/compliance/HIPAA/ - returns a list of sub-elements for the standard, immediate descendants only
• /ssapi/compliance/HIPAA/@all - returns an XML payload with values and freshness for all descendants
• /ssapi/compliance/SOX/ - returns a list of sub-elements for the standard, immediate descendants only

Working on layout for policy expression, will share tomorrow.

Can we API more than vulnerability scans and change management?

I thought a bit more about Chris Hoff's idea of using something like SCAP to provide a Security Stack API (to be honest, at first pass I thought he was only talking about vulnerability scanning, but it's quite clearly more than that)

At last week's local CloudCamp, Glen Brunette lead a session at which we talked about security for IaaS (Infrastructure as a Service) providers. Initially the session started with validating the micro-kernel/hypervisor - either through review, placing it in hardware or providing some sort of integrity metric - but from there we evolved to something a little more useful.

Regardless of the technique, attesting to the integrity of the hypervisor, providing proof that hypervisor is secure, doesn't mean much in isolation. The hypervisor can be the equivalent of Fort Knox and it won't be secure if I can grab a disk from the storage network, clone the virtual machine or walk the server it was running on out the door.

So, we need more than a way to expose security state of the virtual environment. What you really need is a way to attest on the security processes of the entire organization.

In fact, I think I really don't want my cloud provider to tell anyone how patched or unpatched his platform is. What I want him to tell me is how compliant he is with his published security processes (and what his processes are). Processes like user account lifecycle management, logging, auditing, incident response, physical security and take your pick from your favourite ISO27001 derived compliance standard.

I reread Chris Hoff's article on the security stack (love the diagram), but some of the comments by other readers are bothering me - one concentrates on the technical matters and the other again focuses on the "brain in a jar" problem. A lying API is possible but has a number of issues (audience, cost and risk) that mean you're either focusing on the technical aspects of security assessments (only part of the picture) or aren't willing to settle for anything less that a personal audit of the providers entire operation, which is antithetical to what cloud users want.

Ultimately for the die hard security professionals, they'll have to give up the desire to know 100% for sure about security - your business gave up that right when they decided to save money by heading into the cloud (part of the reduce activities in changing the value curve). There is no perfect and cost-effective method for you to determine that you haven't been tricked, so the API's will give you more transparency (into what is rather opaque right now), but eventually you're going to have to make a reasonable decision to trust and live with the risk of a lie.

Why not? You do it already with your software vendors today.

note: While I think this API would provide results on demand, I don't think it should be expected to deliver real-time results - you can't put sensors on everything. During the session at CloudCamp we got to the need for periodic audits of the providers security processes and that periodic should probably be monthly. If this sounds unreasonable, keep in mind Certificate Authorities can have weekly assessments (they rotate through all the major security domains, with full scale audits happening less frequently). I think major cloud providers are becoming as important as certificate authorities are. Ultimately it's up to the provider to decide the frequency, it's just that we should expect them to reveal the freshness of the audit findings.

The security stack could work, don't worry about the rabbit hole

I attended my first cloud camp and came to the incorrect conclusion that there are those that understand the security issues in the cloud and those who don't understand the cloud.

I say I came to the incorrect conclusion because I realized that the second catgegory is not of the uninformed, but rather because there are those folks that just see the cloud as a utility, a tool, and if the tool works as promised, they don't really care about the inner workings until they faced with a problem.

The challenge tends to come in the form of a compliance person or a security officer being a proud member of the RSFTPB (Royal Society For The Provention of Business). The security or compliance expert starts asking hard questions and the tool user goes "um... they have the lock thing on the browser". Which, to me, is the right (obviously wrong) answer; why should the tool user have a good answer?

The problem arises when the expert tries to investigate the utility and gets at best a high level security whitepaper, at worst at bullet point feature list.

Chris Hoff recently posted of building a standardized security assessment API, a way for cloud providers to express the security state of their environment. Some rebutted with concerns of how do you know if the API is letting you talk to the real target of assessment? Short answer is ofcourse you don't (an evil provider can run the API inside a fully hardened virtual instance or just straight out return false answers)?, but I think that kind of misses the point, for three reasons.

Firstly, it's really about addressing the concerns posed to our tool user population, who don't know to ask these type of questions. As long as the system has the appearance of correctness and provides the right answers, then that's enough for the tool user and should appease the compliance kings (we know this from past experience with nearly total acceptance of the output of vulnerabilit scanners).

Second, if you're going to fake the results, you're going to a lot of effort to build a lying stack that will provide reasonable answers that are consistent, persistent and have an appearance of integrity. I'm fairly certain cost issues would win out and it would be cheaper to buy a stack or assemble from COTS components that craft your own.

Third, lies only work if you don't get caught - while it will be small solace for the first victims, it will also be obvious to everyone that something wasn't right and eventually the truth would come out. Admittedly this is not a desirable, but it would not be dissimilar to the poor practices full disclosure policies were designed to overcome.

I think if you give the tool users real and easily accessible answers, in formats they can use (XML and PDF come to mind), we can make 80% of the cloud naysayers happy.