Security Architecture Review Of A Cloud Native Environment

Overview

Due to its massive adoption, cloud computing has become a critical component for every enterprise. A large number of organisations want to migrate to the cloud, however, its security posture is still a blind spot for everyone. Nevertheless, we have seen a big rise in the number of requests to check the security posture of cloud infrastructure deployments.

In this blog post Anand Tiwari will talk about a cloud security assessment that he did for an organisation, which had recently moved their infrastructure from an on-prem to a cloud native solution (AWS). Assessment was carried out in two parts, an architecture review was done and a security gap analysis was performed. The blog will detail how the assessment was conducted and why a cloud security assessment is needed, in addition to a standard application/infrastructure pen-test.

For the course of this blog, the below given diagram will be considered as a sample architecture of the organization in scope when it was on-prem.

Now, when the target organisation switched to a cloud native solution, the architecture was as shown in the diagram below. Note that this again is only for reference.

The workflow of the different entities from the above diagram i.e. cloud architecture in scope is described below:

Internet Gateway: Allows communication between Virtual Private Cloud (VPC) and the internet.
Application Load Balancer (ALB): ALB manages traffic within the implementation and from external connections.
Front-end Server (EC2): Is placed in an auto-scaling group where the front-end web server is deployed on EC2 instances and serves as an application user interface (UI).
Back-end Server: Back-end web services are placed in a private subnet, deployed on EC2 instances.
Amazon RDS (Database): Application database is kept in a restricted subnet that interacts with back-end services.
AWS CloudTrail: Provides compliance, governance, operational and risk auditing of the AWS accounts.
AWS CloudWatch: CloudWatch helps you with monitoring of your applications, responds to any system-wide performance changes, and allows optimized resource utilization, and provides a unified view of its overall health.
AWS Cloud9: AWS Cloud9 is a cloud-based Integrated Development Environment (IDE) that lets you write, run, and debug code in the browser.
AWS CodeCommit: AWS CodeCommit is a fully-managed source control service that hosts secure Git-based repositories.
AWS CodeBuild: AWS CodeBuild is a fully managed continuous integration service that compiles source code, runs tests, and produces software packages that are ready for deployment.
AWS CodeDeploy: It is a fully managed deployment service that automates software deployment pipeline.

Assuming that an application is deployed on a cloud native solution, let us initiate our assessment. First we did the architecture review. Let us understand the need to do so.

Why Do We Need An Architecture Review?

As the saying goes 'the chain is only as strong as its weakest link'. While a regular pen-test activity offers a certain level of assurance against threat actors that may try to exploit vulnerabilities inside an application or its infrastructure, it may not go into details of the overall architecture design and related decisions, infrastructure configurations and other components.

A Security Architecture review looks at these internal nuts and bolts that make up a cloud environment and provides best practice recommendations, tailored towards the organization in scope, to protect it from various threat actors such as compromised developer accounts, disgruntled employees, etc. The information derived from this exercise can be acted upon to strengthen the security posture of the overall cloud environment. The goal of a cloud security architecture review is to identify and highlight cloud security weaknesses and strengths and provide guidance towards building a mature cloud security architecture.

With an increasing number of organisations moving towards Agile/DevOps methodologies and running their infrastructure in a cloud environment, the attack surface has widened and become difficult to understand as now there are many moving parts involved in deploying changes into production. NotSoSecure's cloud security architecture review process helps in mapping out the attack surface, identifying attack vectors and evaluating the threats.

Architecture Review Methodology

Now that we know why an architecture review is needed, let us advance towards the methodology. The methodology used by NotSoSecure for architecture review can be summarised as follows:

First, a Data Flow Diagram (DFD) of the cloud infrastructure is created. This will be done by referring to the target organization's high-level cloud architecture.
A Threat Model of the cloud infrastructure will be created.
Non-Functional Security Requirements (NFSR) documents that highlight security best practices and hardening guidelines of the entire technology stack in scope will be created.
Finally, Gap Analysis will be done.

