Modern Defense in Depth

Chapter 1. What’s Not Working, and Why?

When you examine the context of defending your users and public-facing web applications deployed in your data centers, you need to understand what’s not working, and why. We discuss the expense and complexity of available solutions, what attackers know and understand, the deficiencies seen in both user and web application protection, a major noise problem that exists, and, finally, why attackers are so successful.

Expense and Complexity of Solutions

For nearly two decades, organizations have taken the multivendor approach as suggested by industry experts, deploying independent lines of defense that operate autonomously in nearly every case. Unfortunately, most of these technologies are designed to solve only a single problem, and they are often found to be marginally deployed, which equates to expensive and ineffective solutions.

For example, to combat cyberthreats targeting users today, it has become a common practice to deploy independent lines of defense between users and the internet. These include next-generation firewalls, advanced intrusion prevention systems, network access control, and end-point malware protection. Data loss prevention systems, sandboxes, identity access and management systems, automated patching solutions, security information and event management solutions, and so on are often deployed around the periphery of the networks supporting the users’ network connectivity.

In addition, many of the security technologies deployed require various skill levels to effectively deploy, tune, and manage, adding to their overall costs. The various technologies also come with their own support, maintenance, and renewal costs, in addition to end-of-support and end-of-life announcements.

For organizations to gain measurable value from the technologies they purchase and deploy, they must be able to implement the technologies to their fullest ability. In many cases, before the technologies are completely deployed, operators are pulled away from deployment and tuning activities to work on new or more critical projects. As a result, the “complete value” of the solution is never realized because it has been marginally deployed.

Finally, and often because of industry consolidation, even if an organization deploys a single vendor’s solutions, the systems still do not communicate with one another, increasing cost and complexity overall.

Marginally Deployed Web Application Firewalls

The number of organizations that have invested in hardware-based web application firewalls (WAFs) to protect their public-facing web applications is enormous. However, many organizations have deployed their WAFs out-of-band, in monitor mode, or have never adequately tuned the WAF rules to their fullest capabilities.

Attackers Understand How Security Technologies Work

Today’s cyberattackers fully understand the shortcomings in the security technologies that organizations deploy, as well as the way they are deployed. For example, attackers know that almost every network today is protected by a firewall. However, attackers still know how to gain access to internal networks quite effectively, right through firewalls.

Because attackers can’t penetrate the firewalls from the outside, what do they do instead? They take advantage of unsuspecting computer users and phish (fool) them into taking some sort of action. The action on the user’s behalf can be as simple as clicking a link or opening an attachment in an email. In the case of clicking, the internal user starts the conversation from within the firewall, outward.

When the return traffic (as a result of the click) arrives on the external side of the firewall, it allows the traffic to seamlessly pass to the internal user. Normally, the return traffic carries a piece of malware, an exploit of a system or application vulnerability, or even worse—ransomware. As soon as the traffic arrives at the user’s computer, it executes the malicious code and normally allows an attacker to gain a foothold into an organization.

Why Do Phishers Phish?

It’s simple. Attackers completely understand how firewalls work. Because nearly every network is protected by firewalls that are very effective at blocking all incoming unsolicited traffic, how do attackers get around them? They don’t get around them because there is no way to do that. Instead, they get the victim to do the work for them.

This Approach Is Not Adequately Protecting Internal Users

When observing the perimeter defenses (commonly called border or edge defenses) most organizations deploy today to protect their internal user community, we can see a common methodology. Most organizations deploy layer upon layer of independent technologies designed to stop various cyberattacks. These lines of defense are normally deployed in a serial fashion with one line of defense deployed behind another, or they are deployed out-of-band, operating in a monitoring fashion only.

Next-generation firewalls are normally deployed as the de facto “first line of defense” at the edge of a network. Using these firewalls, most organizations block all incoming traffic destined to their user community that originates from the internet. However, understanding how phishing works, firewalls are severely limited in their ability to block these attacks.

