Whitelists and Blacklists

A “whitelist” is a list of things that are allowed, with everything else denied. A whitelist may be contrasted with a “blacklist”, which is a specific list of things to deny, while allowing everything else. In general, we want to be as restrictive as possible (without being silly), so most of the time we want to use whitelists and deny everything else.

IP whitelists are what many people think of as “traditional” firewall rules. They specify a source address, a destination address, and a destination port.¹ IP whitelists can be useful for allowing only specific systems even to try to get access to your application. But because IP addresses are so easy to spoof, they should not be used as the only method to authenticate systems. That bears repeating: it’s almost never a good idea to authenticate or authorize access simply based on what part of the network the request comes from. Techniques such as TLS certificates should be used to authenticate other systems, with IP whitelists playing a supporting role.

IP whitelists also aren’t good for controlling user access. This is because users have the irritating habit of moving around on the network. In addition, IP addresses don’t belong to users, but to the systems they’re using, and NAT firewalls are still ubiquitous enough to make those IP addresses ambiguous. So IP whitelists don’t authenticate individuals; they authenticate systems or local networks in a relatively easy-to-fool way.

In many cloud environments, systems are created and destroyed regularly and you have little control over the IP addresses assigned to your systems. For that reason, IP whitelist source or destination addresses may need a much broader reach than was traditionally acceptable. They may even be specified as “0.0.0.0/0” (representing any address) in limited cases, which firewall administrators have traditionally not allowed for most rules. Remember that we are depending on many other controls besides just IP whitelisting to protect us.

With the rise of Content Delivery Networks (CDNs) and Global Server Load Balancers (GSLBs), IP whitelists are also becoming less useful for some types of filtering (such as controls on outbound connections) because the network addresses can change rapidly. If you stick to requiring specific IP addresses for all rules and the CDN’s addresses change every week, you will end up with a lot of incorrectly blocked connections.

With those caveats in mind, IP whitelisting is still an important tool for cutting off network access where it isn’t needed, as long as it isn’t used as the primary defense or the only method to authenticate systems and users.

DMZ

A DMZ (which in warfare stands for “demilitarized zone”) is a concept from traditional network controls that carries over well to many cloud environments. It’s simply an area at the front of your application into which you let the least trusted traffic (such as visitor traffic). In most cases, you’ll place simpler, less trusted components in the DMZ, such as your proxy, load balancer, or static content web server. If that particular component is compromised, it should not provide a large advantage to the attacker.

A separate DMZ area may not make sense in some cloud environments, or may already be provided as part of the service model (particularly in PaaS environments).

Proxies

Proxies are simply components that receive a request, send the request to some other component to be serviced, and then send the response back to the original requester. In both cloud and traditional environments, they are often used in one of two models:

• Forward proxies, where the requester is one of your components and the proxy is making requests on your behalf.

• Reverse proxies, where the proxy is making requests on behalf of your users and relaying those requests in to your back-end servers.

Proxies can be useful for both functional requirements (to spread different requests out to different backend servers) and for security. Forward proxies are most often used to put rules on what traffic is allowed out of the network (see egress controls, discussed below).

Reverse proxies can improve security if there’s a vulnerability in a protocol or in a particular implementation of a protocol. In that case, the proxy may be compromised, but will usually provide an attacker with less access to the network or critical resources than the actual back-end server would.

Reverse proxies also provide a better user experience, by giving the end user the appearance of dealing with a single host. Cloud environments often make even more use of reverse proxies than traditional environments, because the application functions may be spread out across multiple back-end components. This is particularly true for microservice-friendly environments, such as Kubernetes, which includes several proxies as part of its core functionality.

Although you can have a proxy for almost any protocol, in practice the term proxy usually refers to an HTTP/HTTPS proxy.²

Software Defined Networking (SDN)

SDN is an often-overused term that can apply to many different virtualized networking technologies. In this context, however, SDN may be used by your cloud provider to implement the virtual networks that you use. The networks you see may actually be encapsulated on top of another network, and the rules for processing their traffic may be managed centrally instead of at each physical switch or router.

From your perspective, you can treat the network as if you were using physical switches and routers, even though the implementation may be a centralized control plane coordinating many different data plane devices to get traffic from one place to another.

Network Features Virtualization (NFV) or Virtual Network Functions (VNFs)

