Cybersanity in the Incident Response Age
Their unprecedented breach presents an opportunity to learn.
A Jolley | Hadaway Article.
The recent data breach at Equifax has shocked many of us, even the ones who have become desensitized to the “breach parade,” the regular stream of news regarding major organizations falling victim to poor security. It has been hard for us to keep true to our blog mission (that we are a trend blog, not a news site), especially given that several Clients have asked us “where we’ve been” on the Equifax breach. Indeed, we’ve even half-written articles only to be reminded of WHY we want to hold to that mission . . . the article became out-dated before we finished it. And we’ve received so many links from friends who, fascinated with the process, knew we’d be interested in reading the article. And while we just have to at least allude to the article found by our friend Joe Cychosz, about the auto-sue website, as the ultimate example of what Dan predicted in last year’s M-7 article (that lawyers were using incident response as a digital ambulance). We received so many articles that Dan was even thinking about opening a spreadsheet to analyze which of them would be worth writing about. But then we realized: slow down, all of them would be “article review worthy,” if they were not so newsworthy.
We’re information security people, not journalists.
Now, that’s not to say we haven’t reviewed articles touching on current events in the past, but in doing so we try to use those events to discuss broader trends in security and technology. Other organizations report developing stories better than we could, and you’ve probably got a few places you already go to for that kind of coverage.
Like most people in and out of our industry, we have been keeping up on the story as it has developed, and we think it presents an excellent opportunity to discuss security culture and incident response: two processes that, based on what has been reported, Equifax failed to establish.
It can be hard to “see inside” an organization as large as Equifax, but based on the timeline of events, it can be inferred that security was not a subject that was taken as seriously as required. We imagine heads popping in and out of the sand. Corporate Joes protecting their own position on their climb up the corporate ladder. The priority being on CYA rather than CIA. The priority being on reputation, not protection.
From the delays in applying security patches, to how the initial disclosure was handled, it was clear Equifax was an organization that was unprepared.
That’s why an incident response program is something we consider to be so important: it offers the one process you can test to see an organization’s security posture. Thinking in terms of layered security, imagine designing a test that would cover user awareness, asset management, access management, business continuity, technical security standards, risk management, cyber insurance, management awareness, vendor management, AND incident response . . . . and that’s the incident response test.
But most importantly, we found that testing an incident response program also helps us both test and further establish the technology risk management culture we have discovered will help organizations . . . large and small . . . avoid being the next Equifax.
The reason for this is simple. When we properly test an incident response program, we are able to get the management team on the same page regarding the priorities of an incident response. We’re able to, through doing, help the management team understand how protecting information IS protecting our reputation.
In the picture to the right, we see an excerpt from our boilerplate for an Incident Response Plan in a small bank. You may recognize the language from this excerpt . . . it’s the priorities in an incident response. Your plan could very well use the same language. We all use the same list of priorities, taken from the original NIST publication from 1998. In case you’re struggling with the graphic, let me rephrase the priorities right here:
- Protect Human Life and Safety.
- Protect Customer Information.
- Protect Reputation.
- Prevent Further Damage
- Minimize Disruption.
We all surely would have loved to be a fly on the wall in the board meetings when the Equifax breach was escalated, assuming they even referred to it as escalation. We’re also sure there are many professionals, like those of us at infotex, who would have loved being a fly on the wall during one of Equifax’s incident response tests…that is, if they actually took place. If they did do incident response tests, and if they did actually get their management team to those tests, I am willing to bet that Equifax allowed interruptions, that their management team spent the duration of the test looking at little screens.
And if they did do walk-through of the plan, I am willing to bet they skipped those boring priorities in the plan. Perhaps publicly held companies should add a 2.5 . . . sell no stock . . . just to get the attention of management during plan walk-throughs.
It’s a decision we all will get to help our management team make, because it’s a matter of when, not if. But Equifax may help us help our management team understand that when an organic process focused on ensuring the protection of our customers is the top priority in an incident, our reputation is maintained. In other words, the second priority ensures the third priority. This is because your customers test of your posture is not proactive . . . it’s reactive . . . it’s when (and not if) they see you respond to your own Equifax. You can use the Equifax breach to help your management team understand that your reputation will be based on your next incident, not the 100 years leading up to it.
While we don’t know about any of the tests Equifax may or may not have performed, we’d like to take this opportunity to invite you to our next webinar, where we will walk you through our boilerplate Incident Log, using the Equifax breach as the scenario! We’ll walk you through the timeline of events in an effort to show you how we would have filled out our Incident Log (and hopefully the log will show us how Equifax could have avoided key mistakes made during their response.)
The webinar will be held on November 21, at 10am. Please note, we do not think we will be publishing this webinar as a movie.
To register for the webinar, click here.
Original article by Dan Hadaway and Matt Jolley