How To Survive Breach Failure (Part 2 of 3)
December 12, 2014
Before an incident occurs, it is important for organizations to have a comprehensive incident response (IR) plan in place. In the chaos that arises during a breach, CISOs and security leaders need to avoid the natural tendency to drift from the established process, and make decisions that align with the formal IR plan.
Outlined below are several mistakes organizations can make when reacting to a breach.
Failures During the Incident
Making emotionally-driven decisions
“Reset everyone’s password!” If this isn’t an announcement you’ve been breached, I don’t know what is. Yet we continue to see this decision being made time and time again. Resetting passwords is essentially a self-inflicted DoS with the potential of crippling operations (or the revenue stream if you reset customer passwords) in a naïve attempt to lock out an intruder. If you’re really lucky, you may even get a double-whammy and overwhelm your Help Desk while tarnishing the reputation of your organization (or you personally) while having minimal-to-no effect on the adversary. In many cases the intruder has planned for this response tactic and has already established a means around it.
Organizations that have experienced few security breaches will likely allow emotions to drive decisions. Be prepared for frustration and blame to be directed your way. “How in the world did this happen?” “What am I paying you for?” “I just spent x dollars on y and we still got hacked?”
Whatever happens, it’s imperative that you remain calm and clear-headed, and appear confident when making recommendations to your leadership. Demonstrating emotional restraint and objective thinking will pay dividends in future incidents. However, trust is earned, not given. Over time you may find yourself transitioning from being a scapegoat to becoming a trusted advisor that leadership turns to for guidance during crisis situations. But be prepared for a long path to this nirvana, because the first big incident(s) your organization faces may turn you into a verbal and emotional punching bag. Whatever you do, don’t get rattled or take the attacks personally. At the end of the day, you’re all on the same team and leadership’s opinion of you will be shaped by how you respond to the abuse. Stay positive and look toward the future.
Using management authority to override recommendations made by those closest to the problem, or jumping the chain of command
In moments of panic, it’s not uncommon for authority figures to direct actions their gut tells them will solve the problem they’re presented with. It’s a tactical method they believe worked well with other challenges they faced, so how could a security incident be any different? The problem is this: such behavior demonstrates organizational acceptance of defying written guidance (i.e. “do as I say, not as I do”). It also devalues the expertise and professional recommendations provided by experienced analysts and middle-management that may be best suited to advise on technical response tactics. Once those individuals realize they are likely be overruled, expect them to delay (or avoid) reporting future incidents up the chain of command to gain more time to work on the problem. In any case, you may be called upon to temper leadership’s shotgun approach and will need to redirect them to the established process for managing security incidents. Softly remind all parties involved that the incident commander has authority established by policy, that all actions taken during the incident can be audited/investigated at a later time, and that refusal to follow established procedures undermines the effort/resources already invested in developing a formalized process. You may also need to counsel analysts who are on the front line and are frustrated by being steamrolled into decisions they know may have little effect on the incident at hand.
Failing to use confidential channels to discuss the incident
APTs often monitor unencrypted communication channels to get a leg-up on your response, so use secure messaging whenever possible. Consider having a backup email service with end-to-end encryption hosted outside your environment as a safety net ready for limited emergency use, but be aware of the legal implications of storing highly-sensitive operational data on third-party resources. Can it be subpoenaed? Is your organization contractually protected if the information is leaked?
Also, consider immediately changing your conference bridge passcodes and distributing them out-of-band prior to initiating response operations. Conference bridge passcodes are commonly stored in unencrypted locations that can be easily compromised and used to covertly listen in to incident management operations.
If all else fails, consider sticking with voice-only communications or text messaging via cell phone providers.
Whacking the mole rather than studying the adversary to seek-out root cause
This will vary based on the specific threat you’re faced with, as some non-targeted attacks originating from a specific source may actually go away after being knocked down. However, targeted attacks that are sophisticated and persistent in nature will likely be a moving target. “Block them at the firewall” may be a resource intensive cat-and-mouse game that’s only loosely/temporarily effective. Consider redirecting the attack into a honeypot or black hole with minimal access to study the adversary’s behavior. Your response strategy will be more effective if you have a better understanding of what they’re going after, especially if your manpower resources are being used as efficiently as possible.
After your organization has gone through a breach, you may think that the impact is over. But there are things to consider after the incident, which I will outline in the final blog post of this series.
**Disclaimer: The observations above are subjective to interpretation and are not the result of any specific scientific study.