No two incident response plans are alike. What your plan looks like will depend on many variables, from the size of the company, the scope of business, regulatory needs, to the company culture.
You might be surprised to hear that culture plays a role in incident response, but it does. An active, engaged, and educated user community in both privacy and cybersecurity is an important asset in detection, communications, and remediation. A passive, disengaged, and generally privacy- and cyber-ignorant culture frequently contributes to the incident and may even hinder its remediation.
By now, I expect you have a solid understanding of your firm’s privacy and cybersecurity programs. By understanding your business-continuity and disaster-recovery plans, though, you will gain the necessary solid footing in framing your incident response plan.
Similarly, the absence of either of these two plans speaks volumes about the company’s priorities and risk-management capabilities. It is your job to confront this reality head-on, starting with engaging the executive team, whose active support is a requirement in all privacy and cybersecurity program development efforts and is critical in developing IR capabilities.
In-house or Outsourced?
Remember the hospital-building analogy in my previous post? Think of incident response as the surgical center. Question number one, therefore, is: Do you need a surgical center, or are you shipping your patients to a different facility altogether? In other words: Do you need, can you afford, and will you keep an in-house incident response team engaged? Or do you need to enter into an agreement with an outside incident response services provider?
For the majority of small to mid-sized businesses, the answer will be to outsource the IR function (at a minimum). The current lingo describing these providers is managed detection and response vendor, usually shortened to MDR vendor. If this were a hospital, that would mean you keep the internists (or at least the nurses) in-house but outsource the surgeons. It is highly unlikely that a small business will be able to both afford and to keep engaged a team of highly skilled and specialized privacy and cybersecurity incident response people. But that doesn’t get you off the hook from designing your incident response plan appropriately!
Remember, you can outsource responsibility, but you cannot outsource accountability. You still need to work with the service provider in designing and owning the plan. For your cybersecurity program development effort to succeed, you must always maintain accountability and full ownership. You are the one responsible for being knowledgeable enough and engaged enough to be able to successfully complete a cybersecurity handshake with your vendors. And you’re the one whose head is on the block should the company be found ill prepared.
Businesses that use an in-house team for incident response need to also recognize that they must provide a complete governance ecosystem for that team to succeed. An in-house IR team should report directly to the chief information security officer (CISO) and should have unfettered access to the privacy and risk management teams, as well as the information technology, human resources, legal, and communications departments. The minimum size of an IR team will always be two: an IR manager and an IR engineer. One interfaces with the organization and directs the incident response, while the other is deep in the weeds doing forensic and remediation work. The larger the organization, the larger the IR team, and the more specialized and complex its structure.
Organization
Irrespective of the size and scope of the company, be it in-house or outsourced, your IR plan will need to address several key components, starting with a detailed description of your policies, standards, procedures, and guidelines as they relate to cyber incidents. These, thankfully, will be derived to a considerable extent from your privacy and cybersecurity programs, the business continuity and disaster recovery plans, and with the added input of at least risk management, legal, and communications. These policies will introduce organizational structure and will essentially define the who-does-what-when part of the IR workflow.
With regards to the organizational structure, you’ll need to adopt the one that best reflects the organization’s needs. If you are decentralized, you may need decentralized IR teams. If not, perhaps a single centralized team is best. Depending on size and scope, you may decide to introduce a blended approach, where some IR capabilities are in-house, while the rest are outsourced. This works well when there is a large, headquarters-type of facility with smaller satellite offices scattered around the planet. In this case, you’re probably better off having a centralized IR team at headquarters, with several vetted and contracted IR vendors at the remote locations. All involved get a copy of the plan, ideally saved in a big red binder with “Don’t Panic” written all over it.
Communications
In addition to a clear organizational structure, a strong IR plan will also have clearly defined communications protocols. Think of this as the who-says-what-to-whom-when part of the plan. This is key. For one, you don’t want to instigate a panic among users by screaming through the speakerphones, “Incident Alert! Incident Alert!” And you certainly don’t want to broadcast to the bad guys that you have detected an incident. So avoid emails and non-secure messaging platforms, all of which may have been compromised. In fact, consider that even unsecured telephone lines may also have been compromised. To the degree possible, stick with personal, one-on-one, secure communications on a need-to-know basis.
Needless to say, this is not the time to get social! This is the time to carefully assess your situation: what exactly is happening; what is its potential impact on privacy, the business, clients, and vendors; and, of course, is there a need to notify law enforcement and regulators. The last thing you want to happen is to have someone from the press calling you with, “I got a tweet about you folks having been breached and three million PII records have been compromised…Can you comment on that?” That’s definitely not a good place to find yourself!
The “whom” in the “who-says-what-to-whom-when” workflow can be long, complex, and dynamic. It will change regularly and likely involve several third parties, such as your own insurance company, business vendors, cloud solutions providers, and your Internet services providers, as well as a slew of IT vendors and their own IR teams. You may be required to notify law enforcement—my go-to is always the FBI and the local district attorney’s office. If you happen to be a multinational, then the contact list becomes substantially longer, since you may need to comply with local regulations on incident reporting on a country-by-country basis. On top of all these, you should consider sharing the information that you have with the US Computer Emergency Readiness Team (US-CERT) and other industry-specific IR organizations.
The fun part of notifications, of course, is letting your clients know about the breach. To be clear: There is no avoiding this, and the experience will not get better with time. The last thing you want is to have your clients learn about the situation from the news media. You need to be prepared and well rehearsed. Privacy, legal, insurance, and communications departments must all be in complete alignment on (at a minimum) what happened, who did it, why it happened, what you are doing in response, and how you’re making sure it will not happen again. You may not know all the facts (such as who’s behind the incident), but you need to be as proactive in your communications as due care and prudence will allow. Nothing destroys trust in a company faster than a poorly communicated privacy cyber incident. Get in front of it as soon as is practical—engage the news media and be as forthcoming as possible.
Integration and Updates
The next step in your IR plan creation is to integrate the wonderful results of your work to date in threat analysis, environments, and defense in depth and control deployments. The plan needs to reference all these, with specific clarity on where your threat intelligence is coming from and how you can leverage that in case of an incident, your environments at risk (clouds, Internet-connected devices, and your distributed workforce), and your defense in depth and controls deployment. These will be critical in both the detection of an incident and the response to it.
Remember, all these entries in your plan need to be kept current. If you learned anything from our earlier discussion of threats, it’s that the threat landscape is highly dynamic. For your plan to be useful, it needs to reflect the appropriate level of changes over time. What does this mean for you? Get comfortable with two words: change management.
Tools and Personnel
To complete your incident response plan, you will need two more entries. First, you will need to identify your incident response toolkit. This is a set of mostly software tools (there are some hardware tools as well), that are specifically built for forensic and incident response work. Please note: These are surgical instruments, and they need to be handled by experts.
Moreover, the toolkit, like all else, evolves over time; in fact, toolkits are the fastest-evolving component of your response, because software is constantly updated. It is therefore critical that the plan reflect the most up-to-date toolkit in use, its locations (yes, there needs to be more than one), and any access credentials necessary. You do not want to be scrambling for USB keys in the middle of an attack. You need to know where your toolkit is, what is in it, and who are the right people to use it.
I can’t emphasize enough the importance of the right people. Forensic and incident response work is very complicated and requires highly skilled specialists. Even the best-intentioned and expert IT professional can wreak havoc if she attempts to use forensic tools without specialized training and experience. There are any number of case studies where IR professionals walked into a site under attack only to find the well-meaning IT team having turned off the servers and already restoring systems from backup. This common mistake destroys the evidence, leaving you with no way to know who attacked and why, no way to learn how to prevent it in the future, and so on.
Training
The last component of your incident response plan is the training. And by that I don’t mean the company-wide cybersecurity awareness training. Here I mean war games. Full, all-out incident response exercises, conducted frequently and analyzed exhaustively. Just like the old joke about how you get to Carnegie Hall, the only way to get to be good at incident response is practice, practice, practice. The higher your dependence on your IR team, the more rigorous your practice exercises must be—think Red Teams and Blue Teams; the works! The exercises need to be comprehensive across all your environments, including your executive team, staff, and all key vendors. Some should be well planned, rehearsed, and announced, while others should be out-of-the-blue surprise drills. Everyone, from executives on down, should be aware and sensitized to incident response. They all have a role to play.
Meanwhile, your IR team must remain constantly vigilant. I know that may sound harsh or over the top. But, that’s the job. It’s what they do. Constant training and practice are the only things that will make the final difference during a real attack.
Now, get to it!
0 Comments