Remember Who the Adversary Really Is

There has been a dramatic increase in the attention paid to the information security field due, in part, to a number of high-profile breaches. There is a much higher level of concern over what information security means, what it provides and how to approach it. The field has graduated from fringe awareness to bad mainstream TV dramas. This growth has also opened a large marketspace where vendors are flooding in to solve all of your security problems for a price. Most often this comes in the form of magic black boxes and expensive software deployments with many promises of technology that will reduce all of the problems to a single alert that the system has protected you from an attack. They will happily tell you that you will need less staff and that your budget should go to them, instead. Meanwhile, breaches continue to happen and go undetected for extended periods. Each new round serves as a sales pitch to just spend more on increasingly complex magic black boxes for protection. At some point, we need to take a step back, re-evaluate who the adversary is, how to confront them, and what tools to use because much of what we are doing now is just not effective.

The Adversary

When the majority of the work is done on computers and code, it's easy to lose sight of who the adversary really is. Behind every breach, banking trojan, or botnet is one or more humans. These adversaries we face are not bits of code, but incredibly complex entities with motives, creativity and an adaptability that a magic black box cannot compete with. As long as we continue to treat the adversary as the latest malware family and a list of indicators instead of a human, we will continue to lose and lose badly. We need skilled human analysts to combat a skilled human adversary.

What Next?

We have rightfully turned towards automation to attempt to solve these problems. There are a lot of avenues for attack and there is a lot of data to deal with. It isn't reasonable to expect human analysts to be able to handle all of this manually. However, in the rush towards automation there has been a focus on replacing humans rather than augmenting them. It is easy to continue to chase the unicorn of a system that does everything and hands it all to an analyst on a silver platter and there are many vendors that are happy to assist. The majority products will give some kind of alert that an attack or anomaly was detected, but rarely do they provide enough data for an analyst to validate why the alarm went off or what it means. We are creating an overreliance on automation and when the autopilot fails there are serious consequences if the pilot doesn't know how to fly without it. The way out is through more human interaction. We need more tools focused on enhancing human capabilities and we need to develop those analysis skills in humans. We need tools focused on allowing a skilled analyst to quickly get the data they need to make a decision rather than trying to make the decisions for the analyst. This also means that analysts need to be armed with the skills for finding valuable data instead of an ever growing list of narrow indicators. A trained analyst will be able to do predictive analysis and work on guessing an attacker's next technique rather waiting to see where and how they strike next.

Tools and Techniques

A significant portion of modern business runs on open source projects. Many of these are extremely complex and scalable pieces of software with many large scale users, contributors and backers. There is no reason that we cannot produce similar high quality, flexible, and easy-to-use security solutions. Projects like GRR, OSQuery, Snort, Suricata and Bro are excellent examples of tools that can allow analysts to go looking for problems rather than passively waiting for an alarm. These are tools that give analysts a tremendous amount of control over what goes in and what comes out rather than leaving them to try and interpret the output of a magic black box. Learning how to use these types of tools to go looking for evil will allow analysts to better evaluate other tools, define better requirements for tools, and respond more effectively to alerts raised by other systems. There are good vendor products out there, but if analysts can't validate what the detection systems alert on then there is no way to know if those systems are doing their job effectively. Skilled analysts with flexible tools will also shift the focus towards learning and sharing attacker techniques rather than searching environments for large lists of malware/attack specific indicators. I will be speaking more on this topic at BSidesSF, including a few usage examples, of these tools and techniques.  

Image

About the Author: Sean Gillespie’s career in the InfoSec field began as a network defender in the USAF where he later transitioned to an attacker role with an aggressor squadron. After leaving the Air Force he has spent most of his career developing tools and techniques for intrusion detection for both DoD and private companies. He moved to the Bay Area as an early member of Mandiant’s Redwood City SOC focusing on advanced detection methods and now works at Yahoo! working on projects such as GRR for effective intrusion detection and response. Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.