@sroberts advanced persistent incident responder

Intelligence Concepts - OODA

The information security community loves lists, cycles, and other guides for actions. We have important steps that need to be followed, but no investigation is exactly the same, and every one requires a bit of improvisation.

So how do you balance these needs? The paradox of disciplined steps mixed with room to adapt to a situation. Lots of groups are posing solutions, some useful, some not so useful, and some 100% misconstrued. I’m going to take this week to break down a number of the most common cycles and processes including OODA (keep reading!), the Intelligence Cycle, the Cyber Kill Chain, & F3EAD.

The OODA Loop

OODA is easily the most misunderstood cycle on this list. It is simple but powerful, so powerful it causes people to want to over think it. At it’s core OODA is an abstraction of the typical human thought process. Developed by American fighter pilot and tactician Col. John Boyd to understand fighter engagements the OODA loop is applicable to most decision cycles, including incident response decisions.

Boyd's OODA Loop

While the annotated version above is complex at it’s core the OODA Loop is made up of four simple steps.

  • Observe: Gathering data that may be relevant for action.
  • Orient: Next information is contextualized by the decision maker.
  • Decide: Finally based on the contextualized data a decision is made.
  • Act: The decided upon course of action is carried out.

At this point the cycle restarts based on observing the results of the action.

OODA in Incident Response

“Under OODA loop theory every combatant observes the situation, orients himself…decides what to do and then does it. If his opponent can do this faster, however, his own actions become outdated and disconnected to the true situation, and his opponent’s advantage increases geometrically.” - John Boyd

So how does this actually apply to incident response? In a tactical sense this happens all the time:

  • Observe: Monitoring via network (Intrusion Detection), system (Anti-virus), and environment sensors (Social Network Monitoring).
  • Orient: Data is compared against known bad indicators, known good white lists, and considered based on analyst experience.
  • Decide: An analyst decides what to do based on data discovered. This could be to decide it is a true positive (start remediating), a false positive (make a plan for tuning), or inconclusive (gather more data).
  • Act: The analyst initiates their plan to either start remediating, request tuning, or continue gathering more data.

And the cycle begins again. Where this gets even more fascinating is when you compare this against the OODA loop being carried out by an attacker:

  • Observe: The attackers gather information based on implants, usually including scanners, keyloggers, etc.
  • Orient: Access available is contextualized based on goals at the current phase of a compromise, whether persistence is achieved, if current access is specific, etc.
  • Decide: The attacker makes a plan to expand their access, solidify current access, evade investigators, or complete objectives (steal data, turn up centrifuges, etc).
  • Act: The attacker executes their plan using the capabilities they have available.

These two loops are running simultaneously, competing with each other every second. The fact is whichever actor can complete this loop faster, continuously, will be most likely to achieve their objective. Over time it is almost guaranteed that a group that OODAs faster will always have the decision/action advantage, and thus more likely to be more successful. The big caveat to this is in an adversarial setting these loops are occurring simultaneously, meaning that the data collected during the observation phase might not be accurate by the action phase. This is why the relative speeds each actor can complete the loop are so key.

Takeaways from OODA

The great thing about OODA is it gives us a framework to talk about how we make decisions. At it’s core the thing Col. Boyd was able to show in a concrete way something everyone implicitly understands: whoever makes decisions and acts fastest has a distinct advantage.

“The future has already arrived. It’s just not evenly distributed yet.” - William Gibson

For incident response our goal needs to ultimately be to OODA faster than attackers. In most cases at it’s core improving a DFIR capability is all about being able to OODA faster as a team. New sensors improve your ability to observe while threat intelligence data improves orientation. You can’t really put OODA into practice, but it can be used to structure how you think about decision making, and what you can do to improve the speed with which you make decisions.

Further Reading

2015 Professional Goals

The start of the year is a time for goals and plans. I’ve given it some thought and want to put mine out there for two reasons:

  • To be held accountable. I know a couple people who may read this and chide me a bit for not keeping up. I can use that.
  • In the hope that some people may join me in a couple of my goals.

Goal 1: Read one technical book a month

“A capacity and taste for reading gives access to whatever has already been discovered by others.” - Abraham Lincoln

In 2014 I read the fewest technical books since getting done with college. This isn’t a trend I want to see continue. My work life balance isn’t what it used to be, but 12 books covering intelligence, security, and development in a year seems more than reasonable.