Data Flow Diagram (DFD) of Cloud Infrastructure

A data flow diagram allows us to visualize the flow of information in the infrastructure. It shows how various systems are interconnected, how information is exchanged, and where the information is stored. It also portrays the various sub-processes from where the data flows.

Creating a DFD

We used draw.io and threat modelling library to create the DFDs.

DFD Elements

draw .io offers you DFD elements which are available in the 'dfd.xml' library. The elements that we used are shown below:

Creating a DFD involves the following simple steps:

Define a Trust boundary.
Add symbols that represent external entities, processes and data stores.
Connect systems using data flow or bidirectional data flow and links to sub-processes.
List down all the assets, security controls and the possible threat actors for systems.
Add text and labels on all the entities.

Using elements and the steps mentioned above, we accomplished the first step and created a cloud infrastructure DFD that traced the complete flow of data right from where it originated to where it ended.

The basic working/role of the various numbered entities from the above diagram is described below:

Users (legitimate as well as malicious) interact with applications. TA01 malicious users are the threat actors.
Front-end Application Load Balancer is for load-balancing of HTTP and HTTPS traffic and provides advanced request routing targeted at the delivery of modern application architectures.
EC2 instance serves front-end services of application. Potential internal threat actor – Unauthorized access to TA04.
EC2 instance serves back-end services, potential internal threat actor – Unauthorized access to TA04.
An Amazon EBS volume is a durable, block-level storage device that you can attach to one or more instances.
Amazon RDS database allows easy setup, operations, and scalability of a relational database in the cloud.
Application Logs are stored in S3 bucket.
Developers interacting with Cloud9 IDE and CodeCommit with potential threat actors as TA01, TA02, TA03, TA04.
Cloud9 IDE interacts with AWS CodeCommit having TA03, TA04 as potential threat actors.
AWS CodeCommit interacts with developers and AWS CodeBuild using SSH keys.
AWS CodeBuild interacts with CodeDeploy after compiling source code, runs tests, and produces software packages.
AWS CodeDeploy is used to deploy applications on EC2 instances.

A DFD helps us to understand threat actors and possible threat scenarios..

Threat Modelling of the Cloud Infrastructure

The second step of our review methodology involves threat modelling. Threat modelling is crucial as it helps teams to proactively understand and develop a strategy for identification of potential threats lying inside the cloud infrastructure. As per OWASP, threat modelling is a procedure for optimising security by identifying objectives and vulnerabilities, and then defining countermeasures to prevent, or mitigate the effects of threats to the system.

It defines an approach for operationalizing, hardening, and automating security throughout the software development life-cycle. There are multiple ways of threat modelling, such as by using any of the following methodology:

STRIDE methodology
P.A.S.T.A. methodology
Trike methodology
VAST methodology

For our assessment we used the STRIDE methodology which is as described below:

STRIDE

STRIDE is a threat model developed by Praerit Garg and Loren Kohnfelder at Microsoft for identification of computer security threats.

The methodology for identifying and categorising threats is as below:

Threat Table

Using the STRIDE methodology we created a threat table that focused on Spoofing, Tampering, Repudiation, Information Disclosure, Denial of service and Elevation of Privilege. There are two types of threats – internal and external.

The table below is an example of threat modelling of the cloud native components where we have listed a sample potential threats to the AWS infrastructure.

Non-Functional Security Requirements (NFSR)

NFSRs are a set of best practices that can be applied to an application or an infrastructure component to help the systems operate securely and safely.

So basically a threat model highlights potential threat scenarios and threat actors, and to protect against these threats a set of NFSR documents are created. These NFSRs will be used as a baseline for performing a structured audit against the components in scope. Further, Gap analysis will highlight the discrepancies between the expected values as per these NFSR documents and the observed values for each component.

If you are using AWS Cloud for your applications, an NFSR document for the AWS used by your application architecture should be created. Similarly, if you are using any other component which may directly impact the security of your application, an NFSR for that component should also be created.

