Now that we have a broad understanding of the native security tools available to us in the cloud, we can dive into some examples of how to design and build common deployments. It is important to realize that each use case will not leverage all security tools and will not exactly match other security patterns. We aim to demonstrate a palette of different approaches to varying problems and give the reader the ability to select and combine different solutions.

As our first example, let's consider a three-tier web application:

Security groups should be used to separate tiers within a stack, as shown in the previous diagram of a three-tier web application. Each tier has its own security group, which has unique rules that expose minimal attack vectors.

For our first security pattern example, let's use a basic three-tier web application. The 3 tiers comprising this pattern are the web, application, and database. A user routing from the internet will not directly connect/interface with the application or DB tiers. The DB tier will not interface with the web tier. Given these network patterns, we should build our security group rules accordingly:

We've exemplified configurations for three different security groups corresponding to each tier of a three-tier web application

By using three separate security groups for each tier, we are able to create the smallest attack surface for each group of instances while enabling functionality. After configuring each security group and ensuring the stack can operate, we need to apply the security methods and approaches discussed earlier in the chapter. Ensuring the configuration doesn't drift from the original structure is essential to maintaining a secured environment.

This is where service configuration management comes into play. Either through custom scripting (utilizing the APIs available from each CSP) or utilizing services such as AWS Config, changes can be detected and acted upon when configurations change outside of set bounds. This is critical when dozens of individuals are operating in a production-like environment. Expect changes to happen that are against policy and have the tools in place to detect and mitigate them.

If we further build on the three-tier web app example, we can layer on a simple WAF loop that captures some advanced functionality. A URL honeypot can be built to detect botnets, capture their IPs, and add those IPs to rules on the WAF in an automatic fashion:

As shown in this diagram, Web Application Firewalls are a cloud native method of increasing security. WAF services from cloud providers are API driven, allowing programmatic loops to be built, such as the automated honeypot scenario.

This is done by adding hidden URLs to the public site that are invisible to ordinary users, but will be caught during the scraping process that bots use. Once the hidden URLs (the honeypot) are navigated to by the bot, a function can pick up the IPs from the weblogs and add them to the WAF rules to blacklist that specific IP. A serverless function service is available on AWS, called Lambda, and can support this pattern easily.

As our second example, let's look at another example of an enterprise environment:

An enterprise IT environment typically looks like the network topology as shown—spread across multiple office locations and regional cloud environments. The cloud native security approach requires us to utilize nuanced approaches at several layers to mitigate vulnerabilities.

Enterprise environments are typically spread across multiple sites and cloud providers. This is done to minimize business risk, reduce blast radius, support workloads that are required to stay on-premises (such as nuclear reactor power control applications), and to support satellite office locations. This creates a large attack surface and requires security controls at several network interchange locations.

The first tools we can reach for are familiar to all IT veterans: site-to-site VPNs and private fiber connections provided by ISPs and CSPs (for example, AWS Direct Connect). The second is to utilize network access control lists (NACLs) to prevent all non-standard network pathways. For example, in the previous diagram we have several different subnets across two cloud regions plus two corporate locations. If we have office productivity apps running in subnet 2, we can enable NACLs to restrictively only allow packets from the CIDR range of the office users. Let's say DBs are also in subnet 2; we can add rules to allow connectivity to subnet 3 and 4 to work with the application servers running in region 2.

Furthermore, we can restrict our high performance compute (HPC) cluster utilizing personal identifiable information (PII) data running in subnet 1 to only communicate with our on-premises servers in using network pathway 1. The use of NACLs allows us to provide a high level of control to connectivity across disparate enterprise sites.

Looking at each VPC individually, we should understand the type of traffic ingress and egress. This gives us a baseline of good traffic, the ability to catch improper packets from non-approved pathways, and a tool to debug applications as they misbehave. CSPs have services such as AWS VPC Flow Logs, which captures and generates logs containing the source/destination IP, packet size, time, and other metrics for packets entering and leaving the VPC. These logs can be ingested into SIEM tools to monitor non-approved or abnormal behavior:

A cloud native security approach involves layering security services at every layer of the stack. From the bottom network layer, up to network interfaces, within an instance's OS, running against data stored across the environment and finally against user behavior within the overall environment.

In addition to the wide spread of the network we need to protect, we must also consider how to deal with the hundreds or thousands of users that will interact with the environment. How can we safely and responsibly enable them to work and be productive while mitigating risks of accidental keystrokes?