NFV, also called VNF, is just the idea that you no longer need a dedicated hardware box to perform many network functions, such as firewalling, routing, or IDS/IPS. You may use NFV appliances in your design explicitly, and NFV is also how many cloud providers provide network functions to you “as-a-service”. When possible, you should use the “as-a-service” functions rather than maintaining your own services.

Overlay Networks and Encapsulation

An overlay network is a virtual network that you create on top of your provider’s network. Overlay networks are often used to allow your virtual systems to communicate with each other as if they were on the same network, regardless of the underlying provider network.

This is most often accomplished by “encapsulation”, where packets between your virtual systems are put inside packets sent across your provider network (Figure 6-1). Some common examples of encapsulation methods are VXLAN, GRE, or IP-in-IP.

Figure 6-1. Encapsulating IP packets between systems

For example, if virtual machine A on host 1 wants to talk to virtual machine B on host 2, it will send out a packet. Host 1 would wrap that packet up in another packet and send it to host 2, which will unwrap it and hand the original packet to virtual machine B. From the perspective of the virtual machines, they’re plugged into the same Ethernet switch and/or IP subnet, even though they may be across the world from one another.

Virtual Private Cloud (VPC)

In the original concept of “Cloud”, all provisioned systems were reachable on the Internet, even if the systems did not require inbound access from the Internet. Later, “private cloud” used the same delivery model as the public cloud, but for systems owned and operated by a single company instead of being shared among multiple companies. Private clouds could be located inside a company’s perimeter, with no access from outside and no sharing of resources.

Although each cloud provider’s definition of VPC can vary, the VPC hardly ever isolates virtual hosts to the same degree as a true private cloud. Shared resources in cloud IaaS often include storage, network, and compute resources. VPC, despite the name, generally deals only with network isolation, by allowing you to create separate virtual networks to keep your applications separate from other customers or applications.

That said, VPC is the best of both worlds for many companies. With VPC, you get the cost and elasticity benefits of a highly shared environment, and still have tight control over which components of your application you expose to the rest of the world. Cloud providers often implement VPC via software defined networking and/or overlay networks.

While it still makes sense in many cases for the front door of your application to be on the Internet, VPC allows you to keep the majority of your application in a private area unreachable by anyone but you. VPC can also allow you to keep your entire application private, accessible only by a VPN or other private link.

Network Address Translation (NAT)

Network address translation was originally designed to combat the shortage of IP addresses by using the same IP addresses in multiple parts of the Internet, and “translating” those addresses to publicly routable addresses before sending them across the Internet (Figure 6-2). Although IPv6 will eventually save us from dealing with NAT, we’re stuck with it for the foreseeable future.

Figure 6-2. Network address translation in and out of a VPC

NAT is used heavily in cloud environments, particularly in VPC environments where you use private range addresses defined in RFC 1918 for the systems inside of the VPC. These addresses are easy to spot and start with “10.”, or “192.168.”, or “172.16.” through “172.31.” The difference in cloud environments is that you generally don’t have to manually configure NAT rules in a firewall. In most cases, you can simply define the rules using the portal or API, and the NAT function will be performed automatically for you.

Source NAT (SNAT, or “masquerading”) is changing the source addresses as packets leave your VPC area. Destination NAT (DNAT) is changing the destination address of packets from the outside as they enter your VPC area so that they go to a particular system inside the VPC. If you don’t perform DNAT to a system inside your VPC, then there’s no way for an outside system to reach the inside system.

There’s a commonly repeated phrase that “NAT is not security”. That is 100% true, but practically useless. Performing NAT doesn’t in itself provide any security; you’re just making a few changes as you route IP packets. However, the presence of NAT implies the existence of a firewall capable of doing NAT, which is also whitelisting the DNAT traffic, and which is configured to drop all packets that don’t match a DNAT rule (or process them locally). It’s the firewall providing the security, not NAT. However, the presence of NAT in almost all cases implies the security you get from whitelisting, and some people use NAT as shorthand for the translation plus these firewall features.

Using NAT in your solution doesn’t mean you’re relying only on the translation feature for security. You also have exactly the same security without NAT by using IP whitelists for the traffic you want to forward with an implied “drop everything else” rule at the bottom.

IPv6

Internet protocol version 6 is a system of addressing machines that makes far more addresses available than the traditional IPv4. From a security perspective, IPv6 has several improvements, such as mandatory support for IPsec transport security, Cryptographically Generated Addresses, and a larger address space that makes scanning a range of addresses much more time consuming.

