[Cloud Architect] 12. Defensive Security in the Cloud
Overview
In this lesson, we will explore methodologies to incorporate defensive security when designing a cloud architecture.
We will identify tools and methods to help safeguard applications and data in the cloud at the various stages of an application's life cycle.
We will also look at an example deployment pipeline that incorporates these common security practices.
By the end of the lesson you will have a better understanding of:
- How to identify misconfigurations that can lead to vulnerabilities
- How to identify and guard against malicious activity
- How to design a deployment pipeline that ensures that security practices are implemented early on.
Common Threat Vectors
Before we delve into tools and techniques, let's first get a better feel for the common threat vectors that affect cloud environments.
External Threats
Let us look at the attack surface of a cloud environment from the perspective of an actor who is on the internet and does not have access to the private network space of our cloud environment.
Public Facing Web Applications
Attackers will attempt to exploit application related vulnerabilities such as those found in the OWASP top 10.
Cloud architects and engineers designing cloud environments need to ensure that any external web applications are defended appropriately. Teams should also perform security and penetration testing on applications to reduce risks prior to deployment.
Public Facing Server Infrastructure
Aside from web applications, any other server infrastructure such as bastion hosts, databases, etc are prime targets for attackers. Any resources, such as these, need to have additional hardening and isolation from other internal resources that host sensitive data. At a high level, the use of these types of resources and exposing them to the internet should be avoided, limited, and restricted.
The AWS API and Console
Due to the inherent nature of the public cloud being public, access to the AWS API for managing cloud services is public facing. If this access is compromised, an attacker could gain control of your environment and start managing your resources from anywhere!
Public Facing Infrastructure and the AWS API are Both Common Targets of Internet-Based Attackers
Internal Threats
Although it is important to defend our external public facing perimeter, it is equally important to assume those same threats can potentially exist within the private network. Internal attackers may also have gained access to instances and hosts running in the cloud and will attempt to install and run malware or access data on cloud instances.
The threat is compounded if an attacker or a piece of malicious software has gained network access to other private networks that are connected to your cloud environment. To prevent this, it is critical that cloud hosts are hardened and set up to restrict access even if they are not public facing.
The AWS API can also become a target if attackers gain access to internal code repositories that mistakenly hold API keys and other secrets.
Identifying Threats and Vulnerabilities
The goal of this entire course is to design cloud architectures so that the likelihood of any of these types of attacks, both external and internal, are reduced or eliminated.
In previous lessons we looked at how to implement best practices around securing cloud networks, access to the API, and storing our data securely. In this lesson, we want to take that a step further so that we can identify vulnerabilities and identify and block suspicious behaviour.
Attackers who have Gained Access can Obtain API Credentials to Gain Control Over Other AWS Services
Defensive Security In The Cloud
One of the most widely accepted benefits of leveraging public cloud services for running applications is the speed and agility with which we can deploy new infrastructure and environments.
Agility and speed of change bring challenges to security and stability.
In the first few lessons we focused on designing cloud environments securely. We now want to get a better sense of how to keep those environments once they are deployed.
Important Considerations for Defensive Security
Understanding of Threat Landscape
The first step is to have a firm understanding of the threat landscape. Quantify specific vulnerabilities that could increase risk and lead to exploitations.
Identify Misconfigurations and Vulnerabilities
The second key item is to ensure checks and processes are in place to scan for misconfigurations and vulnerabilities. These processes should be designed to assess each part of the application stack from the code all the way to the core cloud infrastructure services.
When it comes to the cloud, some of the most obvious vulnerabilities include:
- Server instances without any OS hardening
- Exposure of AWS API keys and other secrets
- Overly permissive firewall rules and IAM policies
Identification of these types of vulnerabilities needs to happen during all phases starting from initial deployment of a dev environment all the way to post production. Identification and remediation of vulnerabilities earlier drastically reduces risk of exploitation.
We call this idea "shift left".
Shift Left: Reduce Risk and Cost to Fix by Identifying Vulnerabilities Early On
Identify Suspicious Activity
Lastly we want to be able to identify suspicious activity so that active threats can be identified and remediated as soon as possible.
It is critical that tools and processes for defensive threat detection are checking all layers of the stack.
As an architect it is essential that you design environments with the right tools in place for threat defense and monitoring.
Key Terms
Threat Landscape
Identify potential attack vectors and quantify potential exploitation and worst case blast radius.
Shift Left
Identifying security vulnerabilities and misconfigurations in the early phases of an application or environment's lifecycle.
Public Facing
Any resources which are accessible from the internet, such as web applications, public facing infrastructure, or the AWS console and API.
OWASP Top 10
A widely accepted set of vulnerabilities which can lead to exploitation of web applications.
Checking Infrastructure as Code for Vulnerabilities
With any software that is developed, the cost to remediate and the impact of finding defects is much lower when identified earlier in the life cycle rather than later.
This also applies to code that defines cloud infrastructure or infrastructure as code. Infrastructure as code should be tested prior to deployment to ensure that it will do what it is intended to do and to ensure that any potentially insecure configurations are identified early on.
Static Code Analysis for Infrastructure as Code
Static code analysis for finding application security vulnerabilities is not a new concept. However, this concept also applies to code that defines cloud infrastructure or infrastructure as code. Infrastructure as code should be tested prior to deployment to ensure that it will do what it is intended to do and to also ensure that any potentially insecure configurations are identified early on.
These insecure configurations should be treated as vulnerabilities and dealt with as such. Many times organizations will check these configurations post deployment, however it is important to add this check during the development phase to ensure that vulnerabilities are investigated and remediated.
Open Source Resources
There are many open source projects which allow you to construct security policies and then check terraform or cloudformation template code for any security related configurations which are out of compliance with your security requirements as defined in the policies.
CloudFormation
Terraform
Terraform is much more widely used infrastructure as code language, so there are more options including:
In addition to open source options, many of the major commercial cloud security products offer infrastructure as code scanning as part of their product platform including prisma cloud, cloud conformity, fugue, terraform cloud etc.
Additional Considerations
When implementing infrastructure as code scanning in your DevOps pipeline there are a few additional considerations to keep in mind.
Scan Configuration Management Code and DockerFiles
Scanning Code for OS / VM / Docker images in addition to Cloud or AWS Configuration Docker files, Ansible, Puppet, Chef, etc should ensure that configurations are in-line with security standards that have been established by the organization.
Scan on Code Check-in or Prior to Deployment
This depends on the tool selected, such as, during a terraform plan. If security related violations are found, your process should be set up to notify the appropriate parties and halt the pipeline from progressing.
Scan Terraform Code Using Regula for Security Compliance Prior to Deployment
DEMO
1. Install Regula
https://github.com/fugue/regula
2. Create a simple terraform file with the below contents. Call it iam_policy.tf:
resource "aws_iam_policy" "policy" {
name = "cand-c3-l4-e1-iam-policy"
path = "/"
description = "a policy to test IAC scanning"
policy = <<EOF
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"*"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
EOF
}3. Run
regula run ./iam_policy.tf
4. Result:
5. Change code to:
resource "aws_iam_policy" "policy" { name = "cand-c3-l4-e1-iam-policy" path = "/" description = "a policy to test IAC scanning" policy = <<EOF { "Version": "2012-10-17", "Statement": [ { "Action": [ "s3:GetObject" ], "Effect": "Allow", "Resource": "*" } ] } EOF }
6. Run again
Additional Resources
Vulnerabilities on Instances and Containers
Containers and instances that are deployed and running in your cloud environment should also be checked for vulnerabilities. These types of checks will scan instances and containers for vulnerabilities and lack of best practices.
Examples of these types of vulnerabilities include:
- Allowing SSH password login
- Vulnerabilities to Django libraries
Ensuring that instances are launched from the latest image, patched regularly and have basic security hardening will reduce the chance of vulnerabilities being found.
AWS Inspector
AWS inspector is intended to specifically analyze and report on vulnerabilities on EC2 instances.
Operating System Vulnerabilities
AWS Inspector is designed to identify vulnerabilities at the OS level.
Once the inspector agent is installed on an instance, it can scan against:
- CIS benchmarks for linux and windows
- AWS security best practices
- Common vulnerabilities and exposures or CVE findings
Operating System Vulnerabilities
AWS Inspector is designed to identify vulnerabilities at the OS level.
Once the inspector agent is installed on an instance, it can scan against:
- CIS benchmarks for linux and windows
- AWS security best practices
- Common vulnerabilities and exposures or CVE findings
Network Reachability
Inspector can also provide a report on network reachability from the public internet to instances and load balancers along with specific ports that are reachable.
Limitations with AWS Inspector
The type of scanning that inspector provides is considered static scanning.
Static scanning refers to a one time (or scheduled) that will run and provide a set of findings.
Dynamic scanning, on the other hand, is continuous monitoring that is designed to catch changes to configuration or other suspicious activity in real-time.
Outside of AWS, there are many many products and vendors that provide varying levels of OS vulnerability scanning. Since this concept is not new to the cloud, many security teams opt to use existing products to achieve OS level vulnerability scanning.
Vulnerabilities on Containers
Checking container images for vulnerabilities can be done using a number of open source and commercial tools.
Open source tools include:
- Clair
- Anchore
- Trivy
- etc.
Commercial products include:
- aquasec,
- sysdig
- twistlock
- etc.
Commercial products generally also provide dynamic container monitoring once containers are deployed and running.
Security Information and Event Monitoring Sources in AWS
Security information and event monitoring is a fundamental pillar of information security.
As you start operationalizing and deploying workloads to cloud environments, it is critical that there is insight into activity and events related to the cloud accounts or applications.
It is important to have this monitoring in place in order to:
- Identify any suspicious activity in cloud accounts, servers, networks, and applications.
- Provide auditability, and traceability for forensics and root cause analysis.
We will look at some of the event sources available in AWS and methods to monitor these sources.
Security Event Sources in AWS
Security information and event monitoring is a pillar of information security.
As you operationalize your workloads in the cloud it is critical that you have insight into activity and security events related to the cloud accounts and applications.
This type of security monitoring is important in order to:
- Identify any anomalous or suspicious activity in cloud accounts, servers, networks, and applications
- Provide traceability for forensics and root cause analysis.
- Provide auditability for access to sensitive data or actions
Event Sources Available in AWS
Let's look at some of the event sources we should be looking at in AWS.
CloudTrail
AWS CloudTrail is the source of activity logging within an AWS account. Any API activity, console usage, cross account access etc will be recorded in CloudTrail. CloudTrail will log all activity and allow you to search these logs for 90 days.
However it is highly recommended to configure CloudTrail logs in all accounts and all regions to be written to S3 buckets, preferably a central S3 bucket in a dedicated security account. These logs can then be examined later or ingested by a log analysis or SIEM tool.
CloudTrail is by far the most valuable tool to monitor and audit activity in your AWS account.
VPC Flow Logs
When VPC flow logs provide insight into network activity including:
- Connection attempts or rejects, allows or denies
- Source and destination IPs, ports
- Packets and byte counts
It is important to note that VPC flow logs do not provide visibility into actual traffic content or payload.
If you need visibility into network traffic content in order to perform more sophisticated detection of activity you can enable VPC traffic mirroring.
Once VPC traffic mirroring is enabled, you can ship this data to third party network monitoring tools.
For more details regarding network mirroring please refer to AWS documentation
S3 Bucket Logs
Any changes to an S3 bucket's configuration will be logged as API calls in CloudTrail.
From a security standpoint it is important to be aware of attempts to read or write objects to S3 buckets - especially those that contain sensitive or critical data. Object level logging is optional and can be enabled either through CloudTrail or the S3 bucket's settings. All calls to read or write data will appear in CloudTrail.
AWS Config logs
Config logs record all state changes for any resources that are being monitored by AWS Config. These logs should be sent to a log analysis tool to gain deeper visibility into configuration state changes.
DNS logs
DNS query logging is also available in AWS Route53. Regardless of your choice to enable DNS query logging, AWS does maintain these logs behind the scenes and will use them for identifying suspicious activity.
EC2 Instance Server Logs
System logs from your Linux and Windows instances are also critical to identifying suspicious activity or auditing. These logs can be sent to cloudwatch logs or other log analysis tools or products that provide intrusion detection and dynamic host based security event monitoring.
Identify and Monitor Security Events
Let's look at some methods to identify suspicious activity based on security event sources in the cloud.
Setup AWS GuardDuty
AWS GuardDuty can monitor CloudTrail, DNS, and VPC flow logs to identify suspicious activity. A few examples of activity that GuardDuty can identify:
- SSH brute force attempts.
- API calls from IP addresses that are on threat lists.
- Traffic that is destined for crypto-currency related IPs from an EC2 instance.
Use an SIEM Tool
Log sources can be sent to SIEM tools for creating security dashboards. Many cloud security monitoring and SIEM tools have out of the box features to look at cloud native logs such as CloudTrail and VPC flow logs and identify anomalous activity.
Example vendor tools include:
- Splunk
- Sumologic,
- Lacework
- CloudKnox
- etc.
CloudWatch Alarms
CloudTrail logs can be sent to CloudWatch logs and custom alarms can be set up to monitor specific CloudTrail event types. An example use case of this, is an admin being notified on concerning activity, such as modifications to security groups or a root user login to the AWS account.
GuardDuty
Additional Resources
Defending Web Applications from Exploits
Many cloud architectures and environments are designed to host internet facing web applications and services.
Once an internet facing application or resource comes online it can be as little as a few minutes before external actors start testing those applications for exploitable vulnerabilities. When designing the environment, it is critical to be aware of cloud native defense mechanisms for blocking these types of attacks and where in your environment this type of defense should be set up.
Defending Web Applications
Once an internet facing application or resource comes online, it can be as little as a few minutes before external actors start testing those applications for exploitable vulnerabilities.
To learn more about these types of attacks I recommend you become familiar with the OWASP Top Ten, which functions as a high level list of the most common security risks that web applications may be susceptible to.
Web application firewalls or WAFs are designed to sit between a client and an application to inspect application HTTP traffic and determine if the traffic patterns signify exploitation attempts. The WAF can then be set up to block or log suspicious traffic.
A WAF can Protect Internet Facing Applications from Attacks that Attempt to Exploit Application Vulnerabilities
Web Application Firewalls in the Cloud
There are a few different ways of incorporating WAF protection to defend against application level exploits.
Cloud-Based WAF product
There are many vendors, such as Akamai or Cloudflare, which web clients point to as an entry point into your application. These are designated as CDN providers, however they provide WAF capabilities as part of their offering.
Cloud providers such as AWS also provide this type of service natively. AWS WAF can be placed in front of public facing application services such as CloudFront and API Gateway transparently so that application endpoints do not need to change.
WAF appliance
A WAF appliance or network based WAF can be deployed into a VPC to protect EC2 based application traffic. These can be costly and complex to implement and what you would typically find in a traditional data center environment.
Example vendors include:
- F5
- Fortinet
- Imperva
- etc.
Host-Based WAFs
These products attempt to provide similar defense but are deployed as part of a web applications server instance.
Serverless Security Tools
Serverless applications also need to be defended. Many products offer capabilities to defend serverless applications from application exploits.
Example products include:
- Aqua
- Twistlock
- PureSec
WAF Best Practices
1. Test and Fine Tune WAF Rules
Set up the WAF with identical configuration in lower environments for testing to ensure that your applications still work as expected in production. Fine tuning may be required to rule out false positives.
2. Penetration Testing
Perform penetration and exploit testing against applications to ensure that the WAF defends as expected. Test both with and without the WAF to get a better understanding of defensive capabilities.
3. Logging
Enable WAF logging and export logs to your security monitoring tools.
4. Discovery
Identify all public endpoints for your applications including CloudFront, Application Load Balancers, API Gateway. If your application is exposed to the internet with other methods, consider moving your application behind these mentioned services.
Once identified, put together a plan to start defending your applications with a web application firewall.
Web Applications can be Protected using Third Party WAF Providers or the AWS Native WAF
Key Terms
Web Application Firewall (WAF)
A web application firewall is used to defend an application that may contain vulnerabilities from exploitation.
WAF Rules
Logic that will dictate what type of requests to allow or block
Managed Rules
Sets of rules provided and managed by third parties or AWS. Different rule sets are designed for specific purposes.
AWS Firewall Manager
Control WAF settings and Security Groups for all AWS accounts from a central management interface.
Additional Resources
You would like to protect your applications from bot traffic and plan on using the AWS managed rules. Check the documentation and identify which AWS managed rule set will help us mitigate bot traffic.
Answer: Amazon IP protection
