Section 1: Background and Forecasting
Understanding your Organization
Before devising an effective IR plan, it is imperative to gain a clear understanding of your organization and its various facets. Specifically, we need to map out the scope of your IR plan and a number of required components.
First, you need to know how many locations you have that will be included in the IR Plan and where they’re situated. You also need to detail the types of functions carried out at each location, for example, headquarters, satellite offices, operations, manufacturing, IT infrastructure, or customer service. This includes consideration of any acquired companies and making sure to understand whether they operate with different administration, IT infrastructure, legal rules (including requirements, obligations and systems) or HR practices. Within each location, you need to have a handle on the number of employees and the nature of their role, for example, whether they are full-time employees, remote workers, independent contractors, or consultants or union workers.
Other key organizational information required includes financial information, such as annual revenue. You should also note external factors such as competitor relationships and media presence. In particular, is there any notoriety among executives or does the company receive a lot of media attention?
What is Your Worst Case Scenario?
Understanding the worst case scenario is a vital component in mapping out an IR plan. The ideal way to do this is to begin by asking personnel from each department what IT systems they rely on to do their jobs.
If a particular system is unavailable, would it bring mission-critical work to a halt?
Note that standard systems such as email platforms should be considered here as potentially mission critical.
Then you need to ask which of those systems—if it were inaccessible for hours, days, or weeks—would cause the biggest disruption to the company. What is the organization’s most important function? Your worst case scenario is probably tied to any mission critical systems that are needed for that function. Based on this, you can work backwards to determine how best to prevent damage to these systems and to minimize the impact if an interruption does occur.
Goals for the Plan
Goal-setting is crucial to any successful plan, and it’s no different for IR. Goals will be specific to each organization, but you’ll want to describe why you’re putting this plan in place and the outcomes you want it to achieve.
IR plans might be mandated by industry regulations or required to fulfill other goals of the organization. You should map out exactly what the IR plan is designed to do, for example, minimize harm to your organization, employees, customers, vendors and partners.
Scope of the Plan
The scope of the IR plan defines exactly what it covers. When we say incident or incident response, this could potentially refer to a host of different cyberattack scenarios as well as threats to hard copies of information. It’s important to be clear upfront about what you're protecting against.
Note that within most organizations, not all data is digitized, so the scope could cover tangible assets, for example, printouts of employee data, log books and customer records. In this sense, you can think of your IR plan as a response to information security incidents in general, not just cybersecurity incidents.
Information Security Standard
With the scope of incidents defined, the next step is to map out the foundation of your incident response plan, based on long-standing information security principles. The ideal way to do this is to align the plan with an information security industry standard. This way, if you are involved in a breach and are being investigated, you can show that you intended your IR plan to be constructed as per a reputable set of recommendations.
Choosing a suitable standard to follow can be difficult as countries and states don’t typically prescribe a premier option or an option that is. However, most of the different information security industry standards generally contain similar information and don’t contradict each other. They simply differ in terms of organization and flow.
That said, California does treat the The Center for Internet Security (CIS) Top 18 Critical Security Controls as a good guide for reasonable information security practices. This is a highly viable option, particularly if your organization conducts a lot of business in California or serves a large number of California-based customers. Other solid options include NIST publications such as the NIST Cybersecurity Framework, the NIST SP 800-53, and the NIST incident response framework.
Geographic Scope
The geographic scope of your plan can have a significant impact on the details of the type of response required. For example, are you only located in the US or do you conduct business in multiple countries? Perhaps you have an affiliate in the EU? Will all operations be covered under the same IR plan or will some be separate? You can refer back to the work you did to understand all of the entities and offices in your organization and to define which are covered by the IR Plan.
Whatever the organizational structure, the IR Plan’s geographic scope needs to spell out exactly which locations the IR plan covers. This provides the foundation for the legal analysis that goes into putting the plan together.
If there are separate plans within the organization, there may be some integration required to prepare for certain scenarios. For example, if you have disaster recovery or crisis management plans, they should be noted in your IR Plan, particularly if there is crossover and connections between the various schemes and the IR plan. If you're in critical infrastructure, you likely have national security emergency plans and you may want to address any integration between the two.
Attacks Common In Your Industry
When preparing your IR plan, you need to consider which types of attacks are common in your industry. This is key to help determine the plan’s action items and to train and inform management on the plan’s purpose. For example, your list could include items such as ransomware, information theft or cyber espionage.
This list should be concise and well-researched. Bear in mind that the threat landscape changes over time, so you’ll need to review the list to make sure it’s up to date. A reliable way to do this is to check in with forensic experts to find out the latest information about threats in your industry.
Categories of Information in the Plan
To round out this stage of developing the IR plan, you need to map out which categories of information will be covered or that should be considered in any of the incidents covered by the plan.
The traditional approach involves identifying each type of data separately, for example, personal information, market-moving information, and confidential information. However, we recommend you separate the categories of data into two core groups: nonsensitive information and sensitive information. This is helpful because most people in your organization won't be expected to know how to determine whether or not a piece of information falls into one of any number of legal categories (each with differing statutory obligations). For training purposes, it’s far more valuable to teach incident responders in your organization exactly when to alert the legal department or IR team lead.
Non-sensitive information is public or non-confidential information held by your company, for example, an employee directory. You wouldn’t necessarily want it to be exposed, but an incident involving this information would not cause a serious problem.
Sensitive information is any information you either need to protect from exposure or from being inaccessible. The simplest way to define this type of information is to use a statutory definition, for example, for personal information, you might use the definition from the California Consumer Privacy Act (CCPA) or the General Data Protection Regulation (GDPR).
Note that there is other sensitive information, aside from personal information, that needs to be protected in cyberattacks. While personal information leaks can lead to litigation and regulatory response, other information, such as pricing, investment information or customer lists need to be closely guarded too. Confidential company information might not be defined by statute, but nonetheless should be included in your IR Plan.
Section 2: Data Inventory
Let's move on to the next section of your plan—data inventory. In this section, we define and note the types of data that are held within your company.
We reviewed this briefly in the first section, but in this exercise, we define each in detail to understand what types of data could be compromised in the event of a security incident.
In your planning, identify and note the following:
- Your organization’s Confidential information
- Third parties’ Confidential Information
- Intellectual property (especially trade secrets)
- MNPI (Material Nonpublic Information)
- PCI (Payment card information)
- Personal Data
- PHI (Protected Health Information)
- PI (Personal information)
- Consumer Credit information
- Nonpublic (financial) information (NPI)
- Information subject to banking regulations
One of the additional key elements of an effective IR plan is ensuring that you include almost all departments in creating and executing the plan, not just IT, IS and the legal department. This includes the data inventory review.
For example, Human Resources (HR) plays a critical role in data review. HR can help explain the systems used to store employee information, third parties who hold or access benefits data, which employees have access to salary data, as well as how permission is granted to access these types of data, the process for managing user accounts and granting access to critical data. In terms of your own employee data, HR will know what types of employe data is stored (i.e., driver’s license number, payroll information, dependants’ information, health insurance numbers, etc.), how current and former employee information is stored and most importantly, any recent contentious departures or volatile employees.
Creating a data inventory is a critical step in the IR planning process and one that if in good standing, will save your organization time and resources in the event of data breach.
Section 3: Defining the Incident Response Process
Defining the incident response process is the practice of brainstorming and establishing the required steps and allocation of tasks for how to respond when a cyber incident occurs. Moreover, taking the time to really work through and strategize this effort is important to ensure all key stakeholders in an organization understand the roles and responsibilities of the IR team.
Definitions
To some extent, the earlier sections of your plan covered some of the definitions required to build an IR plan, but this section is designed to lay out all pertinent definitions required to understand the function and scope of the overall plan. So much of the terminology used in IR, cybersecurity, technology and organizational work mean different things to different people or companies. It’s important to include these definitions so that everyone in your organization is on the same page when they use a term.
In this section, you will define groups in your organization or executives with particular tasks that will play a pivotal role in the IR plan execution. Additionally, you’ll need to define any third-party relationships or support, such as an outside counsel. Taking the time to define all the roles and a high-level description of their responsibilities is a key component to IR preparation. The larger your organization, the more complex its organizational structure may be, and the more important this section becomes.
You’ll also take time to define how your organization wants to refer to the response team. Popular options include incident response team (IRT), security incident response team (SIRT), or cybersecurity incident response team (CIRT or CSIRT). You will also decide what to call the lead, for example IR Team ead or IR Commander.
The last key area of focus is to establish who needs to be involved in incident response planning and the response effort once an incident occurs. You will almost certainly involve more departments in the planning process than will participate in an IR. For example, you may include relevant departments in the planning process, but at the outset of a physical security incident, determine that finance and HR do not need to be involved. Outlining examples of IR Team pool members that would be required in possible incident response scenarios can help ensure you are prepared to manage zero day attack incidents effectively.
IR Team
The IR Plan will identify many people who may be involved in IR at an organization. Instead of including specific people’s names, the IR Plan should specify roles. For our purposes, a role is the title of a position at the organization (e.g., Director of IT, Human Resources Associate - Recruiting). A person may leave a particular role, but the role itself remains part of the IR Team Pool even though the person may not. Using names in the IR Plan requires more maintenance on an ongoing basis to keep current.
- (Cybersecurity) Incident Response Team - This group of individuals is tasked with participating in an IR effort following a specific incident. IR Teams are incident-specific and not necessarily the same from one incident to the next. The incident response team is responsible for responding to certain cybersecurity incidents such as cyber attacks, data breaches, lost or stolen information, ransomware and system failures.
- IR Team Lead - In the IR Plan, a default role for team lead should be identified. The team lead heads the IR team and is the main point person in the aftermath of a cyber incident. Once notified of an incident, the team lead identifies appropriate roles from the IR team pool and convenes an IR team with the individuals in those roles. The IR team lead oversees the response effort, ensuring protocol is followed according to agreed-upon procedures outlined in the IR Plan.
- IR Team Pool - The IR Team Pool comprises roles who the team lead may need to call into action in response to a specific incident. The IR Team Pool will include roles from multiple departments outside IT, IS and the legal department, including those unrelated to IT.
Cybersecurity Incident Response Team Commissioning
The IR Team is responsible for responding to incidents as per the outlined IR plan. The plan includes details of the types of incidents that the IR team will respond to and how roles or individuals will be selected and appointed to a particular IR response effort.
IR Team Lead
The most important assignment is the default IR Team Lead. If you have a CISO, they may be the natural choice. Some organizations with large security departments might assign someone other than the CISO to the IR lead position. The head of IT or a senior manager in IT is another popular choice in certain organizations. In rare cases, the IR Team Lead might be someone in the legal department. If you’re having difficulty deciding on the right person, you might look at who, if anyone, has been the default lead in past information security incidents and the effectiveness of previous response efforts. In some companies no one wants to be the default lead and in others multiple roles see themselves as the best fit.
The plan should also specify whether or not the IR Team Lead can delegate this responsibility if necessary, for example, in the case of an IR Team Lead’s absence or lack of availability due to other priority projects, or multiple critical (unrelated) incidents needing attention simultaneously. If your IRP applies to other regions, affiliates or subsidiaries, you need to specify if they will have a different default IR Team Lead on certain incidents. If there are multiple leads, who will be the lead in case of an organization-wide incident? When must the team leads contact each other to alert them or enlist help? What about incidents that only carry legal reporting obligations in one region?
IR Team Pool
The IR Team Pool should include roles from relevant departments, a complete list of which is not necessarily intuitive.
Depending on the structure of your organization, the IR Team Pool should include:
- Information Security
- Legal
- Other IT
- HR
- Finance
- Compliance/Risk Management
- Physical Security
- Communications/PR
- Investor Relations
- Business Units
- Same departments in other countries, if applicable
Additionally, external parties that may be involved include:
- Outside counsel
- Forensics firms
- PR/Communications
- Outside IT services providers
Adjacent vendors relevant to the IR plan include:
- Cyber Insurance brokers / carriers
- External auditors
Forming the IR Team
Once the default IR team lead is identified you then need to outline the protocol for the team lead to follow to form a team that can respond appropriately to an incident. The IR team lead needs to understand and brief the team on facts that are currently known about the incident as well as important unknowns. Then based on these facts, the Team Lead needs to make a decision about which roles from the IR team pool they believe should be involved in this particular incident.
Aside from internal personnel, the IR team lead must work with other team members to identify any external assistance needed. The IR team lead should consult with the legal department to decide if outside counsel is required. The IT/IS pool members can help decide whether outside help is needed from an external forensic team. Executives or a PR/Communications pool member can help decide whether a PR communications firm should be brought in as well. And the Team Lead should make sure appropriate people in the organization determine whether any external parties need to be notified, such as the organization’s cyber insurance broker carrier? Note that everything involved in the incident response process itself can change every minute, every hour, every day. As such, the IR team lead may invite and dismiss members of the team as needed depending on how the incident unfolds.
Ideally, the IR team lead will call required personnel by phone and hold an in-person meeting. Before using email to communicate, IR team leads should consider whether adversaries or threat actors have access to the email system, which may be detrimental. For example, if email is infiltrated, and an email regarding an IR team meeting is viewed by attackers, they'll be aware that the incident is far from resolved and may (and do) decide to execute additional attacks.
Initial Team Meeting
The IR Plan should specify that at the beginning of the first meeting, the IR team lead should have the inside or outside counsel brief the team on any privilege protocols for meetings, work, reports, discussions, phone calls and emails. This is an important piece if the investigation is being conducted under privilege in support of counsel’s being able to provide competent legal advice to the client. This includes briefing any third-party vendors engaged to assist.
The IR Plan should outline that the next part of the meeting involves briefing the team on the currently known facts of the incident. Next, the plan should instruct the team to come up with lists of questions from team members. What do they each need to know to do their jobs? What tasks need to happen in order to get those answers?
The next step is one of the most important parts of establishing a stable foundation for making decisions during the IR effort going forward. After the team has a list of information needed for each role and compiled a collective list of the tasks required to get answers, it is essential that the plan direct the team to take the time to assign a name (Note: Assign a specific individual by name to each task in an actual IR, not just a role). This is an important step because it helps the whole team have a clear picture of the large number of tasks to be completed and - often - whether too many tasks are assigned to one person. It also helps everyone in the room realize they have to collectively make priorities regarding required actions and either agreeing to defer tasks or decide on alternative personnel who could assist.
Triage
The next section of your incident response plan is triage. One component of triage is naming incident levels approportely. While there is no significant difference to naming levels, it’s important that they are easy to understand within the organization. One simple example is level 1, 2, and 3,. Or you could replace level with tier, triage, severity or another applicable word.
It’s a good idea to look elsewhere in your organization and not use words that already have another meaning. For example, if you've got a large help desk and they use the terms level 1, 2, and 3 support, then avoid using a similar system for incident response as it will prompt confusion. Also bear in mind that the numbers should make sense within the organization, for example, is level 1 the most or least severe?
Once you've chosen a naming system, you need to come up with a list of criteria and thresholds. These might include things like potential or likely financial losses or whether or not executive emails may be sent. Compiling the criteria list typically requires input from everyone in the IR pool and is developed over time. Each stakeholder needs to think about what’s important to their role and the organization as a whole, deciding what they are comfortable with versus what constitutes sounding alarm bells or even a ‘bet the company’ incident.
Setting criteria and thresholds helps define when the IR team will be involved. Incidents that don’t meet the criteria could be handled within the relevant department or passed to the IT department. If a defined threshold is crossed, the IR team is formed and the IR process begins.
It should be clearly noted in the plan in plain language that the triage formula serves as a guideline only. One of the most important factors in the event of an incident is the gut reaction of the incident response team lead, or whoever else is qualified to decide if the severity of the situation warrants the formation of the IR team. Based on their knowledge and experience and sense of the available information at the time, they will determine the level of severity of the incident, and the plan should include language to this effect.
Aside from helping deal with situations correctly, having this stated in the IR plan can make it clear to regulators or anyone else scrutinizing the plan that the correct course of action is not set in stone, but rather an educated decision. It also facilitates discussion among the IR team. Criteria and thresholds can vary greatly depending on the culture of an organization. For example, in some organizations, the CTO wants to know the minute something happens, so the thresholds for informing the CTO are low. It’s ideal to have these conversations early on so that it’s easier to make decisions when an incident does occur.
Privilege
We mentioned privilege above, and if applicable, information about privilege should be included in this section of the IR plan. The inclusion and scope of these details will depend on the legal counsel and their preference, but will usually outline the types of information various IR team pool members may have access to.
Incident Response Process
The next step is laying out the incident response plan in terms of the process to be followed including prompts for actions that must be taken. In general, you can follow industry standards for broad categories and the overall order of events.
Then comes the process of filling out the specifics. For example, you should note points at which specific people must be contacted. Or place reminders for certain actions, for example, checking if EU personal data is exposed every five minutes so you can start a clock for a potential reporting obligation timeline.
Lessons Learned
The last item in this section is the post-mortem or lessons learned. This is the easiest part of the incident response plan to write, but it’s the most frequently discarded piece of the puzzle. And it's important.
This is where you'll include a list of questions that stakeholders can go through after an incident response. Once things have settled, they can analyze their response, identifying what went well, what didn't go well, and what changes should be made.
This is also where you ask questions about new knowledge of topics such as the risks the organization faces, how the budget should be allocated, whether the IR team should be built differently, and whether changes should be made to public messaging.
If your organization is looking to create a robust incident response plan or have an incident response plan reviewed, updated or challenged with a tabletop exercise, ZeroDay Law can help. Learn more about our services and contact us with any questions.