The concept of cloud security is an ambiguous one and means different things to different people. Most people tend to think cloud security is the same as SaaS security; all about Identity and Access Management. To an extent, those people are correct but there is so much more architecture and design that goes into it. Throughout this article I’ll be relaying my strategies for AWS cloud security and categorizing them in relation to the NIST Cybersecurity Framework stages of Identify, Protect, Detect, Respond, Recover. Please note that even though this article focuses exclusively on AWS, the fundamentals and flow hold true for any cloud environment, to include Azure and Google cloud platforms.
Identify – Preparing The Foundation:
The question of where to start in the security process is often situational and dependent on a multitude of factors for each individual organization. Once you know what you have you can create a plan on how to secure it. There are a few universal truths that will aide every organization on their security journey.
- Deploy AWS Organizations, and keep the Organization owner account free of all deployable resources. This should be an empty account utilized for billing, Single Sign On, Control Tower, Service Control Policies (SCP’s), and Identity and Access Management. This account is often referred to as the management account. It’s recommended to utilize a group email address for the management account’s root user, and keep track of who has access. Additional best practices for the management account can be found here.
- As was eluded to above, deploy AWS Control Tower in the management account and setup dedicated accounts for Logging and Security Auditing. Set those accounts up in accordance with best practices. All logs should be shipped to the Logging account (more on that later), and the Security Auditing account should be setup as the service administrator for each of the AWS security services (Guard Duty, Security Hub, etc.). Deploy the guard rails that fit your needs.
- Deploy an Organization Cloud Trail and configure logging to go to the logging accounts.
- Setup the Config service to track all changes to the account, and configure multi-region data aggregation. Here an AWS document on how to configure Config across all accounts.
Completing these four items will set a good foundation for building a good security posture. From here, every existing AWS account should be added to the Organization and grouped by Organizational Unit (OU) the same as we would structure an Active Directory. The structure will be unique to your organization. Most have some format of ‘Sandbox’, ‘Development’, ‘Quality Assurance’, and ‘Production’. Others will have ‘Internal Accounts’, ‘Client Accounts’, ‘Production Accounts’. There’s no wrong way to organize as long as it makes sense.
Protect – Prepare For Evil:
This is the phase that goes in depth as required. We often hear the phrase “how much security is enough?”. This is the phase where you take into account all of your regulatory guidance, frameworks, and threat model and tailor a security plan to fit your needs. I’ll be going through what I recommend as a baseline for everyone, which may be more in depth than most companies think they need.
Security of The Cloud:
These security services are worth enabling and using in nearly all situations, as the cost is low and the benefit is high.
- Guard Duty: Amazon Guard Duty is a threat detection service that continuously monitors your AWS accounts and workloads for malicious activity and delivers detailed security findings for visibility and remediation. This will give you insight as to which EC2 instances are running malicious scans, which Access Keys are potential compromised, and which systems are being attacked from the internet.
- Amazon Inspector: Amazon Inspector is an automated vulnerability management service that continually scans workloads for software vulnerabilities and unintended network exposure. This service scans all of the accounts EC2 instances and Container services.
- AWS Detective: AWS Detective assists in visualizing and conducting faster and more efficient security investigations. This one is situational depending on your tool stack but I’ve found to be useful.
- AWS Key Management Service: AWS Key Management Service (AWS KMS) lets you create, manage, and control cryptographic keys across your applications and AWS services.
- Security Hub: AWS Security Hub is a cloud security posture management service that performs security best practice checks, aggregates alerts, and enables automated remediation. By default it now comes enabled with benchmark settings that audit the environment against the below. The inclusion of NIST 800-53 is new and used to have to be applied with a Config performance pack, so this is an excellent new feature update. Review the guidance that these standards utilize and perform the remediation’s they list (within acceptable bounds); this is the majority of cloud security hardening and includes best practices such as enabling MFA.
- CIS AWS Foundations Benchmark
- AWS Foundational Security Best Practices
- NIST Special Publication 800-53 Revision 5
Security in The Cloud
Now that the “Security of The Cloud” has been addressed it’s time to look at security in the cloud and architectural design decisions. Regardless of if you decide to use EC2 instances or container services for your compute it’s considered best practice to configure security groups with a whitelisting approach, only allowing communication on ports that are required and expanding this train of thought outward in the architecture.
- EC2 Instances: Deploy the most up to date versions of hardware and operating system from vetted and approved AMI’s. Assign IAM roles to manage the systems in accordance with the principle of least privilege. It’s recommended to apply hardening standards to all systems. I recommended utilizing the CIS Level 1 Benchmarks specific to the operating system.
- Security Groups: Apply security groups that are configured in accordance with the principal of least privilege, and tag the entries for future understanding.
- Public and Private Subnets: By default you should deploy all systems in a private subnet so they are not publicly accessible from the internet, only deploy systems to the public subnet that are required. Utilize a WAF in front of the public subnets. Use public IP’s sparingly.
- Virtual Private Network: Deploy a VPN connection so that approved administrators and users can access the private networked systems. Utilize authorization rules to allow groups RBAC access to only the networks that they need.
- Systems Manager: Utilize this service to deploy maintenance windows to automatically apply patches to all systems in accordance with your company’s patching schedule.
- Backups: Utilize the AWS Backup service to automate system and volume level backups. Backup your applications to AWS S3 where possible to save costs.
Detect – Find Evil
As important as the Protect phase is, in my opinion the Detect phase is where the magic happens. Hackers and bad guys only need to get it right once in order to make an impact, whereas defenders need to be right every time in order to prevent negative impacts. The detection phase helps you identify both successful and unsuccessful attacks and provides threat intelligence on the attack surface of your landscape so that adjustments can be made and actions can be taken before an adversary reaches critical mass.
1.) As stated in the above Security of The Cloud section, Guard Duty is going to be your bread and butter of detection of cloud native attacks. Having an analyst monitoring this tool daily is critical for early watch detection of security incidents.
2.) If you want to double dip on network analysis, set up a network intrusion detection system like Security Onion and configure traffic mirroring from your EC2 instances. In my opinion it is well worth it to have the additional coverage, as Guard Duty doesn’t yet have as much coverage as a traditional NIDS product.
3.) It’s also advisable to deploy a SIEM solution and collect operating system logs. This isn’t as new space and there are multiple great articles on open source solutions such as Wazuh
4.) Finally for consideration is deploying an EDR, Next-Gen Antivirus, or traditional antivirus solution to all your running instances.
As you can see, security in the cloud is very similar to security on traditional corporate networks. Or at least my approach is.
Respond – Contain and Eradicate Evil
This is the part of the job that takes the most dedication – creating and practicing incident response runbooks for the most likely scenarios your likely to encounter. In addition to the traditional “on premise” style incident response plans, AWS has released template Incident Response guides that everyone should incorporate into their cloud IR plans.
- Analyzing VPC Flow Logs
- Code Exposure
- Compromised IAM Credentials
- Cryptojacking
- Denial of Service
- EC2 Forensics
- RDS Public Access
- Ransomware Response [Linux, Windows, RDS, S3]
- S3 Public Access
- Unauthorized Network Changes
Recover – Return to Operations
This phase goes hand in hand with the Respond phase and is an integral part of any incident response plan. There needs to always be a way to recover from backups and restore normal operations. Traditional IT best practices should be reviewed and implemented to best support the types of workloads running in your cloud environment.
Leave a Reply