Tuesday, February 28, 2012

Identifying Scope for a Breach

I've spent considerable time of the last ten years in training new team members.  This is a whirlwind of activity; explaining the organization, the history, why some things are done stupidly, as well as how the team has grown to respond to security breaches.

When I first started doing this, it was an informal thing involving a white board and shoulder surfing while I did stuff.  By the time I left my last team I had much more structure around the orientation of these new team members.  But I'd like to go back six years.

I was training a new teammate.  He had no exposure to incident response or incident detection (Both of which I mentally lump together and call "Defense").  I had no formal training in defense, I relied on "just in time" training, sometimes called "On the job" training.  Because of that, I was pretty lousy at explaining things.

I focused on the tools I used and how to use them.
I explained when and why I jumped from one tool to another.

Or at least I tried to.  How do you explain your mental processes, your range of experience?  Without good introspection and clarity you will have an extremely difficult time explaining "Why".  The "What" and "How" on the other hand are easy and what inevitably the discussion turned to.

Too many times, the answer to the "Why" resulted in a one word response of "Because" with no elaboration.  It was in my head but I couldn't express it intelligently.

But I now have a partial explanation on this.  It was my assumption as a responder that my goal is to identify the scope of the incident.  A fair assumption, as that is what any book or whitepaper will tell you.

And it's both wrong and right.

The goal is absolutely to identify the scope.  Proper ID of the scope is an outcome of your investigation.  But as a seasoned incident response analyst, it's not actually the process you follow.  You consciously are asking "Is this out of scope? Is this just a symptom or the cause? What about this thing over here?"
This line of questioning and the reasons I knew when to switch tools or analytic techniques was not methodically identifying the scope of the breach.  The line of questioning and techniques I was using was instead answering an implied question of
What can I find that proves the scope of this breach isn't larger than what I believe it to be?
There's a bit of nuance there, but when it's practically applied it makes a large difference.  My new teammate was not instinctively asking this question in his head and I was at a loss to convey the concept.  He was biased in assuming the data he was presented with did indeed identify the scope of the breach.  And he was right; however the data did not proof the breach was contained to what he was looking at.

