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 course work.
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 uh Excel spreadsheets or different
functionalities of that Excel spread sheet 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 accomplish 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 work,
how many were successfully uh uh fixed and how many problems I actually
fixed depending on where that problem and lied within our different systems.
Or since 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 KP I 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 for a process,
uh 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
for 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
reoccurred or the alert reoccurred 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 be
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, a phishing attack or
how generative ai is being utilized within our structure, maybe threat detection.
Uh It's not often where higher level management will
see a specific news article or a sister company
and they decide, oh,
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 jump 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 co 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 network with one another to identify different aspects
of their own corporation or government under an ND
A that says my company faced this issue,
this cou
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
a 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 places
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 drawing
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 csos.
It's also not common or uncommon to see
the federal government come out or for different enterprise environments to
interface with federal governments where a
notices come out specifically stating,
hey, there's this attack that we have 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 go 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
this
in the different blogs or the news articles and we need to
arrange or a ball of our technology against a specific attack,
you may be asked why
and that report needs to reflect why you're moving against a specific trend.
Why used manpower that may not be readily available to safeguard
against this specific trend or an attack in a proactive nature.
And the report needs to be reflected as such.
There's also the top 10
WSS came out with the top 10 every three or
four 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 10.
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 10.
However, I don't want to retract from the actual usability of the top 10 report,
especially when it comes to web application and web pages.
The top 10 provides us a streamlined
narrative to interact with the 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,
script of graphic failures in web applications and
then perplex onto on that report going,
hey,
I uh upgraded our SSL or CLS from version 1.2 to 1.3 and it directly reflects the oas
top 10 in cryptographic failures. So we'll see
a top 10 and it's easier for managers to go back through and
identify specific technological issue and crop reference
to this open source intelligence gathering for
OS.
And then it just kind of solidifies why you did what you did
in perplexity towards the the aspect of uh your reporting structure,
critical vulnerabilities is often up from CV SS scores or from top
10 trends or something you've never seen from a zero day attack.
We want to go through and identify the 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
planning stage, you've remediated the issue,
you've provided compensation controls and mitigations, you've worked your
off for 60 straight hours and then you did the lesson learned and now it's to refine
the 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 cybersecurity 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 garn 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.
And hey,
this is what we're talking about and then put it into layman
terms for our uh 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.
Uh I had a buddy of mine who thought the,
the manager didn't have a technical background, the, the manager I had an MB A
and had no idea. But in his 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 point which is and proceeded to talk down in a dumb
way to him where the ciso 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 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 the report,
people will pick it up very quickly and you will
be looked down upon yourself as somebody that's hard to do
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 SL A is only 99.1%.
Our slo or objective for our company internally is 99.3.
And then our sl I is the real number.
When we're identifying these on our reports,
a lot of times we'll put this in broad or very numeric functions.
We say my SL A is 99.1.
My slo is 99.3 and my SL I, which is the number to actually hit is 99.2 while yes,
we hit that SL A and the company is happy with us.
We failed to meet our slo. You may have to go into details of why our SL A is our SL A.
Usually this is just a contract line that we're putting out.
We say, oh, well, we have a contract with this company.
So SL A 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 if you're reporting this out to explain why we
made an slo that was higher than our SL A
and the, the reasoning behind that.
So when you identify an slo uh throughout your reporting structure,
make sure that you clearly identify and articulate why the SLO is higher than the SL
OS L A and why we are moving forward with that slo hitting that point.
Sl I
a little bit more indicative of the real numbers if I've
got an SL I and I failed to meet my sla I
need to be able to readily explain why our SL I was
below that SL A and slo in terms of actual numbers,
it's not enough to just say my sl I was 99 when my SL A is 99.1.
We need to come up with why we failed to meet the standard.
What we're doing to fix that standard II
that standard
and the different ideologies or technologies that
we're going to utilize moving forward.
If we failed to meet our sl A 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 sl A
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.