After reading ENISA’s “Benefits, risks and recommendations for information security” , I am convinced even more so now than I ever was before, against the cloud. For those unaware of the acronym, ENISA stands for European Network and Information Security Agency. It can be viewed as Europe’s version of the USA’s NIST. Their document is 125 pages, with 71 pages encompassing the main scope and the remaining pages consisting of a Glossary, Bibliography and Annexes. It is a must read for any manager thinking about moving to the cloud in this lifetime. It is also QUITE an eye opener.
For those who many not time on their hands or simply choose not to read the document, here is a “carefully selected” punch list of risks ENISA detailed in their report. These risks were specifically chosen because of the scope of dangers involved with cloud security. ENISA makes some great points; however, every topic is covered in a rather broad sense. Therefore, I have decided to correlate real world events with real instances, and to offer an alternative explanation of those risks. Whether it is pointing out how they have been or are being exploited, or simply expounding on ENISA’s findings, this will turn out to be a rather long read, so I will deliver it in installments under different posts as time allows. First ENISA’s list of risk topics include:
R.2 LOSS OF GOVERNANCE
R.3 COMPLIANCE CHALLENGES
R.5 CLOUD SERVICE TERMINATION OR FAILURE
R.6 CLOUD PROVIDER ACQUISITION
R.8 RESOURCE EXHAUSTION
R.10 CLOUD PROVIDER MALICIOUS INSIDER – ABUSE OF HIGH PRIVILEGE ROLES
R.11 MANAGEMENT INTERFACE COMPROMISE
R.12 INTERCEPTING DATA IN TRANSIT
R.13 DATA LEAKAGE ON UP/DOWNLOAD, INTRA-CLOUD
R.14 INSECURE OR INEFFECTIVE DELETION OF DATA
R.15 DISTRIBUTED DENIAL OF SERVICE (DDOS)
R.16 ECONOMIC DENIAL OF SERVICE (EDOS)
R.17 LOSS OF ENCRYPTION KEYS
R.19 COMPROMISE SERVICE ENGINE
R.20 CONFLICTS BETWEEN CUSTOMER HARDENING PROCEDURES AND CLOUD ENVIRONMENT
R.21 SUBPOENA AND E-DISCOVERY
R.23 DATA PROTECTION RISKS
R.25 NETWORK BREAKS
R.27 MODIFYING NETWORK TRAFFIC
R.28 PRIVILEGE ESCALATION
R.29 SOCIAL ENGINEERING ATTACKS (IE, IMPERSONATION)
R.30 LOSS OR COMPROMISE OF OPERATIONAL LOGS
R.32 BACKUPS LOST, STOLEN
Under the “LOSS OF GOVERNANCE” topic, ENISA lists the following vulnerabilities:
Unclear roles and responsibilities;
Poor enforcement of role definitions;
Synchronizing responsibilities or contractual obligations external to cloud, clauses within a SLA with conflicting promises to different stakeholders;
Audit or certification not available to customers;
Cross-cloud applications creating hidden dependency;
Lack of standard technologies and solutions;
Storage of data in multiple jurisdictions and lack of transparency about this;
No source escrow agreement;
No control on vulnerability assessment process;
Certification schemes not adapted to cloud infrastructures;
Lack of information on jurisdictions;
Unclear asset ownership.
Quite a mouthful of possible issues compromising security wouldn’t you agree. Be aware, those vulnerabilities comprise ONE topic.
These are all risks that no one in cloud organizations like to bring out into the open for discussion. In fact, I don’t think any cloud provider will do it willingly, whether it’s SaaS, PaaS or IaaS. Perhaps in a broad sense they might, but that would force security organizations such as ISACA and ISC2 to introduce “Ambiguity Tolerance”  into training and subject matter. Regardless of opinions, let’s differentiate between you as both data owner and administrator, who is tasked with due diligence on data, processes and the likes within your company, as opposed to someone who works at a cloud provider who is tasked with keeping “the cloud” secure. As a manager, it is easier to determine whom should have access to what data as well as what roles are given to whom and why. For example, you don’t want someone in the mailroom having access to the servers or data in finance. In “the cloud”, you can never be sure beyond word of mouth whom has access to your data, because control is not in your hands. This reality meshes strongly with ENISA’s risks desingated R.2, R.3, R.10, R.11, R.20, and R.33, whether like it or not.
Imagine for a moment that you sign up with, say, SomeCloudCompany.com who is offering cut-throat rates that “can’t be beat“, “with prices so low they’re practically giving it all away!” (Remember Crazy Eddie?) After signing up with this company, seeing how their “data center” looks mighty impressive and is coupled with some great marketing, you find out that someone, in say another country, has access to view that data. Because the provider outsourced tasks such as programming or system administration, your data is now visible to someone who would have never seen it had you kept it in-house. That in itself heightens risk and it is something that occurs almost daily. There is always a reason why the prices are so cheap, but at what expense? Are you willing to throw away the keys to your kingdom to save pennies on the dollar?
Aside from that, as mentioned in ENISA’s document, what can you do when “Audit or certification IS not available to customers”? How can you truly be sure, outside of word of mouth, SLA, ToS, etc., that at some point in time someone with a clue audited your segment of the cloud. An audit MUST BE (not should be), must be done prior to trusting an outside source with your data. If this is not done prior, you might as well post all of your client data on a text page and make it searchable BY Google. By not independently auditing and/or validating security risks, a misconfigured system, say via a SQL injection attack, could cost you dearly. Information security auditing is not and must not be viewed as “run a tool to check for holes!” followed by a summarized pie chart with pretty colors. Saying that “we did our due diligence, we ran ten tools against your PaaS instance!” is a shameful method of thinking. Running tools allows for an easy compromise, since after all, weren’t both Heartland and TJX “PCI Certified.” Far too many security managers have lost sight of their roles and have come to rely too much on automated tools: “We run THE INSERT_VULN_SCANNER_HERE on a daily basis. We’re secure!” For these types of security professionals, if they haven’t gotten a clue yet, the odds are that they never will.
Loss of governance couldn’t be any clearer. No more of ensuring you’re compliant, no more of your staff running security tools. Sorry security folks, but no more HP Webinspect, CORE Impact, CANVAS, Nexpose, Shavlik. Nada! No more validation, Because you’re at the liberty of the provider. Please don’t be fooled Mr. CIO/CTO/CSO, since there are plenty of methods that a provider can use to mislead you into thinking that your virtualized company has received a “thumbs up” on security (consider again, for example, TJX and Heartland). You do know that a provider can run any tool against a pre-defined, known-to-be secure cloud instance and pass it off as the cloud you’re on? There is NO way for you to validate this, As ENISA risks R.2, R.3, R.20 can validate this to an extent. A provider will not allow you to potentially disrupt other customers, so you will never ever be sure. There is no “assurance” in the cloud–period; But alas, there always is marketing.
John Engates, CTO of Rackspace, stated IN Forbes Magazine: “You have to treat it like a factory instead of like a custom shop. You have to think large-scale. It might be easy to do something for one customer, but you have to think about the next 1,000 customers behind them, because everything has to be replicable, both from an operational standpoint and from a technology standpoint. You have to be able to do a lot of work with relatively few people. You always want to make a customer happy, but sometimes you have to say no to be able to have a scalable product or service. You need a menu of offerings; you can’t do one-offs–they’ll break the model.“
ENISA states: “No control over the vulnerability assessment process” and, while this statement alone would stop me in my tracks before signing anything over to any cloud provider, John Engates validates this (at least for Rackspace’s practice) by stating: “You have to treat it like a factory instead of like a custom shop.” That statement makes me cringe. From the technical aspect, I’d like to validate independently that my data, MY processes and MY business are secure. I don’t need a “trust me…” statement from anyone, especially when they make eye opening statements such as Engates’: “You need a menu of offerings; you can’t do one-offs.” Validation for me means proving to myself, and to my superiors who in turn answer to shareholders, that we’ve performed not only our due diligence, but we also take the privacy of our customers serious. Not only that, but my customers and their privacy are more important to me than treating them solely as some bits of zeros and ones. When I do answer my phone, I don’t address my client as: “010011010111001000101110001000000100110001101111011100110110010101110010” or “9AE45C4098DEE6CAE4.”
I try hard to give my clients personal assurance as well as security and peace of mind. In the end, without my clients, I have nothing.
Reading ENISA’s paper allowed me to see other dangers that I’d missed or overlooked. ENISA is one of the first “cloud anything” groups I’ve even seen that has mentioned “guest hopping,” yet sadly they minimize the threat by calling it “so-called guest hopping!” This is interesting. While I would rather not ramble on about what guest-hopping is, I’m hoping that you can determine what it means on your own, if you find find that to be a new concept. ENISA’s view seems contradictory in that they state “so-called guest-hopping” yet they reference an existing hypervisor exploit called Cloudburst.  Now imagine if you can, this following statement coming from a politician: “Enemy Zero *MIGHT* have a nuclear weapon… Here is a picture of them using the weapon.” Wouldn’t a statement like that make you think twice about their view? By the way, for those unfamiliar with what Cloudburst is and what it does, I’d rather save time and quote than to type more than I have to: “The risk here is that in a Cloud environment, a virtual machine can run a program that escapes into the Host O/S and CAN be used on other virtual machines belonging to other companies. These compromisation attacks could be identity or intellectual property theft, confidentiality, or simply hide a Trojan for delayed attack on other systems.” 
At this point, ask yourself an honest and logical question for a moment: “If my bank decided to move their operations to the cloud to save themselves a penny, would I use them?” Personally, I wouldn’t. I would always have questions like: “What happens if the cloud is unavailable? What happens if they find out months later THAT my data was compromised? Who do I sue?” Then again, if my account is wiped out, it likely wouldn’t matter in the immediate, because I’d have no money to hire a lawyer to start a lawsuit. All it takes is one incident to bring down the house. This one bad incident has happened to countless companies already. In any case, I’ve been reading so much about cloud computing this week that I’m literally seeing clouds. I will discuss further risks broached ENISA’s paper soon. Stay tuned!