“Old age is like a plane flying through a storm. Once you’re aboard there’s nothing you can do.” – Golda Meir
Let’s set the context to begin with: the “cloud” is your infrastructure and data in someone else’s data center. Most components of this infrastructure have IP addresses and so are hackable. Worse still, your data is stealable and/or leakable.
Now, to a more polished definition, the National Institute of Standards and Technology (NIST) defines Cloud Computing as “a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction”. This is the most complete definition I have found so far – all the key selling points of cloud computing wrapped up and delivered in one sentence! Now if you’re a cyber security practitioner whose heart skips at the mention of the word “cloud”, I’ll advise you start training your heart to get used to it. Like a security breach (which is a matter of when rather than if it will occur), migration of some or part of your infrastructure or data to the cloud is inevitable. Infact, you probably already have terabytes of business critical data in the cloud that you’re not aware of. Coming to the realization that the tremendous cost savings (if adopted properly!) and agility offered by cloud computing is just too attractive to those accountable for bringing the desirable impact to the bottom line should be a no brainer.
Some say going to the cloud means you lose control; others say going to the cloud means you gain more control; I say it depends on the controls you put in place. The worst sin that a cyber security practitioner can commit is to have (or provide) a false sense of security. No security at all is much better than a false sense of security because if you admit that you have no security then at least you already know that something needs to be done. Non-security people can easily be forgiven for committing this same sin. To the adversary, it makes no difference where your infrastructure or data is. If the target server is accessible over the network and the target data is trade or dirty secret, the rest is simple! Pitching to decision makers that having your infrastructure and data in your own data center enhances your security posture, based solely on that premise, is a great mistake. It is like a false negative in security events monitoring world – bad stuff are happening but your tool is (falsely) indicating that everything is hunky-dory.
For all its merits though, cloud computing has its demerits especially if adoption is not well thought out. One key thing to bear in mind is that a cloud transition project would have failed should key organizational objectives not be adequately enabled and/or supported post-transition. Few among other things to bear in mind are your organization’s risk appetite, legal obligations and regulatory requirements. Suffice it to say that cloud adoption has to be in line with an organization’s overall strategy.
The primary goal of every organization in the private sector is to be profitable, not secure. If securing the infrastructure and data that run its business makes it more profitable (it sure does!) then security, being a business enabler, becomes one of many secondary goals. To this end, security practitioners need to realize that just saying “No” or “It’s too much of a risk” without properly making themselves understood by answering the “why” question in the most simplistic way would not make business leaders change their minds. They will do whatever they’re planning to do where they believe it is in the best interest of the organization. Providing a reliable and usable data point in a timely manner to support the decision making process is the job of every security practitioner. Following this, you should be fine with whatever direction the business decides to go as you would have done your job to the best of your ability. As a way to help organizations develop practical solutions to implementing cloud services safely and securely, the Information Security Forum (ISF) published a report which outlines and addresses “seven deadly sins” that should be avoided when implementing cloud services. They are as follows:
- Ignorance – little or no management approval
- Ambiguity – contracts are agreed without authorization, review or security requirements
- Doubt – little or not assurance regarding provider’s security arrangements
- Trespass – failure to consider legality of placing data in the cloud
- Disorder – failure to implement proper management of the classification, storage and destruction of data
- Conceit – belief that enterprise infrastructure is ready for the cloud when it’s not
- Complacency – assuming 24/7 service availability
Which of these is your organization guilty of?
Whether your organization has already selected a Cloud Service (or Managed Service) Partner (CSP or MSP) or is in the process of selecting one, here are five (5) key things you need to think about as a security practitioner (bear in mind that your most advantageous position is prior to signing on the dotted line);
- MSP or CSP – In order to determine what controls you can exert, you would need to understand the type of service to which you’re subscribing. MSP Alliance defines Managed Services as the proactive management of an IT (Information Technology) asset or object, by a third party typically known as a MSP, on behalf of a customer. The key difference between an MSP and a CSP is that with an MSP, for the most part, the customer has the right to dictate the security controls (my asset, my rules!). The leverage isn’t so much there with a CSP where the provider lets the customer know what security controls and operating procedures are in place. The closest analogy I can think of is the difference between a real estate owner and a tenant. A real estate owner can dictate what type of maintenance standards and procedures to which his/her management company must adhere if they must win or retain his/her business (think MSP). Conversely, a tenant has to live with what his/her landlord or property manager has on offer or go look for another property that suits his/her needs (think CSP). Looking at the above example, it is quite clear who occupies the position of maximum opportunity. Like the real estate manager, the MSP will do their best to win your business. In terms of security controls, they will almost always tell you they can do anything and everything. To draw parallels between their guiding principle and the biblical verse Matthew 6:33 “seek ye first the kingdom of God, and his righteousness; and every other things shall be added onto thee”, in the MSP’s world, it is “seek ye first the opportunity to boost profitability – as you know its benefits – and your rewards shall be plentiful”. Don’t get me wrong, some of them will already have most of these security controls as it’s a business enabler for them. However, it is important to “tell them what you want them to do” rather than “ask whether they can do what you want them to do”. There’s a big difference there! In the latter case, they will almost always say YES first and then go figure it out if they don’t already have that capability. Also, the fact you’re asking if they can do X (rather than tell them “here is how we want X done”) already gives an hint that you probably don’t know what “sufficiently good” looks like.
- Shared Responsibility – Once you’ve gained enough clarity on the type of outsourced service to which you’re subscribing, the next thing to do is understand who is responsible (and ultimately accountable) for what. There’s a brilliant article on Microsoft Developers’ blog site which talks about the fact that elements of defense in depth such as host security, network security, data security (and so forth) controls still need to be addressed regardless of your deployment model. The figure below (taken from the same article referenced above) summarizes quite well how shared responsibility works across different cloud service models:
It would be highly beneficial to know now who is accountable for the security of your cloud-based asset rather than learn the hard way following a security breach – when your intellectual property may have potentially become public property.
- Security Assurance – identifying and implementing security controls is one thing; ensuring that those controls are effective and working as intended is another. Achieving this assurance can be quite challenging in an environment where you do not have full control over the IT infrastructure. With this in mind, when discussing security technologies and processes with your potential cloud partner, ensure that you’re not being led down a blind alley. For instance, looking at the cloud model graphic above, the cloud customer is responsible for data protection in each of the deployment models. This means that if you have a business need to encrypt your business critical data at rest, you should be in custody of your cryptographic keys – to get to your data, the adversary will need to get through you first. Most providers will promise that they have strict controls around key management (remember, they won’t say NO) but having them manage those keys flies in the face of best practice. It always comes down to a risk tolerance or cost vs benefit decision though. In addition to data security and cryptographic key management, other security controls that should be seriously considered are vulnerability management, host security controls, firewall assurance, multi-factor authentication, and application security.
- Continuous Visibility – One of the key tenets of cyber security is “prevention is ideal but detection is a must”. In accordance with this, maintaining situational awareness of security events associated with your infrastructure and data is critical. Think about, develop, and test your alert use cases prior to go live to ensure that potentially damaging security incidents wouldn’t be flying under the radar once you’re up and running.
- Incident Response – If you had an incident response plan prior to moving your resources to the cloud then you need to pull it up and start updating it to reflect what obtains today in your world. Roles and responsibilities will change and so will response procedures around incident containment, eradication and recovery. You will no longer be able to instruct a colleague in the data center to pull the network cable and take that compromised server offline; you will no longer be able to do memory or dead box forensics on that same server; and you may also not have all of web proxy, firewall, IDS/IPS, and host event logs available for correlation and analysis. When Service Level Agreements (SLAs) are mentioned as part of a managed service, they’re usually in relation to system/network uptime and service availability. Those who wear the security hat should define incident notification and containment SLAs that align with organizational risk tolerance level prior to signing any agreement.
Finally, to answer the question “To cloud or Not to Cloud”?, Not to Cloud is not an option because, slowly but surely, the cloud is already coming to a location near you!