Survey the landscape of your service
“He who defends everything defends nothing.” - Frederick the Great
In this play, you will assemble key information about the landscape of your product or service, its security needs, and what is important to your organization so that you can make good decisions about procedures in later steps.
In many ways, this play is about understanding potential risks so that they can be prevented in the future. It is similar to understanding flood zones and historical weather data when buying or building a home. There may very well be risks or tradeoffs, but the goal of this play is to document and understand them so that you can start to make more informed decisions.
Start by observing and documenting the digital and physical aspects of your service or product.
Every meaningful incident response process must begin with building the team’s shared understanding of the details of the system, product, or application they’re supporting. That knowledge must also include what the biggest vulnerabilities are likely to be. If this process feels overwhelming, it might help to start by asking the engineers to make a simple diagram of how the system works.
Work with your team and organization to:
- Document your service, product, or system
- Define what would constitute an incident in this context
- Determine what types of incidents you are likely to encounter and what data might be sensitive or targeted by bad actors
- For example, availability incidents, security incidents, data leaks, etc.
Try to define expectations for the expected operation of your system. This often takes the form of a Service Level Agreement or some other documented policy. These policies help you know when system performance dips below expected levels and might trigger an availability incident or what expected behavior should look like to users.
Then, define what is important to your organization in terms of an incident response process.
A service that lets users browse product documentation will need a very different incident response policy than a service that lets users schedule physicians appointments. A small team or organization will have fewer resources available than a larger one but may also face fewer numbers of risks. So, rather than starting with someone else’s answers, define what is important to your organization, so that you can later find the best possible procedure for your situation.
Again, Ad Hoc recommends beginning with guiding principles. What is most important to your organization? Once you understand these principles, you can more easily prioritize and write procedures. In the case of incident response, a useful way to determine your organization’s values is in terms of risks and potential damages in the case of an incident. In the following example, notice how the questions about data and storage lead naturally to questions about risk.
- What type(s) of data does your application or team utilize?
- How/where is it stored?
- What risk does this data present?
- What data or information is most likely to be targeted by outside actors?
- What data would be most damaging if it was accidentally exposed?
- What kind of breaches or exposures would put you or your stakeholders at risk of having to testify before Congress?
Prioritizing the most vulnerable systems or data can help your team develop processes that achieve the highest value for the least effort.
Determine what incident response processes already exist, if any.
In many cases, your team may not be starting completely from scratch, so it might be helpful to take some time to understand what processes already exist.
- Do an audit of any existing incident response documentation, the outcomes of past incidents, or any relevant process documentation.
- Identify the biggest gaps in those processes based on what your team decided was the most valuable or important.
If you’re starting from scratch developing an incident response process, don’t try to do everything all at once. Identify what systems or data are most important to your team and prioritize from there.
Your team should consider running a threat modeling exercise where you try to anticipate what type of threats your system might attract.
Build a clear list of all relevant stakeholders and users.
A key part of understanding your system and preparing an incident response plan is documenting who might be impacted by incidents. This includes users who might rely on the functionality of the software to do things like make a doctor’s appointment or file an insurance claim. This list should also include stakeholders who are responsible for the successful operation of that software for users.
Making this list ahead of time will help in the later stages of developing an incident communication plan.
- Document key stakeholders and try to include contact information in your documentation.
- Consider checking with stakeholders during this process to verify their preferred method of communication during an incident.
- Document different users — both internal and external — who might be impacted during different types of incidents.
- Check to see if you already have this information documented by a UX designer or researcher.