I’ve already gotten started with Incident Response & Computer Forensics, Third Edition by Jason T Luttgens, Matthew Pepe, & Kevin Mandia. Even better I’m reading this along with with Alex Pinto. I plan to post a “book report” each one.

I’m also planning on reading:

I’d love to continue having a discussion partner to work through each book with so feel free to reach out if any of these books peak your interest.

Goal 2: Blog at least once a week

“Either write something worth reading or do something worth writing.” - Benjamin Franklin

I’ve had this blog going for a little bit more than a year and honestly I’m a bit ashamed of how little is on it at this point. I think I can do better. Writing forces me to structure my thoughts and gives me a chance to explore ideas that require more than 140 characters.

Goal 3: Learn a System Programming Language

I write Python multiple times a week. Working at GitHub I see Ruby/Rails more than a bit. Between web frameworks and Jekyll I write HTML/CSS/JS quite often. That said I haven’t really spent time working on traditional system programming language since C++ in college (and that wasn’t really a great experience).

While Python is a great Swiss Army Knife of a language there are times you need something more. Google’s Go certainly has gotten a lot of attention and apparently for good reason. It’s highly performant, portable, and has a clean (dare I say Pythonic) syntax. It looks like a great language. I’ve also heard some great things about Rust as well (this article may sway me). Taking the time to learn and develop a project in a system language would round out a gap I have.

Personal Goals

I’m not really keen on making this blog a LiveJournal but while I’m at it I may as well mention a couple personal goals as well:

  • Read 12 cooking books this year. Currently I’m reading Twelve Recipes by Cal Peternell. Cooking more goes along with this of course.
  • Complete the C25K (Couch to 5k) program and run regularly.
  • I’ve been talking for awhile about getting a dog (my wife has had one since before we got married). I’ve never had a dog that was primarily mine and I think it would be a great experience and challenge to raise and train a dog myself.

It should be a great year.

The Perils of (Mis)Attribution

It’s impossible to be involved in the information security community right now and to avoid the incident going on at Sony. All of the details of the attack by “The Guardians of Peace” may never be publicly known, but it is safe to say that this has become one of the defining computer security events from a public perspective. Plenty of people are addressing this from a variety of angles so I just want to speak to one, somewhat tertiary but none the less key issue, the “attribution” debate.

Super Creepy Computer Spy Eye

Obligatory “Darky Computery Hacker” Image

A bit of History

In every major security incident one of the first questions asked is “Who”? We call this attribution (we’ll go into detail on that word later). Defining this boogie man has been the major driver of information security hype cycles since the beginning of our profession.

Time frame Event Boogie Man Result
1980-1990s The Great Hacker War & multiple government intrusions Basement Hackers (LOD, CDC) & Nation State Hackers Selling lots of firewalls. Inventing IDS. Wargames!
Mid 1990 - Mid 2000s Code Red, Slammer, & other computer worms Malware writing criminals & pranksters The Antivirus Market. Ended largely with Conficker.
Dec 31 1999 Y2K Bug Unknown bugs & unintended consequences Nothing. Zip. Zilch. Nada. Society continues.
Late 2009 - 2012 Google’s Aurora Incident China Peoples Liberation Army (APT) Suddenly everything was China/APT. Mandiant released the APT1 report. Everyone at the RSA Conference promised “Anti-APT” solutions. None delivered.
2012 Dozens of high profile activist hacks Anonymous & LulzSec Hactivism is touted as the next great threat to the world. It’s been mostly ignored and a few Twitter accounts & companies (including Sony) were compromised.
Summer 2013 The Snowden Leaks NSA TAO/ANT Global mistrust of the US intelligence community. “Anti-NSA”-ifying of various American companies and a slight global move away from American tech.
November 2014 Sony’s current incident North Korea The press leaks speculation it’s actually North Korea. Vendors release their DPRK reports. The FBI confirms the press rumors. President Obama announces sanctions.

The first thing that needs to be noted is none of these time frames are accurate. Every one of these groups & threats have been active before & since their “time in the sun”. What these rough dates frame is the hype cycle; when the media and vendors have emphasized these various issues. This represents a moving idea of “who the bad guy is” that’s largely based on a single idea: attribution.


Attribution is a loaded word, even in the simplest terms. According to my handy Dictionary.app:

attribute: verb |əˈtriˌbyo͞ot| [ with obj. ] (attribute something to)

  • regard something as being caused by (someone or something): he attributed the firm’s success to the efforts of the managing director | the bombing was attributed to the IRA.
  • ascribe a work or remark to (a particular author, artist, or speaker): the building was attributed to Frank Lloyd Wright.
  • regard a quality or feature as characteristic of or possessed by (someone or something): ancient peoples attributed magic properties to certain stones.

