Over the past decade we have helped countless organizations respond to security incidents around the world. There is a common theme each time, with exception to large enterprises with an established security team, most small businesses have no idea where to start.
The following article will help expand on some of the lessons we’ve learned over the years. It will help provide the practical recommendations that we have used to help guide companies through their most vulnerable period.
This guidance will be most valuable to organizations that fit this criteria, but there is a lot of value that micro-businesses can also take from this.
|Total Revenue||$1M – $20M|
|Total Employees||< 250|
|CISO / Security Leader||No|
The key to responding to an incident is having a basic foundation from which you’ll operate. For a small business that has never experienced a compromise before, you’ve likely never felt more vulnerable. A foundation will remove the emotion from the equation, and help you function rationally.
The minute you realize you have been compromised there are a series of questions you should immediately ask yourself, and your team:
|What is the scope of the compromise?||Understanding the scope of the compromise will help you figure out your response, and who needs to be involved. You won’t always know the answer up front, but it’s a question you’ll want to continuously ask.
Note that scope will change through the entire process. You might realize the scope was not as bad as you initial though, but it might also be a lot worse.
|Who is taking ownership?||If everyone is leading, then no one is leading.
You need to assign roles and responsibilities during any compromise. Who is the one making the decisions? Who do I go to for information?
One of the biggest mistakes executives make is assume they are in control, and they have the need to work directly with the operators. They MUST know what is happening every minute! This can’t be further from the truth, as a leader you are definitely a stakeholder but you’re not necessarily the operator in charge.
|What is the communication cadence and medium?||Identify how information will be communicated to all the stakeholders.
Will you use an asynchronous form of communication via a medium like Slack, Teams? Will you use email?
What will the communication frequency be? Will you do updates every 30 minutes? every 60 minutes? When must information be shared?
The minute you become aware of an incident, it should be all hands on deck for those teams that have the ability to make a difference. If your team can’t make a difference, then your responsibility is to get out of the way.
Clearly assigning ownership will help will ensure a seamless process and outcome. This person should function as the buffer between the stakeholders and operators. They will also be responsible for managing the various streams of work that must begin the minute a compromise is identified.
Here is an example of what different work streams might look like across different business functions:
The table is not designed be exhaustive, modify it to your specific needs. It is, however, meant to provide a foundation from which any organization can start regardless of industry.
Most of these jobs can be performed in parallel.
For example, communication itself can have a series of other streams and can be divided between internal and external communications. While the technical teams begin their investigative process you can have a separate team start preparing artifacts for best and worst case scenarios so that they are ready once the information is available.
One thing to be cognizant of are the various laws that exist across different jurisdictions with regards to data breaches and your responsibility to notify partners, and customers. It’s why understanding the scope of the compromise is critical.
In the United States, all 50 states have their own legislation that you have an obligation to confirm with. The best resource we have found to stay up to date with the changes is the National Conference of State Legislatures.
Additionally, organizations need to be considerate of their industry and their obligations under whatever regulatory body they have to conform too (e.g., PCI DSS, HIPAA, ISO 27001, FISMA, etc…).
It is impossible to fully capture the entire process required for incident handling in one article, let alone a series. Thankfully, guides have been written at length about this. One of our preferred sources is the guide provided by the National Institute of Standards and Technology (NIST) on Computer Security Incident Handling.
In it, it highlights four distinct phases as it pertains to incident response:
We like this illustration for its simplicity. It is something easy to understand, and something that can help group activities as you proceed through the process. It also highlights a very important part of security, the fact that it is a continuous process. It also highlights the importance of post-incident activity in which you learn from what has happened and improve your security program.
We can say without a doubt that in every incident we have handled over the past decade, there is always this feeling of dismay amongst the companies we work with. It doesn’t help that they always happen in the middle of the night or right as you’re going on holiday. You will find yourself frustrated with the mistakes you made, the actions you didn't take, or information you don’t have (secret: you will never have enough information).
Know that this is all normal, and expected behavior.
This article should provide your organization a basic foundation from which you can lead your team through whatever incident you’re facing.