Author: James Wickett

  • DevSecOps: Deception in Depth

    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

  • DevOps Predictions for 2018

    DevOps Predictions for 2018

    The new year is upon us, and that can only mean one thing: outrageous tech predictions! This year, we have a few that are easy to believe and a few that are completely off-the-wall. See if you can pick them out.

    Serverless Overtakes Containers

    Serverless is the future and containers are dead. Some (or maybe even a majority) of the industry will come to realize this. Serverless is largely defined as using functions as a service (FaaS) as the backbone of your architecture. These services are a layer on top of containers that provide an opinionated way to run code that scales with demand and ties true compute usage to costs at sub-second billing increments. Much like virtualization in the data center was dwarfed by cloud providers doing opinionated virtualization a decade ago, serverless offerings will overtake the container market.

    DevOps Backlash Gets Loud

    DevOps has been happily spreading through the industry as an extension of Agile to the rest of IT. But in 2018, the pushback comes. In the early days of DevOps, there was a movement called “No-Ops.” It was championed by some, but then later, reversed back to DevOps. This year, we will see stories of failed digital transformations and DevOps attempts at conferences across the globe. At first, they will be marked as “not doing DevOps right,” but as more and more happen, they will be branded with the old-new stigma of No-Ops—and they won’t come back.

    Chaos Engineering Overtakes the Airwaves

    You remember the Chaos Monkey Netflix released to the IT world that captured the hearts and minds of software engineers everywhere? Well, this is the year when chaos reigns! We’ve already had a taste of it through the new open-source project ChaoSlingr on the Modern Security Series show at Signal Sciences, but my guess is that we are far from done. With the release of Nassim Taleb’s book “Antifragile” in 2014, this has been brewing for a few years. Expect to see more chaos-themed engineering books, conference talks and podcasts in the coming year.

    Software Flaws Mean Prison Time

    Unit testing used to seem like such a good idea, but this year it’s going to become illegal to release software without testing rigor applied. Congress has been on the edge of threatening software accountability legislation for years now, but at this point it looks unavoidable. Will this be the year that a landmark legal battle happens and an engineer who didn’t do proper testing gets thrown in jail? Don’t laugh. We have already seen the first signs of this with the VW diesel scandal; just imagine if it was a pacemaker failure. In 2018, lawyers make the new rules for software engineering.

    Promise Theory Finds New Adoption

    Mark Burgess brought physics to IT through his groundbreaking book on Promise Theory and its implications for the way our applications and infrastructure will be built over the coming years. Instead of making assertions of obligation from machine to machine, networks will be composed of voluntary agents making promises. At the time it was released, Promise Theory received a lukewarm reception. But with the new services-based architectures such as serverless and even the rise of container orchestration platforms, the industry is now ready to adopt Promise Theory thinking. Networks, applications and systems are already functioning as voluntary agents working together through promises. This year, we will see more and more mainstream adoption of the concepts and more examples of how to get it right. Get ready to learn how systems can be self-organizing.

    Application Security Becomes More About the Application

    The perennial web application security checklist is to avoid XSS, SQLi and all the rest of the OWASP Top 10. Application security will finally shift from language and framework vulnerabilities to more conversations around how applications are getting attacked. In the new year, the conversation hinges on account takeovers, fraud detection and abuse inside the application. This is good for the industry because we will move past fighting automatic scanning by adding real instrumentation to detect bad actors.

    Happy New Year!

    The next 12 months are certainly going to be an adventure, and I hope you have a happy new year.

    P.S. Please don’t get thrown in jail!

    — James Wickett

  • It’s Time to Break Up with Your WAF

    It’s Time to Break Up with Your WAF

    If the only reason you have a web application firewall (WAF) is for compliance, you deserve better. It’s time to replace it with something that provides not only compliance, but real security value as well.

    In the land of web application security, there are a few not-so-well-kept secrets, arguably none bigger than this: The WAF survived not by being excellent, but by being mandated.

    The WAF is an antiquated technology that was created to help stem the rise of application security vulnerabilities, which had been overwhelming organizations with their frequency of discovery. Static and dynamic analysis tools dumped huge quantities of bugs onto development teams that had no possible way to fix so many code issues.

    Meant as a stop gap measure to address this problem, the WAF made it possible to filter out rampant SQLi, command execution and XSS attacks that were threatening to consume all of the development and security team’s available resources. The idea behind the WAF was that the application bugs and security flaws would be triaged for now, and then eventually fixed in the code at the root of the problem.

    At the time, a drop-in web application security filter seemed like a good idea. Sure, it sometimes led to blocking legitimate traffic, but such is life. It provided at least some level of protection at the application layer—a place where compliance regimes were desperate for solutions. Then PCI (Payment Card Industry) regulations got involved, and the whole landscape changed.

    PCI requirement 6.6 states that you have to either have a WAF in place or do a thorough code review on every change to the application. Given the unappealing nature of the second option, most organizations read this as a mandate to get a WAF. In other words, people weren’t installing WAFs due to their security value—they just wanted to pass their mandatory PCI certification. It’s fair to say that PCI singlehandedly grew the WAF market from an interesting idea to the behemoth that it is today.

    And the WAF continues to hang around, an outdated technology propped up by legalese rather than actual utility, providing a false sense of security without doing much to ensure it. If that isn’t enough for you to show your WAF the door, here are four more reasons why WAFs should be replaced.

    The Minimum WAF Rules Approach is Broken

    A common side effect of a WAF implementation is the blocking of legitimate traffic. In the application security business, we call these false positives. Don’t be fooled by this innocuous phrasing—what it means is that customers aren’t able to buy things they want, or upload their latest vacation photos or generally use the functionality of your applications. It’s the kind of experience that can quickly turn current customers into former customers.

    To combat WAF false positives, most companies run the bare minimum number of rules to get by. This means that only the most obvious and most egregious attacks are caught, while everything else just sails right past the filter. Simple rules mean easy-to-bypass rules, leaving you with an ineffective WAF.

    Learning Mode is Broken at Speed

    One way that WAFs try to cut down on false positives and avoid breaking valid traffic is through a “learning mode.” In learning mode, the WAF learns what normal traffic looks like versus what malicious traffic looks like and protects accordingly. A lot can be said about how tough it is to get learning mode right, even under perfect conditions, but let’s skip to the real problem we see in production environments.

    Learning mode takes time. WAFs that need to learn to recognize “normal behavior” require a certain amount of traffic review before they can actively block everything else. It may take a few hours to learn safe application traffic patterns.

    When you move from waterfall to agile and DevOps, deployment speed gets faster and faster. The application code changes weekly, daily or even hourly. If you deploy using anything close to a modern cadence, putting the WAF in learning mode on every code change means you are always in learning mode. Essentially, any kind of learning mode, when applied to modern application development techniques, just can’t keep up with the pace of production.

    Monitoring Mode Really Isn’t Compliance

    The fact that WAFs have survived due to legal mandates rather than effectiveness isn’t the only open secret in the business. You also won’t be shocked to hear that most companies never put their WAF into active blocking mode. After all, blocking mode has high false positive rates and breaks your legitimate traffic, so it’s the way to go only if you’re hoping to break your application.

    Instead, the WAF is run in monitoring mode, where it watches traffic and logs any event as an attack. When it’s time for audit, the WAF gets flipped on for a short bit, then back off again. In reality, of course, some auditors don’t even care if you have it in active blocking mode. Just having a WAF in place is good enough for them.

    Running your WAF in monitoring mode is not an effective control. All it does is add a false sense of security and additional overhead to the security team to evaluate logged events. In this scenario, you’re spending money where it doesn’t need to be spent while adding close to zero defensive measures.

    CDN-based WAFs Were for Convenience, not Effectiveness

    The last not-so-fun thing about WAFs is their daily care and feeding. Your WAF adds complexity to your network, and having to dynamically scale it in the cloud is not exactly easy. Enter the content delivery network (CDN). Since most shops are already using a CDN to offload web application woes, why not add a WAF at the CDN layer? This meets compliance (yay!) and we don’t have to manage it (double yay!).

    For many enterprises, this idea is the win-win that has allowed the WAF to persist even as its usefulness has been questioned. The problem with the CDN-based WAF, though, is that you end up running the WAF with a minimum set of rules again (see above or here), leaving the door open to all kinds of attacks. In fact, in my work at Signal Sciences, many customers use our web protection platform behind their CDN-based WAF and discover tons of real attacks that happily made it through the CDN.

    If compliance is your main goal, go ahead and use a CDN-based WAF. If you want real defense, look elsewhere.

    Achieve Compliance and Real Security at Speed

    If this article sounds a little too familiar—if all you’re getting from your WAF is compliance—then it’s time to replace it. There are new options for adding defense at the web application layer and achieving compliance at the same time—for example, using runtime application self-protection (RASP) or next-gen WAF to provide application-aware defensive coverage. This means that, instead of just checking a box for PCI, you can be actively defending against the OWASP Top 10, account takeovers, instrument business logic and fight off bots, all without interfering with legitimate customer activity.

    Don’t settle for compliance alone. You can achieve both compliance and real protection—and that’s what your business and your customers deserve.

    — James Wickett