In short attribution is two different things:

  • tying an action to a specific actor
  • characterizing a certain aspect of an action

Reading these definitions attribution seems wildly reasonable to want to attribute a security incident. So why the fuss?

Attribution is Hard

Accurate attribution of attacks is difficult under the best of circumstances and there are a few key, common issues.

Incomplete Information

In most cases collecting data on security events is difficult. Very few organizations really have sufficient, comprehensive monitoring (full network content monitoring, endpoint monitoring, centralize logging, etc) necessary to recreate any and every event after the fact. Even if they do have the monitoring in place few companies can retain those logs long enough to pull up attacks going back 6+ months. Recreating incident are difficult even if you can acquire the malware and exploit vector (phishing email or watering hole). So at best most security teams are working with incomplete information.

Circumstantial Information

At it’s core one of the most attractive things about offensive network operations is how easy it is to be someone you’re not.

On the Internet no one knows you're a dog

  • IP Addresses are easy to fake with VPN software or a cheap VPS, thus seeming to come from any country you like.
  • Many network protocols have limited or zero security built in, making it possible to intercept, spoof, or manipulate many types of communication with proper technology or network position.
  • Most of the Internet doesn’t require any real form of ID, it’s simple to sign-up for Facebook, Twitter, or SSL certificates as anyone.
  • Anonymous payments are easier than most people realize. That means VPS, VPN endpoints, etc.
  • Pay for play & open source remote access trojans, exploits, and attack toolkits mean multiple actors may be sharing significant parts of their toolchain, leading to possibilities of attackers emulating other attackers to encourage misattribution.

In a world where many common attack characteristics are easily changed, manipulated, or mimicked it’s no wonder attribution is difficult.

Operational Security

During any security incident operational security is paramount. This takes on 3 aspects:

  • Internal
    • You don’t want your own employees taking actions that undermine your investigation or recovery. This is actually a fairly common issue.
  • External
    • Letting information leak about your investigation can cause dangerous speculation among outside forces, most notably the press. This can affect a companies financial standing well beyond the scope of an incident. Damage control such as this may not be important to an incident response team, but it’s critical to stock holders and the C-Suite.
  • Attacker
    • The most important operational security concern is preventing any information from getting back to your attacker. If an attacker believes you’re on to them they could take a number of actions: destroy data, change their malware or infrastructure, steal data at a quicker pace, or disappear entirely. Any one of these can be devastating.

As a result it’s key that information that could lead to those outcomes is carefully controlled and only released when it can’t cause any damage.

So What about Sony

I cannot say for certain, having had nothing to do with the investigation, but I would speculate that in this case all 3 (incomplete information, circumstantial information, and operational security) have played a role.

Sony’s Incomplete Information

I don’t want to kick someone when they’re down, but there’s been plenty of information to suggest Sony’s security team wasn’t operating at 100%. It seems reasonable to believe they may not have been in a position to identify and gather information about the attack when it happened. This would lead to gaps of information that would be difficult to reconstruct.

Sony’s Circumstantial Information

This part is the same in every investigation. It is easy to bite and attempt to use information like IP geolocation or certificate data or language pack information, treat it as fact, and make assumptions about an attacker. That isn’t to say this information is useless, contrary it’s highly valuable data, but it does have to be used carefully. Data itself needs to be developed before it can be considered intelligence.

“Carefully” in events like this is tough. It’s hard for security teams, it’s all but impossible for the press or firms trying to feed off the marketing potential of a new and exciting boogie man. Circumstantial evidence like this, coupled with confirmation bias, can often lead to jumping to obvious, even convenient, conclusions.

Sony’s Operational Security

Plenty of people have questioned the FBI’s attribution to North Korea. One of the things most commonly cited is how little information they provide, much of which was circumstantial. This concern neglects, or at least naively ignores, what information they’re withholding deliberately to protect their sources & methods.

Does the FBI/US Gov have better intelligence than they’re letting on? I would guess they do, especially since the intelligence community can access all the different diciplines of intelligence (SIGINT, HUMINT, etc), but burning good sources just to make naysayers feel better isn’t good intelligence management.

Damage Control

