Welcome to Cash in the Cyber Sheets. I'm your host, James Bowers, and together we'll work with business leaders and industry experts to dive into the misunderstood business of cybersecurity and compliance to learn how to start making money from being secure and compliant. Welcome to Cash in the Cyber Sheets.
Hey, everybody. Welcome back to Cash in the Cyber Sheets. I'm your host, James Bowers, Chief Security and Compliance Architect here at Input Output.
Very happy to have you back here with us today as we continue, as we are getting to the end of our FTC Safeguards Rule Checklist for Compliance series. We've been doing this as both podcast and as a whole blog series on the Input Output website. You can also follow right along on that.
There we go. That's a little bit more legible. Follow right along with the FTC Safeguards Rule Checklist.
It's available in the description of this blog, in the description of this podcast, and it's in the associated blog, which we'll also link in this podcast description. So definitely get the checklist, and you can go right down the list. That is exactly what we've been doing in this entire series, and we are second from the bottom now, where today we're going to dive into incident response management.
Now, before even getting into this, I just want to say incident response is a huge area. It is not something we are going to cover in the 10, 15 minutes that we're going to go through everything today, but we do have a lot of information on our other podcasts. We have a lot of information on our website, and it's definitely something we can get very deep into.
But what I want to do today is go over all of the basics, all of the high levels to make sure that you have that core structure in place for what you need to make sure that you're well protected in the organization and you're meeting those FTC safeguards requirements. There we go. That's the word.
So before getting in, please click that subscribe, click that like, wherever you're listening to us, Apple, Spotify, YouTube, definitely let us know what you like, what you'd like to hear more about, and give us some ideas for some areas that you're having some trouble with, and I'd be more than happy to cover it. So with that said, let's jump into incident response management for the FTC safeguards. Now, we've talked about incident response management quite a few times on the show before.
We've got a lot of information on our website, and typically when we're talking about incident response management, we'll look at it in these different steps, to where it's preparation, looking at how we can do detection, how we're identifying weaknesses, events, and incidents, how we can do containment, once we've detected something, how do we contain it, and then how are we supporting our evidence collection, how are we doing our response and recovery, how are we doing our communications, and how are we doing our lessons learned. That normally encapsulates the entire incident response process, from planning and prep, all the way to final review and lessons learned. FTC safeguards structures it a little bit different.
So we're actually going to go just right down the list of all of the statute requirements to make sure that those are all addressed appropriately. And it's basically the same thing, just reordered a little bit differently. So the very first part of the FTC safeguards requirements is setting clear goals.
That really aligns with our process of the planning. What you want to do is make sure you're identifying, really, if you can, any type of SMART goals. So not, we're just going to detect an incident, but perhaps how much of a response time are we looking for, that we get our teams involved within one hour or 15 minutes, whatever that is.
You want to set goals that help limit financial and reputational damage. And you really want to ensure fast, informed decision making. Obviously, that you're also complying with all the breach notification laws. But this is where you want to make sure that you're identifying everything that that incident response plan is supposed to do. So as you're designing the other parts, you can make sure that it's addressing those needs. And it should go without saying that all of this should be based on your risk-based approach.
Now, second step, section 314.4, subsection H2, is documenting the entire response process. You want to make sure that everything's documented. Just like we've talked about with everything in information security, everything related to your WISP, if it's not documented, it doesn't really exist. And you also want to make sure that with your documentation here, that a lot of our other policies, a lot of the other structure that we do, it's all policy-based, it's all high-level. Here, we really want to start getting into more of the specific processes. What are we going to do, and who's going to do what, which will also tie into the next section. But if we're too vague in this section, if we're not specifically identifying all the different things that we need to do, it's going to leave a lot of room for delays, for finger-pointing. I'm not sure who's supposed to do what, and this will create incredible slowdowns in your incident response process. And especially at the beginning of an incident, when you're working to get everything contained, when you're preventing the spread, delays there can have huge impacts down the line.
So you want to make sure that you have some of the processes in place. What are your detection protocols? What are the things that are going to trigger the alerts? How are you going to respond to those, identify those threats? What are your escalation procedures? And very important, what is your actual chain of command? Who actually makes the decisions? And what we always like to identify is what's a pre-approved dollar amount that your teams are allowed to spend without having to go for management approval. So that could be $500, $2,500, $10,000, whatever that is, it's good to get that approval set up front so that way you can quickly execute.
The next step, and this ties into those processes, 314H3, is clarifying roles and decision authority. This is really identifying who's leading the incident response. And that's typically either the CIO, the CTO, your CISO, or some other qualified individual. This should be somebody that has either cybersecurity experience, incident management experience, or, at the very least, very good project management and team leadership skills. During an incident, it's really going to be like trying to wrangle and herd a lot of kittens. So you really need somebody that has that experience and can keep everybody together and everything moving.
You also want to identify who's going to talk to customers, who's going to talk to suppliers and regulators. You should have all of this spelled out. And a really good practice here is to have a good PR team that will manage the client communications. Have your legal team, which will identify what can and can't be said, and any other teams who's going to speak with different clients. Perhaps you have some different teams that will manage larger clients. However that is, make sure it's identified and make sure that's communicated so that everybody knows this is who's going to talk to the clients. I keep my mouth shut.
Next, we want to plan for the internal and external communications. We just kind of talked about this and the roles and responsibilities, but we're really going to want to identify all of the who, what, whens and hows.
Who's going to do the notification? How are we going to do that? Is that going to be an email? Is that going to be something on our website? When is that going to take place? And this you really want to have legal involved with because it depends on each state how you have to make the notifications, if it's based on once data's been accessed or if it's just based on acquisition, if it's based on once you've identified what was taken or just the notification of a breach. It all depends on the state requirements. It all depends on what's in your individual contracts, which is why it's very important to make sure you keep those as tight as you can when you're setting them up so you don't have so much to deal with at times like this.
You also want to identify all of your legal obligations for breach notifications and how you're going to coordinate with third parties and other vendors. The FTC safeguards then goes on to require remediating system weaknesses. This is more about kind of the holistic side of things. A lot of times this is addressed in the lessons learned section of the Incident Response Program. But you want to make sure that you're performing root cause analysis, also sometimes the five whys. Just why did this happen and ask why another four times.
Why did this happen? Why did that happen? Why did that happen? I think you get the point. Also looking at doing patch management, vulnerability remediations, and again a big part is the documentation. What we found, what we did to remediate it, and the proof showing that.
Keeping detailed documentation. This is so important they basically say it twice. But they do break it up to where this is more of an incident documentation, more of an incident ticket. Timeline of events, all the actions that were taken, evidence of your compliance steps. You want to maintain all of that in a central location so you can show who did what. And if you decide not to notify because perhaps you don't need to, there wasn't any access of customer information, you also want to retain all of that evidence of how you came to that conclusion. That way if there's ever a lawsuit, that way if there's ever a regulator, you'll be able to show here's why we did what we did, and here's why we didn't do what we didn't do. You want to make sure all of that is, that you're able to back it up with documentation.
And then finally, review, revise, and repeat.
You want to test with tabletops, you want to update your procedures whenever there's new vulnerabilities, whenever there's new threats, whenever there's substantial changes in your organization. And you constantly want to be refining those roles and escalation paths. This is something that I can't over stress enough. The tabletop exercises are where you're going to find out where things really fall apart. And take this a step further than just doing some brainstorming and asking who's going to do what. Kick the can down the road a little bit.
Actually start going through those call trees. Actually reach out to some of the PR people and say, Hey, what communication are we going to send? What do you need from me to be ready for that? This will really help start teasing out all of those areas where you're having trouble and where you have gaps in your incident plan. Because what you don't want to have happen is you don't want to go through your first tabletop, you don't want to go and start identifying all the problems with your incident plan when you're having an actual real-life incident. It's horrible. I've seen companies be there. And do not put yourself in that position.
With that said, I am just double-checking here, but I think that is everything in that section of the FTC safeguards. Now, we've talked about it. I've mentioned a little bit of it here. Even just flipping through our own incident response policy and procedure, this is definitely something that if you're feeling overwhelmed, you're more than welcome to reach out to us and we can help you with either helping you to identify your gaps, helping you to perform the tabletops, even helping you to build the entire incident plan itself. We have all of that already put together, so don't stress yourself out over it. We are more than happy to help.
With that said, we are wrapping up our FTC Safeguards Rule Checklist for Compliance series. So, if you haven't already, get the checklist, and next week we'll be going over our last section of it, 'Reporting to Senior Management.' So, thank you very much for listening to us today on Cash in the Cyber Sheets, and until next time.
Thanks for joining us today. Don't forget, click that subscribe button, leave us a review, and share it with your network. Remember, security and compliance aren't just about avoiding risk, they're about unlocking your business' full potential. So, stay secure, stay compliant, and we'll catch you next week on Cash in the Cyber Sheets. Goodbye for now.
