Cloud computing environments are designed to be secure by default. That does not mean, however, that they are free from security vulnerabilities, or that there is nothing you need to do as a user to keep your cloud workloads secure. On the contrary — while cloud providers offer tools and services to help defend your environment, a great deal of the security burden falls on you.
Shared Means Shared
The basic model for cloud security is shared responsibility. What does that actually mean? What is shared and how is it shared?
When it comes to dividing up responsibility, there are three main levels of cloud security:
Cloud Service Provider (CSP) Responsibility
Because of the nature of the cloud, there are some types of security that are necessarily the responsibility of the service provider. These include:
- Physical Facilities: Guarding the location where the cloud hardware is operating;
- Personnel: Screening and monitoring all employees who have or may have access to either the cloud infrastructure or user data;
- Cloud Infrastructure: At the hardware and software levels, including cloud management, virtualization, memory and storage management, etc.
This does relieve you of many of the security responsibilities otherwise associated with local on-premises servers. The other side of the coin is that past a certain point, you have to trust the CSP to maintain a sufficiently high level of security at its end and to take measures to protect your data and your operations if something does go wrong.
Outside of the domains where security is the unavoidable responsibility of the CSP, there are areas in which service providers may and often do either take responsibility for security or provide clients with facilities for managing their own security. This includes security for individual software as a service (SaaS) applications, as well as optional security features you can apply to your cloud-based operations.
It is your responsibility to know which security features the service provider activates by default, and which features it offers on an optional basis — and it is very definitely your responsibility to make use of those features.
When you operate in the cloud, you’re renting space (along with the associated facilities) from the CSP. What goes on in that space is your responsibility. That means it’s up to you to make sure that the applications and websites that you develop or manage have adequate security, and that any data which you store in the cloud is secure.
Simply storing a document in the cloud is not a guarantee that it will be secure. Some types of storage come with built-in access controls, but in other cases, it may be up to you to control access. Your default assumption should be that you are responsible for the security of everything that goes on within your rented cloud space.
Beefing Up Security
What can and should you do to beef up cloud security and take care of security in those areas which your CSP does not handle? Here are some basic steps:
Understand Your CSP
Find out which security features and services your CSP activates by default, and which ones it makes available as an option. You also need to find out how your CSP rates when it comes to providing basic, infrastructure-level security. The large, well-known cloud providers are typically very security-conscious, but you should be aware of any outstanding security issues involving services which they offer.
With smaller or lesser-known cloud providers, reports of frequent security breaches or chronic security issues at the facility/infrastructure level may be a sign that it’s time to look for a new cloud on which to hang your operations.
Use the Tools Provided
You need to know which security resources and settings your CSP makes available, and you need to put them to work. This includes resources for limiting access to data, setting user privileges, encryption, passwords and monitoring. Don’t assume that security features are activated or security settings are turned on by default.
The actual security resources available from your CSP may (and for the most part, are likely to be) extensive and reasonably configurable. If they aren’t activated or set by default, that doesn’t mean that your CSP thinks that they aren’t important. It can simply mean that there’s no practical way to set them until you upload data, set up user accounts or create databases. It also can and usually does mean that your CSP expects you to understand your own security needs and to behave responsibly in meeting those needs.
Use Security Policies
Adopt basic security policies for cloud operations and apply them consistently. When you do this, you are much less likely to neglect an important security issue because you’ve assumed that your CSP will take care of this. Key policy areas include:
Passwords and Authentication
In the past few years, large enterprises and government agencies have experienced major security breaches (some of which involved large volumes of confidential user data) as a result of storing sensitive data in the cloud without any password protection. You can’t assume that because the address of a document isn’t public, no one will find it. In fact, it’s safer to assume the opposite — that people will find it, and try to make use of it.
Your default policy should be to require passwords for locations where data is uploaded. You should also take a close look at the kinds of password-expiration and authentication policies that will best suit your organization. It’s better to experience a little in-house inconvenience than a public security meltdown.
Privilege levels (for users, for roles, for anything else) should be no higher than necessary — if it isn’t necessary, don’t allow it. Even admin accounts should be set to levels lower than root when at all possible. Ideally, any attempt at privilege escalation by an attacker should lead to nothing but dead ends.
And needless to say, no admin or root account should ever be left with its default password still in place. Any account with a high privilege level should have a password that is both very difficult and non-obvious.
Encrypt your data. You can never be completely sure no one will be able to access the location where a document is stored. A security breach on the CSP side, for example, might give attackers access to everything stored on the servers. If the data is adequately encrypted, however, they won’t be able to use it.
If you develop software and run it in a cloud environment, then (as is the case in any environment), anything that software does is 100% your responsibility. For container/microservice-based applications (which are in many respects cloud-native software), this means you need to follow basic container security best practices. These include:
- Use a private container image registry for full control over your container images;
- Scan your container images regularly for vulnerabilities and other security issues;
- Limit user privileges inside containers, for all of the reasons outlined above;
- Do not include unnecessary resources. Containers should only include what they need to do their job;
- Monitor containers for potential security problems while they are in operation.
What about serverless applications? A serverless application typically runs in a container that is managed by the CSP, which is by necessity responsible for infrastructure-level security. You, however, are responsible for what the application does, just as you are responsible for the contents of any container that you deploy. In terms of security, this means that it must behave properly with respect to your data and all other applications with which it interacts. Basic best practices for containers still apply.
The task of maintaining a high level of security for cloud-based applications becomes much easier if you use a comprehensive cloud-oriented security service such as Twistlock. A service of this type will allow you to scan container images before deployment, and to monitor containers in operation in order to detect both potential security breaches and anomalous patterns of behavior, while alerting responsible individuals when such problems are detected.
Cloud security may not always be simple, but it doesn’t have to be a mystery. With a clear understanding of how it works, and with the right tools, you can turn the cloud into a genuinely secure environment in which to operate.
This post originally appeared in The New Stack.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Beyond App Security: Securing Applications No Matter Where They LiveRead the Blog
Surveying the Container Orchestration LandscapeRead the Blog
Building the Right Toolbox for a Successful DevSecOps CareerRead the Blog
BOD 19-02: DHS Vulnerability Remediation RequirementsRead the Blog
How Cloud Native Security is Adapting to New Hybrid Reality for EnterprisesRead the Blog