Unveiling the Game-Changing Security Architecture That Attackers Fear

The Situation So Far

In previous blog posts we’ve discussed why a security program consisting of only protective controls is insufficient (https://www.vantage-cyber.com/post/the-limitations-of-a-protection-only-approach-to-cybersecurity), and we’ve looked the limitations of typical detective controls (https://www.vantage-cyber.com/post/unmasking-the-limitations-navigating-the-challenges-of-detective-controls-in-cybersecurity) resulting is extremely long dwell times and increased data breach costs. In the post on detective controls, we also discussed why rapid attack detection and automated response would actually reduced the effectiveness of security controls. So, what is the answer? If we can’t rely on protection, and if detection is inherently flawed, what can we do to truly reduce risk to an acceptable level? The answer is the Detection Oriented Security Architecture or DOSA.

Operations Not Infrastructure

There are a number of aspects of DOSA including shifting from an infrastructure focus to an operations focus and leveraging the Pareto Principle (80/20 rule) when it comes to security prioritization but the major components involve the centralized collection of security information, the identification and differentiated use of high fidelity alerts, the use of non-production resources, and the implementation of environment variability.

Security Information Collection

The first aspect of DOSA that we will discuss is the centralized collection of security information. The idea is simple. The longer it takes to detect and respond to a security incident, the greater the cost of the breach. One factor affecting response time is the availability of security information including system, application, and device logs, packet capture, netflow data, etc. Many organizations do not capture this information other than what may be generated using default configuration settings. Those organizations that do intentionally collect this information leave it dispersed across multiple repositories making access more difficult. Other organizations fail to distinguish between security information and alerts and therefore filter out or fail to collect information that could be useful during incident response but that is not an actual alert in an attempt to reduce alert overload.

Step one in a detection oriented security architecture is to enable as much logging and security information collection as possible. This means enabling comprehensive logging on servers, critical applications, network devices, printers, and even end user workstations. All of these generated logs should be sent to a centralized repository. The repository could be as simple as a Linux computer with a large quantity of fast storage configured as a syslog server. If possible, more advanced technologies such as a SIEM or XDR solution should be used to make access and analysis of collected data more effective. There are many commercial SIEM and XDR solutions but for organizations lacking sufficient budget, free solutions such as the ElasticStack (https://www.elastic.co/) and Wazuh (https://wazuh.com/) can be implemented for the cost of some hardware (or virtual systems) and some time. The goal is to collect as much log data as possible as any of it could provide valuable information when investigating an incident. It is important to note that for this step, we are not trying to generate true alerts but rather simply attempting to collect information that may be needed during incident response.

There are some types of information that cannot or should not be sent to a SIEM or XDR including captured networks packets, network monitoring data (e.g., from a solution like Zeek), and netflow data. If your SIEM or XDR solution does have the capability of ingesting packet data or netflow, then it should be used. If not, another option is to implement an NDR (network detection and response) solution. As with SIEM and XDR solutions, there are both commercial and free solutions (https://corelight.com/products/open-ndr/) that can be used. Alternately, it may be sufficient to simply store captured packets, Zeek logs, and netflow data in a central location such as a mapped network drive. In the end, the goal is to collect as much security information as can be generated from the environment and store it in as few repositories as possible. This allows incident handlers to respond as quickly and efficiently as possible.

High Fidelity Alerting

Step two in a detection oriented security architecture involves identifying high fidelity alerts. To understand what is meant by “high fidelity alerts” we need to look at security information in more detail. Security information can be broken down into two large categories, alerts and contextual information. Security information that specifically states that something bad has occurred are alerts and include messages generated from intrusion detection solutions, some EDR information, messages generated form file integrity verification solutions, messages generated form deception technologies, and similar. Contextual information does not identify an action as being good or bad but rather simply records that something happened and includes netflow data, captured network packets, and most logs. When attempting to implement DOSA, alerts and contextual information must be segregated. Conceptually, this could mean creating two different repositories, one for alerts and one for contextual information. More practically, tagging or labeling can be used to provide the necessary differentiation provided the repositories used support it.

Once contextual information and alerts have been segregated, we need to looks specifically at the alerts. Alerts can differ widely when it comes to their level of fidelity as evidenced by the fact that an average of one in three alerts received by a typical SOC is a false positive. Some alert sources are inherently higher fidelity than others. For example, deception technology and file integrity monitoring tend to generate virtually no false positives while network IDS solutions tend to generate more false alarms. This is not to say that lower fidelity alerting is necessarily a problem. Most organizations intentionally tune their detective controls to err on the side of false positives in an effort to eliminate false negatives. DOSA recognizes and leverages this fact, with a bit of a twist. Just as we separated alerts from contextual information, we are going to separate high fidelity alerts from lower fidelity alerts either by using different repositories or via the same tagging/labeling discussed previously. The end result is a collection of alerts that, when triggered, mean something bad is absolutely occurring.

It is important to note that high fidelity alerts will be subject to false negatives. Not every attack will generate a high fidelity alert but that is not a problem as we still have lower fidelity alerts and contextual information to work with. When a high fidelity alert is generated, incident response is immediately initiated. When lower fidelity alerts are generated, SOC personnel analyze the alert and relevant contextual information to determine whether an attack is underway. In other words, lower fidelity alerts are processed in exactly the way that alerts are processed by most organizations today. The only difference is that we are differentiating high fidelity alerts and expediting the IR process when they occur.

This isolation of high fidelity alerts may not significantly impact larger organizations that already have 24x7 security operations centers but is critical for smaller organizations that may not have the resources for 24x7 monitoring. Instead of a fully staffed SOC, smaller organizations can benefit from 24x7 alerting where security alerts are sent to appropriate personnel via email, SMS text message or similar. If an organization generates thousands, or even hundreds of alerts per day, 24x7 alerting is not feasible as the quantity of alerts would be excessive. By focusing only on high fidelity alerts, the volume of alerts will be significantly reduced and the ability of smaller organizations to respond in near real time is significantly enhanced.

Non-Production Resources

The third component of DOSA is the use of non-production resources. In a subsequent posting we will cover the various ways in which non-production resources can be put to use but for now we are going to focus on what they are and one critical benefit they provide. Simply put, a non-production resources is a computing asset such as a file, application, credential, open port, listening services, server, workstation, printer, network device, IoT device, OT device or just about anything else found in IT or OT environments but that has no traditional production value. To an attacker, non-production resources look like production resources but because they contain nothing of real value and perform no real production function, attacks against them result in no harm.

In a previous blog post we discussed how the resistance provided by protective controls provides the attacker with intelligence that can be used to improve subsequent attacks. In another post we discussed why achieving the goal of rapid, reliable attack detection combined with automated response effectively converts detective controls into protective controls and the problem of resistance re-emerges. We can’t rely on blocking all attacks. We can’t rely on detecting all attacks and if we could, we would need to do something with the attacker. Immediately ejecting the attacker gives the attacker intelligence that improves their capabilities but letting them stay increases the risk of harm and may result in legal liability. So, what is to be done? This is where non-production resources come into play.

By giving the attacker non-production servers, workstations, and devices to “play” with, we are no longer forced into immediate ejection. We can allow the attacker to continue in our network, as long as they avoid production assets, until we decide to take action. This approach eliminates the feedback that automated ejection generates and provides, if desired, opportunities to learn more about the attacker’s tools, techniques, and goals; knowledge that can be used to improve overall security. Non-production resources can also be used to generate high fidelity alerts. Because of their very nature, there should normally be no use of or interaction with any non-production resource. Any use or interaction, therefore, represents an alert. The discussion about non-production resources goes far beyond this and will be addressed in an upcoming post.

Environment Variability

The last component of a detection oriented security architecture is environment variability. Most environments are fairly static. Large changes occasionally occur, and small changes occur relatively frequently but from an attacker’s perspective, the environments they target do not tend to vary to any significant degree between attack attempts. Making things worse, even if detected, attackers rarely face long term consequences. As a result, attackers can return to their target environment again an again using what they learned in previous attacks to improve subsequent attacks. It’s like playing a game or rock-paper-scissors against someone who only ever throws rock. Eventually the attacker figures out to throw paper. The ideal situation would be for organizations to change their computing environment regularly so that each time the attacker returned, they would see something different. At best, this increases the attacker’s level of uncertainty causing them to find an easier target. The worst-case situation is that the attacker must re-discover the environment, costing them time and increasing the likelihood of detection. Either situation is desirable.

Making wholesale changes to a computing environment, however, is impractical. Saying it would be challenging to change the names, IP addresses, MAC addresses, operating systems, and open ports of production systems is a significant understatement. Fortunately, the aforementioned non-production resources can help because we can change their names, operating systems, addressing, and open ports. As a result, an attacker interacting with a single environment multiple times will see a different picture and will have to re-discover the environment. The biggest weakness in this scenario is the lack of production system variability but that can be at least partially addressed. Non-production port listeners can be implemented on production systems. This does not require a listening services and therefore does not expose production systems to increased risk. When these non-production port listeners are changed it makes at least some aspects of the production system appear different and, as with all non-production resources, any interaction generates an alert.

Summary

When implemented together, we achieve a security environment that is substantially more security, more responsive, and more resilient than any model previously seen. The use of non-production resources generates high fidelity alerts and when combined with other high fidelity alerting functions, allows organizations of any size to take advantage of 24/7 attack detection reducing the overall attack lifecycle. The availability of centralized repositories of security information allows incident responders to be more effective and more efficient once an alert is generated, further reducing the lifespan of the incident. Those non-production resources also provide defenders with the ability to decide when to eject the attacker reducing feedback and therefore reducing intelligence available to the attacker and making regular changes to non-production resources means that any intelligence gained by the attacker during previous attack attempts will be of limited value. Attackers get caught faster, more reliably, and at lower operational costs. Incident responders engage more quickly with more information and can therefore be more effective. Attackers must work harder, and that work generates less value increasing the time and effort required by the attacker. The result is fewer successful attacks, reduced monitoring costs, reduced data breach costs, and more effective security. Each element of the Detection Oriented Security Architecture will be covered in more detail shortly so stay tuned.