Deceive or Treat

4 min readNov 13, 2021

In this article, I’ll try to deep dive a little about Deception and why you need to consider it as part of your security strategy.

I’m sure most of you know what deception is and its history, so I don’t think I need to explain it, but if you need refreshment, you can check this and this to get the background and understanding about deception.

Now, let me start by explaining why you might need it.

If you’re following the NIST framework and the industry best practices to achieve targeted capabilities, that should be enough. However, we have witnessed increased threats from remote working, cloud transformation, IoT expansion and other regulations that require more adequate controls to increase the resiliency of your environment. That means (but not necessary) a new thinking model is needed based on game theory instead of traditional controls theory, and one of these new tactics is deception. There are two types of deception as follows:

1) Active Deception, which assumes the attacker already get into your environment. In this type, your objective is to confuse malicious users, increase his effort and cost as much as possible without degrading your services until he either gives up or you’re in a better position to eliminate the attack.

2) Passive deception, like sensors deployment to detect/notify if any reconnaissance is happening by malicious users. In this type, your objective is to get a notification as fast as possible (i.e. early warning), isolate and study attacker’s tactics and act according to the level of the threat exposed in your environment.

The covertness score of your deception deployment (i.e. to be detected by an attacker) would play an essential role in your action to isolate, study or eliminate the attack.

Most likely, you would need both types of deception as ATP attacks will continuously attack your systems even though he became aware of the deception deployment in the environment.

The deception, to be effective, needs to be deployed fast, automatically and dynamically changing.

However, that would come with operational challenges and costs.

You might ask, does it worth? That would depend again on your industry and threats landscape and the criticality of your business at the national level (i.e. critical infrastructure or services). However, in my opinion, the deception is worth considering (in general) regardless of these factors, but the deployment model might be different. The most important thing that you need to understand deception is not a point solution and more of a methodology to increase your systems’ resilience to security threats.

Researchers suggest different deployment models, for example, the Deception in Depth model, by deploying layers of deception techniques with the weakest layer at the periphery and the strongest one at the core of your systems to assess the intention and capabilities of malicious users. Gartner identified four deception layers (Network, Endpoint, Application and Data) while the weakest deceit at the Network and the strongest at the Data.

How do you design your deception scenario model? by the following three steps:

Step 1: Discovery & Analysis

Your initial step should start by analysing your current environment to identify the possible entry points, targeted systems, surfaces and constraints/limitations of existing controls.

Step 2: Build a Story

The previous analysis should sketch what deception story you want to make the attacker believe or perceive. Most likely, you will create multiple deception scenarios for each deception layer, as explained before, then deploy required deception techniques accordingly in your environment. And the deployment of these techniques could be one or a combination of Built-In, In-Front-Of, Added-To or Standalone-From the possible targeted systems.

Step 3: Create Evaluation Metric

Once all done, you need to test your created scenarios if it works as planned by running attack simulations, and in-addition you frequently need to measure the covertness score of your deception.

Finally, in your regular operation, you need to consider one of the following operational run models for the deception in your environment shown below. Again, it’s important to remember it’s a process and not a point solution, as mentioned before, and you frequently need to revise your run model as your environments and threats changing.