I guess you would agree that security is one of the most important topics today. The environment is changing so rapidly that old security tools, tactics, and principles become obsolete in a blink of an eye.
Cloud is a new normal and it applies some specifics and changes the landscape of what we call security today.
In the next few articles, I’ll try to give you a helicopter view of a modern security system that would work for a cloud environment and cover 90% of cases. As well I’ll try to share some tools and specific tips, but the format of an article is limiting. So off we go on the adventure of Cloud Security!
NIST framework
You probably already know the Cybersecurity Framework designed by the National Institute of Standards and Technology (US). If not, please visit nist.gov and specifically https://www.nist.gov/cyberframework/framework . There are a few standards that we consider in our practice of security, but for this article, we will focus on the NIST framework.
NIST tells us how our cybersecurity system should look like, and which building blocks it is constructed with. It decomposes all security tools, processes, and practices into five buckets:
The specifics in cloud security is driven by a few factors:
- there are few models of the consumption of cloud services (IaaS, Paas, iPaaS, SaaS, etc.),
- cloud provider usually offers some security tools and best practices which might or might not work well or better than standalone tools (for example, NewRelic vs CloudWatch, etc.),
- cloud services are evolving at a great speed (for example, some time ago CloudWatch had no way to gather logs and monitor constrainers, but now this is no longer a problem, etc).
In a cloud environment (and especially in a multi-cloud) environment we have to iterate the five steps described in the NIST framework often enough to be able to keep up. A general recommendation is to re-evaluate your Cybersecurity framework at least once a year.
In the next few articles, we will discuss all five groups of security activities (Identity, Protect, Detect, Respond, Recover) from the perspective of cloud security.
Identify
First of all, let’s check what assets we have so we know what we’re protecting. In cloud environments, there is a concept of accountability span. To put it simply some of the assets are out of our control and we have to trust the cloud providers to secure them. The diagram below illustrates how accountability spans look like for IaaS, PaaS, and SaaS models. The blue color is a cloud provider (AWS, Azure, GCP, etc.) accountability areas, and yellow – customer (us).
The more control we have the more we have to secure. Some time ago security was one of the concerns that made companies hesitate to move their assets to the cloud. Today we all know how great their security is and this is no longer the case (well, mostly).
Now you can review your assets that are in your accountability span and define what you’re going to be protecting.
Here is a list of potential assets you would be willing to secure:
- VMs,
- Containers,
- Kubernetes clusters,
- App platform as a service,
- Serverless services,
- Storage,
- Databases,
- Message queues,
- Configuration storage,
- Secrets configuration storage,
- Encryption key storage,
- Certificate storage,
- Source code repositories and deployment pipelines,
- Network Assets.
Each of them would have a list of potential vulnerabilities. Like for example, VMs have vulnerabilities called “hypervisor breakout” and “VM escape”. Both of them are caused by the virtualized nature of VMs.
Protect
Ok, so now you know what you’re protecting. Let’s see what possible principles, tools, and instruments you can use to protect each. We’ll talk about protective measures in Identity and Access Management, Data protection, and Network security areas.
Identity and access management:
- Least privilege: this is one of the core security principles. Check if you have users (or service accounts) that have more permissions than they need to perform their activities. Reduce authority to only absolutely necessary. Use Role-Based Access Control policies and Security Groups when applicable.
- Separation of duties: second core principle, we should not give too much power in one person’s hands (for example power to commit and deploy code to production, or power to create and authorize payments, etc.). Try to avoid such super-users as they are very good targets for the attackers.
- Trust boundaries: inside your secure perimeter, each asset would trust some entities more than others (for example, a database should trust application on a certain VM, but not the rest of the world, and it can trust admin, but after admin will be authenticated and authorized). Make sure to visualize different trust boundaries and implement them.
- Layered security: there is a temptation to think that entities operating within the secured perimeter (admin accounts, or service accounts, not users from the internet, for example) could be trusted. This is very risky. Because it is quite often that attackers use one of such trusted entities to break into the secured perimeter and do bad things. To avoid this, create layers, and limit the abilities to cross boundaries, implement additional checks and authorization procedures. If done right it will help you a lot at an hour of trouble as you will be able to localize the damage from the breach.
- Multi-Factor Authentication: this is fairly straightforward. Make the life of attackers harder so they also have to still somebody’s phone not just password.
- Single Sign-On: many people use the same or similar passwords. This means that our security is as strong as the weakest system in the chain. And it could be a mail service or a browser game. It is usually a good idea to use SSO with strong requirements for passwords so you have more control over the authentication mechanism.
- Secrets encryption and management: it might sound counterintuitive but you should keep your secrets in secret. It is all I can say here.
- Identity governance: it is easy to create identities and provide access in the cloud and it’s even easier to forget to delete identity or revoke access. Make sure you have a mechanism to check and revoke access that is no longer needed.
All the limitations and policies described above are managed via cloud Identity and Access Management Services (such as IAM in GCP, Cognito in AWS, or Azure AD, etc.).
Great, we’re almost done! Next comes data protection.
Very often the target is the data. Attackers aim to steal or corrupt the data we have. By doing so they expect to either get paid or us to suffer. The principles and tactics described above should be very helpful for data protection. But we also have to consider data encryption. Also on top of the encryption sometimes we might need a mechanism of data self-destruction. But his is a topic for another article.
There are a few places where you’d want to encrypt your data:
- Sensitive user information (like user financial information, etc.). For such data, it is recommended to use the Tokenization procedure (PCI DSS and other standards). Cloud providers have some services that offer partial or full range data loss prevention tools that perform tokenization of such sensitive data (GCP Cloud DLP, AWS KMS + Lambda, Microsoft 365 Data Loss prevention, etc.)
- Data at rest, meaning data that is stored in the database, storage, and filesystem. There are two basic ways to encrypt data at rest: server-side (database, storage, for example, SE-S3, SSE-KMS) and client-side (application). Cloud providers provide an ability to implement Transparent Data Encryption (required for PCI DSS) for data in a database (columns or entire DB) and storage encryption (for example in GCP databases and storage are encrypted by default and we don’t have to do anything).
- In transition: when we’re transferring the data, it should also be protected. Most often SSL/TLS protection would be sufficient, but not always. Sometimes it can require a VPN or other ways of secure data transfer.
- It is quite often that we forget to protect data in use. When an application is using the data and it is located in memory or in the process it is also vulnerable. Some cloud providers have services (such as GCP Shielded VMs and Azure Confidential Compute Trusted Execution Environments).
Now that your data is secured in all places you’ve reduced the risks of attackers stealing it. But what if they just want to destroy your assets, or disrupt your operations? Yes, you need to protect your network as well.
Network security measures are pretty straightforward:
- Use Virtual Private Cloud (VNet in Azure) to establish a secure perimeter.
- Segment your network and use Firewalls (layer 4, layer 7, etc.). Usually, the external firewall that filters traffic to DMZ (an external segment of the network) gets a lot of noise, and you don’t want to react each time the firewall blocks connection. But you do want to pay attention to all blocked connections for the firewalls placed inside of your secure perimeters.
- Use RASP (runtime application self-protection) where it makes sense.
- Network access control lists (ACLs) and Security groups will implement an additional layer of protection and control traffic within your VPC.
- Usually it a good idea to have additional security layers for power-users. A good practice is to allow administrative access through bastion hosts. This way makes attackers life harder because they also have to get access to the bastion host. As well bastion host can have additional login, checks of suspicious activities, and notifications.
- Whitelists and Blacklists are two common instruments. Often for the networks and sub-networks inside the secure perimeter, we’d want to disallow all the ingress and egress traffic. And then allow specific requests to go through with a clear and specific goal.
- Use proxies and revert proxies, like AWS API Gateway, Azure Front Door, Google Apigee. They provide an additional layer where you can execute access and routing policies.
- Protect your assets from DDoS attacks. There are quite a few network services like Akamai, Apigee, AWS Shield, Azure DDoS protection, and others.
- Use Transport Layer Security (TLS) whenever possible.
This seems to be a good list for protecting your network that covers most of the possible vulnerabilities.
In the protection section, we’ve discussed passive protecting actions. It is important to review your security system at least once a year and update it. As well it’s always a good idea to go a step further and implement active detective and blocking measures.
In the next articles, we will talk about Detection, Respond, and Recover principles, policies, and tools.
