As a security analyst, it's important to understand the different aspects of how your operation or
organization functions.
It's your job to make sure that as an analyst that you're taking those under you, whether they're brand
new analysts or coming in fresh from the career, or maybe they're going in from a job change and making
sure that your organization runs smoothly, that goes to the processes that may be standardized to make
the process more efficient.
And efficiency really comes into play with just the technology, but with the people as well.
You need to understand all the makeup of they train the hardware, the equipment, the software, the
people, the data, all that comes into play.
And you as an analyst, especially a senior analyst, need to understand how to make those processes
and policies intertwine with one another to become more efficient.
It's not uncommon, as a security analyst to be way over your head, and I don't mean that from a technological
point of view.
I mean it from a point of view as there's never enough people, and when there's never enough people
to streamline the operation, to be as efficient as possible is definitely something that you want to
work towards.
Now, standardized processes really kind of make this groove within our organization to make sure that
person A is doing the same thing that person B is doing, which is the same thing that person C is doing,
and that we have processes that combine and interchange with one another so that your night shift is
working the same way as your day shift, and that those processes and policies are being followed so
that the person coming in after you can quickly pick up where you left off, and that way you're able
to leave on time without having to stay an hour later because of overtime rules and the policies weren't
being followed.
So it's really important for you to have a standardized process to run smoothly within the organization
and become a well-oiled machine because you're, quite frankly, never going to have enough time for
everything that needs to be done, especially in a SoC environment or in an incident that's going not
your way.
A standardized process needs to be consistent.
That means that it needs to be the same as a week ago, from three months ago to even a year ago.
Now, that doesn't mean that we can't change things or tweak things to make it better.
It just means that it needs to be consistent across the board, whether you're a graveyard shift employee
or a morning employee, or if you're doing one job over another, or moving from an incident over to
a malware analysis, it needs to be consistent across the left field.
If your manager comes into play to fill in a specific role, or if you're going from a server role over
to a malware role, the process needs to be consistent.
And you'll hear me harp on this quite often when we're talking about standardized processes, because
consistency really does provide us an efficient pathway.
I know in my own pathway, we had a process that was not being followed by every employee.
And the way that I did things, while I thought it was more efficient, kind of went against the processes
that we had in place.
Now, as time came into play and I talked to the manager, we were able to tweak that process to more
conform to a more efficient streamline, but it could also play some headaches with everybody else that's
going into play, I want you to imagine that you're working on a malware analysis, and you've been
working a 12 hour shift and you just want to go home.
Maybe you've got kids that you need to pick up from the daycare.
Maybe you've got a hot date.
It doesn't really matter what's going on, but what you really need to go into play is, is the process
consistent so that somebody can pick up where I left off very easily.
In some places that's not the case.
And it could cause a handover failure, meaning that the person that's coming in after you can't readily
lead your notes, or you have to spend half an hour with them so that they can understand exactly what
you did already.
Having a standardized, consistent process and policy in place really formalizes that handover exchange.
It also makes it to if your manager is looking over what's going on, they can quickly identify and
in detail and report to hire exactly what we've done.
This usually entails note keeping or providing a log of the work that's been done, a detailed analysis
of what's going on and basically going forward with our processes as we as we move forward.
A lot of times, analysts forget to write things down, and this makes it really difficult not only
for your managers, but for your co-workers who may be working after you on the same process.
And so it's very persistent that we have that consistent policy in place, not only for operations but
for incident management.
Consistency really is the key when we talk about a standardized process.
Within this, we usually use different policies or technologies that come into play with our standardized
process, i.e. vulnerability scanning.
When vulnerability scanning, maybe we started at 6 a.m. in the morning, and we go through specific
tools or specific protocols in order to scan our network.
If you're going through and you've got a very large network of over a million different machines, you
can see that scanning needs to be very formulated, very consistent and very articulated in going in
forward meaning I need to scan different sections of my network throughout the course of the week or
the month.
If my company says, hey, every Monday, the first Monday of the month we're going to scan the operations
department, all their are 250,000 machines, and that's going to take a week because they have a lot
of machines.
Then we need to follow that scanning process to the queue, as in we're going to scan that network as
opposed to a different network.
But we also need to scan it specifically for what we're trying to scan it for, whether it's malware
or open ports or different vulnerabilities.
We're looking for specific items, and usually that entails having a set scanning process in place that's
already predetermined.
We don't want to go outside that predetermined because we want to provide consistency.
There's also patch management.
If I have a patch that comes into play, there's usually a policy or procedure that quickly identifies
a consistent way to do that.
Patch management, usually through change management policy that interprets what step A is to step B
to step C, you need to understand those standardized processes as they relate to your specific organization.
There's log management and how we utilize those logs.
But where we store those logs I talked earlier about how we had different logs within my own organization,
and we would grab those logs both in the raw and the filtered, and we would store the raw logs over
offsite so that we had full control over those logs if we needed to go back to them.
But we also had filtered logs, which only provided us the specific details that we needed for our sin.
Now, log management is a key point of consistent, standardized processes of how we use those logs
within our internal functions with across our organization.
There's also threat intelligence feeds and how we can utilize those feeds where we can get those feeds
from and how we can use those feeds within our individual organizations.
That doesn't mean that we can't experiment a little bit.
If we have a little bit of permission from our manager, or we want to take it in a different direction,
but it does mean that we have a process in place that needs to be followed on a consistent basis as
we go through those threat intelligence feeds, usually goes through a specific department, and then
we can go through and identify specific threats that may be associated with the information that we're
gathering and how we utilize that information and the feed process to get permission to move forward
on something.
provides its own process.
Again, there's also user behavior and analytics, which means how are our users using specific machines?
And can we do a trend analysis to identify specific vulnerabilities or associated behavior with those
users moving forward?
All of these have a standardized process or policy that we need to be aware of within our own organization.
Often when it talks about standardized processes and consistency, the number one thing that comes into
my mind is team coordination.
What kind of communication are we dealing with?
Communication is key with any organization, but especially true within a chaotic environment such as
a security operations center.
When you're consistently undermanned and it's highly technical and there's a lot of handovers going
on.
You have to have communication both in the written form as well as the verbal form.
I can tell you there are many times where we had an issue within my own operations center, and we would
go through and we work through an issue, and I was on 14 hours, no sleep.
I'm really dead tired.
I still have a two hour drive home, and I need to communicate to the technician that's coming in after
me, to what I'm doing, what I've done already, and what has worked versus what hasn't worked.
Now you may think to yourself, oh my gosh, 14 hours.
That's not unheard of.
And some really bad scenarios.
And so by communicating to the new person, both written so they have a specific log of everything that
I've done including ports, protocols, test procedures, scans that I've conducted, tests that I've
done, all of that written down, that new technician can come into play and go, okay, they already
did this, did they did this, did this, but not just what I've done the results of those as well.
And then I would verbally hand off to them as I was driving home, i.e. a two hour drive home.
A lot of times allowed me to talk on the phone with them and can provide and provide that handover to
where they can say, hey, I'm looking over your logs and I see something.
Did you see this?
I'm not seeing it.
And so communication to where they could come into role and not have to start from scratch really is
key.
If you've got an incident where you've got a major attack ongoing, you really need to have that communication
with that new shift coming in to really relay everything that was happening not only before the incident
occurs, but while the incident is occurring.
There's also role and responsibilities need to be clearly defined and manager that's clearly defined.
His role as overseeing a security operations center may have a subsidiary role of being able to actually
dive in from a technical standpoint when needed.
However, there may be clear delineation that goes, hey, you're working specifically on servers.
That's your job.
If we have an issue with a client, you're not really relied on or responsible for those clients.
I need you to stay on your side of the tracks, and that's perfectly okay.
But we may pull them over under specific circumstances.
What is the policy or the procedure or the responsibilities as defined by their work role and by management
team?
There's also collaboration.
As we all know, servers that have an issue sometimes trickle down to a client, which may trickle over
to other network equipment.
And so having collaboration, not just only within your cyber team, but also with the IT team, is
very paramount to how our teams function across the organization.
Nothing sucks more than having a non-collaborative environment where your IT team and your cyber team
are constantly finding one another, it makes things last way longer than what they actually should.
It's your job as an analyst to not only perpetuate a good culture and a good environment to work with
those other teams, but understand where they're coming from and facilitate a very positive environment
that produces high collaboration.
This not only allows our cyber team to pull from good IT people that may want to transition into cyber,
which is often lacking, but also provides backup in some circumstances where the IT team can really
help us out on different aspects of a cyber incident occurring.
How many times would you actually like to work on a client when you've got a major networking issue?
It's not uncommon to have 5 or 6 employees in your cyber department, but have 50 or 60 in your IT department.
And if the IT department can handle a client issue while we concentrate on the network issue, that's
a major win.
But if you don't have good collaboration, all of a sudden the IT team is going, we're too busy, we
can't help you And that's just going to put more hours on you and lead to those long days and long nights
of wishing you had hair like me.
There's also the training aspect of it, right?
We want to cross train and cross collaborate with those other environments.
You'd be surprised how many times it comes into play, and they've got great training because they have
a higher budget, or they've got training coming into play specific to a specific equipment that they
may allow the cyber team to join in on.
At the same time, we may have training that we only have 5 or 6 people in our cyber team, that maybe
some IT people want to jump into.
And so we have that cross collaboration, cross training platform going on.
Team coordination and collaboration is really big when it comes to cyber security.
You truly cannot do this job alone.
The days of the hoodies and the basement where you've got that one giant guy that's just an expert in
his field that you see on the movie screens.
It's just not a thing in cybersecurity.
We really are a team, and you need to get it through your mind that not only do we want to need a team
environment, we want a cross team environment where we can collaborate and coordinate with other departments
to make our job easier.
Throughout this episode, we talked about team coordination.
We talked about the process of standardization.
We talked about consistency and through processes and policies as well as operations, we.
Talked about communication and why communication is fundamental not only within your own department.
But within collaboration with other departments.
Uh, throughout this episode, we really need to.
Understand that as a security analyst, we're not looking at the foundational level that you may.
See, within Security+, we're looking at it as a mid-career level where you're moving forward.
And you're really perpetuating a good culture and environment and facilitating and enforcing those processes,
policies and procedures and being an expert in your field, when Sisa is really talking about in this
field is you are the expert for cyber security analysts, and you are really providing that expertise
not only from a technical perspective, but from a human perspective as well.
You need to go through the process within Sisa of understanding both the people position.
But the technical position as well.
If you do that, you should be successful on this exam.