Iron Fog

A6 becomes Cloud Audit

2010-02-14T19:32:00.005-05:00

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

2009-10-08T22:39:00.001-04:00

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:

Don't use the wireless network
Always assume someone is intercepting traffic and displaying it on a big screen somewhere
Always assume that someone with less than noble intent is intercepting traffic
Always assume that some wannabe is sniffing traffic for some reason
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

2009-08-31T22:49:00.001-04:00

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:

EC2 admins can't disengage the network isolation controls
The network isolations control are some orthogonal mechanism that cannot be directly accessed from any EC2 instances (either inside or outside the VPC zone)
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

2009-08-18T23:04:00.001-04:00

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

2009-08-16T09:42:00.000-04:00

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

2009-08-12T22:20:00.001-04:00

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)

2009-08-12T20:53:00.001-04:00

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

No Assurance function (specifically my treatment of the assurance function as either emergent or orthogonal)
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

2009-08-12T00:25:00.001-04:00

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:

The blog posts are fragmented and make it harder for any potential implementers to follow
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

2009-08-03T12:31:00.002-04:00

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

2009-08-03T00:12:00.002-04:00

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?)

2009-08-02T19:37:00.004-04:00

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

2009-08-02T17:21:00.001-04:00

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)

2009-07-31T22:45:00.004-04:00

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)

2009-07-30T22:30:00.009-04:00

(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)

2009-07-29T23:05:00.006-04:00

(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:

</networkID>

</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)

2009-07-28T20:31:00.008-04:00

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)

2009-07-27T22:35:00.006-04:00

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?

2009-07-26T23:53:00.006-04:00

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

2009-07-26T18:05:00.006-04:00

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.

Google Wave - how do I secure your document when it's the cloud?

2009-06-17T12:35:00.011-04:00