Looking further in, past edge firewalls, organizations normally deploy advanced network intrusion prevention systems as the next line of defense. These technologies are designed to block “known” exploits of system and application vulnerabilities that often find their way past the border firewalls. However, unknown exploits that can infect users’ computers often pass right through intrusion prevention systems quite easily.

When potentially suspect traffic makes it past next generation firewalls and advanced intrusion prevention systems, the traffic next finds its way to a sandbox technology deployed downstream, usually at the periphery of the internal network. Because most sandbox technologies are deployed out-of-band, they capture copies of network traffic destined to a user computer, ingest the traffic, and try to make some sense out of what the traffic entails.

How Sandboxes Work

When an internal user mistakenly clicks on a link or downloads executable code from the internet, sandbox technology captures a copy of the downloaded code and executes it in the same fashion as the user’s computer would. The whole idea here is to execute the code within a sandbox container to observe the code’s intention without allowing it to spread an infection elsewhere. Because the code has already found its way to the user’s computer, this after-the-fact execution of the code serves to alert security personnel that an infection might have already taken place.

The next line of defense most organizations deploy is endpoint malware detection and protection software (antimalware) on the users’ computers themselves. Understanding that there are millions of discrete variants of malware found on the internet today, these software-based solutions are limited in their ability to defend against every known malware strain, due to computer processing limitations and malware-signature storage.

Surrounding all the security technologies deployed, organizations often deploy peripheral solutions to address data loss prevention, network access control, identity and access management, automated patching, and a long list of other independent technologies designed to detect and/or block internal and external malicious activity.

Most would agree that there is an abundance of technologies and solutions that make up the various lines of defense deployed in most enterprises, just to protect internal users from attackers on the internet. However, few, if any, of these technologies are integrated in any fashion whatsoever, and none them are aware of the other technologies deployed. I fully believe that this “independent lines of defense approach” is a major contributor to high number of successful attacker campaigns, and this commonly accepted methodology must be addressed given that it has been proven to not be adequate in many cases.

This Approach Is Not Adequately Protecting Internet-Facing Web Applications

Next, let’s see how similar, nonintegrated cybersecurity technologies are most commonly deployed in today’s data centers to defend the public-facing web applications hosted there. Here you will find parallel lines of defense that are nearly the same as the lines of defense found when protecting users from the internet. Again, the independent lines of defense are very apparent in organizations’ data centers.

Today, many organizations that use data centers deploy their own authoritative Domain Name System (DNS) servers, web servers, and publicly exposed web applications in what is known as the demilitarization zone (DMZ) within corporate data centers. These DNS servers, web servers, and web applications are normally protected by firewalls as the first line of defense. However, most people don’t realize that firewalls provide little, if any, protection for devices connected in a DMZ, because organizations must configure the border firewalls to allow all inbound traffic from the internet on TCP/UDP port 53 (DNS), TCP port 80 (HTTP), and TCP port 443 (HTTPS).

As a result, organizations still must do better than supposedly protecting their DNS, web servers, and applications with a DMZ. Organizations are next forced to deploy more independent lines of defense like advanced intrusion prevention systems, web application firewalls, bot management solutions, server-based malware protection, and so forth within the DMZ itself to protect the devices deployed there, as well.

This nearly replicates the lines of defense that are deployed to protect the internal user community and adds additional cost and complexity because most of these systems in the DMZs are designed to protect only applications, not user’s computers. Another issue with the aforementioned approach is that, again, none of the lines of defense are integrated and none of them are aware of any other line of defense deployed.

Noise, Noise, and Even More Noise

One of the most significant problems experienced today—because of all the independent security technologies deployed to protect users, DNS, web servers, and web applications that we just mentioned—is the massive number of event and alert logs that each solution generates. Today’s security technologies are very noisy, and, in most cases, organizations are completely overwhelmed by the sheer number of logs that they are supposed to consume daily, not to mention the log and alert fatigue that security personnel experience when they observe those same logs and alerts over and over again.

