The move to AWS and other cloud services is a strategic initiative for many enterprises today. While companies rush to expand their cloud presence and use more cloud services, security considerations are lagging behind. This article will discuss five key threats in cloud computing, and some of the ways to defend against them.
A common mistake by security teams is the belief that traditional approaches to data security, such as perimeter control, also apply to the cloud. As a result, valuable resources are being allocated to endpoint security and server security, firewalls, etc, whereas the focus in going to the cloud is growing within the following domains:
Mobility: Employees are no longer working from a specific office or location, hence how can we protect this new office structure?
BYOD: Employees not only connect today from all over the world, but also with their own laptops and mobile devices – how can we control employees’ personal devices?
Application Mobility: Most of an organization’s applications are mobile – we consume these services from SaaS providers such as Gmail, Box, SalesForce, Office365, etc
Public Clouds: The cloud has overtaken traditional data centers, and we are now configuring our servers through providers such as AWS, Azure and GCP.
SSL: Secure connections are becoming a must for all applications, and all data is encrypted; normal security solutions are blind to SSL traffic – how can we defend what we cannot see?
I. Serverless Risks
Serverless is an emerging computing concept that has been gaining momentum. But security professionals need to ask themselves key questions.
1. Does the fact that we no longer directly manage our infrastructure mean that we no longer manage its security?
2. Has the number of threats increased?
3. Are our tried and trusted tools capable of dealing with the threats to serverless computing in the cloud?
In the serverless world, your functions can run on any physical or virtual instances within the cloud provider. This means that the new security perimeter is around your function, and not around the platform on which it runs. Moreover, functions can run on instances that spin up momentarily and then spin down once the function has run, making it difficult if not impossible for traditional security tools to handle.
So, what can we do to secure the serverless world?
Permissions – it’s all about permissions. The security manager must ensure that permissions are always the least necessary to accomplish the task. Since serverless functions are so interconnected, it is essential that each function has the minimal level of permissions it needs to do its job, and no more. It is recommended that security audits be performed periodically to review the permissions granted to functions.
Open Source Dependencies – today a significant amount of code comes from open sources, such as Python, Node.js and Maven, so it is important to check these sources and packages for vulnerabilities, preferably using automated tools that check against up-to-date lists of known vulnerabilities, and can issue warnings.
3. Poor Coding Practices – in the serverless world, code is deployed to production very quickly, leaving less time to detect errors. This can expose your development environment, and leave openings for attackers to exploit. It is important that developers be trained in development security, and that code be checked for security issues using automated tools.
II. API Misconfigurations = Asset Exposures
All resources in the cloud are usually one API call away. Typically, cloud providers will provide an API for almost any resource, in order to provide developers with programmatic access to their cloud environment. As a consequence, attackers also need only the correct API, with the correct credentials, to compromise these same resources.
Mitigation – The responsibility here is shared between cloud provider and customer. The cloud provider must ensure the security of the API. The customer must periodically review the level of security of their API portals in issues such as how and where credentials and keys are stored. The customer should also periodically test the security of their API portals, by conducting penetration tests.
III. Compromised Access Keys in CI/CD Systems
Theft of keys from code repositories such as Github or Bitbucket is one of the main attack vectors used in AWS. These are widely used platforms, and careless storage of keys or other sensitive data in code repos can provide easy access t. o cloud networks.
Mitigation – The clear recommendation is to never store access tokens, passwords, or other authentication or encryption keys in the code. If the developer must include them in the code, we recommend they implement additional operational safeguards to prevent unauthorized access or misuse (such as encryption).
IV. Permission Elevations
Gaining access to a root account on an instance is “striking gold” for an attacker, and game-over for an organization. IT personnel who are not familiar with cloud platforms can cause considerable damage to their organization by improper use of root accounts. Not only with root account access, but when granting IAM permissions to other users, it is important to check which permissions are granted, and for what purposes.
For example, AWS policies are JSON objects that specify which permissions are granted. These policies are attached to resources such as S3 buckets or EC2 instances.
A simple policy will look like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": [
"arn:aws:s3:::MyExampleBucket/*"
]
}
]
}
Often, in the haste to develop and deploy applications, or under pressure of troubleshooting, permissions may be granted that are much wider than necessary. This can be as simple as adding a “*” in a policy, something that is easy to overlook:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:Get*",
"Resource": [
"*"
]
}
]
}
Mitigation
1. Follow the principle of least privilege – restrict the use of root account
2. Enforce password policies for IAM users
3. Rotate root account keys and always enable MFA
4. Use CloudTrail to log & monitor all user activities
5. Remove unused IAM users and credentials
V. Network Attacks on Overly Permissive Security Group Policies
Because of the ease with which Security Groups can be created in cloud environments, IT personnel can easily, and sometimes inadvertently, create rules that are overly permissive, that provide unnecessary access to your cloud assets. Added to this, the internet is teeming with bots that search for vulnerabilities in cloud networks which can be exploited.
Mitigation – The best way to prevent this threat is to properly plan the Security Groups, to block access to your environment as much as possible, to reduce the traffic that is permitted to your assets, and to eliminate access from ‘any’. This should apply, for both inbound and outbound traffic. Outbound traffic should be restricted to the minimum number of ports necessary.
1. Use VPCs
2. Don’t use public IPs and routers unless needed
3. Use Security Groups at the host level as a personal firewall, control inbound and outbound traffic
4. Make sure your network is simple to understand
5. Use reverse DNS names to protect your elastic IP’s
6. Access only with bastion servers and NAT where possible
7. Make sure you log all the traffic using CloudWatch and flow logs
8. Check your environment constantly for new vulnerabilities
The threat landscape has evolved in the public cloud. As customer workloads transition from on prem VMs and bare metal servers to microservices and dynamic serverless functions, it is imperative for CISO’s to strategically rethink security beyond the traditional network perimeter. For regular updates on security topics, subscribe to our blog