A lot has been made of Kevin Mandia’s comments about the sophistication of the Sony attack. Some people have suggested that this leader of one of the best investigation teams saying what he said means this really was an advanced and sophisticated attack. Some have suggested this was just him providing some cover for Sony leadership.

It’s difficult to say which is more the case, though personally I lean towards the former. Regardless this is one of the services an experienced IR firm provides: assuring the public that the situation is being handled by professionals and easing concern. The Mandiant team, being that they’re actually involved in the incident and an experienced team, has a far better perspective than I do.

Good Attribution

So lest I just seem negative lets talk about what makes good, effective attribution:

  • Comprehensive telemetry collected from multiple sources
    • Network full content is great, flow & proxy logs are great too
    • Memory and system logs from any systems the bad guys get into are key
  • Extensive Analysis by multiple experts (hopefully corroborated by multiple analysts)
    • Compromised system memory analysis
    • Compromised system disk forensics
    • Deep malware analysis (dynamic and static, as well as utilizing a comprehensive malware library)
    • Log correlation, especially centralized authentication lots
    • Open source analysis of the attackers infrastructure (attack infrastructure, C2 & exfiltration nodes)
  • Analyzed Multiple Attacks against a single Victim
    • It’s incredibly difficult to see one incident, even a long running one, and develop meaningful attribution
    • Many attackers will come back to the same victim multiple times and comparing these multiple attacks can give incredible insight into how the attacker evolves, what resources they keep going after, etc
  • Multiple sets of telemetry from one incident
    • In many cases attackers use the same tool chain & tactics, techniques, and procedures against multiple victims
    • By sharing information between similar organizations who see the same attackers you get yet another opportunity to understand TTPs vs tactical decisions as well as ultimate goals for actions over target

At it’s core there are two ultimate goals conducting this analysis:

  • Identify common tactics, techniques, and procedures
  • Identify common attacker goals (actions over target)

This process is not for the faint of heart. It takes time, good information, determination, and a skilled team to turn the necessary mountain of data into verifiable, trustworthy attribution. It often requires quite a bit luck. Even if a team can accomplish this and provide solid attribution making the case, especially publicly, can be difficult. Plenty of people in the security world are happy to be contrarian for a variety of motivations.

Actor vs Attribution

When conducting this analysis the question is “what’s the goal?”. Being able to put a name to an actor is psychologically incredibly useful, but does that mean it’s necessary to have a persons given name or the name of their employer for this to be a worthwhile exercise? In my experience this makes for great marketing fodder, but unless you have hand cuffs (and necessary legal documents to use them) or cruise missiles (and war powers) what good is “direct attribution”? I’d argue none at all.

Being able to tie a series of TTPs to a name, even just a made up code name, is highly valuable and removes the “boogie man” fear that most people have to attackers over the Internet. Teams that take this “indirect attribution” approach will start to recognize these code named actors. This leads to faster identification, more effective remediation, and eventually the ability to start applying counter intelligence approaches. This should be every incident response teams ultimate goal.



Ok… this was some amazing Photoshopping by Gizmodo!

So what’s my take: Are the Guardians of Peace actually North Korea? This may be the the unpopular response, but I’ll say it anyway: I don’t know. I haven’t analyzed the malware, studied the packet captures, seen the phishing emails, or anything else relative to the investigation. I know there are smart people working this incident and I trust they’re taking every step necessary.

What I do know is that we are making major decisions based on the idea that this attack can be attributed to the Democratic Peoples Republic of Korea. I don’t just mean whether companies buy a new tool from a vendor with a good graphics department, I mean major international policies. I urge anyone, from federal law enforcement & policy makers to lowly incident responders like myself: be careful pointing & un-pointing fingers. Attribution is difficult when you’re intimately involved with an investigation, and all but impossible to an armchair quarterback.

I also recommend reading Nick Selby’s “I Have No Idea Who Hacked Sony. And Neither Do You.”.

Learning Git and GitHub

I suppose it makes sense that when you work for a company everyone assumes you know everything about using its products. When I worked at Symantecs Managed Security Services people asked me all the time how to use the antivirus. It’s a normal assumption, even if it’s off base.

So working at GitHub I get asked git & GitHub questions all the time. #REALTALK: The fact is I’m not a great Git user. I don’t rebase. I’m terrible about using bisect. I had to squash a commit once and it took me an embarrassingly long time.

There are all kinds of features I know exist but hardly ever use. That said I know about 90% of what I need to use Git effectively, and I’ve gotten pretty good at GitHub (the product) itself. So here’s where I learned and what I think will help you get the most out of Git and GitHub.