IPv6 has the potential to make system administration tasks easier in the near future, because overlapping IPv4 ranges can make life difficult from the perspectives of asset management, event management, and firewall rules.³ (Which host does that 10.1.2.3 refer to? The one over here, or the one over there?) Although the use of IPv4 on the Internet will probably continue for decades, a move to IPv6 for internal administration purposes is much more likely.

From a practical point of view, the most important thing with IPv6 is to ensure that you maintain IPv6 whitelists if your systems have IPv6 addresses. Even though many end users don’t know about IPv6, attackers can use it to circumvent your IPv4 controls.

Encryption in Motion

TLS (Transport Layer Security, formerly known as SSL) is the most common method for securing communication of data “in motion” (flowing between systems on the network). Some people may categorize this as an application-level control rather than a network-level control, because in a traditional environment it’s often under the control of the “application team” rather than the “network team”. In cloud environments, those may not be separate groups, so it’s included as a network control here. Any way you classify it, encryption in motion is a very important security control.

Many components support TLS natively. In cloud environments, I recommend using TLS not just at the front end, but for all communications that cross a physical or virtual network switch. This includes communications that may realistically cross such boundaries in the future as components are moved around. Communications between components that will always remain on the same operating system, or between different containers in a pod in Kubernetes, do not gain a security benefit from using TLS.

There is debate in some circles as to whether it’s a good idea to encrypt traffic going across networks you control, because you lose the ability to inspect the traffic as it passes through your network. The implicit assumption is that it’s unlikely for an attacker to get through your perimeter to view the traffic that you want to inspect. As of this writing, one of the top causes of breaches is attacks on web application attacks, allowing an attacker into the application server-which is behind the perimeter, it should be noted. There’s no reason to think this trend will reverse. For this reason, I recommend encrypting all network traffic that contains information that would harm you if made public. This easy rule of thumb excludes network traffic such as “ping”, which contains no useful information for an attacker. Rather than relying upon network inspection to detect an attacker, you should rely upon event information generated by your systems. Refer to Chapter 7 for more information.

Simply turning on TLS is not sufficient, however. TLS loses most of its effectiveness if you do not also authenticate the other end of the connection by certificate checking, because it’s not difficult for an attacker to hijack a connection and perform a “man in the middle” attack. As an example, even on modern container environments it can be possible for a compromised container “M” to trick other containers “A” and “B” to send traffic through “M” (Figure 6-4). Without certificate checking, “A” thinks it has an encrypted TLS connection to “B”, when in reality it has an encrypted connection to “M”. “M” decrypts the connection, reads the passwords or other sensitive data, and then makes an encrypted connection to “B” and passes through the data (possibly changing it at the same time). TLS encryption doesn’t help at all in this situation without certificate checking!

Figure 6-4. Man in the middle attack

What this means is that you also have to perform key management-creating a separate key pair and getting a certificate signed for each one of your systems-which can be painful and difficult to automate.

Fortunately, in cloud environments this is becoming easier! One way to do this is via “identity documents”, which some cloud providers make available to systems when they’re provisioned. The provisioned system can retrieve a cryptographically signed identity document that can be used to prove its identity to other components. When you combine an identity document with the ability to automatically issue TLS certificates, you can have a system automatically come up, authenticate itself with a PKI provider, and get a keypair and certificate that are trusted by other components in your environment. In this fashion, you can be certain that you’re talking the the system you intended to and not to a man-in-the-middle attacker. You do have to trust the cloud provider, but you already have to trust them because they create instances and manipulate existing instances.

A couple of examples:

• You can automatically create certificates using AWS Instance Identity Documents and Hashicorp Vault. When an AWS instance boots, it can retrieve its Instance Identity Document and signature and send those to Vault, which will verify the signature and provide a token for reading additional secrets. The instance can then use this token to have Vault automatically generate a keypair and sign the TLS certificate.

• On Kubernetes environments with Istio, Istio Auth can provide keys and certs to Kubernetes containers. It does this by watching to see when new containers are created, automatically generating keys/certificates, and making them available to containers as secret mounts.

• Cloud certificate storage systems, such as AWS Certificate Manager, Azure Key Vault, and IBM Cloud Certificate Manager can easily provision certificates and safely store private keys.

