Modern Defense in Depth

Chapter 4. How to Achieve the Integrated Approach

In this chapter, we cover the concept of cloud edge and cloud core and what technologies reside within each. Because you will hear these terms often when working with cloud environments, it makes sense to cover these terms first. The purpose of this discussion surrounding edge and core is to understand that you cannot effectively protect the core without adequately protecting the edge first. But how can organizations achieve integration with all the defensive lines previously discussed in Chapter 3? And what are the pros and cons of on-premises security operation centers (SOCs) versus outsourced SOCs? Let’s take a look at the terms “cloud edge” and “cloud core” first, before moving on to the discuss how to achieve integration. Then, we end with a comparison of SOC approaches.

Cloud Edge and Cloud Core

When looking from the perspective of a visitor (or attacker) who wants to gain access to your public-facing web applications, the traffic first arrives at what we again call the cloud edge. Today, there are cloud providers that have built their cloud edge from the ground up, implementing all the security technologies listed here:

• Edge routers

• DDoS defenses

• Managed DNS

• Reverse proxies

• Bot management

• Web application firewalls

• API defenses

• Caching

Conversely, in cloud environments, you will often hear the term cloud core. The cloud core is where the web applications reside. Inside the core, you will often find compute, storage, connectivity, and, of course, databases containing private and highly valuable data. Also, you will often find other security-related technologies that perform encryption, access control, key management, and so forth that are more often thought of in the context of the core because that is where they most often reside.

Integrate Like a Modern Military

The modern military uses the concept of integration in all its defenses by way of capturing and communicating internal threat intelligence gained about the tactics, techniques, and procedures of their adversaries. This intelligence is shared across each of the preceding lines of defense as well as to the lines that follow. What is achieved here is that the lines of defense begin to work in unison, in an integrated fashion, providing synergy and cooperation between all lines of defense. The aim of integrating the lines of defense is to address the shortcomings of the original “definition,” which calls for “independent” lines of defense.

Cybersecurity lines of defense must be aware of each other, much like a modern military, in order to achieve a modern Defense in Depth (DiD) approach to web application security. All lines of defense must be fully capable of sharing internal threat intelligence bidirectionally between all other lines. In addition, where one line simply does not have the ability to block something malicious, another line must be engaged that can perform the required action. Next, let’s discuss how integration is achieved in cybersecurity today.

How Integration Is Achieved Today

I know of only two ways organizations can integrate the lines of defense outlined in Chapter 3: either through a single user interface or through human expertise. Let’s take a look at how these two solutions work, including the advantages and challenges of each so that you can figure out which is best for your organization.

Method One

The first method to obtain integration between the lines, is obtained by integrating the user interfaces (UIs) that provide access to all lines of defense. In most organizations, every technology in each line of defense comes with its own UI. This results in many different operating requirements, expertise, and expense. Most organizations today operate with dozens of UIs in their organizations.

On the other hand, there are some promising steps being made in the cloud. For example, some cloud-based web application security vendors offer a fully integrated UI, from which all defensive lines can be accessed, monitored, controlled, configured, and supported—all from a single screen. An integrated UI is one of the first steps that should take place in a modern DiD approach to better web application security.

Although integrating the UIs of the deployed security technologies is an advantage to the overall technology management, and it can give you the impression that the lines of defense are actually fully integrated “under the hood.” Unfortunately, that’s not always the case. The following is an example of what I mean by this:

Organizations often receive tactical threat intelligence from external sources in the form of threat feeds, and an integrated UI can be used to help push those threat feeds to the various lines of defense. However, one major challenge organizations face is that this is nearly always a manual process, and it does not always address the collection and sharing of internally gained threat intelligence similar to the modern military. Also, it does not address automating configuration changes on one line of defense from the intelligence gained from another line. Let’s look at different approaches.

Method Two

The next level of integration being achieved today is by way of human expertise. This concept currently holds a great deal of promise. This is beginning to be performed in various organizations. For example, many of today’s cloud-based web application security providers who offer the highest levels of security-as-a-service (SECaaS) are integrating their security technologies through integrated UIs as well as by human expertise. They’re integrating the aforementioned lines of defense with multiple security operation centers, operating 24/7 and fully staffed with highly competent security and networking experts. These experts are tasked with operating like a Central Command in the Military, integrating the lines of defense by way of proficiently utilizing automation, scripting, and API techniques.

An Approach Similar to the Modern Military

Figure 4-1 presents a comparison that highlights how similar an integrated DiD approach to better web application security is to an actual modern military, which operates under the same precepts, especially concerning integration.

Figure 4-1. Lines of integrated defenses in the cloud

The figure highlights the integration needed to gain better web application security. Reading from left to right, the lines of defense near the bottom are very apparent. At the top, the SOC, acting like a military Central Command, receives logging and alert information from the various technologies and then uses this information to disseminate the adjustments needed in an automated fashion to the appropriate lines of defense via automation, scripting, and APIs. This demonstrates the true power of integration, as all lines of defense begin to act as one cohesive defensive force, similar to a modern military approach.

Security Products Support Management APIs

Nearly every security technology on the market today supports application programming interfaces (APIs). In this case, these APIs are not designed to be used like ecommerce or social media APIs. Instead, they support the gathering of information from the security technologies deployed in the form of logs, events, alerts, and even traps. The other usage for the APIs is automating security technology configurations with the ability to make changes “on the fly,” often using automation. This is where the tremendous value of scripting and APIs comes in to play.

The Importance of Synergy

The synergy of automation, scripting, and APIs is one of the most vital talents required for SOC teams today. When people hear the term “APIs,” they immediately think of application programmers because they are commonly involved with utilizing today’s APIs. However, in this case, APIs are an extremely powerful tool for security experts who have mastered scripting techniques. When organizations are searching for security experts to be added to their SOC teams, finding those who have extremely high levels of understanding in relation to automation, scripting, and APIs is highly recommended. Let’s take a look how automation, scripting, and APIs operate within the context of a SOC.

When a log (an alert or event, among other things) is generated by one of the lines of defense, this log is received at a centralized logging system located somewhere in the SOC. At that point, there are two approaches that can be taken. One is to have humans acknowledge the log, figure out what the log means, and then determine whether the log can be acted upon with regard to the other lines of defense. However, a more modern approach would be to receive the log and then automate the calling of a preconfigured script that takes some sort of action on one or more lines of defense, by way of making automated changes through the technologies’ APIs.

Common Example

In the case of latter lines of defense, if one of these lines generates a log or alert pertaining to a repeat offender, a script can be called to set up a blocking function at a preceding line of defense quite easily by making a simple change via an API. The concept of scripting is quite powerful due to the ability to write a script one time and then repeatedly call that script to convert a log or alert into an action with very little, if any, human interaction. To help to explain this better, let’s observe the following scenario.

For instance, let’s say the Web Application Firewall (WAF) line of defense detects a steady stream of dissimilar web requests that all appear to be malicious, repeatedly coming from the same source IP address (source). The source is not violating any access control list (ACL) rules on the upstream routers, and the source is not participating in a DDoS attack. The source is not attacking the DNS, and it is performing the required TCP three-way handshake with the upstream reverse proxy. The source has a browser with JavaScript enabled and passes all bot challenges, yet the WAF confirms that the source (likely being controlled by an attacker) is trying its best to break into the web application downstream. Can you defeat this activity upstream? Absolutely.

The best way to block this activity is to automate the calling of a script based upon the attacker source IP address, port, protocol, and behavior and then make a change to all preceding lines of defense via their APIs to block the source for a short amount of time. If the offending source eventually stops the unwanted behavior, another script can be called to remove the block and allow that source through as long as it continues to exhibit good behavior. No one would want to block the source IP address indefinitely due to the potential for IP address spoofing, which is very common. In this case, a short-term block is all that is needed.

