There comes a time in every analyst's life where they really go through the process of figuring out
all the malware that's infected 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 you 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 affecting you on a reporting side.
Now, Cisa only requires the fact 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 into 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 Discussed 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.
Those would 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 fact, after the fact actions.
Once we've identified those primary stakeholders, we need to identify what the impact of the systems
is.
After all, even though we've identified the stakeholders, we need to have some information in order
to relay back to them.
Otherwise, we're going to get questions like, oh, well, when's it's going to 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 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 and that aspect?
We need the information to be both timely and accurate.
The worst thing we can do as a cybersecurity professional professionals say the server is being impacted.
We don't know how.
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 immediate 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 15 20 minutes down.
We've done a little bit of investigation.
While it may not be as timely, we are now providing that more accurate leverage to it.
We're 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 okay.
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 provide towards our primary stakeholders as well as our
immediate supervisors.
Things like expected time to remediation.
How long is it going to take for me 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
can tell somebody, yes, we have something.
We know the impact is this server.
We know that it's affecting these clients and our expected time to remediation is an hour to 90 minutes.
That gives us a nice little window to work within.
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 going to 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 2 hours to 3 hours now, and we're providing specific times that associate to a clock.
We're not saying 90 minutes, we're saying 230 to 3:00 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 going to investigate the IDs, and then we're going
to go through the IPS, and then we're going to go through the 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 reporting 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 IDs.
I have to investigate the IPS, 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 diving into the router.
We have to reconfigure the entire thing.
And that's going to take 30 minutes.
And then I have to go through this.
And 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 IPS 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 after action review.
This usually occurs with everybody that was involved within the actual remediation process.
Obviously we're not bringing HR people into an after action 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.
And this aspect we would want to provide everybody that talked to those third party vendors and all
of our employees that touched 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 how, 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 in to 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 over
protocol so that we can more streamline effective traffic.
Maybe it means updating the IPS.
Maybe it means taking a legacy system offline because it affected the change or 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 own environment.
This is all part of that after action 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 one we're to provide is alert volume.
The reason that we mention 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 could also point out to our detection time.
Our mean time to detection is how long we put eyes on the alert from occurring from 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 their eyes on it versus the actual time.
Detection in this case may have been 17 minutes.
There's a little bit of stuff in there and we need to identify why that occurred.
It may be within the average and that's okay.
However, let's talk about maybe our actual time detection was 25 minutes versus a mean 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 ten 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 meantime 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 can 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 mean time or average time that it takes
to remediate a specific problem like this.
Maybe we're seeing a DDoS attack.
And in 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 27 hours.
Well, what would it constituted?
That extra three hours?
Maybe it's only ten 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 and 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 a 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 IDs unless we spell out and provide within that report exactly
what an IDs is.
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 stock 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.
And in that case, we may tone it down from the 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 size is concerned.
Our reporting or our senior management.
Can 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 toward 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 HIPAA.
This would go through the process, and we may have some extra indicators on that report that we submit
to senior management.
So they then can report that to compliance.
Remember, 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 components 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 responsible for reporting for Sisa, you just need to know that if it's a HIPAA report,
you need to conform to HIPAA 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 formal reporting and everything that comes along with it.
When it comes to Sisa, 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 2701.
That's not what we're talking about here.
What you need to know for Sisa is the difference between a primary stakeholder and a secondary stakeholder,
and why you would include one in your primary 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 Sisa exam exactly who you're reporting to, i.e. those primary stakeholders and why you're
reporting to them.
If you can do that, you should be good to go.