now getting started in our next section, which is making the case for incident response planning. If you're like I am, it seems amazing that we're still having to make a business case for incident response planning. If you look around, read the news, walk outside here, surf the Internet at all
just you'll hear about
reach after breach after breach and companies suffering large scale losses for failure to contain incidents properly.
it would seem that that would make our job much easier. But they're still organizations still managers that don't have the buy in to properly plan for incidents. And then there it's a response plan. Seems to be we're gonna play it by ear and we're gonna wing it, just hope for the best. So we know that's not
incident response plan. We're gonna start off this section by just going through some definitions, making sure we're all on the same page with the terms we use. All right, so first piece, an event, an event is simply a change in state. It's not good. It's not bad. It just is
D. N s service started.
That is an event. Okay, Now, when an event or series of events have a negative impact on the system. That's when they become an incident.
Okay, so an incident is negative and event is neutral.
Instant handling versus incident response. When we look att, insulin incident handling, that's all the processes that are necessary in order to address incidents that happen on the network. So that's gonna include management, planning, documenting and all those different
elements. So incident handling is that
broad topic and incident response is the last step of incident handling where we plan and coordinate, we implement our mitigation
and our recovery strategy. So some subtle differences there I will mention that they may use incident handling an incident management kind of interchangeably, and sometimes they'll even use incident management with incident response. You're just gonna have to read the questions and the topics for context.
All right. So important for us for the exam, of course.
What are our responsibilities as schism in relation to the incident response function?
Well, first thing is, we're responsible for the development of incident management policy. Now, that may not be totally on our shoulders. We're gonna work with senior management on that, and certainly they're gonna have to get final approval, but at the very least we're gonna have a tremendous amount of input.
Here's where we're going to set the expectations and lay out the guidelines and procedures processes for making sure that the service is that air provided to the business are consistent and reliable. Even in the event of an incident,
we're gonna make sure that roles and responsibilities are well documented so people know what they're doing and what they're expected to do.
Um, and then we'll make sure that part of our policy includes any sort of requirements if we're going to have alternatives to critical functions. If there's been some sort of compromise or damage when we need to make sure that the alternatives we configure are going to meet the requirements right, they're gonna meet
that criteria that's met. So that has to be defined.
Other things that we're gonna do is we're gonna work on developing the incident management and incident response plans, of course,
coordinate the activities. Yeah, the schism has a lot of responsibility with incident response. That's why it's a significant pensive the exam,
making sure that the counter measures that are put in place are both verified and validated.
And when we talk about verification, we're looking to find out. Did we do it correctly?
So did we follow the processes per the plan
and then validation is Did it work in a perfect world? If we did it right, then we would have done the right thing. Does that make sense? But sometimes we verify, find out. We followed all the steps correctly
and it didn't work is intended. So that's the difference between verification and validation.
All right. And then we help with budgeting and development for all these matters that are related to information security in the event of incidents.
Now, to me, it does feel silly that we're still trying to get by in for instant response planning.
But that really should be becoming easier and easier because we're seeing a recurrence is increasing. You know, every week that I teach, I think we'll let me just check the media to see which group we're gonna talk about this week.
Whether it's, you know, organizations that have had branches linked in E Bay, Home Depot, Bank of America, Office of Personnel Management. I mean, we could just go on and on and on, and you're certainly hearing a lot more about cyber attacks than we have in the past.
Losses air escalating. We're no longer looking at a website simply being defaced or, you know, some downtime here. There were talking about losses in the millions, and sometimes hundreds of millions of dollars were seeing millions of credit card account number siphoned off
people's personal information.
Uh, we're seeing, you know, the credit card industry
being hit with over $1,000,000,000 in losses with identity theft and credit card fraud. So, yeah, you know, it's happening more often in the impact is getting more severe. In fact, when we talked about risks, we talked about probability and impact.
Well, right there on our 1st 2 bullet points we have in both right, probability is increasing. An impact is increasing. That tells us we have to take this seriously, um,
vulnerable and miss configured systems. It seems to be the trend, and software and system development is to release a product,
then go back and secure it with patches six months later. So we're having systems that are coming out of the box unsecured, perhaps for easy. If you say we're having systems that haven't been thoroughly tested. We have systems that are have dangerous default settings that are well known.
Also one of the news
technologies or one of the concerns that were just starting to realize the potential of is the Internet of things and how many network devices and individual user may have on their home.
And how many of those devices are secured with the default settings. If it all
a legal and regulatory groups may require an incident response plan to be in place. And often when senior management will listen to other arguments, what is their liability? What is their potential for loss? What does the law say that often is a good argument,
and then the growing sophistication of Attackers. Attackers are getting smarter. They're getting sharper.
They have better tools at their disposal. You know, with the advent of the GP use and some of the other technologies to crack a password today versus what it was yesterday night day.
So we certainly have to understand the importance of planning for these incidents,
and if we do our ultimate objectives or don't minimize the impact on the business incidents will happen whether they're large scale or minor. Whether they're intentional or not,
incidents will happen.
But let's have a plan. That's we're gonna be proactive. We're gonna get on her feet quickly and minimize the impact.
Okay, Stakeholders understand what our plans are. So there's that degree of transparency and we inspire confidence because we don't look like we're getting caught off guard,
were able to identify incidents quickly and respond to them quickly as well,
and not just respond to an incident that get to the root calls that we can avoid that same incident in the future,
as well as making sure we get those critical service is back up and running within the acceptable interruption window. Just a quick reminder. The Aye Aye, W is the amount of time that it takes me to restore critical systems.
Don't confuse that with recovery time objective,
which is the point of time till I'm back to a state of normalcy. Those terms are very comparable, and I want to make sure that you have them separate flicks