Although in the early stages of an SOC, much of this is being performed via human intervention. As the SOC team and its support approaches mature, much of this activity can be fully automated. This is the true power being wielded in the hands of today’s advanced SOC personnel.

Value of Intelligence

Beyond the usage of scripts and automation performed by the SOC team, the value of tactical and strategic threat intelligence can be realized. The intelligence gained by “internal means” can be put into action automatically, making it “actionable” threat intelligence. This actionable concept also includes putting threat intelligence gained from external sources into combat, as well. What is achieved is sharing of intelligence across all lines of defense, from the entire edge to the core, and it can eliminate independent lines of defense once and for all.

Comparing On-Premises SOCs and Outsourced SOCs

Many enterprises today have invested heavily in their own on-premises SOCs, which is a great step in the right direction. These on-premises SOCs include a great deal of logging technology (security information and event management [SIEM]) most often manned by expert security analysts. The advantages of the on-premises SOC equates to measurable improvements in detecting and mitigating attacks, which results in better security.

However, there are a number of challenges facing the on-premises SOC solution: there is a shortage of available analysts and security experts (which is affecting the cybersecurity industry overall), small organizations often cannot afford the salaries these experts are paid, and SOC expert retention rates are poor because their opportunities for career advancement abound. And there is one drawback to this solution: because the on-premises SOC is working to defend a single organization, their view of the worldwide cyberthreat landscape is somewhat limited to the attacks targeting their own networks, users, and web applications, and so it can be difficult for them to obtain and quantify the broad picture.

On-Premises SOCs are Making a Significant Difference

Many on-premises SOC teams are making great advances in protecting their organizations against cybercrime and shortening the time from device “infection” to attacker activity “detection,” especially if they are moving toward full integration of the lines of defense in their organizations, and when SOC personnel are competent in automation, scripting, and APIs.

In comparison, one of the benefits that an outsourced SOC offers is the value of the crowd-sourced knowledge gained from the many different customers they support daily. Today’s cloud-based providers gain and share information across their entire customer base concerning internet routing conditions, the current state of DNS worldwide, global DDoS-related outages, latest and greatest botnets and their infected hosts, new attacker tactics, techniques, and procedures, latest vulnerability information, and more.

Advantage of Outsourced SOCs

Suppose, for instance, that one of the customers being managed by an outsourced SOC is experiencing a new attack vector, a previously unseen source of attack, or some trend or another. The intelligence gained regarding attackers’ tactics, techniques, and procedures from that customer alone can be shared, in an automated fashion, via scripting and APIs, to shore up the defenses for every other customer. This has tremendous value because it nearly eliminates the concept of “every man for himself.”

Many agree that there is currently a skills gap in the cybersecurity industry overall. This gap can be improved through collective human oversight by way of outsourced SOC teams managing the security postures of multiple customers simultaneously. This is the whole point of SECaaS, whereby human-based resources are shared among the masses. When automation, scripting, and API usages are in force, the few can quickly and completely support the many.

However, there may be one important drawback when outsourcing your SOC, and it has to do with privacy. Most organizations do not want to share the fact that they are under attack with other organizations for a host of different reasons, which is understandable. Today, especially in the light of the EU’s General Data Protection Regulation (GDPR) and other like regulations, privacy is a major concern and can never be taken lightly. My advice if you are considering an outsourced SOC is to make sure the provider shares only the source of attacks with others and keeps the target identities private.

Conclusion

In this chapter, we covered two methods of integration to empower you to do the same, similarly to the way a modern military operates. We discussed the importance of the synergy that you can obtain by providing examples of how my recommendations can be implemented. Finally, we looked at the tremendous value of actionable intelligence and ended with a discussion about the benefits and challenges of different SOC approaches to help you decide what’s best for your organization moving forward.