Preventative and Detective Controls in AWS - A Primer

Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth. Sir Arthur Conan Doyle

In the context of preventative and detective controls, the words impossible and improbable become very important.

Preventive controls protect your workloads and build perimeter controls against exploits, this helps build on what can be impossible in your architecture. Detective controls provide full visibility and transparency over the operation of your environment, to address the improbable.

In this blog, I will take you through building preventative and detective controls that can be applied to the following aspects of your infrastructure - Network, Infrastructure, Applications/Software and Data.

Network

Preventative Controls

Network level preventative controls are applied for isolation primarily. Building network topologies in AWS starts with the Amazon VPC. There are various components that enable building a network perimeter.

  1. Build a custom VPC instead of using the default VPC in any AWS region.
  2. Ensure you split the custom VPC into multiple subnets. Public subnets for public facing endpoints like load balancers, API Gateways etc. Private subnets for application servers and databases to build isolation of data and business logic from the public endpoints.
  3. Network Access Control Lists (NACLs) are essential to set up Deny rules for ports across IP ranges. Use NACLs to enhance on the isolation aspect of the subnets. NACLs are stateless and you need to specifically create rules for return traffic. For example, with NACLs you would specifically need to configure to allow traffic from ephemeral ports (1024 - 65535).
  4. Where NACLs operate at the subnet level and are stateless, Security Groups (SGs)operate at the resource level and are stateful. SGs support only allow rules. Return traffic does not need to be specifically allowed.
  5. Another important component to control traffic flow are routes. Routing rules determine the flow of network traffic in your VPC. Routes can be strategically used to protect traffic flow by creating a blackhole route to silently discard certain traffic.

There are various other enhancements that you can implement in your network strategy by using AWS Transit Gateway for transitive routing and building a centralised network hub for your AWS environment.

Detective Controls

With the basic preventative controls built out, let us move our focus to building detective controls around the network. The more recommended mechanism is to use VPC Flow Logs to analyse network traffic. VPC Flow logs can be published to Amazon CloudWatch and Amazon S3.

You can use CloudWatch to build custom metrics and alarms to notify you if any undesirable traffic is detected. furthermore, if you use any Security Information and Event Management (SIEM) tool, you can push the logs collected in S3 to build analytics.

Infrastructure

Infrastructure can largely be broken into Compute and Network. After configuring network, it is time to look at compute protection.

Preventative Controls

The first step to compute protection is vulnerability management. Vulnerabilities are nothing but software and configurations (or lack there of) that can be misused by third parties to potentially gain access into your infrastructure. A large portion of these vulnerabilities comes from software written by humans, of which a large portion is detected in operating systems.

A core design principle while building secure infrastructures is addressing defence in depth and automating security controls. Hardening and patching play a major role in securing compute.

  1. Hardening is a mechanism to secure configuration of a system. This can be done at a resource level like machine images (AMIs/ISOs) or at an architecture level using controls like Center for Internet Security.
  2. Patching is a mechanism to mitigate vulnerabilities in operating systems and applications. Vulnerabilities open up weaknesses for third-parties to attempt and potentially succeed at bypassing a privilege boundary and accessing your application. Patching can prove to be a good preventative if done on a schedule, and also detective post an exploit.

If you were to narrow down the guidance by the Australian Cyber Security Center (ACSC) on managing security vulnerabilities, the timelines that you need to work with are:

  1. patching timeline of within 2 weeks of the patch being released by the vendor, for applications, internet facing systems, workstations, network devices and all connected devices.
  2. patching timeline of within 48 hours if an exploit exists for a vulnerability for all systems and applications.
Detective Controls

Detective controls with infrastructure relies on how much information you can gather from the resources in play.

  1. Install the amazon-ssm-agent on the EC2 instances and even on-premises servers to configure automated discovery of compute resources.
  2. Once the amazon-ssm-agent is installed, you can use AWS Systems Manager to operationally manage your fleet including discovery, patching, automation, remote access and command execution.
  3. Use Amazon Inspector to continually scan instances and capture detected vulnerabilities along with the software/library where the vulnerability is detected.
  4. As with network logs, use system logs to build monitoring and tracing capability to identify lower level vulnerabilities that can cumulatively cause an impact.

Applications/Software

Separation of duties along with least privilege is the core of building a strong identity foundation at an application level.

Preventative Controls

As you use frameworks fit for development there are aspects of programming that you can use to build preventative controls.

  1. Build a robust authentication and authorization mechanism in the application or for cross micro-services communications.
  2. Use private methods wherever possible to control flow of information and data access at a service layer.
  3. Use principles of loose coupling to enhance separation of duties and also injecting reliability. Implement loose coupling between dependencies to contain the impact of exploits.
  4. Use proper testing frameworks and valid tests to ensure that the business logic as well as data access patterns.
  5. Automate deployments and change management to inject preventative controls at the code level along with maintaining audit trail.
Detective Controls

Needless to say, logs, metrics and analysis of logs is critical to creating alarms and notifications which allow you to build traceability at the application layer.

Set up detective controls using application and operating system generated logs. But this does not mean enable debug logs to never miss a beat. That approach would increase noise and would not be cost effective at all.

  1. Consider what kind of logs deliver the most value for the application.
  2. Build a logging module in applications to format the raw logs coming from the runtime to something meaningful and then base detective controls on the values relieved from the logs.
  3. Use CloudWatch to create metric filters to analyse specific application interactions.

Data

Preventative Controls

At a data layer, preventative controls can be seen from a different angle. When the application layer has segregation of duties especially in terms of underlying data access, a good practice is to enable encryption and control the access to the encryption keys to prevent unauthorised access to the data layer.

  1. Use encapsulation to to hide the data in a single entity or unit along with a method to protect information from external constructs.
  2. Use least privilege and configure segregation of duties for access to the encryption keys by different systems.
  3. Ensure encryption keys are rotated on a schedule to reduce the chances of long term continuing exploits.
Detective Controls

Drawing the boundary between preventative and detective controls helps build flexibility at the data layer.

  1. Monitor access to the encryption keys using AWS Key Management Service (AWS KMS).
  2. Use AWS CloudTrail to log access to data (even if it is legitimate) to build metrics and monitor based on such metrics. When you know what you should be seeing in terms of behaviour, it becomes simpler to identify what is an outlier.
  3. Use AWS Config to build custom rules or even use the existing rules as a first step.
  4. Use Amazon GuardDuty to enhance on the automated threat monitoring capabilities.