As you work to resolve a security issue, technical knowledge is necessary—and a team with a broad base of expertise is invaluable.
In the past year, several people have asked me some version of the question: “What should we do when there’s a cyberattack or security issue?” My first instinct is to suggest technical actions, such as “review your log files,” “disconnect devices from the network” or “rely on your backups.” I also want to ask for more details: “What sort of a problem? Ransomware? Pwned passwords? A corrupted website? Databases accessed? Files inappropriately shared? A DNS issue?” The technologist in me wants to troubleshoot the problem.
SEE: Security incident response policy (TechRepublic Premium)
But technical troubleshooting solves only a small slice of a security problem. Customer concerns, potential legal implications and public opinion also may affect how your organization recovers in the long term after an incident. So, instead of a technology-only focused response, I recommend that organizational leaders make sure to address all five of the following items as part of incident response planning efforts.
1. Identify your team
Ideally, you will identify the key members of your response team long before they need to meet. Depending on the nature of your organization, this team could include people with expertise in the following areas:
- Technology (IT and security expertise),
- Legal (attorney or law enforcement),
- Operations (employees),
- Decision-making roles (executives and possibly board members), and
- Communications (media/staff/customer communication) experts.
In some organizations, such as a bank or data center, you might need people with physical security expertise, as well.
Keep the number of people involved to as few as possible. Regardless of the size of your organization, make sure that people with expertise in each of the five areas identified above are on your team.
2. Maintain an admin access list
To shorten the time needed to gain access, make sure to maintain an accurate and up-to-date list of the people with admin access to critical systems. These systems include identity and access management systems, communication systems (e.g., Microsoft 365, Google Workspace, phone systems, etc.), databases (e.g., human resources, customer/client databases), financial systems (e.g., payroll, expenses, accounting, etc.), website and social media (e.g., Facebook, Twitter, etc.), as well as core network components (e.g., servers, routers, firewalls, etc.). Unfortunately, I’ve too often watched inexperienced response teams struggle to gain admin access.
3. Choose communication channels
Since normal communication methods may not function in an emergency, identify a prioritized sequence of ways the response team might communicate. For example, the list might include your organization’s standard email, chat and video conferencing tools (e.g., Gmail, Google Chat and Meet), along with alternative email addresses, phone numbers (e.g., mobile numbers), phone conferencing or chat services (e.g., Signal, Element). If most communication alternatives aren’t available, a team might agree to meet in person at a particular place and time.
SEE: 3 emergency communication solutions to implement now (TechRepublic)
4. Discuss convening conditions
As a team, discuss the threshold of a problem that merits convening the response team. While some issues may be serious, such as a website outage, they may not merit activation of the incident response team. In general, I tend to encourage organizations to allow any member of the response team to convene the group. Presumably, the people on the team are experienced, smart people with good judgment who won’t call a meeting unless circumstances merit it. (And, if not, you should probably rethink the composition of your team.) Typically, all that would be needed to convene the group would be a message to the group via a defined channel.
5. Communicate while you work the problem
As the team works to resolve an issue, maintain communication among the group members and with appropriate other parties. Those other parties might be employees, customers, board members, members of the media or the public at-large. As a group, always specify the next time the group will convene before you end a meeting. Similarly, when communicating about an issue externally, identify the next time you will provide an update.
How has your organization prepared?
Has your organization identified a security incident response team? What methods do you use to maintain your current admin access list? What communication channels have you selected or used? Are there additional steps you recommend organizations take to prepare to deal with potential security issues? Let me know your thoughts, either in the comments below or on Twitter (@awolber).