Service Level Agreements (SLAs) and Metrics to Monitor Protection Abilities

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
less than 3.4 service level agreements and metrics to monitor protection abilities.
The objectives for this lesson include understanding what service level agreements or s L. A's are and how they're used within IR.
Discuss Example. S. L. A's between I T and security teams
and identify common metrics that may be used to strengthen S. L. A's and measure their effectiveness.
Service level agreements can be a powerful tool to use between organizations or between companies and their vendors or service providers. You'll often see S. L. A's with cloud providers, for instance, where they
offer a 99.999% or nine fives. Or however they define it up time for their network, where there
cloud capabilities and features.
But you can also use S. L. A's internal to an organization also, and I'll go through a couple examples of how you might want to do that.
Most organizations aren't mature enough to have s L. A's or they just don't know how to write them or have never even thought about doing these before. But they can be a great way to use alongside of racy and some of the other things we've talked about to measure the effectiveness of an organization and make it clear who is responsible for what
and what the expectations are.
A few SL examples. So, for instance, vulnerability management SLS can be used and should be defined between cybersecurity and I t You might say something like I t will remediate vulnerabilities with a CVS s score of 7.0 and above within 30 days.
So this makes it clear who's doing it? Its I. T s responsibility.
They have to remediate the vulnerabilities with a CVS s score of 7.0 and above. So now it's clear what you're talking about,
and they have to do it within 30 days. Now, with a company, there's generally things like financial penalties or rewards for performance against an S L A. So, for instance, you may have a contract that says, if the contractor provides this software with an X amount of time, they get a bonus
or for everyday there late,
they lose $1000. So that's not typically seen in internal organizations. But nonetheless, having these in place with those expectations can be very helpful, especially when we go into metrics reporting which will get into in just a minute.
Another example, I t will re mediates CVS s score 9.0 and above with active exploitation within 48 hours. So again, very clear. We all know what who's doing what when it has to be done and what level of vulnerabilities were talking about
in order to see whether the SLS air being hit and people are complying with them. You have to have metrics and we'll talk about those quite a bit
and also create an executive level score card on the performance against S. L. A's is a great way to show how things were being done, and it can also become a leading indicator of future impact to the business or organization. So metrics traditionally fall into one of two areas you've got leading and lagging.
Lagging indicators. Just tell you what's already happened. It's not really good for any predictive capabilities, but it's certainly informational. It might be useful
where leading indicators help you predict what may happen as a result of the information you've collected.
So an example of this is if your critical application is way behind on vulnerabilities and I'm sorry on patching vulnerabilities,
and you know that that raises its susceptibility to being compromised or taken off line. Then you can say this is a potential leading indicator, that we will have a business impact because the likelihood of this system being taken off line or being compromised is much higher.
And that's an example of a leading indicator
that you might be about two years.
Some sample metrics that are out there that you might use are things like penetration testing results,
aging metrics on remediation, action items,
vulnerability scan results by severity and type.
By that, I mean having metrics on
how many CVS s nine and above is in the enterprise, and how long have they been there? That's a critical one to keep track of. Also the currency of patch levels. Are we current? How far behind are we in patch levels for different applications,
the percentage of incidents detected by internal controls? This could be really helpful to see how good your internal controls are detecting them, Or are you continuously finding
compromises and incidents with threat hunting teams with outside consultants? Is the law enforcement calling you and saying, Hey, did you know that half your data is out on paste bin.
Obviously, that's none of those were good, but much
be much better to find them internally than having somebody from the outside tell you.
But if you're not catching these things with internal controls, then the next question is, Why not? And then you can figure out. Do you need new controls, new tools? Or you need to adjust what you already have in place.
Also, vulnerability. Scanning coverage. So if you know you've got
100 devices on your network, but you've only got results for 60 of them, what's going on with the other 40? Are you being blocked? Are they offline? What's going on? And that's another great metric tohave.
And then another metric to look at is what is the information security or cybersecurity? However, you want to call it budget as a percentage of the I T budget.
There's lots of benchmarking out there how much the I T budget should be, how much security should have of the I T budget, and it's helpful to know, are you even in the realm of median numbers for your budget? Are is your company paying more for security than they should
probably not likely are they way underfunding? And executives like to know how they stack up to the competition to. So
if you get benchmark results for,
let's say, 2% of the overall I T budget is usually spent on cybersecurity for higher education, and I'm just throwing that out there then and you're 1% and you're in higher education. That might be something the highlight to see. Why is there a disparity there? This could be tricky because people report things differently.
But it is something to consider looking at
quick lesson here, and we'll do a quiz question
wire S L. A is a good idea.
A. They provide a common understanding of expectations and capabilities and can be used to measure performance.
Be they make senior leadership, understand what I T and cybersecurity are spending their budget on or see. They measure employee engagement.
This answer is a. They do provide a common understanding of expectations and capabilities, and they can be used to measure performance because you can have metrics and key performance indicators or KP eyes associated with them.
So if you have an S l. A that says you will patch CBSS nine and above within 48 hours. Well, then you have a metric to say. How good are they doing it that we will do vulnerability scanning once a week. And if we see CVS s nine or above that is older than 48 hours.
Then what's the percentage of the systems that have not been patched
within the 48 hour timeline? And you can start reporting on that? And it could really help drive some good questions and look at practices and staffing and procedures and tools.
So if you have these SL is in place, it can really make your organization more mature, And it's not necessarily a way to point the finger at somebody else, although some people will use it that way.
That's not what I'm getting at here. It's really to mature the organization, have good data and metrics and
create some dialogue between the different groups on how you can all improve together as a team because we all have the same goal in mind, which is protecting the organization.
So in summary, with this lesson, we talked about what s L. A's are and how they might be used in incident response. Some sample s L. A's I went through and also some common metrics that could be used to strengthen S. L. A's.
He would also want to have S l. A is with external service providers to. So if you do have a retainer with an incident response company or you've got external consultants doing cyber security work for you, then S L. A's would probably be appropriate, particularly with response times and things of that nature
when you're looking at having somebody come in to assist on an incident.
Up Next