The Typical Parts to an Enterprise IR Plan

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

5 hours 19 minutes
Video Transcription
lesson wouldn't point Teoh the typical parts to an enterprise incident response plan.
For this lesson, we're going to talk about the appropriate questions to ask an organization to gauge their I r maturity.
We'll discuss the recommendations on how to define a cyber incident and how to differentiate different activities within incident. Response
will identify the key strategic and tactical components of an incident response plan.
Oh, go through how you should write an IR plan. And then finally, I'll introduce you to a couple of frameworks that you might consider using for your incident response program.
The questions that you should focus on when you're looking at an IR plan is first what people in skill sets do you need for the i. R. Organization to function correctly.
Every organization is going to be different. You have to base this on your risk, tolerance, your activities, the type of skill sets that you have in house and make a differentiation between what you have and what you need. What are those gaps that you might know,
and also do you need the higher for that skill, or can you contract that out or have outside consultants help you with that.
Secondly, what technology and tools do you have access to? Do you have a sim? Do you have in point detection and response tools? Do you have I d. S I. P s tools? Do you do full packet capture? Do you need to do full pack capture? So those are the kinds of things to go through and just take
an assessment in an inventory on the tools available to and I, our team.
Third, what mechanisms exist to use lessons learnt to make you better and more secure?
So if you have previous incidents that you could walk through and learn from, that's ideal If, you know, maybe there's a soft spot in the organization, maybe you've got a real problem with employees clicking links. Maybe you have, ah, weakness in your defense in depth. So these are things to look through just to identify
holes and low hanging fruit. He might be able to take care of quickly.
And then finally, how do you manage your I R organization? Is it going to be part of I T. Is there going to be part of another group and I'll walk you through some examples of organizational structures and chain of command and that sort of thing as we go.
So how do you define a quote unquote incident? Some people say, Well, we know it when we see it. Not a good strategy whatsoever. This is not the answer you should have. If somebody asks you how you know when you have an incident, I'm gonna give you a couple of ideas on how you might define this.
So if you look through a few different organizations and some research out there, there's a couple different ways you can do this. I'm going to give you one way, and you may take it or leave it. But no matter what, you need to have some definition for this.
So here's some suggestions in event, an event, maybe something that happens on an information system but doesn't require anything malicious. And it doesn't require any action. For example, a successful log on. Well, that's certainly an event, something that gets you logged in the event logs on a window system,
and you should be capturing things like this. But you don't need a sign ir to go investigate that.
Now you have alerts something potentially actionable maybe notification of Mao, where on a device could be an example
incident with a small I.
This is some sort of a violation of the confidentiality, integrity or availability that C I. C I. A triad that we all know and love and cybersecurity. But there's no business impact. So maybe you have a single system
that got some malware on it, and it just affected that system. It wasn't anything that Fuller proliferated across the organization.
There's no lateral movement. It didn't steal anything, just simply something that happened on that single device. But then you have an incident with a capital I. This is that same violation of C I. A. But it does have a business impact. Maybe data was stolen. Maybe it's ransomware. Maybe it had lateral movement.
So this is something that
its impact and I say business. It could be agency organization. Enter your name there, but there's some impact to the operator,
and then finally, a breach. A breach is loss of specific regulated data that triggers legal obligations above and beyond any incident, response issue or thing that you may need to dio. But there's actually some regulatory impacts here,
so some people on that little I or big Guy incident. They may call them different things like a type one incident
is impacting the mission. It's enterprise wide. A Type two incident is a single host, or you may call it a a Rabi or something like that. But again, you should have some differentiation.
Now, when you look at the maturity of IR capabilities in an organization, here's just a sample of how you may do this. So the bottom tier here is there's low maturity. Or maybe there's no real capability whatsoever. There's an ad hoc incident response process, and it's essentially
we get some sort of an alert or malicious activity or somebody just says my systems acting weird.
The default response is re image it and get back out there and that's it. There's no investigation, no logs, no nothing.
There's a lot of organizations that do this
moderate maturity. This is There may be an I R team there some tools in play here, mostly like E T. R. Firewalls. I DPS maybe a SIM tool. Maybe not, but they've got some basic processes in a play look, playbook to find here
and then a mature team is really full time incident response. They've got some senior staff that know what they're doing. They've got executive level sponsorship. They're well funded, their processes air repeatable. They've got high visibility into networks and in points. They're doing continuous monitoring. Maybe they've got a threat Hunting capability.
They've got digital forensics capabilities, reverse engineering of malware.
They probably do their own pen testing. They do security, orchestration, automation and response or sore. And these air really top level organizations, lots of money, lots of people. And these air, You're mature, cutting edge organizations, not a lot of those, especially in
small and medium sized businesses and a lot of smaller government organizations.
When we look at writing the actual incident response plan, we're gonna look at two different components. One is strategic and one is tactical. So for the strategic parts of your I R plan, you want to have a few things. One. What's the mission of the incident response team? Your I R teams should have a mission statement how you align with the organization, how you protect them,
what it is that you do, why you function, why you exist in life.
What are your strategy in your goals. Do you have metrics a mature I Our team will have metrics, and I'll walk you through several times, actually, in this course some example. Metrics toe. Look at foreign. I Our team will talk about roadmaps for maturing the air capabilities. You saw my last slide. I've had that tear.
Maybe at the bottom tier, you put an IR plan together and use
incorporate. The strategy is perhaps a roadmap. You say your low now you want to get to medium, and here's the way you're going to do that and then organizational structure of the I. R team and how it fits with the broader mission in business.
On the tactical side of things, here's some components that you may want to have in your plan terminology. What is all these? What are all these different terms mean and have them clearly defined
command and control? Who's in charge? Who's making decisions and what is the decision authority who gets to declare an incident and we'll talk about this? This is a big actually a big deal, and you'll want to have that clearly defined What are the I R. Team roles and responsibilities. How do you triage multiple incidents at once?
Do you have a command center in a war room defined within the organization? How do you do status updates and communications with both internal and external stakeholders?
What about alternate communications? Do you need to have a plan? If you can't communicate on your own network because it's compromised,
who can make the decision to disconnect? And then finally, how do you do recovery lessons learned and writing after action reports?
When you write the plan, there's a few things to keep in mind as well. One. We don't want to make it a warn document written once red. Never. You do not want to have a stale incident response plan that is sitting on a shelf somewhere. These need to be frequently updated,
practised and
at the fingertips of those that need to have access to this document.
Plan should be updated at least once a year. You should have appendices for rosters of your I R team. References and checklists also make the plan simple to read. This is not a time to show off your skills or your knowledge of fancy terms and the cybersecurity industry.
It needs to be quick to read, easy to understand, easy to action,
and then consider where you store this plan. Is it hard? Copy virtually do version. Control the plan up. Or maybe it's all three, I would say, though, make sure you don't have your I. R. Plan somewhere that's non secure because it is something you want to protect. If adversaries got ahold of your playbooks, that would not be a good thing.
And secondly, consider having it in hard copy form. I used to have a binder for all of my incident responders that had our I our plan, our playbooks, contact lists, references just because if our networks compromised and we can't get into something, we want to have that information at our fingertips.
The frameworks that will go through, for the most part on all introduce you to a few others as we go. But I'm doing a lot of foundational information in the scores on these two, and they're very similar. On the left hand side. You see the NIST incident response framework. On the right hand side, you see Sands Incident Response framework There's
on the left. The nest
framework has really combined several of the things into just four overall, where Sands has six. But you'll see some overlap there, and we'll go through these more in depth.
So for this lesson, let's walk through the quiz. Question. What is an example of a process that may be found within a mature sock? A ad hoc? Responsive are I'm sorry? Response in an image and move on mentality.
Be antivirus software or C sore tools?
Well, he answered. Sore security orchestration, automation in response. You're correct. That is something we would certainly see on a more mature sock.
One more quick question. Select the component below. That is a strategic part of the ire plan.
A maturity roadmap for the i R Team B Command center, a war room location. Or see who has the authority to declare an incident.
A maturity roadmap for the i R team. That's certainly on the strategy side. The other two are things I've talked about but those air more tactical than an actual strategy. A road map for the organization.
So in summary, we looked at what appropriate questions to ask an organization. Engage their maturity and I are some recommendations on how to define a cyber incident that's critical. I really want you to know that and do that in your organization. We all have to be on the same page. We all have to know what an incident is.
Also, some key strategic and tactical items toe have within your strategic plan some mechanics of writing the I R plan and I introduced you to a couple IR frameworks.
Up Next