This article was originally published on Technology.Info.
As part of our continuing strategy for growth, ITProPortal has joined forces with Technology.Info to help us bring you the very best coverage we possibly can.
NASA's own auditor recently rated its cloud computing deployments very poorly in a report that raises some interesting questions on the use of the cloud at the space agency. I'd encourage you to read the NASA report itself, if you have time, as it's genuinely interesting and can be found
I won't repeat the content of the article and report but will summarise thus: in short, of the five cloud provider contracts NASA has in place, none address the business and IT security risks of public cloud and none meet "best practices for data security"; moreover, much of the information was moved onto the public cloud by various parts of NASA without knowledge or consent from the CIO's office. This throws up a few points.
A bit of history – NASA and cloud
NASA's history with cloud computing is interesting. Through its Nebula private cloud project (see the report for more information), it developed significant expertise in building large scale-out compute environments. In 2010, it partnered with Rackspace to develop OpenStack, an open source software stack for building clouds (a de facto competitor to the likes of VMware and Microsoft in the proprietary space and Xen, KVM and CloudStack in the open source space).
This was a logical move for Rackspace, leveraging its storage expertise. It is a less obvious play for NASA (there are no clouds in space) and one can only assume that Rackspace has no plans for building rockets. This history is useful mainly to make the point that NASA is far from a Johnny-come-lately in cloud, far from it; rather NASA is one of the pioneers. So it really ought to know better.
Single vs multi-tenant (or public vs private)
It would be all too easy for me to make this about public cloud vs private cloud. But NASA's own research makes it clear that private cloud was the more expensive option. As we've argued many times, we prefer the distinction of single-tenant versus multi-tenant. If a customer builds their own cloud, the hardware is obsolete immediately, whereas a multi-tenant provider is required, by market forces, to maintain bang up-to-date hardware and software specs and to refresh its infrastructure to remain competitive.
However, we would strongly argue that for deployments such as this, a multi-tenanted virtual private cloud, with customised contracts and bespoke SLAs, would have been a far better fit than off-the-shelf, one-size-fits-all, public cloud technology.
Does NIST mean "not if strategic technology"?
The rigid definition-by-committee of NIST is a personal bugbear. As we have stated many times, users serving themselves is not necessarily a good thing and it certainly shouldn't be a mandated part of a cloud service. The NASA experience demonstrates this better than I possibly could. The US government itself, through NIST, has encouraged exactly the sort of behaviour that the NASA auditor slams – namely departments within NASA spinning up some VMs and shifting sensitive data upon it with no thought to governance, compliance, the law, intellectual property protection, or anything.
The most damning part of the NASA audit was, for me, the table that outlined the contractual status of the five cloud deals (presumably from five different providers) it had in place. None had defined roles and responsibilities. None had service level reporting metrics. None had data retention and destruction policies. None had data privacy requirements. You really must read the report – it's a brilliant "what not to do guide".
By NIST's own admission, there are only two types of cloud contract: negotiated (like all managed hosting providers offer on a fixed term) and predefined, non-negotiable contracts. In its own words:
By definition, all self-service public clouds fall into this category. After all, the SP isn't going to allow you to write your own contract terms and SLA so it's invariably the lowest common denominator. Yet it's these same "users must serve themselves or it's not real cloud" environments that our governments seem so enamoured with, at the cost of data protection, sovereignty, security and common sense.
Reducing cost is usually a bad driver in isolation
Another personal bête noire is the obsession with reducing costs as an absolute motivator. Our own government has delivered terrible results with this aim in mind and is guilty of encouraging the same procurement practices in G-Cloud. It's inevitable that at the scale NASA is talking about, a multi-tenant cloud would be more cost effective than building and maintaining its own. But at what cost?
Value – that hard-to-define blend of quality and price – should always be the aim, with defined outcomes preceding it. Rarely is one supplier the best and the cheapest. But it is a beautiful thing when you deliver a new technology project that adds value, enhances efficiency, improves competitiveness – in short, makes your organisation better – and then also delivers it at a lower price point. But if all you do is change how you deploy tech in order to reduce cost, the business breaks, you break the law, you get sacked - do you still care about the cost saving?
A wiser man than me, Oscar Wilde, once opined that a cynic is one "who knows the price of everything and the value of nothing". It's important not to be cynical with IT procurement; it's too important to be viewed merely as a cost centre to be slashed if possible.
It's not about technology - it's about supplier management
This is such an underrated and understated area when people talk about cloud. NASA's litany of mistakes has nothing to do with public clouds being less secure than private/virtual private ones (they are). It's not even about cloud. It's barely even about technology. It's about contracts, expectations and good governance. If you don't know how to manage a cloud supplier and sort out the contractuals, you shouldn't be let loose on sensitive data. Indeed, NASA wasn't allowed – it broke its own rules. It's not about cloud. IT in a cloud-based world is as much about managing suppliers and SLAs as it is about keeping the tin working.
Good news for wannabe Dr Evils
NASA may be concerned with its intellectual property falling into the wrong hands – good news if you always wanted a space shuttle or a base on the moon. But anybody outside wealthy rogue governments have nothing to fear. No patient records, criminal records, tax records or other sensitive information about members of the public have been exposed here, to our knowledge.
However, the object lesson is clear. The UK government has swallowed the NIST definition hook, line and sinker too, so the risk is there. Happily, our civil service with the CESG security regulations – the likes of IL2, IL3, etc – is well on top of things. But caveat emptor – if people are encouraged to serve themselves in a cloud world, then public cloud platforms could give us the new "CD-ROM left on train" or "documents left in park bin" headlines.
Focus on your core competencies
It's particularly interesting that it's NASA involved. You just can't get an organisation better qualified than NASA to stand up a cloud project – at a technical level – but they still got it badly wrong. They should, perhaps, focus on aeronautics and space exploration and let those who wake up every day keeping data safe get on with doing that. One of my most vivid childhood memories is being a small boy back in 1981 watching the first orbital flight of Columbia and I've loved NASA and spacecraft ever since. I'd love it if we had a side project at 6DG on "satellite computing" but I suspect we'll remain on terra firma. Back on planet Earth, it's important that people stick to what they're good at.