Below is a sample NFSR for AWS Cloud components like AWS CloudTrail, AWS EC2, and AWS EBS:

Gap Analysis of AWS Cloud Components

After the creation of NFSR, we tested the expected values of cloud components (as per the NFSRs) against observed values in the cloud components in scope. We did this using various manual and automated methods. A read-only access to the systems and components in scope will be required for the same.

Infrastructure as a Code Scan

Terraform static code analysis tool provides the infrastructure as a code service. It scans cloud infrastructure provisioned using Terraform and detects security and compliance misconfigurations. As our entire cloud infrastructure was set up using Terraform, it made logical sense to scan Terraform code that we had written.

There are multiple open-source tools that help you to detect security misconfigurations such as the ones given below:

We used the tfsec tool. Below screenshots are from the output that we got after executing the tfsec tool on our terraform scripts.

1) tfsec detecting a fully open ingress security group:

2) tfsec detecting hard-coded passwords:

3) tfsec detecting an unencrypted S3 bucket:

Below is the list of all the findings extracted from the tfsec tool:

Cloud Infrastructure Audit

To review AWS infrastructure, a read-only and SecurityAudit access will be required. Multiple open source tools are available for review of cloud environments. Some of the tools are:

ScoutSuite

ScoutSuite is an open source multi-cloud security-auditing tool that we used and which allows security assessment of cloud environments. Below screenshot shows ScoutSuite in action.

ScoutSuite report shows that there is a problem with some of the AWS components and has highlighted the same with a Red flag.

A detailed report of the IAM misconfigurations:

A detailed report of misconfigurations for EC2 machines:

Below is a sample list of all the findings from ScoutSuite that helped us identify gaps between the implemented controls against the expected controls as described in the NFSR. ScoutSuite also gives a clear picture of implementation of the cloud native services that can match with the infrastructure as a code review findings.

Hence, using the above tools we were able to perform a GAP analysis highlighting the expected values as described in the NFSRs and the observed values shown in the reports.

DevSecOps Cloud Native Architecture

Architecture of an organisation is bound to change in a dynamic cloud native environment and hence below we showcase a DevSecOps cloud native architecture with embedded security controls that address a good majority of threats.

For more information about how to implement a DevSecOps pipeline on an AWS cloud native infrastructure please refer to our blog on the same subject.

Achieving DevSecOps using AWS Cloud Native Services

Highlighting below the security components that were added to the existing infrastructure to enhance the security posture of the application:

AWS WAF: AWS web application firewall that helps protect web applications or APIs against common web exploits.
AWS Shield: AWS Shield provides managed Distributed Denial of Service (DDoS) protection service for protection of applications running on AWS.
Amazon GuardDuty: Is a threat detection service that continuously monitors for malicious activity and unauthorized behavior to protect AWS accounts.
Static Analysis using AWS CodeBuild: Performs static analysis using AWS CodeBuild that fully manages continuous integration service.
AWS Secrets Management: Is a secrets management service that helps to protect access to applications, services, and IT resources.
AWS Key Management: AWS Key Management Service (KMS) is to create and manage cryptographic keys and control their use across a wide range of AWS services and applications.
Amazon Inspector: Amazon Inspector is an automated security assessment service that helps improve security and compliance of applications deployed on AWS.
Vulnerability Management: Tools helps you in managing vulnerability data from various automated scanners.

Conclusion

A cloud security assessment that includes both gap analysis and a security architecture review, helps in securing public cloud native solutions. A gap analysis routine allows organisations to determine how their security objectives can be achieved. It does so by comparing an organisation's existing security practices with prevailing and industry-wide accepted security best practices. Gap analysis highlights shortcomings and opportunities for improvement. A security architecture review offers a comprehensive view into the security weaknesses and mis-configurations of the cloud architecture, related components and more.

A security assessment of this type will boost an organisation's confidence about their security maturity and protect them from malicious threat actors.