DevSecOps: Deception in Depth

Mantraps, tripwires and tarpits … sounds like the start of a solid spy-movie plot, doesn’t it? These are among the many concepts of physical security that are making the crossover to software security.

You’ve likely heard that security is all about defense in depth—the idea of layering several defensive measures so that their combined effectiveness is stronger than if they were used individually.

In the case of deception, we are taking tried-and-true warfare approaches and applying them to DevSecOps. According to researcher, deception specialist and popular speaker Herb Todd, there is no rule of law in warfare, and in environments where you put code on the web, you are giving the world access.

Deception Approaches

There are two primary approaches to deception in software security. The first is to get attackers to look in places where you have no vulnerabilities. Todd would call this, “Appear weak where you are strong.” This is what honeypots do: offering an attacker a weak-looking target that appears as if doors are unlocked and there’s an opportunity to gain a foothold. All the while, there is no real vulnerability to be found, and the defensive team can be alerted to an adversary on the network.

The second approach is to isolate or slow down attackers as they progress through your networks and application. One way to do this is to add tripwires throughout. When parts of your web application starts being manipulated in ways that normal users wouldn’t do, you know you have an adversary testing your application looking for vulnerabilities. At this point, you can move them off to a segmented portion of your application or network through the use of a mantrap, or slow them down with a maze or tarpit.

Provoke Action

Deception measures hinge on being able to get attackers to take an action. This is the main goal of deception. If we can provoke an action from the adversary, then we can begin to understand them and to track them throughout our system. This creates a feedback loop in DevSecOps for developers, operations and security to determine how many adversaries are currently interacting with the system, what they are attempting to do and how to add new defenses in the future.

None of the major data breaches you read about start with the organizations saying, “Our security team has been tracking these attackers for weeks.” In fact, it is the exact opposite: We usually learn that the attackers had been inside the system and exfiltrating data undetected for months on end. The organization didn’t know they were under any attack until after their database got dumped on the internet or leaked to the media.

Start with Tripwires

Deception sounds great, but how do you go about it? In Todd’s talk on the Modern Security Series, he gave several ideas on how to get started in the case of web application security development. Methods in DevSecOps include adding fake paths to robots.txt and fake hidden fields to your application. When someone hits your tripwires, you log it and fire an alert for the team to investigate. As you gain familiarity with that, moving into tarpits and mantraps begins to make more sense.

One example that Herb Todd gave in his talk was to add a hidden field of “encrypted-auth” and set it equal to “YWRtaW49ZmFsc2U=”. An astute web developer will notice that this is not actually encrypted. This is a base64 encoding of “admin=false.” When an attacker sees this, they will immediately think, “What if I tried sending admin=true?”

So the attacker takes the string “admin=true” and then uses base64 encoding to produce “YWRtaW49dHJ1ZQo=” and submits that. Now, if your application receives a value for the hidden field that isn’t the original value or matches “YWRtaW49dHJ1ZQo=”, then you have actionable intelligence to alert on.

When creating a tripwire is this simple, why stop with just one? Adding small tripwires throughout an application through DevSecOps can be highly valuable to identify more advanced attackers.

DevSecOps: Making a Practice of Deception

While deception is beginning to gain favor among AppSec professionals and thought leaders, it’s not yet standard practice by any means. But this should soon change, as  the next year or two see the best security teams adopting deception strategies—and for good reason. With traditional methods such as web application firewalls (WAFs) breaking down in the face of high-volume traffic and more sophisticated threats, security needs to become more creative. Defense-in-depth concepts such as deception have been proven effective in the physical worlds of warfare and spycraft—and when incorporated into DevSecOps, they can be just as powerful for ensuring protection in the digital world as well.

— James Wickett