Heartbleed notwithstanding, TLS is still a very secure protocol if configured properly. At the time of this writing, TLS 1.3 is the current version of the protocol that should be used, and only specific ciphersuites⁴ should be allowed. While there are definitive references for valid ciphersuites, such as NIST SP 800-52, for most users an online test such as one provided by SSL Labs is the fastest way to verify whether a public-facing TLS interface is configured properly. Once you have verified your public interface, you can then copy a valid configuration to any non-public-facing TLS interfaces you have. Network vulnerability scanning tools such as Nessus can also highlight weak protocols or ciphersuites allowed by your systems.

You will need to include new ciphersuites as they become available, and remove old ciphersuites from your configuration as vulnerabilities are discovered. You can review acceptable ciphersuites as part of your vulnerability management processes, because network vulnerability scanners can spot out-of-date ciphersuites that are no longer secure. Fortunately, ciphersuites are compromised at a much lower rate than other tools in common use, where vulnerabilities are routinely discovered.

It’s also important to generate new TLS private keys whenever getting a new certificate, or whenever they may have been compromised. Solutions such as Let’s Encrypt generate new private keys and renew certificates automatically, which can limit the amount of time that someone can impersonate your web site if the private keys are stolen.

Our attacker, Molly, may be able to snoop on or manipulate the connection between the user and the web server, or between the web servers and the application servers, or between the application servers and the database. With a correct TLS implementation, she shouldn’t be able to get any useful data (such as the credentials for accessing the database, in order to steal the data).

Firewalls and Network Segmentation

Firewalls are a network control that is familiar to many people. Once you have a plan to secure all of your communications, you can begin dividing your network into separate segments (based on trust zones) and putting firewall controls in place. At their simplest, network firewalls implement IP whitelists between two networks (each of which may contain many hosts). Firewall appliances may also perform many other functions, such as a terminating VPN, IDS/IPS, or WAF, but for this section, we’ll concentrate on the IP whitelist functionality.

Firewalls are usually used for two main purposes:

• Perimeter control, for separating your systems from the rest of the world

• Internal segmentation, to keep sets of systems separated from one another

You might use the same technologies to accomplish both purposes. One important difference is in what you pay attention to, however. On the Internet there’s always someone trying to attack you, so alerts from the perimeter are very “noisy”. On internal segmentation firewalls, any denied connection attempts are either an attacker trying to move laterally or a misconfiguration. Either one should be investigated!

There are three main firewall implementations in the cloud:

1. Virtual firewall appliances. While still appropriate for some implementations, this is largely a “lift and shift” model from on-premises environments. Note that most virtual firewall appliances are “next generation” appliances that combine whitelisting with additional functionality described below, such as WAF or IDS/IPS. While you design and implement your network controls, treat these separate functions as if they were just separate devices plugged back-to-back, and don’t worry about designing the higher-level controls until you have the perimeter and internal segmentation designed.

2. Network access control lists (ACLs). Instead of operating your own firewall appliance, you simply define rules for each network about what’s allowed into and out of that network.

3. Security groups. Similar to Network ACLs, you simply define security group rules and they’re implemented “as-a-service”. The difference is that security groups apply at a per-OS or per-pod level instead of per-network. Some implementations may not have all the features that Network ACLs provide, such as logging of accepted and denied connections.

Table 6-1 shows, as of this writing, the IP whitelisting controls available on popular cloud services.

Container Firewalling and Network Segmentation

What about isolating access in a container world? Although the implementation differs somewhat, the concepts are still essentially the same. At the time of this writing, Kubernetes is the most popular container orchestration solution, so I’ll focus on it here so as not to get lost in vagueness.

For a perimeter, you will typically use existing IaaS network controls such as VPC or security groups, but you may also use Kubernetes network policies to enact local firewalls on the worker nodes. In either case, the goal is to prevent any inbound traffic except to the nodeport, ingress controller, or whatever mechanism you’re using to accept traffic from outside. This can be an extra safeguard to prevent a misconfigured backed service from accidentally being reachable from the Internet.

For internal segmentation, you can use Kubernetes network policies to isolate pods. For example, the database pods can be configured to only allow access from the application server pods.

The equivalent functionality to security groups is already “built in” for many use cases. In container networking, you allow access only to specific ports on the container as part of the configuration. This performs much of the functionality of security groups at the container level. In addition, containers are usually running only the specific processes needed and no other unnecessary services. One of the primary benefits of security groups is that they act as a second layer of protection in case unnecessary services are running, to prevent access to them.

For a certain amount of virtual machine separation, you can also “taint” specific worker nodes so that only DMZ pods will be scheduled on those nodes. You might put those nodes into a separate VPC subnet. Figure 6-5 shows an alternate version of the sample application using containers.