A few days ago I got a change to sit down and watch the entire hour of the Google IO video on the early release of Google Wave. If you haven't watched it, here it is (suggestion, do it offer lunch, it's long but worth the watch). If you don't feel like watching, here's a link to the product team's blog posting. To summarize, Wave is a collaborative real time editing environment (think Wiki meets subethaedit meets IRC meets CVS) delivered via the browser (assuming yours supports HTML5). I can invite people in to a wavelet (a document or object on Wave) and we can work together. As a collaboration tool, this takes sharepoint out behind the woodshed. What really interested me was the part about federated wave servers - in a nutshell, Google wants to make Wave as popular as email and expects (or hopes) that organizations will setup their own wave servers, so they're open licensing/sourcing the whole stack, protocol and concept. The interaction between the federated servers is just too cool to watch - little chunks of document flying all over the place - being digitally signed, delivered over encrypted channels, synching perfectly so everyone can see the same thing at the same time. It got me thinking, what happens if my employer has a wave server and I have a wave server at home (or use Google's Wave product):

Can I invite my home account into the document I'm working on at work and continue editing when I get home?
The document will now be in two places (sync'd in glorious real-time)
What happens if I quit/get fired - how does my employer remove that document from my Wave server?

...and then there's the normal stuff, like to companies working together, sharing information and all the ownership/security issues that come with it.

Now granted, we're probably no worse off with email now (I can email work documents to my gmail account at will), but with a powerful tool like Wave, the sharing becomes continuous and real-time; the corporate firewall becomes a fine mesh and my documents are quite literally everywhere. DRM's a nice answer (assuming it can be implemented), but it's somewhat antithetical to an open protocol and assumes that all participants honour the rights management request. Besides, DRM has never been very granular (its atomic tends to be the document or the song) and simple deletion seems wrong when it's a collaborative document between multiple participants. Maybe the best we can for is legal agreements plus an honour driven deletion system that works along the lines of:

Party A asks Party B to drop all content generated by Party A
Party B walks the current wavelet tree structure and nukes anything added by Party A
Party B reports back to Party A on what it deleted
Party A reminds Party B of it's legal obligations (pre-negotiated) and disappears in a puff of smoke

The two interesting properties are of an open rights management protocol are:

Healable data - Party B is now free to use the remaining elements of the wavelet (the stuff it provided) to rebuild the document with its own content (as much as you'd like, you can't scrub the human mind, the ultimate anti-drm tool)
Granular information protection - I can't actually stop stuff from going out, but at least I know where it lives and can demonstrate I took reasonable steps (short of seizing the other parties wave server) to protect my content.

One of the things an open rights management system presupposes (at least to me) is this notion of automatically negotiated (legal) agreements and policies between federated wave servers about how they will behave.

OohRah! here come the security clouds

2009-06-09T22:08:00.011-04:00

I'm not sure what to make of this article, at first pass I thought it was somewhere between classic security "re-invited here" and solution seeking a problem, but I reread the article and on the second pass this piece got my attention:

Cloud Computing: The Dawn of Maneuver Warfare in IT Security A theoretical example of how maneuver IT security strategies could be use would be in responding to a denial of service attack launched on DISA datacenter hosted DoD applications. After picking up a grossly abnormal spike in inbound traffic, targeted applications could be immediately transferred to virtual machines hosted in another datacenter.

It's a nice idea of using on-demand infrastructure to outmanoeuvre your attackers (rather than fighting a war of attrition) a concept made great by the USMC, but the articles a little short of real world examples. So it got me thinking, what defensive security activities can be improved by the application of cloud infrastructure (IaaS)? We've got the (simple) use case of rerouting traffic to defend against a dDoS attack - but we already have that in the form of CDN (content distribution networks), although it would probably be noticeably cheaper given it's on-demand nature. What about managing virus outbreaks, patch deployment and vulnerability detection? managing virus outbreaks - If I can scale my security infrastructure rapidly, I can scan my distributed filesystem and workstations, I can hunt down and remove infections - in theory I can scale my cloud rapidly enough to combat warhol-esque worms. patch deployment - if I need to force patches across my environment, I can deploy a swarm of servers that will connect to every server and workstation in my enterprise and force the patch down (after I've spun up a multiple VM's to test/socialise the patch against my standard configurations). vulnerability detection - Scanning a class B sized network can take a while, but what if I can launch a few hundred servers and ask them to scan a less than a class C each, in parallel (note: this idea wasn't mine, credit to Richard at Enomaly) - I can get near-realtime vulnerability intelligence on my environment at relatively low cost. Running a few hundred EC2 servers for less than an hour is pretty cheap, especially if compared against buying a whole bunch of expensive scanning appliances (then again, there's nessus). Here's the rub (actually two) 1) How do I coordinate this on-demand security infrastructure? how do I make sure work is evenyl shared? what about providing (domain) administrator credentials 2) Unless you're a highly distributed organization with multiple points-of-presence, you're biggest constraint for making using of IaaS from external providers (e.g. EC2) is bandwidth - granted, patches, vulnerability scans and virus detection aren't bandwidth intensive on their own, but there a chance your on-demand security infrastructure could overwhelm your not-so-scalable connection infrastructure. So here's my wild thought of the day, today you have peering points between major ISP's, service providers and backbone carriers - how long before enterprises will want to have peering points with EC2 and Savvis to make IaaS almost local? side note: I recently read an article about user provisioned hardware, when you add that to more remote work/work from home - maybe the connectivity problem goes away and the need for highly scalable security IaaS becomes more important - maybe the problem the solution has been looking for is "how to I secure employees working form hundreds of different locations?" update: Jeff Barr from Amazon Web Services pinged me, apparently oeering with EC2 is doable - a little google-fu revealed Amazon uses Equinix for peering.

Where's my VMSafe for VMSafe?

2009-04-23T21:11:00.011-04:00

VMWare continues to tease with VMSafe prototypes; while Reuven Cohen points out that vsphere isn't cloud computing (argue amongst yourselves about terms like "private cloud"), I like the idea of the ability to use the hypervisor to inspect the security state of the guest machines, but where's my API to confirm that the hypervisor is in a secure state?

VMsafe enables partners to build security solutions in the form of a virtual machine that can access, correlate and modify data to help control and protect: * Memory and CPU. VMsafe provides introspection of virtual machine memory pages and CPU states. * Networking. VMsafe enables filtering of network packets inside hypervisors,,as well as within the security virtual machine itself. * Process execution. VMsafe provided in-guest, in-process APIs that enable complete monitoring and control of process execution. * Storage. Guest virtual machine disk files can be mounted, manipulated and modified as they persist on storage devices.