Proving the scope of a breach is at a particular size doesn't actually prove anything other than it's existence.  On the other hand, the ability to prove something is false (that is, the breach isn't bigger) is provable.  This is a direct application of Popper's falsifiability concept.

Tuesday, January 3, 2012

2011 Reading List

Last New Years I set a goal to read 30 books in 2011.  I nearly got there, with a total of 22 under my belt.  That compares with 2010's total of 17 books; a 22% increase.

I moved over to goodreads to keep track of my books a bit better:

"The Medium is the Massage" by McLuhan was my top book of the year, with "The Exploit" by Galloway as my least favorite.  (Anything with 3 stars or above I would generally recommend).  Philosophy was the most tagged category, with infosec and military right behind it.

Interestingly, reading 30 books introduced some logistics problems.  Assuming each book's average cost was $15 I would have $450 sitting on my bookshelf.  Instead, I did a mixture of using Project Gutenberg and borrowing through the public library to balance things out.  Going through that, I repeatedly failed to have the 'next book' ready, and several days or weeks would pass before it would ship or I could get it from the library.  Finally, reading interfered with other activities (computer tinkering, listening to podcasts, etc) more than I anticipated.

Here's my final 2011 reading list:

Five Star:
"The Medium is the Massage" by Marshall McLuhan

Four Star:
"Strategy" by B. H. Liddell Hart
"The Book of Five Rings" by Musashi
"Gangleader for a Day" by Sudhir Venkatesh
"Kingpin" by Kevin Poulsen
"America the Vulnerable" by Joel Brenner
"Dragon Bytes" by Timothy Thomas

Three Star:
"Analects" by Confucius
"The Firm, The Market, the Law" by Ronald Coase
"Soccer War" by Ryszard Kapuscinski
"Managing Humans" by Michael Lopp
"What Technology Wants" by Kevin Kelly
"On China" by Henry Kissinger
"Tiger Trap" by David Wise
"Tempo" by Venkatesh Guru Rao
"Worm" by Mark Bowden

Two Star:
"Starfish and the Spider" by Rod Beckstrom
"Finite and Infinite Games" by James Carse
"Outliers" by Malcolm Gladwell
"Cyber War" by Richard Clarke
"Cyberdeterrence and Cyberwar" by Martin Libicki

One Star:
"The Exploit" by Alexander Galloway

I'm not making a goal for 2012 but I do enjoy reading.  Already on my bookshelf for 2012:
"The Logic of Scientific Discovery" by Karl Popper
"An Introduction to Information Theory" by John Robinson Pierce
"Thinking, Fast and Slow" by Daniel Kahneman
"Military Orientialism" by Patrick Porter
"The Regulatory Craft" by Malcolm Sparrow
"Steve Jobs" by Walter Isaacson
"The Republic" by Plato
"The Brewmaster's Table" By Garrett Oliver

Two new releases I'm looking forward to in 2012:
"Inside CyberWarfare" (2nd Edition) by Jeffrey Carr (Just released a few days ago)
"Liars and Outliers" by Bruce Schneier (To be released in February)

I'm always looking for good books, feel free to leave recommendations in the comments!

Monday, November 7, 2011

Defensive Kill Chain

So I became aware of the intrusion kill chain in 2009 when Mike Cloppert referenced it in one of his presentations at the SANS Incident Detection Summit (I can't find an agenda to this).  In 2010 he released a formal paper on the concept.  If you're not familiar with the intrusion kill chain please pause and read it.  It's worth your time.  Don't TL;DR me.

I recently used the kill chain as an example in a few presentations I gave.  That made me think a bit more about the kill chain concept.  Specifically I asked the question:  Does the defensive side have a kill chain?

Short answer? no. 

Long answer?  A kill chain relies on the fact that "any one deficiency will interrupt the entire process."  Through an entirely inductive reasoning process I've identified five steps of defense that can, if interrupted, will greatly disrupt the defensive process.  Unlike a kill chain, disrupting one phase will not necessarily interrupt the entire defensive process or posture.

So what's my back-of-the-napkin defensive kill chain?  More precisely, what would a targeted attack focus on in order to disrupt a defensive operation?  First, the attacker will leverage penetrating the defensive operations security of the target.  This is through a variety of means, including OSInt, HUMInt, etc.  Next, the attacker will find weaknesses in the orientation of the defensive operation.  This means taking advantage of both the defenders and overall target's mindset, expectations, and beliefs.  This includes social engineering.  It also includes understanding defensive operations shifts, holidays, and general abilities.  Next, the attacker will leverage this combined information and subvert the IT architecture.  This is exploitation, this is escalation, this is action.  This is done in tandem with subverting the security architecture.  This avoids detection and prevention measures; this defeats any defense-in-depth control which is not already inherently built into the IT architecture.  Finally, the attacker will defeat any responsive/reactive measures by the defensive operation.  This means working faster and better than the defensive team.

The short version of the Defensive Kill Chain: Operations Security -> Orientation -> IT Architecture -> Security Architecture -> Response Activities

I'm wishy-washy on this as an idea; but it's a fun one that I may use and strengthen in the future.

Wednesday, September 14, 2011

Creating a tabletop exercise scenario

There are several types and ways to conduct exercises, drills and team training.  A tabletop exercise is one of the ways that I’ve found generates understanding, traction, and visibility.  It can be a bit overwhelming to create a good tabletop exercise.  Why? It requires an attacker mindset, creative use of evidence trails, technical accuracy and excellent presentation.
Attacker Mindset
You must become the attacker to devise an attack.  Your first obstacle is to define an end state and motive of what you wish to desire.  Disruption? Theft?  It should not be arbitrary.  Once you have your motive you then must develop an attack that’s technically accurate and realistic. I recommend outlining each sequence of the attack to create depth of the scenario (see table)- I’ve had scenarios surpassing forty sequences.
Evidence Trails
Your defensive ops team require tidbits of evidence to allow them to think critically and make decisions.  Ideally these evidence trails are slowly revealed through the course of the exercise and projects real-world activities.  These evidence trails must be customized to the defensive operations tools and procedures- if the defensive ops team utilizes netflow data and HIPS events then fictional flows and events may be presented to them.  I recommend having a potential evidence trail with each sequence of attack in a table.  This will help the scenario stay organized and will allow you to decide how the scenario is ultimately presented to the participants.
Technical Accuracy
The tactics and tools used both by the fictional attacker and the participants must be grounded in accuracy.  A zero day exploit in Adobe Reader is fair; a “zero day exploit” which “takes down the network” is not.
Excellent Presentation
The presentation must be done plainly and convince and inform all levels of audience.  I recommend separating out the attack sequence from the observations and responses of the participants.  Once the table top is complete, you may then walk the participants through each sequence of the attack.  They then tie in their observations and reactions based on exactly what happened.  That’s where the lessons can be learned.

A mocked up attack timeline.  This is used to help build the basis of the exercise.  It helps generate the depth and scope of the attack, the evidence trails, and allows you to then craft how the tabletop exercise itself may be carried out.  
Date Time
Evidence / Artifacts
4/15/11 13:41
Attacker A uses google searches to locate a series of employee email addresses
Screenshots of google hits
4/16/11 08:41
Attacker A sends a crafted phishing message to the identified email addresses
SMTP email gateway logs
4/16/11 8:45
Victim B erroneously clicks malicious link / successfully compromises PC “DougH”
HTTP gateway log
Windows prefetch entry
File: C:\windows\tasks\svchost.exe
4/16/11 8:46
PC “DougH” establishes C2 with example1.dyndns.org:443
HTTP gateway log
4/16/11 8:46
PC “DougH” downloads p.zip from rapidshare.com/
HTTP gateway log
File: c:\windows\tasks\p.zip
4/16/11 8:46
PC “DougH” executes p.exe (pwdump) and transfers results via FTP to example2.dyndns.org
Windows prefetch entry

Thursday, September 1, 2011

Establishing Defensive C2

Sustained defensive operations should expect an incident at any time. This has tought me that well crafted, exercised, and useful C2 is required. This is particularly important for operations which have small teams, geographically separated personnel or lack a 24x7 operations center.

The below techiques may seem banal but it's striking at the seemingly lack of recognition by the community on how vitally useful they are. Offensive operations are deliberate in both their actions and their C2. Defensive operations require those same characteristics. I loosely define communications plans as a formalized C2 structure at both an organizational and technical level.

A successful communications plan allows for adaptability, high tempo operations, preparedness, and leadership understanding. These aren't buzzwords, they are achievable and necessary. It is a foundation for medium to large scale incident response operations.

Individual preparedness
All personnel mobile phones should include contacts which are needed during incidents. This includes team members, leadership, external parties, or preplanned meeting locations (see below). Such a list should reside on each team member’s mobile phone. As a contingency, keeping a subset of the most critical contacts on wallet-sized cards and carrying them on your person can provide coverage when cell phones are unavailable.

Keeping these lists up to date can be a nuisance; testing them through scheduled call trees can make sure they remain up to date and useful.

Secure comms
Think in terms of both standard as well as worst case options. If you can no longer trust your hosts or networks how can you properly share and collaborate with team members? How can the defensive team access workstations, servers, or security controls? How can you inform leadership? When and how can you engage law enforcement? Have preparations on how to securely share documents or files with in-team, in-company, or external parties. As maturity develops, different categories of communications may be used. For instance, open email may be satisfactory in some incidents while encrypted attachments are needed in other cases. Out of band communications may also be desired in certain circumstances. Quickly deploying an airgapped network for defensive operations may be needed. Having these defined ahead of time will prevent “just-in-time solution building”. Finally, staff will gravitate towards communications medium they typically use; treat this familiarity as a strength when building a communications plan.

Defensive operations rely on access to equipment. This includes workstations, phones, servers, and other security systems. These control channels - including hands on a keyboard in a data center, coordinating collection of evidence, remote access, application access, and log retrieval - and their contingencies should be considered in the communications plan.

Preplanned Meeting Locations
You know those meeting spots where everyone is trained to walk to in case of a fire drill? Having such preplanned locations (either physical or virtual) can be essential in unknown or complex situations. Many organizations telephone systems can create predefined conference bridges. These conference bridges can act as a central preplanned meeting place for geographically dispersed teams. These bridges can act as a staging and coordination center and can be invaluable. If you do use such systems, be mindful that they may be VoIP and not necessarily out of band.

Various communication media can be used in different ways. Technical staff can achieve a higher performance tempo through utilization of secure and instant communications through services such as jabber, skype or SILC. Such virtual conference rooms can act as a copy/paste medium to spread critical log file entries or other plaintext to team members in real time. If timestamps are enabled its backlog can also serve as a useful historical timeline of response activities. This medium is excellent as it is both realtime and can be used in conjunction of other media such as physical or telephone meetings.

Recognize that heavy incident response operations will utilize a variety of communications at once. These channels can often clash and cause delays or confusion. The response staff should reserve their own communications channel for coordinating activities - determining the vector, scope, and seriousness of the situation. Other channels should be pursued to communicate findings, reports, and recommendations to higher leadership, business partners, law enforcement, etc.

Some conclusions:

  • Comm channels are key and often underappreciated during response activities.

  • Comms plans are essentially C2 activities. These C2 channels need clear paths from top leadership to defenders to defender equipment- if a defender can't initiate analysis or containment then it's going to be a bad day.

  • Comms plans should address realistic contingincies surrounding confidentiality, integrity, and availability.

  • This isn't an exercise of paper but of preparedness.

Monday, August 29, 2011

Dragon Bytes Followup

Last year Richard posted a review of "Dragon Bytes" by Timothy L. Thomas. This book was no longer being published when Richard reviewed the book; to the extend that Richard had to do a followup post to answer questions on how to obtain a copy.

Fast forward nearly a year and I was able to obtain my own copy through Amazon's new/used program. I liked the book. I did a few searches and found several of his papers on the Defense Technical Information Center (http://dtic.mil/). Some of them are directly related to "Dragon Bytes" while a few cover Russian theory and one covers Al Qaeda. They're worth checking out if you have not had an opportunity to get a copy of the book due to it's unavailability.

The Chinese Military’s Strategic Mindset

Google Confronts China’s “Three Warfares

Russian and Chinese Information Warfare Theory and Practice

Russian Views on Information Based Warfare

Dialectical Versus Empirical Thinking: Ten Key Elements of the Russian Understanding of Information Operations

Al Qaeda and the Internet: The Danger of “Cyberplanning”

Also, I recommend "On China" by Henry Kissinger if this subject interests you.

Friday, August 26, 2011

Sustained Operations

Lately I've been thinking of security operations in the context of the duality of defensive and offensive operations. An offensive operation may achieve little if it doesn’t account for security controls deployed by a defensive team. Alternatively, a defensive operation must take into account the tools and tactics used by various categories of offensive operations. In this view, security operations is the combination of both offensive and defensive operations. It is the competition between these two operations.

An offensive operation can exist without a defensive counterpart however a defensive operation cannot exist in a successful or sustained fashion without at least one effective offensive operation. This perception that offensive operations do not exist, are ineffective, or otherwise in a nebulous or unknown state is an undertone in the continual incorrect risk calculations performed by business leaders. This recently has been reflected by both Sony and RSA breaches in 2011 and their apparent disregard for defensive personnel.

If security operations is the duality of defensive and offensive operations, what is defensive and offensive operations? Offensive operations is the willful and sustained intent of an actor or a set of actors to control your technology or information against your will. The operation includes actors as well as the actor’s specific strategy, tools, tactics or procedures. For instance, the Zeus Trojan is not an offensive operation but is a tool of an offensive operation. Exfiltrating data through the use of encrypted RAR files to a drop host is not an offensive operation but may be a procedure of one.

Defensive operations is the willful and sustained intent of actors to prevent such control. This operation may include tasks such as incident detection and response, architecture design, vulnerability discovery and correction. More on what makes up a defensive operation will be outlined in later posts.

The defensive posture built over the last several years has strengthened to a degree which generally deters automated threats such as worms or brute force scanners. The steady and slow advancement of security over the last twenty years has yielded an unexpected result: the offensive side has moved to sustained operations.

Some conclusions:
  • Defensive operations must move to a sustained model of operation in order to counter this growth of depth by nearly all offensive operation categories.
  • It’s in the best interest of offensive operations to have a continuing bag of tools, tactics and procedures and use each as needed over a large period of time.
  • Offensive operations are no longer reliant on a particular exploit. Unlike twenty years ago, such exploits are only a subset of tools at the disposal of the offensive operation.
  • Nearly all defensive operations are exceptionally bad at acknowledging and sharing the offensive operations tools tactics and procedures with each other. I suspect this lack of acknowledging or sharing of information is a contributing factor to successes by the offensive operation.
  • Correcting vulnerabilities as they are uncovered does negligible good for the defenders while deterring known tools, tactics and procedures has a greater impact.

If you haven't read it, my cause and effect post from last year attempts to compare defensive and offensive operations.