Figure 6-5. Sample Container Network Controls

Note that this addresses only network isolation; compute isolation is still a concern in the container world, which is why Figure 6-5 showed the most vulnerable systems isolated to separate worker nodes. Containers all run on the same operating system, and an operating system provides a lot more functionality than the virtualized hardware of a VM, which means that there are more possibilities for an attacker who gets inside a container to “break out” and affect other containers.

Allow Administrative Access

Now that you have set up some walls around your application and some internal trip wires to catch anyone who’s gotten inside, other systems or your administrators may need a way of getting past your perimeter to maintain your application.

One of the worst things our attacker, Molly, can do is to get access to administrative interfaces—for example, direct access to our database administration interfaces—and pull all of our customer data out through the back door. Requiring that all administrative access take place via a VPN or a bastion host makes her have to go through considerable effort before even attempting to log into our back-end database. This section discusses when to use VPNs or bastion hosts.

Web Application Firewalls and RASP

At this point you should have a perimeter, internal controls, and a way for your administrators to get through the perimeter as needed. Now, let’s move on to some more advanced controls.

A Web Application Firewall (WAF) is a great way to provide an extra layer of protection against common programming errors in your application, as well as vulnerabilities in libraries or other dependencies that you use. A WAF is really just a smart proxy; it gets the request, checks the request for various bad behaviors such as SQL injection attacks, and then makes the request to the back-end system if it’s safe to do so. WAFs can protect against attacks that traditional firewalls can’t, because the TCP/IP traffic is perfectly legitimate and the traditional firewalls don’t look at the actual effects on the application layer.

WAFs can also help you respond quickly to a new vulnerability, because it’s often faster to configure the WAF to block the exploit than to update all of your systems.

In cloud environments, a WAF may be delivered as Software-as-a-Service, as an appliance, or in a distributed (host-based) model. In the cases of a WAF service or appliance, you must be careful to ensure that all traffic actually passes through the WAF. This often requires the use of IP whitelists to block all traffic that’s not coming from the WAF, which can lead to additional maintenance because the list of IP addresses for requests coming from a Cloud WAF offering will vary over time. It can also be difficult to route all traffic through your WAF appliance without creating a single point of failure. Some cloud providers offer services, such as AWS Firewall Manager, that help you ensure that your applications are always covered by a WAF.

A host-based model doesn’t have these problems; all traffic will be processed by the distributed WAF regardless. You do need to have good inventory management and deployment processes (to ensure that the WAF gets deployed to each system), but this is often an easier task than ensuring that all traffic flows through a SaaS or appliance.

A RASP (Runtime Application Self-Protection) module is similar to a WAF in many ways. Like a WAF, RASP modules attempt to block exploits at the application layer, but the mechanism used is significantly different. A RASP works by embedding alongside your application code and watching how requests to the application are handled by the application, instead of only seeing the requests. RASP modules must support the specific language and application environment, whereas WAFs can be used in front of almost any application. Some vendors have both WAF and RASP module offerings, and an application can be protected by both a RASP module and a WAF.

Our attacker, Molly, may attempt to come right in the front door as a normal user and find some problem with our application that allows her to steal all of our customer data. If we’ve accidentally left a way for her to fool our application into giving up the data, a WAF or RASP module might be able to block it.

Note that one of the most common methods of attacking web applications is the use of stolen or weak credentials. If Molly has a set of administrative credentials providing access to all data, a WAF or RASP module will not defend against this type of attack, which is why identity and access management is so important! However, I still recommend the use of SaaS or host-based WAFs and RASP modules for web applications on cloud, and even APIs can get some limited benefits from parameter checking.

Anti-DDoS

Distributed Denial of Service (DDoS) attacks are a huge problem on the Internet for many companies. If you receive too many fake requests or too much useless traffic, you can’t provide services to the legitimate requesters.

The other controls we’ve discussed are generally recommended; you should rarely accept the risk of doing without them. However, you need to check your threat model before investing too much in anti-DDoS measures. Put more bluntly, is anyone going to care enough to knock you off the Internet, and how big of a problem is it for you if they do? Unlike a data breach where you can never remove all copies of the stolen data, a DDoS attack will eventually end.