If the API that provides my security tools the ability to look inside guest machines doesn't allow me to confirm that it's executing in a secure state, how can I trust the output from the API. It's the same old problem, if the someone shows up with a blue pill, any reliability assertion I can make from technology above is effectively meaningless. So really at the end of it all, I'm just going to have to make an assumption that the stack is secure driven by how much I trust the provider and the compensating controls on the underlying host (anti-X, ACL's etc...) knowing that there will always be (with current state tech) no way to defend against a nested VM attack were the true hypervisor is malicious. Speculation: Would full hardware virtualization solve this problem? Probably not unless it were completely locked in its behaviour (which would probably make it rather less than useful). I think the only way we're going to solve the nested VM security problem is a process outside of the virtualization stack, with a read-only monitoring port that can make assertions about the integrity of the virtualization stack (but that's just a WAG, I'm clearly no computer scientist). and now for a moment of pointless FUD: Here's a funny thought, if VMSafe allows me to inspect the "memory pages and CPU states" of a guest OS - does that mean I can get access to the encryption keys and other sensitive information inside the guest VMs?

IBM puts a WAF in the cloud?

2009-04-23T07:44:00.001-04:00

IBM just announced a new cloud initiative around their Preventia and Rational platforms. The Rational play seems to meet the on-demand and scalability requirements of a cloud service (as many scans as you need for as many applications as you have) which puts them into the competitive space that contains solutions form Qualys and Cenzic among others. The Preventia platform leaves me a little fuzzy though, my first read on it is that it's a software appliance that you could put into your particular environment to protect your web app - same as you could incorporate a checkpoint software appliance into your cloud. So yes it adds security to web apps in the cloud, but it doesn't follow the same pattern as the "route through" solutions out there, so I don't think this isn't a cloud security service. Still, a start to addressing the security concerns of QSAs and CISSPs everywhere. (Best subtitle ever "Probably has a shiny uniform, catchphrase and secret handshake"). UPDATE: The Hoff of Rational Survivability is checking it out at RSA, thanks!

mal-machine mark 1

2009-04-21T17:53:00.002-04:00

Reuven at Elastic Vapor posted Introducing The Virtual Machine Trojan on a PoC tool called ViMtruder. It demonstrates Kris Buytaert's concerns on portability of malicious code inside VMs, but I still believe that downloading a random VM from an untrusted source without doing your due diligence is asking for trouble, whether or not this trojan was available.

Defining a true Cloud Security Service (Part 1)

2009-04-20T23:52:00.001-04:00

I got excited by the title of this article in Channel Pro, "Cloud-based security services - will 2009 be the year this much hyped sector comes of age?", hoping it was a spiritual successor to Craig Baldings earlier posting. Sadly it was not (guess it's my fault for reading a trade rag). The Channel Pro article quickly headed towards product flog land (nothing wrong with that, if you don't try to sell, you don't sell) but it did give a brief consideration towards the reasons that security in the cloud hasn't happened:

no doubt resistance to some of the changes in thinking and internal processes needed to implement a SaaS strategy is a significant factor

Then I realized, the logic was sort of nonsense given that MSSPs (Managed Security Service Providers) are alive and well. Once a company is willing to outsource, whether it's on-premise and remotely managed, in someone else's data centre or in the cloud really comes down a price/functionality/trust debate. Consider the following crop of cloud security services: enStratus provides security services for the cloud; Rozmic has emailcloud (which seems to be a competitor to ProofPoint, Frontbridge prior to rebranding and lets not forget Postini); and Zscaler provides anti-X solutions. This list is by no means canonical, but with the exception of enStratus, all of the cloud security services use a route-through implementation to provide the service. So does that make this current crop simply souped-up MSSPs? McKinsey's report on cloud computing (with all its vagaries) tried for a three part definition of "the cloud" (see page 12) that goes like this: 1) Hardware management is highly abstracted from the buyer 2) Buyers incur infrastructure costs as variable OPEX 3) Infrastructure capacity is highly elastic (up or down) Cloud services are defined as only two of the three, specifically: 1) Hardware management is highly abstracted from the buyer 3) Infrastructure capacity is highly elastic (up or down) MSSP's are clearly not cloud or cloud service, you buy a firewall or an IPS and if you need more capacity your MSSP will sell you another device. If you look at McKinsey's definitions, I think it's important to clarify that abstraction should be so great, that not even the cloud operator really deals with the hardware - in the extreme, they simply plug in the raw physical substrate and the cloud subsumes it (look at Google - do you think they do any manual provisioning outside of putting their servers together). For the variability of the OPEX cost, periodicity counts (think by the hour, not the month). Finally, infrastructure elasticity should be automatic and not require the purchase of additional equipment on a per customer basis. With that in mind, it's clear that services like ZScaler are not souped-up MSSPs, so does McKinsey's definition for clouds and clouds services work for cloud security services? I think so, but there's an interesting distinction to be made between services like enStratus and Rozmic's emailcloud.