DosAndDonts

When designing decoys, keep the following topics in mind:

Don't confuse your real users.

One reason why people hesitate to adopt deception technology is that they are afraid of false positives. You will lose your users if they start worrying about being presented deceptive information. The best way to avoid confusing your users is to only deploy decoys that require some type of tool or action to be revealed, such as:

• the source code 'inspect' feature
• the developer tools of the web browser
• an interception proxy
• forced browsing / brute-force scripts
• dedicated web app scanners
• fuzzers

This means that you should not add a button in the main UI and hope that only attackers click it. You should avoid decoys that can be triggered with a botched URL copy/paste. You should not use a decoy which overlaps with an existing, legitimate action. The rest is fair game.

What this means is that, as an attacker, I can still trust the visible UI options. But this part is likely to be the most tested and robust one and thus the least vulnerable...

Use detection decoys.

A detection decoy is a decoy which does not have any 'inject' part. Detection decoys can be useful to protect the parts where deception is not a good idea, such as in the main UI. A good setup is as follows:

• you have a backend endpoint which expects a certain input
• you expect the input to have certain properties (such as: be of type integer, be positive, not be greater than 10)
• you restricted the UI to enforce these properties (client-side validation) All that is left is to define a decoy which checks if the rules are violated.

Use threat modeling

If you're not sure what kind of decoy to deploy and where, then consider having a brainstorm phase during threat modeling. When you identify a possible attack - even if you know that your application is not vulnerable, think whether there would be some space for a decoy or for a detection.

Use obvious decoys

"who would code an application which trusts a 'role' cookie to enforce access control?" Well, many applications do. If you add such a decoy, your attacker will have to decide:

• "it's a potential vulnerability": you will get the alert
• "it's obviously a trap": this mind state will reduce the willingness of the attacker to ever tamper with role cookies in the future. The attacker will now further expect the application to use deception and will be wary about everything, slowing down the attack process and possibly preventing the exploitation of another, equally suspicious-looking, real vulnerability.

Use subtle decoys

If you use obvious decoys, then the attacker might think that they got you at your own game and will start avoiding 'easy' attacks in favor of more advanced ones. By blending basic and advanced decoys, you will reach maximal efficiency.

Use many decoys - or not that many

We estimate that attackers have a certain preconceived estimation of how many deceptive elements an application should have. What this means is that:

• if you add only few decoys, attackers will overestimate the number of decoys and will refrain from attacking legitimate elements (thinking they are traps)
• if you add many decoys, attackers will underestimate the number of decoys, will try to list your decoys, and consider the rest valid (and be detected)

Don't brag

The fact that you use decoys should not be a secret, as it has a psychological impact on the attacker who will start to blame deception for anything going wrong during the operation (instead of doing a real root-cause analysis). But don't say how many decoys you use or what type of decoy you use, and don't brag that your application is protected with deception as some attackers may take this as a hacking challenge. The best compromise is probably to let attackers realize that there is deception by themselves - either because of the default x-cloud-active-defense header, or because of the presence of some obvious decoys. The more you keep things blurry, the better.

'spread' decoy injection and detection

The injection and detection can be two elements completely separated. You may for example inject a GUID deep into a javascript helper file, and test for its presence in an entirely different part of the application.

Test, test, test

Cloud active defense can inject anything into any HTTP response. This means that you can inject javascript code that will be executed on the user's browser, and that you can completely modify the layout and content of what is shown to the user. Be careful not to confuse your real users and be careful not to break the UI. Injecting a single character at a bad position can possibly mess up the full user experience.

When working on new decoys, do as follows:

• add to your whenTrue clauses a check whether the request comes with a tester=<your-name> cookie
• when trying out the decoy, attach a tester=<your-name> cookie to your requests
• once satisfied with the behavior of the decoy, remove this whenTrue clause, effectively releasing the decoy to the public

We recommend that you run your integration tests on the normal application (e.g. without decoys), then that you test it again with the deployed decoys. Since they are supposed to be about normal application usage, all tests should pass again - and zero alert should be triggered.

Think about alert response

It's up to you to decide what to do when an alert is triggered. If you ban the IP address immediately, this might let the attacker understand what triggered the ban - and thus identify a decoy. An alternative is to wait for a random amount of time before banning, and/or, since the alert is sent in real time, to look at all logs received from this IP address (including application logs and security logs) for traces of a possible successful intrusion (such as a successful login).

If there is an authenticated user identified when the alert is triggered, you will want to contact the user and to ask for a password reset.

Be careful as well with automated response. Blocking the ip address of a corporate VPN can block legitimate users using the same VPN. Blocking based on the ip address and on the user-agent can remediate this issue, but then an attacker using two different browsers or spoofing the user-agent will be able to work around the ban. You may want to restrict automated response to authenticated requests only and leverage the session token instead.

In any case, all alerts should be actively monitored and followed-up on, including alerts for which an automated response is in place. Using an automated response will help you gain some time, but you will always want to correlate the alerts to your network and application logs to get a global picture of what is at stake and of what damage might already have been done.

Think about your public information

If you expose an API along with its OpenAPI specification, then don't add decoys to whatever is public. This will frustrate people trying to develop something calling your API and attackers will just have to read the OpenAPI specification to identify what was added. Detection decoys remain a valuable addition, though. You can also always add decoys which simulate 'hidden' features or 'outdated' versions.