If you’re running any sort of online retailing application, or a large corporation’s web presence, or any other application such as a game service where downtime can obviously cost you money or cause embarrassment, you’re certainly a target for extortionists who will demand money in return for stopping an attack. If you’re hosting any content that’s controversial, you’re likewise an obvious target. Note that the bar to entry is very low; there are “testing” services available cheaply that can easily generate too much traffic for your site to handle, so it only takes one individual with a few hundred dollars to ruin your day.

However, if you’re running a back-office application where some downtime will not obviously limit your business or embarrass you, you may need very little in the way of anti-DDoS measures. If this is the case, make sure that you clearly document that you’re accepting the risk of DDoS attacks and get agreement from all of your stakeholders! While foregoing anti-DDOS (or having very limited anti-DDOS protections) may be the correct choice in some cases, it should not be the default choice and it’s not a choice to be taken lightly.

Anti-DDoS measures can be a “blinky box” or virtual appliance, but in most cases today, anti-DDoS is delivered in a SaaS model. This is largely due to economies of scale; anti-DDoS services often need a large internet “pipe” and lot of compute power to sort through all of the incoming requests and filter out the fake ones, but this capacity is needed only occasionally for each customer.

If you choose to use an anti-DDoS service, I recommend you use a cloud provider. You will need to have a method to route all of your traffic through that provider, tune your rules, and practice an attack scenario. There are third-party providers, and some IaaS providers also provide anti-DDOS as a service.

Intrusion detection and prevention systems

In a traditional IT world, an Intrusion Detection System (IDS) is often a “blinky box” that generates alerts when the traffic that passes through it matches one of its rules. An Intrusion Prevention System (IPS) will block the traffic in addition to alerting. An IDS/IPS agent may also be deployed to each host, configured centrally, to detect and block malicious traffic coming to that host. IDS and IPS are almost always offered in the same product, and are generally treated as the same control. If you are more certain that traffic is malicious, or your risk tolerance is lower, you will configure a particular rule to block rather than just alert.

An IDS/IPS rule may be signature based, and trigger on the content of the communication. For example, the IDS/IPS may trigger on seeing a particular stream of bytes included in a piece of malware. For this to work, the IDS/IPS needs to be able to see the clear text communications, which it often does by performing a sanctioned “man-in-the-middle” attack to decrypt all of the communications. This is a valid model, but it makes the IDS/IPS a valuable target for attackers. Not only can an attacker on the IDS/IPS watch all traffic going through it, but an attacker that obtains the signing certificates or private keys used by the IDS/IPS may be able to carry out attacks elsewhere on the network.

IDS/IPS rules may also be based on behavior, triggering only on the metadata of the network traffic. For example, a system that is initiating connections to a lot of network ports (port scanning) may be owned by an attacker. Such rules can be useful even when traffic is encrypted end-to-end so that the IDS/IPS cannot look inside it.

For this control, there is not a lot of difference between traditional deployments and cloud deployments. In the “blinky box” model, the box will often be a virtual appliance instead of a physical box in cloud environments. However, all traffic must flow through that virtual appliance in order for it to detect or prevent attacks. This can sometimes lead to scalability concerns, because virtual appliances often cannot process as much traffic as a dedicated box with hardware optimizations. It can also be difficult to position an infrastructure IDS/IPS solution so that all traffic flows through it, If you succeed at this, you may still add considerable latency as traffic takes extra hops to get to the IDS/IPS and then to the back-end system, instead of directly from the end user to the back end system.

Host-based IDS/IPS solutions in cloud environments also function similarly to their traditional counterparts, although they can often be baked into virtual machine images or container layers more easily than they can be rolled out to already installed operating systems. Incorporating them into images can be an easier model to use in cloud environments, because the systems being protected may be spread around the world.

Although there is some difference of opinion on the matter, an IDS/IPS might not add much value as part of a perimeter control if a Web Application Firewall is used correctly. This is because the Web Application Firewall prevents the IDS/IPS from seeing most attacks. However, an IDS/IPS can be very useful for detecting an attacker who is already through the perimeter. If our attacker Molly attempts to perform reconnaissance via a port scan from one of our cloud instances, an internal IDS/IPS may be able to alert us to the threat.

If you have already correctly implemented and tested the other controls above and want additional protection, I recommend baking a host-based IDS/IPS agent into each of your system images and having the agents report to a central logging server for analysis.

Egress Filtering

You’ve implemented all of the controls above and you want to tighten down the environment even further. Great! You absolutely have to expect and block attacks from the outside. However, it’s possible someone will take control of one of your components. For that reasons, it is also be a good idea to limit outbound, or “egress”, communications from components that you should be able to trust. Some reasons to perform egress filtering include:

1. An attacker may want to steal a copy of your data, by transferring it to some place outside your control. This is termed “data exfiltration”. Egress filtering can help reduce or slow data exfiltration in the event of a successful attack. However, in addition to limiting “normal” connections, you must take care also to block other avenues of data exfiltration such as DNS tunnelling, ICMP tunnelling, and hijacking of existing allowed inbound connections. For example, if an attacker compromises a web or application server, that system will happily serve up the data, bypassing any egress controls). This is primarily useful when you have a large volume of data to protect; smaller amounts of data could be written down or screen-shotted⁹.

2. Egress filtering can also help prevent “watering hole” attacks, although these are less common against servers than against end users. For example, your policy may require that all components are updated from an internal trusted source. However, due to human error, a service might be configured to make unauthorized calls out to an update server that could be compromised by an attacker to provide it with a malicious update. In this case, egress filtering would be a second line of defense against that attack by making it impossible for the misconfigured component to reach out to the update server.

Outbound port restrictions are the simplest way to limit traffic, but also the least effective. For example, you may decide that there’s no good reason for any part of your cloud deployment to be talking to anything else other than over the default HTTPS port, tcp/443, but that you can allow tcp/443 to any destination. That may prevent some types of malware from calling home, but is a very weak control overall. In a cloud deployment, port-based egress filtering can be done via security groups or network ACLs, analogous to the way it’s done for the ingress controls discussed earlier.

Like inbound IP whitelisting, outbound IP whitelisting is becoming less and less feasible with the rise of Content Delivery Networks (CDNs) and Global Server Load Balancers (GSLBs). While these are very important tools for making content and services available more quickly and reliably, they render IP-based controls ineffective because the content may reside at many different IP addresses around the world that change rapidly.

There are two general ways to implement effective egress controls. The first is via an “explicit proxy”, enforced by configuration each component not to communicate directly with the outside world, but instead to ask the proxy to make the connection on its behalf. Most operating systems have the ability to set an explicit proxy; for example, on Linux, you can set the HTTP_PROXY and HTTPS_PROXY environment variables, and on Windows you can change the proxy settings in the control panel. Many applications that run on the operating system will use this proxy if it’s set, but not all.

The second way to accomplish this is via a “transparent proxy”. In this case, something on the network (such as an intelligent router) sends the traffic to the proxy. The proxy then evaluates the request (for example, to see whether it’s going to a whitelisted set of URLs) and makes the request on behalf of the backend system if it meets the validation requirements. Some newer technologies, such as Istio, can transparently proxy only allowed traffic within a Kubernetes cluster.

While HTTP is certainly the most common protocol to proxy, there are proxies available for other protocols as well. Note that for HTTPS connections, the source should validate that the destination is the correct system by means of an x509 certificate.¹⁰ This validation will fail unless the transparent proxy has the ability to impersonate any site, which is risky.

In general, I recommend only limited egress controls (such as port level controls via network ACLs and security groups), unless slowing data exfiltration in the event of a breach is a primary concern. If you have large volumes of valuable data and want to give yourself additional time to respond, strict egress controls may help. In this example, I’ve shown a combination egress proxy and Data Loss Prevention system, but this may also be performed by an as-a-service offering.

Data Loss Prevention

Data Loss Prevention, or DLP, watches for sensitive data that is either improperly stored in the environment or leaving the environment. Cloud providers may offer DLP services as an add-on feature to other services, or you may choose to implement DLP controls yourself in your environment.

If implemented in an IaaS/PaaS cloud environment, DLP may be implemented as part of egress controls. For example, the web proxy for outbound communications may be configured with DLP technology to alert an administrator or block an outbound communication if it contains credit card information. DLP may also be integrated into an IDS/IPS device or as a standalone virtual appliance that traffic flows through and is decrypted and inspected.

A SaaS environment may integrate DLP directly to prevent certain data types from being stored at all or to automatically tag such information. This type of DLP, if available, may be considerably more effective than egress-based DLP controls, but is highly specific to the SaaS service.

If you have sensitive information such as payment information or personal health data, you may need to incorporate DLP controls into your cloud environment. For the majority of cloud deployments, however, DLP may not be required. Unless you are willing to carefully configure the solution, follow up on alerts, and deal with false positives, DLP will only provide you with a false sense of security.