There comes a time in every analyst's life where they really go through
the process of figuring out all the malware that's affected their systems.
They've just completed an incident and they go through
the process and they're left with the final aspect.
That's right, documentation and reporting.
It's our favorite thing in the world to do. And we're going to discuss it today
in this episode, we're going to talk about different reportings,
different stakeholders that need to be affected by
that our after action review and finally,
the formal reporting process
throughout this episode,
we're going to go through and really dissect the different
issues that may be affected you on a reporting side.
Now, cys A only requires the
that you understand it from a high level
and able to identify stakeholders and the after
action review process as well as what's inside
a formal review or formal reporting process.
They're really not going to go that much in depth with it,
but you need to understand the basic foundations of what's
going on and that's what we're going to discuss today.
The very first thing that you need to do as a cybersecurity analyst throughout
your reporting process is to understand who
your primary and secondary stakeholders are.
Primary stakeholders are directly affected by the incident or by the malware.
In this case,
it would be leadership and employees or
even specific departments within your organization.
If you've got an incident that's affecting, say the HR department,
then obviously you need to let the HR department know because we may
be taking their systems or their clients or even file servers offline.
They may lose access to their internet,
they may lose access to their specific servers and it could
be directly affecting how they are able to approach their work.
In that case, we need to let them know what's going on on.
Those will be attributed to our primary stakeholders.
Secondary stakeholders are indirectly affected.
This could be third party vendors, maybe your legal or human resources department,
even your operations department, they need to be notified,
but they're not considered primary stakeholders because
they don't need to be notified immediately.
They're more after the af after the fact actions,
once we've identified those primary stakeholders,
we need to identify what the impact the systems is after all.
Even though we've identified the stakeholders,
we need to have some information in order to relate back to them.
Otherwise, we're going to get questions like, oh well, when it's gonna get fixed,
how impactful is it, what is it doing to my systems?
All of those items need to be addressed when we
communicate clearly to those primary and secondary uh stakeholders,
what's going on with their different systems.
When speaking about impact,
we need to identify very clearly what's impacted
by the incident and how it moves forward.
This could be an entire department, it could be a single machine,
it could be a single server, it doesn't matter,
but the impact needs to be clearly identified.
Is it a business critical asset?
If so what other secondary assets is it affecting if it's a server?
What all is impacted by the server being provided by that incident?
In that aspect, we need the information to be both timely and accurate.
The worst thing we can do as a cybersecurity
professional to say the server is being impacted.
We don't know how uh and we're letting you know 15 minutes after we already found out,
sometimes timeliness and accuracy don't always mesh
up and sometimes we have to decide,
do I want to let them know now with a
little bit of information or later with more accurate information?
If you call up to your media supervisor and the stakeholders and say, hey,
the server is being affected by a piece of malware or a virus.
We don't know the full extent of the impact. That's perfectly fine.
We have provided timely information
and while it may not be accurate,
we let them know what's going on further down the line, maybe 1520 minutes down.
We've got a little bit of investigation while it may not be as tiding.
We are now providing that more accurate leverage to it saying yes,
I know it took 15 minutes.
But now we know it's affecting this file system structure or this
aspect of our servers and we need to take the server offline.
We're providing more information.
Remember,
our goal is to be timely and accurate with our
impact statements when we're addressing incidents within our environment.
Sometimes again,
the timeliness isn't persuaded and we have
that flow of what's timely versus accurate,
the more time it takes, the more accurate it is.
And that's ok. We just need to be aware of that
throughout our monitoring, updating status.
We're talking about monitoring what's going on inside of our
network and how that applies to updating our stakeholders.
We also have expected recommendations throughout this process.
We need to have recommendations that we can
forward towards our primary stakeholders as well as our immediate supervisors,
things like expected time to remediation.
How long is it going to take for to resolve this issue?
Now again, it doesn't have to be completely 100% accurate,
but we usually know within 10 to 15 minutes how long
an incident is going to take in order to be reconciled.
That could be 15 minutes to an hour.
I recommend going with an hour and a half hour increments
as you're going through this so that you could tell somebody.
Yes, we have something, we know the impact of the server, we know that it's a,
these clients and our expected time to remediation is an hour to 90 minutes.
That gives us a nice little window to work with that.
If we're done before then, awesome.
If it's going to take more time, we need to let them know before the hour mark is up.
If we know that it's not going to be fixed within 90 minutes,
we don't want to come back out at the 95 minute mark and tell them.
Oh, well, yeah, we knew it was probably going to be fixed by 90 minutes,
but it's gonna take another 90 minutes.
That's the wrong way to go about it.
The better way is to say at the hour mark,
when we expected the lower end of our estimation to go through,
we come back and say we took longer than expected.
Our new estimated time to remediation is this time to this time.
Maybe it's two hours to three hours now.
And we're providing specific times that associate two o'clock,
we're not saying 90 minutes, we're saying 230 to 3 pm.
After that, we want to talk about the process. Now.
We don't want to go into our primary stakeholders,
say the organization as a whole and say, oh,
I wanted to go through our process and we're gonna investigate the I DS and then we're
gonna go through the IP S and then we're gonna go through the router and the switch and
you get the point right.
We don't want to provide that process to
somebody that really doesn't know what we're doing.
However, if we're recording back to our manager or senior managers,
maybe that process is important.
We want to go through and say, yes, I have to investigate, not only the switch,
but I have to investigate.
The ID si have to investigate the IP S and we
want to provide them the process as we're going through.
It doesn't need to be detailed.
We don't need to tell them we're driving into the router.
We have to reconfigure the the entire thing and that's gonna
take 30 minutes and then I have to go through this.
That's, that's not what we're talking about.
What we're talking about is a very high
level overview of the different systems that you're touching
in order to remediate the problem or the incident that's occurring.
It doesn't need to be deep dive.
It just needs to be a 32nd review of what you plan on touching along the way.
This provides two things. One it tells the managers what route we're taking.
And so they have a warm fuzzy about how we're proceeding with the investigation.
A lot of times those managers,
especially your first line manager has a technical background
and they may be able to provide an input or maybe even know the
network and provide suggestions on how to
investigate the incident further down the road,
this provides you a speedier recovery and it
provides some mentorship from higher level management.
The second reason is because as you're going through that process, if you say, hey,
I have to go through the IP S or I have to go through a specific switch,
there is a chance that switch could go down.
You're letting your manager know that if something else drops
off along the way that it was expected and then they
can handle the public relations between the incidents and the
different department of what's going on and what's being affected.
That's their job as a manager,
your job as an analyst is to remediate the incident as quick as possible.
Now,
that doesn't mean you can just start sweeping
switches offline and just take the entire network,
but it does provide a little bit of cushion for your manager to be able to
report to their senior managers exactly what's going on and take the heat off of you.
Remember,
a good manager is one that separates you from the technician or from the analyst,
from the rest of the managers and serve as a filter or a
roadblock so that people aren't bothering you as you're doing your work.
That's their job.
Once the remediation has taken effect, we're looking at afteraction review.
This usually occurs with everybody that was
involved within the actual radiation process.
Obviously, we're not bringing hr people into an afteraction review.
They don't understand the systems they don't understand what's going on
and they're really not going to provide some
really valuable input to what's going on.
But maybe you worked with a, with a coworker on it.
Maybe you had different partners and even reached out to a third party
vendor for extra support on the incident and how it was occurring.
In this aspect.
We would want to provide everybody that talk to those third party vendors and all
of our employees that touch this incident to get a feeling of what's going on.
Maybe they can provide some valuable insight,
maybe it started with the IT team and we provide
a leverage for the it team to come in and
provide their input so that we have a better understanding
of not only how that incident occurred within our network,
but the remediation process as a whole within this lesson learned process,
we're really looking to streamline and provide some
effective learning and what happened with the incident
and how we can move forward to be more effective at our jobs moving forward.
Once we've identified the lessons learned,
we're going to go through the recommendations for changes.
Now, recommendations for changes can come from anybody within the process.
Maybe somebody that's listening,
then that's the process or the lessons learned had a good idea.
And we want to provide that recommendation for change.
This could be something as simple as 5% of our traffic is going
through this port and 85% is going through this other port or protocol.
Maybe we can move that traffic off of that port,
shut that down and move that port over to this other protocol
so that we can more streamline effective traffic.
Maybe it means updating the IP S maybe it means taking a legacy system offline
because it affected the change of the incident from the get go and
we want to go through a different system that's more up to date.
Whatever the problem is or whatever the change is,
we need to provide that recommendation for change to our senior managers so that
they can move that change forward and hopefully get that process changed within our
environment.
This is all part of that after actual review that we've talked about.
Finally,
the formal reporting process comes into play after the after action review.
After the process, after everything that's occurred,
we want to go through a formal
reporting structure within the formal reporting structure.
We're going to provide some key elements or statistics throughout the report.
The first word we're to provide is alert volume.
The reason that we mentioned alert volume is because we want to know or we want
senior managers to know how much we're dealing with on a day to day basis.
If you're seeing 10,000 alerts per day per hour,
that's important thing for senior managers to know so that
they get a taste of where we're coming from,
this could offset the fact that maybe our detection time or
response time wasn't exactly what we would like to see.
In other cases.
It could provide additional leverage for our manager to maybe get some
more technology or more budget to hire more personnel into our department.
Whatever the reason we want to provide that alert volume and how
many of that specific alert led to that incident from occurring.
This is also point out to our detection time.
Our mean time to detection is how long we put
eyes on the alert from occurring for the first point.
Now, sometimes our incident doesn't actually produce an alert,
but we found it through other means that needs to be dictated as well.
Our mean time to detect literally is the average time that it takes
to detect an incident like this from occurring within our own network.
We also want to provide the actual time to detect
if our mean time to detection is 15 minutes.
That's where somebody puts the eyes on it versus the actual time detection.
In this case may have been 17 minutes.
There's a little bit of stuff on there and we need to identify why that occurred.
It may be within the average and that's ok.
However,
let's talk about maybe our actual time detection was
25 minutes versus a meet time of 15.
We need to provide input and figure out what occurred
in our after action review of why it took so long
it could also be better. Maybe it's only 10 minutes.
This shows improvement to detecting this type of problem.
Maybe we've seen problems in the past and we're
actually improving on this course of action regardless.
We want to provide both the mean time to detection
and the actual time detection within our formal report.
There's also the mean time to respond.
This is how long it took for somebody to actually start working on this.
Now, don't confuse this with detection time. We could have a team
that is fully responsible for detecting problems and then shifting those
tickets up to analysts that are actually responding to it.
This could sometimes be as long as two days or even a week.
In some cases, it could be five minutes, whatever the mean time to respond is,
we want to annotate that within our report versus the actual time to respond
again,
to provide our manager with some leverage for
the different needs for our cybersecurity department.
And then there's mean time to remediation.
We have incidents that are occurring and there should be a meantime or
average time that it takes to remediate a specific problem like this.
Maybe we're seeing Adidas
attack and the meantime to
remediate is 24 hours, not a great time, but it is the average for our organization in
this case. Maybe our actual time was
seven hours. Well, what will it cost to you to do that extra three hours?
Maybe it's only 10 hours and we did a really good job.
So again, we need to go through and say yes, this worked,
this worked and this did not work.
Let's not do this again,
whatever the case,
we want to provide that marine time to
remediation versus an actual time to remediation.
So we can identify different processes of procedures that worked and didn't work.
Finally, we want to report to our senior managers.
This report is overall going to our manager which
is then going to submit it to senior management.
Senior management isn't always on top of the technical nuances.
So we provide these statistics so that they can see very big picture
wise based on the average time or statistics that they're well known for.
We want to stay away from words like I DS unless we spell
out and provide within that report exactly what an I DS is.
Uh it needs to be a technical report, but a low
level technical report in most cases.
Now, this really depends on organization from organization.
If you work for a major technical organization
that produces soc reports all the time,
your senior management may look at you and say I want a highly technical report.
However,
you may also work for a retailer and the retail manager that's associated with.
This doesn't need that high technical report. You're just going to confuse them.
In that case, we may tone it down from
technical perspective.
This is where really knowing your environment for reporting really comes
into play and your manager should help you along the way.
As far as CYS A is concerned,
our reporting or senior management reports really go to that in between where
they have some technical knowledge but not an in depth technical knowledge.
You shouldn't see a lot of questions on your
exam specifically to the type of report that you're doing
more on the broad spectrum of what the report actually includes.
And then finally, regulatory compliance reporting,
this usually goes through a manager first,
but then we may have a regulatory component to it.
Let's say for instance,
one of our servers that was affected by the incident is holding health information.
We are then bound by HIPAA regulations to provide a compliance report for HPA.
This would go through the process and we may have
some extra indicators on that report that we submit to senior
management so that then can report that to compliance or as
an analyst isn't your job to report for compliance natures,
but it may be your job to actually put the compliance report together.
Those are two different tracks when we're putting those reports together.
And if it has a compliance element to it,
just be aware that those compliance elements need to be properly filled
out to the letter of the regulatory compliance or our contractual agreement,
your manager should help you along the way.
But if you're responses for reporting for CYS A,
you just need to know that if it's A HPA A report,
you need to conform to HPA regulations.
They don't expect you to know what
those regulations are for the compliance reporting.
Just that you have to actually follow HIPAA compliance reporting.
Within this episode. We talked about reporting and the reporting structure.
We talked about identifying stakeholders and of course, the after action review,
finally, we talked about form reporting and everything that comes along with it.
When it comes to CYS A, they really take a high level overview of all of this.
You don't need to dig into the nitty gritty of going well.
Topic 1.3 includes this according to ISO 27 01.
That's not what we're talking about here.
What you need to know for CYS A is
the difference between a primary stakeholder and a secondary
stakeholder and why you would include one in your
primary uh reporting structure but not the other.
Again, we're not looking for anything deep dive here for the reporting structure,
but you should know for your cys A exam exactly who you're
reporting to ie those primary stakeholders and why you're reporting to them.
If you can do that, you should be good to go.