Learning Git

Just in case you don’t know what Git is here is a formal intro:

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Git is easy to learn and has a tiny footprint with lightning fast performance. It outclasses SCM tools like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenient staging areas, and multiple workflows.

To learn Git I recommend starting out with TryGit. This is a quick, 15 min tutorial that introduces the core concepts of Git that you’ll need and is enough to get started. It’s pretty much the ideal place to start, and you don’t even need to install anything.

TryGit is certainly enough to get yourself started, but eventually you’ll want to move on to some of the more advanced command line options. To learn those I recommend Git Immersion. Git Immersion is actually done on your own system’s command line and teaches things like rebasing vs merging, tagging, and even resolving merge conflicts.

Learning GitHub

Between those resources you’ll have a pretty solid base in using Git. Those concepts will get you most of the way towards using GitHub effectively, but GitHub does add a few concepts on top of Git such as Comments, Issues & Pull Requests, and Releases.

At it’s core the most important part is what we call “The GitHub Flow”:

  1. The master branch is always deployable. Always.
  2. Create a branch from master of a repository you want to contribute to.
  3. Make commits to the code in the branch.
  4. Push the branch back up to GitHub, you’ll get an interface to create a Pull Request.
  5. You (and the other contributors to the repo) can now commit more code, discuss changes using comments, and finalize the code.
  6. At this point a repo owner can merge the changes.

There’s an even better graphical introduction of the GitHub Flow here. Want one more blog based take? I really like Mark Otto’s Some GitHub Flow writeup that covers each step in great detail. No matter which guide you read if you can master those 5 steps you’ll be a GitHub master.

Being Even more Awesome at GitHub

Now that you’ve learned Git and the key elements of the “GitHub Flow” there are still more fun things to learn:

  • Make some of those Git actions even simpler and more tightly coupled to GitHub using GitHub’s native clients. Check it out for Mac & Windows.
  • Learn GitHub Flavored Markdown to write great structured documentation. GHFM also works in Issues and PRs.
  • Start using Issues to track bugs and enhancements.
  • Emoji!!! Not just for your smartphone, you can use them anywhere you use GitHub Flavored Markdown.
  • Learn GitHub’s keyboard shortcuts. Hint: start by pressing shift+?.
  • Take a look at ways to build great personal & project specific sites using GitHub Pages.
  • And more!

I gave a presentation a few years ago about this, give it a look, but even better just go try it!

Looking for More

  • GitHub Guides - In-depth documentation about using Git & GitHub.
  • GitHub Training - GitHub’s Training team puts on great classes & workshops, many of which are free!
  • GitHub Training YouTube Channel - An amazing group of videos teaching many of these concepts by video with some of GitHub’s excellent trainers.

Crisis Communication for Incident Response

One part of intrusion response that rarely gets enough attention in DFIR circles is the communications victim companies make to their own customers. This is almost always the only real information the public (and even security community) see about an intrusion and communicating what happened effectively is crucial to minimizing damage, both to customers and to your organizations reputation.

The 5 Keys to Incident Response Communication

Be Clear

It’s difficult to investigate many intrusions. It’s often even more difficult to explain them, especially to less technical individuals, but it remains crucial that the communication about what happened be straight forward, ideally limited to a 5th grade reading level. Without this understanding victims will remain confused and critics will remain skeptical. This clarity has to go beyond one message by making sure messaging stays consistent across multiple messages and mediums.

Be Timely

Being timely providing information is a double edge sword:

  • If you communicate too early, before you full understand the intrusion, you have to make lots of follow-ups and seem out of control.
  • If you communicate too late your warning is less actionable to victims and thus the impact is even worse.

Its a fine line to walk. In the end the best option is often to over communicate and assume the worst. It’s far better to retract a statement saying “It wasn’t as bad as we initially thought…” than to continually have to say “Actually it’s worse than we thought…”.

Be Actionable

Most people don’t care about “XSRF whatever” and “Buffer Over blah blah blah” geek speak. They want to know what this means to them: what information was exposed and what they need to do to fix it. Whether it’s needing to setup credit monitoring or rolling credentials a notification needs tell victims what they need to do to protect themselves going forward. They key is to be clear about two courses of action:

  • What is the affected organization doing to protect customers going forward?
  • What can affected customers do to protect themselves?
  • Bonus Points: What is the affected company doing to make sure this never happens again?

Be Responsible

