By Frederick Fernando November 15, 2021

Guest post originally published on InfraCloud’s blog by Frederick Fernando

When you start building your cloud infrastructure, security might not be a top priority as much as getting your project up and running. This might lead you to delay security considerations for later and end up having an insecure cloud environment for a long period of time. The more this is put off, the more difficult and expensive it is going to be to fix this. In worst cases, it might be necessary to re-architect your environment. Worse yet if you do have a security attack, it will cost you considerably more money and effort to respond to these threats. In some cases, external incident response teams have to be brought in and making them do this work is exponentially more expensive. This blog post is to guide you through the basic steps you can take to improve your cloud security posture in the early stages of building your cloud infrastructure.

Some of the important focus areas of starting your cloud security journey are:

This guide is focused towards AWS environments, but almost all of these implementations can be carried forward to other cloud providers. You can also find similar tools for the cloud provider of your choice.

Threat modeling

Threat modeling is the process of identifying threats and then defining countermeasures to prevent or mitigate the threats to the system. This works for a wide range of systems including cloud architectures, applications, IoT devices and business processes.

Steps involved in threat modeling:

The first step involved in threat modelling is to build an architecture diagram of the system you are protecting. This also involves building a list of assets in the system. You cannot protect something which you don’t have visibility over. We can use tools such as CloudMapper from the previous step for building an architecture diagram of an AWS cloud environment. There are similar tools for threat modeling for other cloud service providers like Cartography.

Once you have an architecture diagram and inventory list, you can start identifying threats which can occur to the system. You can use threat modeling methods like STRIDE or PASTA to achieve this.

An example of this would be: What is the likelihood of an attack if a developer’s cloud credentials were to be leaked? What are the mitigating controls to minimize damage if the credentials were to be compromised?

Take action by implementing the mitigating controls. This would help you architect a system keeping the security of it as a crucial part of the design process.

Fixing security misconfigurations

One of the major cloud vulnerabilities are security misconfigurations. According to this report, over 95% of the cloud vulnerabilities are related to cloud misconfigurations. Similar to the previous challenge, having visibility into your current cloud environment is quite difficult. Common misconfigurations include having overly permissive firewall rules/security groups.

Prowler

Prowler is an open source security auditing tool which can help us identify cloud security misconfigurations. Prowler is AWS only. Prowler is a command line tool that helps you with AWS security assessment, auditing, hardening, and incident response. It follows CIS benchmarks for AWS and can also assist in GDPR, HIPAA, PCI-DSS, ISO 27001, SOC2, and others.

You can find the Prowler installation steps here.

Prowler will give you a list of security vulnerabilities in your cloud account. You can take an export of the findings in HTML, CSV, JSON or json-asff format.

Integration with Security Hub

Prowler integrates natively with AWS Security Hub. With Security Hub, you have a single place that aggregates, organizes, and prioritizes the security alerts or findings from multiple AWS services such as AWS GuardDuty, Inspector, Macie and others. The json-asff format comes in handy for integration with AWS Security Hub.

Containing network access

Building a network diagram

We need a network diagram to assess the architecture of the cloud environment. It might be difficult for teams to have an updated network diagram, and due to the dynamic nature of the cloud, you might not know what your cloud environment looks like at any moment. Cloud resources are more often than not spun up without visibility and it gets difficult to have a controlled environment.
For these reasons, it is good to use tools like CloudMapper to visualize the current layout of your cloud environment.

CloudMapper

CloudMapper helps you analyze your Amazon Web Services (AWS) environments. It aids in building network diagrams and displays them in your browser. You can find the CloudMapper setup steps here and using a Docker container. Make sure that you create required read only IAM roles with these privileges.

Network segmentation

By implementing network segmentation we reduce the network attack surface. Consider adopting a fail safe network access approach rather than fail open. Explicit network access should be allowed for required applications. You can implement micro segmentation by using Kubernetes network policies for container workloads. Different environments like staging, development and production should reside in segmented networks or different accounts. Different cloud accounts for business units, workloads, logging, monitoring, identity etc. should be used to further reduce the attack surface.

Improving access to cloud resources

Connectivity to your cloud resources should have secure and private access. There can be multiple ways to achieve this, through a VPN setup to a bastion/jump box. Or have a central authentication system with something like Keycloak or Teleport. You can integrate these systems with federated authentication mechanisms similar to Okta or any other SSO implementations. Another way of doing this is by using AWS SSM, this takes away the overhead of managing your own central authentication system.

Securing IAM policies

User access policies (IAM policies) is another core control which can help you secure your cloud infrastructure. By having good security hygiene around IAM policies you can reduce the potential of an attacker doing extensive damage in case of a breach. Here are some of the minimal security controls for a new project.

Some IAM controls you should consider implementing:

You can use tools like policy_sentry to create least privilege IAM policies.

Security logging and monitoring

Security logging and monitoring is an essential part of your cloud security program. This will help you identify what went wrong in your cloud environment and is the only way you can uncover malicious events.

For starters, you can at least have Cloudtrail enabled in all regions and put it in cloud storage. Next, you should set alerts for common security use cases, like multiple authentication denies or privilege escalation failures.

What else to log?
API Call Logs (Cloudtrail), DNS logs (Route53), Network Access logs (VPC Flow logs), Cloud storage logs (S3), Security services logs like Security Hub, GuardDuty, WAF logs and application logs need to be logged to build detection rules. It is recommended to have a separate logging account for long term storage and have a centralized monitoring account and shipping the data into an SIEM like Elasticsearch. Build detection rules for cloud and application security use cases here.

Conclusion

By keeping security as one of the core principles while building out your cloud infrastructure, you save time on security efforts when you have to scale your operations. By doing these steps you can start building your cloud security. Security is a hard problem for businesses to solve and it’s best you get working on these challenges from the get go.

That’s all folks, lookout for more posts on security for the next steps in your cloud security journey. I’d love to hear your thoughts on this post, do start a conversation with me on Twitter or LinkedIn :).