Using Deception Technology for Threat Mitigation

Deception is becoming more and more popular as a detection technology. This is largely due to the unique advantages it offers over other detection technologies – advantages like highly accurate triggered alerts and relatively effortless deployment and maintenance. And while the value of these applications is clear, too often organizations using deception for detection miss out on the full potential of the technology. These organizations have valuable opportunities to build upon the detection approach they already have in place, leveraging their deception capabilities for improved the detection’s results and add mitigation and response.

No More False Positives

One of the largest problems with other detection technologies on the market today is the abundance of false positives. While other solutions do their best to reduce or consolidate the amount of false positive alerts generated, false positives are simply not a problem for deception in the first place. Whenever a deception solution triggers an alert, you know that alert is correct, and actions should be taken ASAP. After all, nobody in your organization has a need to access the deception layer, so any access attempt is suspicious or malicious by default and should be dealt with immediately.

Faster Mitigation

After receiving the deception alerts, the SOC or security team can immediately identify which asset is infected. From there, they can commit to one or several different types of response actions, such as:

1. starting their hunting activity
2. checking and correlating with other events in the SIEM, and
3. sending a rule to a firewall to block the infected endpoint from exfiltrating data, etc.

However, the best response would be to properly identify the process active on the infected endpoint that initiated the access to the deception layer. There are several avenues for attackers trying to breach an, whether through remote infection, or by exploiting trusted insider access. The infected endpoint can also communicate with the deception layer in one of several methods. For example, it can respond to a server request and become a Man-in-the-Middle (MITM) instead of a real server response. The decoy is able to collect relevant information about how the infected asset is communicating with the decoy, and identify the infected IP address and the source TCP port being used to initiate the access.

Automating Incident Response

You are seriously short-changing deception if you are using it solely as a detection mechanism. If an organization falls into the trap of pigeon-holing deception as a detection capability, they will inevitably miss out on some of the most advantageous applications of the technology, such as automated mitigation and incident response.

The optimal approach is to automatically gather the above information from the deception layer, start the analysis/forensic process and then end the attacker’s activities. Analyzing the infected asset starts by identifying the process that is communicating with the deception layer and then collecting its internal activities, its accesses to other assets in the organization, and to the Internet. From there, organizations can disable the activities of the attackers either by stopping the infected process (so the asset can continue to function), blocking the process from communicating to the network, or quarantining the asset.

It would be even better still to map the attacker’s previous activities on the asset, automatically assembling detailed forensic information that will allow the security team to see what other targets the attacker touched after or before detected and mitigated (retrospective analysis).

This kind of approach calls for a component that either exists on the endpoint, or a component that is able to communicate with the endpoint in such a way it will be able to fetch all the above-mentioned information along including the history traces. Ultimately, this will allow organizations to carry out the entire detection and mitigation process automatically, without human intervention.

If you are interested in learning more about Fidelis Deception, please click here.

If you are interested in learning more about Fidelis Endpoint, please click here.

Fidelis Deception and Mitigation

Fidelis Deception takes advantage of the above architecture. Fidelis Deception can be used as a standalone product, but it also is tightly integrated with Fidelis Endpoint supporting the above approach. Fidelis Deception is capable of informing Fidelis Endpoint of the attacker accessing the decoy and the endpoint detection and response (EDR) solution – based on different playbooks – will take the right action to block and mitigate the attackers’ activities and minimize the damage caused to the organization.

Fidelis Endpoint is a fully-fledged EDR responsible for continuously collecting all access to files, systems calls, network connections, and registry, and . taking multiple mitigation actions such as quarantining the asset, killing the process communicating with the decoy, stopping the infected asset and more. With Fidelis Endpoint you can automate response with pre-built scripts and playbooks or customize them for your specific environment.