This is the bitter pill, and in today’s overly litigious society one of the scariest portions, but also straight forward: Admitting you what you did wrong wrong and saying you are sorry. This may seem like a parent’s advice to a child, but even surgeons are resorting to this kindergarten strategy:

But with malpractice premiums soaring and a national patients’ rights movement pushing for full disclosure of medical errors, the industry is rethinking the traditional approach known as “defend and deny.” Stories […] are persuading a growing number of hospitals, doctors and insurers that apologies may end up saving some of the huge sums paid out to settle disputes over medical care.

Wall Street Journal: Doctors’ New Tool To Fight Lawsuits: Saying ‘I’m Sorry’

Be Human

Ok, this one is a personal preference, but one of the key things I have learned is you can’t overvalue a sense of humanity in these communications. This is wildly difficult but crucially important. A feeling that a real person wrote something makes it easier to excuse things taking a bit longer than they could have, or makes the apology believable, instead of just lawyer speak.

It’s not easy, but it is worth it. One of the easiest way to do this is by making sure that all communications go through a single point of contact. This allows communication to have a face as well as a voice.

Done Well: PF Changs

The whole idea for this post came out of my initial reaction to PF Chang’s breach response page. I’d heard about the breach, and while I haven’t been to a PF Chang’s in a few years I felt it couldn’t hurt to check and see if I might be involved. I ended up on a comprehensive page discussing their breach and how it impacted their customers.

Characteristic Score Reasoning
Clear 9/10 Yes. Especially if you ignore the first big block of text and go to the FAQ style section at the bottom. A map would have made a huge difference.
Timely 9/10 They lay out their timeline, which makes a big difference.
Actionable 10/10 They included the basics all the way to “what to do if you’re really mad”, and made it easy to figure out if you were involved.
Responsible 7/10 “We regret any inconvenience this security compromise may have caused our guests.” Ok, a bit too “corp speaky” for my taste, but for a big company this is as close as you’ll usually get.
Human 6/10 This is the rarest one to find so they can’t really be blamed.
Total 41/50 Ok, it’s a B-, but compare it to other incident responses and this one shines.

Room For Improvement: Target

I hate to beat a dead horse, I really do, but Target’s breach response was a clear example of how not to do things.

First of all, lets talk about the number of places you need to go to get Target’s take on the breach (all based on Googling site:target.com breach):

Now these results were in order (whatever that means based on Google’s personalization) from only Page 1 of my search.

Characteristic Score Reasoning
Clear 4/10 Ok… I can tell for sure they were breached. But which of the 6 seemingly relevant articles should I look at first. Brian Kreb’s articles were far more straight forward.
Timely 4/10 Target took the “Communicate early, communicate often” approach. This can work if you’re right in your triage. They weren’t. Numbers ballooned and they looked unaware and ill informed.
Actionable 4/10 So it was clear they got breached but they don’t spell out what that meant for consumers. Thankfully it was big enough news banks addressed the problem themselves and reissued cards.
Responsible 7/10 “Our top priority is taking care of you and helping you feel confident about shopping at Target, and it is our responsibility to protect your information when you shop with us. We didn’t live up to that responsibility, and I am truly sorry.” Depends where you look, but this item, from Target’s CEO Gregg Steinhafel is contrite and responsible.
Human 5/10 Depends where you look. There are great examples of Gregg Steinhafel being very human and putting a face on this, there are also plenty of very HR/Legal team statements. It’s hit or miss.
Total 24/50 Far from ideal, but tough to judge given how many places there were to look. Certain bits could have scored very high, but there were too many places to go for information.

Low score aside it’s clear Target did everything in their power to appease a very wide audience. Customers, share holders, regulators, the list goes on and on (PF Chang’s, it should be noted, is privately held, so they have a significantly less complicated audience). It would have been a massive effort to put everything necessary to all audiences on one page.

In the End

Every incident is different and requires its own communication plan. There are always complications, be they legal, regulatory, industry, or self imposed. Whats key is to focus on clarity, timeliness, actionability, taking responsibility, and ultimately showing victims that there is a human on the other side of the keyboard who understands the situation and is on their side.

If you want to see a really well done response that hits on all 6 characteristics I recommend reading basically any After Action Report/Crisis Communication by Digital Ocean’s Mark Imbriaco. The man could should write a book on this subject.

How to Write a good post mortem

See this Mark Imbriaco post mortem example.

Thanks to Rachel Vandernick of WebpageFX for her feedback as a crisis communications & PR professional.