Understanding cloud security #
In this article, we observe security responsibility of cloud providers: where it ends, what are the gaps and grey areas, and what risks security teams should take into account when using “as a service” platforms.
So, you’re planning your new business in an area where security matters, and you start thinking about choosing your cloud provider to build your application on. Typically, you start juggling with a combination of all the nice building blocks you need and financial aspects you’re facing.
At this stage, you might be thrilled with choices between IaaS and PaaS, or operating planet-scale cloud database. Yet, builders usually don’t spend much time on clearly articulating cloud security strategy when they are thinking about starting their next project.
However, if you’re in a regulated industry (like finance or healthcare) or face stringent requirements from your business environment (like in legal, insurance, fintech), there are security choices you need to contemplate as well.
In general, the mind prefers an answer like “it’s a cloud, best security professionals are taking care of it”. Which is quite right (since the provider’s team really polished their set of controls for millions of customers and stood the test of time with them), but this barely gives you a full picture.
New cloud users try to get peace of mind thinking “I’ve put it in a cloud, and cloud is secure”—that could be called risk outsourcing if it was true, but it’s not.
What actually happens is “I’ve put it in a cloud, now I have to make it secure, but on cloud provider’s on-prem and within limitations defined by the other party” — which looks more like risk sharing.
Cloud provider’s security team takes care of many things. It’s all true. But:
- there are some things they can’t do for you.
- there are things they won’t do for you. Alas.
- there are things you shouldn’t trust them anyway.
- cloud provider’s liability in worst case is far from what could make you sleep well at night.
Here we’d like to share a few observations made after deploying our products and building large-scale solutions in various restrictive cloud environments and aiding customers in improving security in their cloud-based solutions.
- Shared responsibility model gaps
- Definite gaps in a shared responsibility model
- Grey areas in shared responsibility model
- More clouds—more gaps
- Wrapping up & next steps
Shared responsibility model gaps #
Despite the fact that many cloud providers clearly outline their (very limited!) area of responsibility in their usage policies, many customers still rely entirely (and blindly) on the cloud provider’s security efforts.
In general, the application owner is responsible for system’s security for everything that goes above the hypervisor level. Also, they must set up and configure the available security tools of cloud providers, like access control, firewall, logging, backups, etc.
Azure cloud shared responsibility model. Source Azure docs.
Publicly available S3 buckets without any authentication cause huge data leaks. A fresh one counted 24.4GB of data. It became such a typical mistake, that OWASP WSTG now has a separate requirement WSTG-CONF-11 and test case to cover S3 configuration issue.
To put it simply, depending on the cloud provider and their services, responsibilities are expressed as following:
IaaS: responsibility ends at hypervisor. Customers are responsible for application security, data security, middleware security, and host configuration and security.
PaaS: customers are still responsible for their custom applications, data security, application security (sometimes), interfaces, credentials, and platform configuration.
SaaS: customers are responsible for their credentials, interfaces, access, and data.
Shared responsibility model explained. Source Cloud Security Alliance.
In all these cases, access controls, identity management, data security, and control configuration are the customer’s responsibility.
However, are cloud providers really responsible for the things they say they do?
AWS Customer Agreement (see 4. Your Responsibilities) says that “you are responsible for all activities that occur under your account, regardless of whether the activities are authorized by you or undertaken by you, your employees or a third party” and AWS “are not responsible for unauthorized access to your account.”
Also, you’re responsible for your content, for compliance to laws and data regulations, for backups and security, and for keeping your credentials and keys in secret.
You need to analyze whether a cloud provider’s responsibilities are enforced in a way that fits your risk appetite, because even if the cloud provider takes responsibility for security incidents, it’s unlikely that they will compensate for financial or reputational losses for your company when breach happens.
Now that we see the big picture, let’s try to focus on the gaps and grey areas.
Definite gaps in a shared responsibility model #
Cloud credentials and access control #
Admin control. If you don’t design your systems in a clever way, once attackers get admin control over your console, it’s game over. What’s worse—it’s gameover for your whole project, not just one server. Cloud providers are responsible for letting admin credentials owner to do everything they want—unless you’ve explicitly configured not to do that.
Service credentials. The lifecycle of keys, tokens, database passwords. You should define how to share keys across your development team members, how to notice leaked keys and rotate them.
User credentials. If you store users’ passwords for authentication—you become responsible for managing their secrets.
Cloud configuration #
- Service setup. As CapitalOne case shows, in the end you’re responsible for services you’ve misconfigured (or were not aware that you have to configure them).
Data security in a shared responsibility model #
The data owner, but not the infrastructure operator, is held responsible for a breach under a number of regulations (GDPR, PCI, CCPA, country-wide regulations).
All you get from a cloud provider are basic controls, like data at rest encryption, and your provider has access keys and cryptographic keys to encrypted data.
You can either BYOK into your providers’ infrastructure, or you can build your own protection layers (client-side encryption, or transparent field level encryption using tools like Acra).
Application logic and code #
- Whatever you produce—you own its security risks. Application security, dependency checks, patching vulnerabilities, security of your CRUD API, logging, monitoring, analytics of user behaviour, etc.—that’s your responsibility.
Transparent field level encryption for your cloud databases: Acra database encryption suite. Easy-to-deploy and easy-to-manage searchable encryption with zero lines of crypto code.
Grey areas in shared responsibility model #
Identity and directory infrastructure: whether your IAM, directory service or whatever else is hosted locally or in-cloud, it’s LDAP or some weird new tech—you are responsible for managing it, making it a reflection of your security policy that drives access control decisions, and monitoring it.
Networking: although your provider is responsible for core networking, everything that happens above virtualization is your problem, to some extent. Thus, you’re likely to need to manage security-related configuration of relevant assets.
OS: depending on the type of cloud architecture you’re pursuing, you might end up managing OS images yourself. While your cloud vendor provides you with base images of modern server operating systems, your job is to ensure they’re secure and well-configured in your use-case.
Responsibility for security IN the cloud vs Responsibility for security OF the cloud. Source Amazon AWS Shared responsibility model.
More clouds—more gaps #
But these are not all the concerns. There are specific cases where aside from deciding where the responsibility is—you’ve got to actually understand how this responsibility is implemented and enforced:
Multi-cloud and hybrid cloud concerns: #
When your solution operates on multiple public clouds, you need to carefully map the gaps that are different between various cloud providers and ensure that core controls are consistent (or cloud agnostic).
You might want to have a compatibility layer for identity management, application level key management, enforcing the same data protection policies (encryption, tokenization, masking) between your clouds.
Cloud-based CI/CD pipeline: #
If your CI/CD pipeline takes place in a cloud, it becomes one of the primary targets for advanced attacks—unless you monitor and secure it well. Check out stories like XcodeGhost (patched Xcode version that silently injected malware into apps), M.E.Doc, and other supply chain attacks.
Mapping controls in attestation: #
Make a pause to map security controls from your cloud provider into your coverage map. Surprisingly, it could lead you to many uncomfortable questions we’ve outlined above. Especially, if you have third-party assessments providing any kind of attestation to your infrastructure, and “security control coverage” is something you have to obsess about.
You inherit some of the controls from your cloud, at least formally, but when you look at how much you really control in that security control—you don’t control much.
While you can impress your auditors with this clever checklist trickery, attackers enthusiastically benefit from lack of practical attention to appropriate security controls.
We work with companies on demanding markets. Read how Acra database security suite protects data in critical infrastructure.
Wrapping up & next steps #
When defining your cloud strategy, security risks should be treated equal to all others—with meticulous analysis. Because you’re not “putting it in a cloud that’s secure by design”.
When you host your apps in a cloud, you are solely responsible for data security, appsec, managing secrets and accesses, and configuring tools providers give you.
Yes, you may win a lot by putting your assets in-cloud, but only if you’re actually doing it with your eyes wide open.
If you’re struggling with securing data in your apps deployed on the cloud, you’re not alone, feel free to drop us a line to get some assistance.
