When it comes to security incidents, it’s not a question of if, but when they will happen. 80% of organizations say that they have experienced some kind of cybersecurity incident in the last year. With this in mind, it’s essential to have a security incident response plan in place before you need one. At , Zendesk CISO stressed that having a plan enables organizations to handle security incidents both small and large more effectively. This article is adapted from the talk he gave, outlining the steps that teams can take to develop and refine an incident response plan. DevGuild: Enterprise Security Maarten Van Horenbeeck Assign Clear Roles and Responsibilities When you are a smaller organization, you're probably going to be quite stressed when an incident happens. If it's clear to you what it is that you're going to be doing next, then you're not going to be as stressed during the incident and you're going to have a better handle on things when you're reacting. Your first step is to make sure that you assign clear incident response team roles: a communicator, an investigator and a leader. The person leading the response should not be the person doing the technical investigation. They’ll get lost the logs and lose track of the fact that they just discovered something they have to escalate. Additionally, make sure you have someone focused on communication. It's very difficult when you learn something new every 10 minutes to make sure that you keep a good understanding of what's actually happening. It's the communication that gains you trust, whether it's from your CEO or your customers. Build Relationships Before You Actually Need Them The security community offers a wealth of support and knowledge. Build relationships before you actually need them. There's a couple of different forums that you can participate in. There's , there's also information sharing and analysis centers that focus on these types of things. I's relatively inexpensive for you to participate in these forums and learn from them. If you're not ready for that, go to a security conference and ask some of your peers about what it is that they do to prepare for an incident and how you can also help make that better. First.org You really want to know the right people to be able to partner with when something happens. So make sure that you know your peers, your competitors, and that you connect with their security teams and don't compete on security, but try to make the pie bigger for everyone by making sure that they trust SaaS services. As a result, they will trust you. Do Your (Legal) Homework Ahead of Time You're not going to have the ability to know everything from the legal side to the technical side of incident response, so again, make sure that you built these connections ahead of time and you look into what it is that you can potentially even contract ahead of time. There are retainer agreements you can sign with law firms and with forensic investigators, so they can come help you when an incident actually happens. Now, you might ask yourself the question, "Should I really be spending my money on this? The answer is it depends a bit on the size and you may not. But even then, it's worth starting the conversation so you at least know how much it's going to cost you when an incident actually happens. You'll know a little bit about the process, and maybe you can agree on terms for getting support before the incident happens so you don't end up locking yourself into agreements you disagree with. Understanding Your Reporting Obligations Understand who it is that you need to report to, as this has become more and more important with rules and regulations like GDPR. Quite often you're expected to report to a competent authority, which could be a national search, or could be a regulator. What rules are important? What are the things that you really want to learn ahead of time so that they don't catch you by surprise? You can do that yourself, but I would actually highly recommend that you talk to your attorneys. You usually will have an attorney that you work with on things unrelated to security incidents. Maybe have the conversation about what support you need when an incident strikes, so that you can really figure that out ahead of time, and also think about your culture. Security culture is one of the most critical things for a company because if you are very open with your customers and then you have an incident and you don't communicate, your customers may lose a lot of trust. So make sure you have that conversation with your legal support ahead of time, so they also know what it is that you will want to do in terms of your customer relationships when a security incident strikes. Create an Incident Communication Plan Communicate often and early, but always be correct and truthful. That can mean that if you don't know something for sure, you may actually want to tell your customers that you don't know it yet or that you're still investigating and that you don't have that information. But make sure that you're as truthful as you possibly can be, It’s important to have the right mechanisms to communicate to your customers --  you want to create a place where customers can continue to learn new things and get authoritative information from the source. Templatize Impact Statements You will be learning something new every hour, every day. It's very easy to get lost in what is happening there. There are a lot of details, and details may look very impactful and in the end they may not be. Have a couple of questions that you continuously ask yourself as you learn something new and you go to new things. Think about exactly what the impact on customers is. This new information that you just learned, did it tell you something that you didn't know yet? Did you learn something new about how access in this case was achieved? And does it actually impact customers? The best way to do this is by having one document with a couple of paragraphs at the top, and actually call it an "Impact statement." You continuously update it whenever you learn something new, so that everyone involved can continuously stay in the loop and know what the status is. Never Let a Good Incident Go to Waste Finally, you should never, ever let a good security incident go to waste. You will likely have a security incident of some magnitude at some point in time, and it's probably going to be more frequent than you want even though it might not be very frequent. But it's sometimes good to just look at the things that just didn't meet the threshold and treat them as a real incident, so you have an opportunity to go through the entire process and get everyone prepared. Document everything you do during an incident and study it afterwards with everyone involved.  Make sure they know that you're not trying to find blame -- you're just all trying to improve. Get them to share what worked for them and what didn't work for them, and then spend a little bit of time thinking about how you can put all of that in place. Then communicate your needs and share your learnings. The only way we're all going to make sure that we don't all have to make the same mistake again is by actually being transparent about what we did wrong so others can learn the different challenges that they are going to face. For more on creating an incident response plan, watch the recording of Maarten’s complete talk on . Disclosing Security Incidents from Routine to Breach

Routine

How to Create an Effective Incident Response Plan

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Coronavirus Resources for DevTools Startups

Windows Sticky Keys Exploit: The War Veteran That Never Dies

06/02/2018: Biggest Stories in the Cryptosphere

0-Days are on the Rise and that Means a Lot More Work for SOC Teams

Time Bombs Inside Software: 0-Day Log4Shell is Just the Tip of The Iceberg

The Noonification: How the Liver Transplant System Changed Forever (11/25/2023)

Coronavirus Resources for DevTools Startups

Windows Sticky Keys Exploit: The War Veteran That Never Dies

06/02/2018: Biggest Stories in the Cryptosphere

0-Days are on the Rise and that Means a Lot More Work for SOC Teams

Time Bombs Inside Software: 0-Day Log4Shell is Just the Tip of The Iceberg

The Noonification: How the Liver Transplant System Changed Forever (11/25/2023)

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps