After everything is said and done, you're going to have to report out on the different aspects of what
you're trying to accomplish or what you have accomplished in the past, whether it's through cybersecurity
or information security or even information technology.
When that process, we often utilize KPIs, which we've discussed earlier in this coursework.
But how does that translate to actually reporting to hire about what's going on throughout the entire
process?
When it comes to metrics, we often need to utilize Excel spreadsheets or different functionalities
of that Excel spreadsheet to identify or perpetuate the idea of what we've accomplished within our process.
I highly discourage you from simply putting out Excel spreadsheets and going, oh, here was our KPIs,
this is what we met, and so on and so forth.
While those numbers are great and they identify very quickly what you accomplished or where you fall
within the overall process, the fact is that you need to go through and actually articulate what those
different indicators are.
Within my own background, we had different indicators of how many tickets I worked, how many were
successfully, uh, fixed, and how many problems I actually fixed, depending on where that problem
inlined within our different systems.
For instance, if I had a security issue with a specific alarm or alert, we would dictate.
Here's the alert number.
Here was the overall problem.
Here's what I did to fix the problem.
And then we would keep track of all those different aspects and provide a KPI specific to that different
alert.
This provided context to how long it took to fix the issue, how long it took to identify the issue
and what the fix was, and if the fix changed from alert from alert, even though it was the same alert
per process, these different KPIs can provide management with key details about how to streamline the
issue, or to identify if I need to fix the issue in a different way.
Maybe there was a fact where one technician is fixing the alert in a specific way, and it only takes
five minutes, but this other technician is fixing it a different way, but it's taking 15.
They may need to readdress that specific issue and provide training to the overall infrastructure of
the overall employees on how to fix it in a more efficient manner.
They may find an issue didn't really fix the problem because the alarm re-occurred or the alert re-occurred
where we had to send another technician out to fix the same issue only a day or two later.
But the individual technician didn't realize it because we have so many different technicians doing
so many different things that they just didn't put one and one together.
When it comes to KPIs or key performance indicators, we really need to not only understand what the
key performance indicator is, but how it translates to business needs.
Those business needs may translate to different policies or different procedures on how we interact
with the technology itself.
Those KPIs may come into question when you're presenting those specific stats on how you can evolve,
or how you can change those stats for the better, or get down those numbers when you're reporting it
to upper level management.
There's also different trends that come into play.
We often identify different trends as a phishing attack or how generative AI is being utilized within
our structure.
Maybe threat detection.
Uh, it's not often where a higher level management will see a specific news article or a sister company
and they decide, oh crap, I need to address this specific issue because this company, which is our
competition, just had a bad publicity news article written about them specifically for this cyber threat.
And so they jumped through hoops to make sure that we're addressing that issue before it becomes a major
topic within our own individual company.
These specific trends often come into play at different avenues.
They can also be lead ways into problems that we may see in the future.
If I have a company that's a direct competitor and I'm friends with their with their CISO or within
that specific industry, maybe I can get a leg up on my own company going through the same issue and
stopping it before it becomes a major issue to evolve around it.
It's not uncommon to have different CISOs attend conferences and networks with one another to identify
different aspects of their own corporation or government under an NDA that says, my company faced this
issue, this issue and this issue, and for the trends to evolve from that particular issue, where
you may have the CSO coming down and saying, hey, I want you to go through and start looking at our
company for different policy validations, for specific, um, uh, specific issue, whether it's malware,
whether it's a, uh, authenticated use factors because they saw something that you're unaware of that
is developing into a trend.
This often comes in different plays or different aspects of our organization, where a lot of times
we may not know specifically what we're looking for, but we've been directed by higher level management
to proceed forward in a specific issue or topic.
That may not make a lot of sense to us.
Just realize that there's a lot of upper echelon stuff going on in different communication factors that
are being regulated to those different CISOs.
It's also not common or uncommon to see, uh, the federal government come out or for different enterprise
environments to interface with federal governments, where a notice has come out specifically stating,
hey, there's this attack that we've seen in different industries.
Make sure you're aware of it.
There's the complexities of this attack where you're offered advice on how to arrange your email, uh,
technology to identify specific attacks.
These all develop into different trends or technologies that you may not be aware of.
On the other hand, you may be aware of them.
You may be tasked to go through and look at different news articles.
Or maybe you're listening to a blog post where you're seeing an uptick in different attack methodologies
being utilized, and you take it upon yourself to go through, identify those trends, and then safeguard
your systems against those trends moving forward.
These need to be attributed to a specific report and why you're doing it.
Well.
More often than not, high level management dictates down to us, and we don't really have to file that
report.
We just make a little line on a reporting status that says for management, we've started to grow or
evolve towards this specific attack vector or for this specific technology.
And that's a one and done thing.
But if you've identified it as a proactive cyber defender or an analyst, that's saying, I've seen
this in the different blogs or the different news articles, and we need to arrange or evolve our technology
against a specific attack.
You may be asked why, and that report needs to reflect why you're moving against this specific trend,
why you used manpower that may not be readily available to safeguard against this specific trend or
an attack in a proactive nature, and that report needs to be reflected as such.
There's also the top ten.
OWASp came out with the top ten every 3 or 4 years, and management loves to see this on reports.
They love the little graphics that are associated with it that says, oh, I'm following the top ten
now.
You can hear my voice into the laughter behind it, because a lot of times you're thinking to yourself,
oh great, I get to deal with top ten.
However, I don't want to detract from the actual usability of the top ten report, especially when
it comes to web application and web pages.
The top ten provides us a streamlined narrative to interact with.
With upper management, we can identify specific factors in our web applications that should be listed
on our reporting mechanisms for upper level management, because it directly attributes to something
a third party company that's widely known for web application security moving forward.
So we may identify, for instance, cryptographic failures in web applications and then perplex onto
why that report going, hey, I upgraded our SSL or TLS from version 1.2 to 1.3, and it directly reflects
the OWASp top ten and cryptographic failures.
So we'll see OWASp top ten.
And it's easier for managers to go back through and identify a specific technological issue and cross
reference to this open source intelligence gathering for OWASp.
And then it just kind of solidifies why you did what you did and perplexity towards the the aspect of
your reporting structure.
Critical vulnerabilities often are up from Cvss scores or from top ten trends, or something you've
never seen from a zero day attack.
We want to go through and identify the life cycle of a zero day attack, and be aware of those zero
day attacks as they're impending into our system.
There may be a brand new attack that we've never seen before, and it may have taken you 12 hours to
fix it.
You've gone through the entire incident planning stage.
You've remediated the issue.
You've provided compensating controls and mitigations.
You've worked your butt off for 60 straight hours, and then you did the lesson learned.
And now it's time to report back up the chain to what you did and how you fixed the issue.
Oftentimes, we need to identify the whole life cycle of a zero day attack because you're not talking
to technical personnel.
Upper level management is very rarely up to par when it comes to these technology issues or our our
speaking patterns.
When we come to technology, we may spout out things like TLS or SSL or port 25 or port 53, or you
get the point.
And while it makes perfect sense to us as cyber security experts, it doesn't make a whole lot of sense
to upper level management.
That's not their job.
Our job is not only to know that technical jargon, but also be able to translate it for the business
level people.
To understand what we're talking about, we need to provide that theory or that dictionary to understand,
hey, this is what we're talking about, and then put it into layman's terms for our department heads
and for our upper level management when we go through that process, we also need to be very technical
and then break it down.
Don't ever underestimate the fact of how a senior level management may have insight or may have a technical
background.
I had a buddy of mine who thought the manager didn't have a technical background.
The manager had an MBA and had no idea, but in a previous life they were a software developer and were
one of the original people that had gotten into cybersecurity.
They were very up to date with the process and the schematics of cybersecurity and how computers function.
But the technician had talked down to them, not physically or in a way that denoted a level of scrutiny,
but in a way of I'm going to make, say, everything so stupid simple that it almost made it hard for
the software engineer or the CISO to actually understand what they were talking about, because they
had dumbed it down so much.
And I remember the CISO, as this guy is explaining this technical layman's terms of, oh, well, we
had a port, which is and proceeded to talk down in a dumb way to him, where the CISO CSO actually
stopped in mid-sentence and said, stop, I need you to talk to me in technical terms.
Don't talk dumb to me.
And he literally said it that way in an offensive manner.
So we not only want to provide the technical jargon, but we also want to provide the layman's terms
in a way that doesn't denote or diminish from their intelligence.
If you start to talk down to somebody as you're going through their report, people will pick it up
very quickly and you will be looked down upon yourself as somebody that's hard to deal with or someone
to talk to.
So we want to provide it in a very business and professional manner from a technical perspective, but
also from a non-technical perspective that is easy to understand.
By providing both avenues, we're providing a way for business managers to look at it from different
perspectives and understand where we're coming from.
We've also talked about service level agreements, where we have a specific boundary or a specific benchmark
that we need to hit within a service level agreement.
We may say, hey, I need to have 99.1% update time, and then we have a service level objectives that
says even though our SLA is only 99.1%.
Our SLO or objective for our company Internally is 99.3.
And then our SLI is the real number when we're identifying these on a reports.
A lot of times we'll put this in broad or very numeric functions.
We're saying my SLA is 99.1, my SLO is 99.3.
And my SLI, which is the number it actually hit is 99.2.
While yes, we hit that SLA and the company is happy with us, we failed to meet our SLO.
You may have to go into details of why our SLA is our SLA.
Usually this is just a contract line that we're putting out.
We're saying, oh well, we have a contract with this company.
So our SLA is this and it's written by contractual language, but we may have to identify our specific
SLO or why we came up with that SLO.
Sometimes you may be the third person in line, and you're not exactly sure why we came up with this
SLO, other than the fact that you were told the SLO is the SLO because it's always been the SLO.
Does that need to be evolved or changed?
You need to be ready, especially for reporting this out to explain why we made an SLO that was higher
than our SLA, and that the reasoning behind that.
So when you identify an SLO throughout your reporting structure, make sure that you clearly identify
and articulate why the SLO is higher than the SLO and SLA, and why we are moving forward with that
SLO hitting that point.
Slides are a little bit more indicative of the real numbers.
If I've got an SLI and I fail to meet my SLA, I need to be able to readily explain why our SLI was
below that SLA and SLO.
In terms of actual numbers, it's not enough to just say my SLA was 99 when my SLA is 99.1.
We need to come up with why we failed to meet the standard, what we're doing to fix that standard,
i.e. meet that standard, and the different ideologies or technologies that we're going to utilize moving
forward.
If we fail to meet our SLA two weeks ago, they're going to expect a rise since then.
So be prepared on your report to say yes.
We failed to meet our SLA last month, but so far in this month, we're tracking at this percent value.
Those are questions that you can readily see coming through your brief with your higher level managers.