As a result, security information and event management (SIEM) solutions are being deployed today to provide correlation of events, and not just log collection. SIEMs are often implemented with the hope that an organization will be able to effectively manage the massive number of log and alert entries generated by the overabundance of independent security solutions deployed in separate lines of defense. Significant numbers of analysts are in high demand today. They are needed to comb through the logs and alerts daily in the hope of finding something of interest that indicates a successful attack is taking place or had taken place in the past.

Integration Is What’s Missing with This Approach

When an attacker breaches one of the independent lines of protection in this antiquated Defense in Depth approach (as mentioned in the previous two sections), the other layers are often completely incapable of detecting that one defensive layer was breached. This is primarily because these layers are completely unaware of one another, and they are not integrated except for aggregating logs to the associated SIEMs. The security technologies deployed have no concept of the upstream and downstream defenses and have no ability to make automated changes “on the fly” to one defensive layer versus another. This fact has continually allowed attackers to remain resident in networks for long periods of time—often without detection.

Hacker Dwell Time

The time between infection and detection is often called hacker dwell time. Looking at nearly every data breach in the past few years, the victims have unequivocally stated that the attack and the associated loss of data originally took place months, if not years, before it was detected. In most cases, organizations detect a breach only after third parties began to observe and report on questionable activity indicating a data breach had taken place.

Another observation to note is that most historical breaches happened because of an attacker bypassing or defeating one line of defense. For example, after an attacker gains a foothold in an organization directly through the border firewall (normally by way of phishing attack), the attacker next begins to operate covertly within the internal network, looking like any other legitimate user. Attackers attempt to capture login credentials to critical systems or find ways of exploiting internal systems to get closer to the data they’re looking to steal.

Suppose, for example, an intrusion prevention systems (IPS) deployed as an independent line of defense downstream of the firewall detects an exploit or piece of malware coming from the same IP address on the internet. Does the IPS make a call to the firewall instructing it to begin blocking the source IP address of the malicious traffic upstream? Today, the answer is no. There is no construct in place for these lines of defense to be integrated, and they have no ability to share internal threat intelligence and put it into action. Another example of the lack of integrated lines of defense is as follows:

If an internal user computer was just infected with ransomware and, by some chance, security personnel were made aware of the initial infection via a log or alert, can recursive DNS help eliminate the spread of the infection elsewhere in the network? Yes, it can. Because a recursive DNS server can block a user trying to access a specific domain, did the ransomware-related log or alert trigger an automated change to an organization’s recursive DNS servers to block the ransomware callback domain (which is part of the infection process)? The answer is likely no.

Remember, most ransomware strains must make an initial callback to an attacker for an encryption key exchange, or the attacker will never be able to decrypt the user files. When ransomware needs to perform this callback, we can use recursive DNS servers to stop it and subsequently help eliminate the ransomware from becoming an epidemic by spreading to other devices located elsewhere in the network. As we can see by these two examples, integration between the lines of defense is desperately needed.

Conclusion

In this chapter, I highlighted many of the technologies that are so often found in nearly all organizations today and how they’re deployed. In fact, I have implemented many of the technologies mentioned so far in this book exactly in the same way as previously described.

What I have discovered is that these independent lines of defense commonly found in most organizations are not working in concert, have no awareness of one another, and are not sharing internal threat intelligence or acting on it. Because these technologies are doing nothing more than operating as lone citadels (towers), as highlighted in Figure 1-1, it’s no wonder that attackers are so successful.

Figure 1-1. Lack of proper integration leads to technologies operating as lone citadels.

Figure 1-1 emphasizes the gaps that often occur due to the lack of integration in our current security approaches. Understanding that all of these technologies are operating independently, attackers consistently find ways of slipping through the “openings” that seem to exist between them. Integration of our defenses is the key to better security overall.

What I have also discovered is that regardless of the security technologies deployed, when there is no integration, no automation, no internal intelligence sharing, and no symmetrical actions being taken between the lines of defense, attackers will continue to achieve success at the cost of the victim. Simply put, there must be a better way.

The need to look elsewhere for a more effective model is warranted. My next suggestion is to make a comparison to today’s modern military. So, let’s take a look at how that model operates.