Securing Your AWS Infrastructure
In Part 1 of this AWS Cloud Security Best Practices series we gave an overview of Foghorn’s best practices for building and maintaining secure infrastructure on AWS as it relates to IAM. In this final installment we share our advice on securing the layers of your AWS infrastructure from the network to data encryption. By following Foghorn design principles organizations can minimize risk and protect their assets by minimizing vulnerabilities.
Infrastructure Protection
Foghorn builds AWS cloud security best practices into every layer of cloud environments. AWS infrastructure designed by Foghorn are secure by default. While some implementation may differ slightly, the following is an overview of our layered protection fundamentals.
Network Boundaries
Networks are secured by leveraging Foghorn’s AWS cloud security best practices VPC design, and implemented using our m-vpc terraform module.
Our design includes the following network design for each VPC:
- Public subnets: Only resources which need to initiate or respond to public requests are launched in public subnets. These include only load balancers, bastion hosts, and network devices, unless clients request specific additional services to be public. These resources have direct access to the internet via an AWS Internet Gateway.
- Private subnets: Servers behind load balancers as well as servers that need to initiate outbound connections initiate these connections via NAT or Proxy and can be launched here. Depending on client configuration, this traffic is controlled either by an AWS NAT gateway, or by Foghorn’s proxy implementation, m-proxy, which enables layer 7 filtering such as domain based whitelisting.
- Isolated Subnets: Resources that require no outbound connectivity, or outbound connectivity via direct connect and through a client’s data center’s internet connection, are launched here. Redshift and RDS are launched in Isolated subnets.
Host Boundaries
Each host (load balancer, network appliance, ec2 instance, private lambda, etc.) is granted whitelist access to resources via least permission security group rules. For example, if a client is running a web service behind a load balancer, their load balancer will only accept incoming connections on port 443 from the internet, and your ec2 instances will only accept traffic on the application listening port from the load balancer. If client’s intend to add capabilities to existing workloads which require that they initiate or listen on additional ports or to/from additional sources/destinations, security group changes will be required to enable those features.
System Configuration
Foghorn recommends and implements AMI and container bakeries that build off of updated OS images ensuring that all security vulnerabilities are patched. We also strongly recommend implementing the CIS Benchmarks to ensure a secure baseline systems configuration. If clients chose the option, Foghorn integrates CVE and CIS benchmark scanning into the bakery. Foghorn uses Drone (or optionally Jenkins) driving a pipeline that consists of Packer and Ansible to harden and configure systems as well as check those systems against CIS benchmarks. Foghorn also integrates checksec into the pipeline for CVE scanning.
System Patching and Maintenance
Foghorn recommends and implements immutable infrastructure, and prefers replacement of existing instances and containers with new infrastructure spun up from new AMIs which have been updated. This ensures no drift from documented infrastructure standards, minimizes spin up time of dynamic workloads as well as maximizing the reliability of auto scaling.
Data Protection
Data Classification
For large organizations or organizations storing high volumes of data, it is often more efficient to only apply data controls as required, especially if large costs may be associated with protecting a relatively small subset of sensitive data. If this is not the case, Foghorn simply treats all data as sensitive, removing the requirement to classify data.
Encryption / Tokenization
Foghorn by default encrypts all data at rest, and recommends and implements encryption of all data in transit, unless workloads require an exception. By default, Foghorn encrypts all EBS volumes and EBS backed services (RDS, etc.) and S3 buckets with default KMS keys.
Foghorn by default configures all ALBs to listen on secure ports with public certificates generated from ACM. Foghorn by default configures all systems to listen to private traffic with self-signed certificates, or optionally with ACM private certificate manager.
Incident Response
Foghorn configures several default account monitors, which are configured to notify the shared slack channel. Optionally, Foghorn can create custom monitors and send alert notifications to customer SIEM systems.
If you would like more information on migration and security best practices make sure to visit Foghorn’s Whitepaper Library. And don’t hesitate to reach out if you have any AWS cloud security needs.
