Hi everybody and welcome to part three of the routine assessments mini module.
This particular video is going to go over the quarterly assessments so quarterly assessments and a quarter
and a common frequency is about three months give or take.
These types of assessments you need to normally do three per quarter.
This can be a variety of different things but we'll go over that in the next video about the the that
tend to be a monthly type of assessment.
So the types of assessments do truly depend on the organization and what they need at that time.
Now as I mentioned the previous videos that you're going to be building a an assessment plan for the
next one to two years.
So in this in that particular case I'll give you a focus on a particular area that you'll see that you
will focus on at that point.
However depending on the red team's needs.
Organization needs the types of assessments per quarter may change as a priority.
So just keep that in mind going into this so the first type tends to be perimeter testing.
Now don't get this confused in the previous video of the external perimeter testing.
Now this type of perimeter testing is tends to be in smaller sections or a specific service so a specific
subnet has an example which you'll go over that in a in the networking video essentially a sub that
has a small section of IP addresses that are on a particular subnet mask which again we'll make we'll
go over and the networking module but you're focusing on smaller sections maybe a single IP address
a single service.
So these tend to not take nearly as long as the whole scope of the whole external network as a whole.
So these tend to be done at least once per quarter give or take.
Sometimes it can be done every few quarters.
It really just it really depends on the need.
Maybe those new service that your organization just brought up maybe that's a good reason to have a
test in this particular quarter.
Now network segmentation testing is the task of making sure the traffic and access control list on the
firewall which there's a whole module of firewalls that we will go through and how to set one up and
the rules and how everything works but in a nutshell a firewall is more along the lines of a a device
or software that restricts access based on a set of controls or access controls that are normally set
up in the list.
So ACL going forward is going to be an access control list that determines what can or cannot make it
through or access a particular service or network.
So in most organizations there is network segmentation around the production network which is where
everything lives for the cuts the customer base the main organization.
As far as what they deliver then there is normally the corporate network which is the laptops the phones
printers everything around there.
And then there's the development network where developers build and test code maybe there's testing
of different types of products before they launch different types of services that you may have downloaded
that you want to test out before purchase a large variety of different things.
So in most cases production should never reach Deborah corporate unless there's a specific reason for
it.
And under no circumstances should development ever be able to reach production.
Now there may be one or two use cases on a specific host that may need to be locked down entirely but
pending very very rare use cases like that development networks should never reach the main production
network where all your customer data is where your serve your core services is where you rate your business
really is.
Now production the corporate can happen when it comes to like ticketing systems as an example.
The ticket system might need to be able to be reachable and prod production as it does in corp so that
when you file a ticket automatically through automation in the production network it still ends up in
neutral in the corporate space.
Now there are certain situations where stuff like that does tend to happen.
It's not the best practice but it's also it's common.
So understand that it will happen.
However understanding in this particular test what is and is not allowed through whether it's one way
or the other because keep in mind there may be a rule in place going from prod to Corp that's not in
place the other way around.
So maybe an attacker can gain if they're on the corporate network they can get access to prod to a particular
host.
Or maybe when they're on a particular host but reverse that access would never been there.
So there's good there's good ways to test it on either side of the fence.
So phishing campaigns.
So there's two types of phishing campaigns active and passive.
Now the definition of these can change depending on who you talk to.
So in most cases an active phishing campaign is one that we're actually trying to get the user to click
on a link.
So as far as the red team's perspective you are trying to get an employee to click on a link maybe enter
credentials download a file whatever the case might be you wanting to get an actual engagement out of
the employee to test their training maybe they need to have more training it entirely depends on what
your use cases but in most cases it's for active training you get and then that builds the metrics up
as we talked about before who opened what.
How often did they open up anything then passive tends to be where we let the blue team handle the response.
So we're not trying to test the the employee themselves.
Now we still will we'll still keep track of the metrics on the employee side who clicked what who opened
what.
But this is more of a reactive test.
The blue team's side of things so they're they're not going to know about it there.
It's gonna be a surprise for them.
The employees are going to have to report it or they're going to have to catch it in some way shape
or form while active.
We will give them a heads up saying that it is it is coming so zero day audits.
So this is this can change depending on the organization.
So some organizations will do this and some won't.
So a zero day audit is isn't is trying to identify issues unknown previously unknown issues in source
code of some kind.
Now in most cases this is going to entail the internal products or services.
So maybe your you're working with the application security team to work on the web application and see
what issues you may find there.
Maybe some of the engineers have written their own services that they use in production that you have
found an issue with maybe there is a flaw maybe there's command injection.
Whatever the case might be you've found an issue that was previously unknown to them and have identified
it.
Now this can be done misspelled the word on there.
I'll fix that.
It'll be fixed in your in your version when you download it at the top so it can be done for external
code bases as well.
If you know that you're going to be using a particular or particular open source platform right.
Whether that's the engineering group using it the development group using it.
The red team using it whatever the case might be.
Maybe it's something that your company actively uses.
It may be a good idea to just grab the current source code.
The version that you are currently using and do a few tests run through it if it's not too large of
a product.
If it if it's something you guys want to do on a normal basis you may want to move it to a yearly type
of assessment and perform a bigger audit over the course of let's say a month month and a half again
whatever the exploit you develop never test them on production machines always test them in a development
environment read download the product.
If your company uses get have it pull down the repo rebuild it what whatever case you need to do but
you need to test it in a development or local environment never tested on a broad network.
The last thing you want to do is take down a production node on a new exploit that you don't know is
stable or not and have somebody up your ass pretty quick.
You don't want that.
You do not want that at all.
So in the last bit is again the feedback loop.
When you identify an issue you report it you get the ticket rolling they fix it you get the priority
set I'm sure you get the priority you get priority set they fix it you you test the fix and the cycle
continues.
So that is a quarterly assessment.
Now the next thing we're going to go through is the the monthly assessments that need to happen.