In the 1990s and early 2000s, the prevailing school of thought in information security was that there were two kinds of threats: insider and outsider. The insider was the "trusted employee," loyal to the company and unlikely to be trained in the "dark arts" of hacking; the threat was acknowledged, but generally considered relatively inconsequential compared to the unknown, pernicious outsider. This notion led to the perimeterization of corporate networks, the advent of firewalls and DMZs, and an us-versus-them, insiders-good-outsiders-bad mentality whose natural consequence was the dreaded crunchy-exterior-gooey-interior network design that many companies are still recovering from today. I am still routinely asked, by many of the C*Os with whom I interact,

Which is the bigger threat, insider or outsider?

My resolution for 2016 is to answer that question with,

All threats are "insider threats."

Breaking the kill chain

Undoing years of conventional thinking means addressing one of the more misunderstood ideas in information security today: that of the "kill chain," a supposedly predictable sequence of events that, if interrupted, will result in defeat of an adversary. Lockheed Martin's cyber kill chain. This notion, advanced by Lockheed Martin and adopted widely by practitioners and security tool vendors alike , reflects one pattern of system intrusions observed across numerous organizations and industries. In turn, a school of thought emerged that a defense dedicated to "breaking the kill chain" — investing in techniques designed to interrupt the specific steps Lockheed uses to describe the sequence of an attack — is the best way to avoid information security breaches.

This pattern, however, was far from universal, and what makes this well-intentioned idea dangerous is how it perpetuates the fallacy of defenders-think-in-lists thinking that gives agile attackers an edge. It is self-evident that, to avoid a breach, an organization must seize one of the opportunities to interrupt its progress (break the chain)... but for most elements of the Lockheed Martin kill model, there is an equally effective means of intrusion that does not require that a campaign follow the prescribed sequence. More importantly, the model suggests that attacks can be expected to follow a sequence, rather than evolving as a choose-your-own-adventure novel with multiple branches, reroutes, and twists — an assertion that I will dispute below.

From list to graph

If the Lockheed model is incomplete, what does a more complete picture look like?



Erick's simplified, mind-the-gap style visualization of attack sequences. When my team and I catalogue attack methodologies for purposes of threat modeling, we find many plausible attacks that don't strictly follow the seven-step kill chain. For every attack involving thorough, up-front reconnaissance and targeting, we find equally-effective but less-narrowly-chosen alternatives: SQL injection, remote code execution (RCE), ransomware and watering hole attacks are all methods that are often practiced indiscriminately with regard to victim selection in today's threat landscape. Similarly, for every attack that follows the weaponization-through-installation paradigm of Lockheed-Martin, we find attackers deliberately and strategically avoiding these steps: modern malware often relies on social engineering and common features like Microsoft Word macros to execute without triggering antivirus software, and in some cases bypasses the traditional "installation" stage altogether, running exclusively in memory with no artifacts written to disk whatsoever. The conclusion: for a successful attack, adherence to the L-M cyber kill chain sequence is effective — common, even — but strictly optional.

From the suburbs to the Loop: no longer the "outsider" threat

Best. Attack. Tool. Ever. What these attacks do have in common is their ultimate goal: to move from the theater of the external attacker to that of the insider. Whether it's the Target breach (which did not follow the L-M sequence) , the RSA breach (which did) , or the dozens in between, the trend for the first half of this decade has been of attackers focused on a primary mission: acquiring the single most powerful hacking tool available, the employee badge, and the level of access that badge bestows. That means transferring from the suburban, outsider "line" — a relatively well-defended environment with a relatively limited number of viable attacks and attack targets — to the internal "loop" , rich in attack surface, and in which movement between zones and systems is accessible by design to the workforce entrusted with operating the organization's IT systems and business. As long as the outside attacker remains on the "suburban" line, the associated opportunity for theft , sabotage and disruption is limited*, relatively speaking, to methods such as DDoS, RCE or SQL injection against a limited target set . Once acquired, however, "badge-level access" yields opportunities to get at corporate systems or "crown jewel" level databases that are rarely exposed directly to the Internet. The "hail mary" pass is spectactular, but rarely works as well as simply, methodically moving the ball down the field, accumulating incremental gains step-by-step on the way to the end zone. Similarly, the ability to "board" the loop and move from station to station on the corporate network of web servers, applications, databases, corporate systems, and employee endpoints is an attacker's dream scenario.

This, ultimately, is why we are seeing the distinction between outsider and insider threats quickly disappearing: one of the first steps in a successful outsider campaign is to stop being an outsider. Our goal — to interrupt an attack, regardless of the twists and turns it may take — implies that defenders must abandon the us-versus-them, trusted-versus-untrusted mentality that made so many of our environments vulnerable in the first place. It also requires defenders to disabuse ourselves of any notions we have of an "insider" threat's skill levels: that suspicious flow showing up on the analyst's console may have an RFC1918 source IP address, but the keys being pressed may be somewhere else entirely .