They also have another publication for data centric
system threat modeling.
This is a draft document, so it has a look, some other features that maybe a little bit distracting. But the nice thing is that it's very recent.
It just came out less than a year ago,
and it's a little bit more focused on
systems and instead of
explanation of what attacks are.
How they vectors mean in that sense,
how you defend against these kinds of attacks. What kind of security controls air countermeasures
do you put into place?
And then it goes through a methodology, which is somewhat similar to what we saw in the other document.
You're identifying your system. You're gonna find the attack vectors,
seeing if your controls air countermeasures that replace are likely to be effective.
And then you might look at your threat modeling that you did in
using the previous document
to do some of this work.
So it goes through and give some some breakdown on the different
steps that you might take
to do this kind of work.
And because it's still a draft document, there is a lot of mark up information that's still here, but it's pretty useful overall
and definitely worth looking into.
and then another document, which could be useful,
is information sharing. Cyber threat information sharing
This one's also they're recent
only us only a few months old, really
and we talked a little bit about information sharing in a previous discussion.
But it's good to also bring this document up here because we're still talking about the value of a
and how they interact with management so that management committee risk based decisions
the different types of threat information,
the benefits of sharing it, of course.
And then, as we mentioned the previous section trying to identify the appropriate stakeholders who is producing the intel who is
what kind of scope should be defined?
And as we saw with creating an organization that can
organization, we can
enlist the help of other organizations to share information together
and give each of those organizations a little bit of extra advantage because you've got access to a larger amount of information
so that's a good document to look into a CZ. Well, these are all fairly short. So
not not not for a very long reading exercise, but definitely worth looking into.
So international. Ready for
risk management threat Modeling with Internet 1 54 and then information share 1 50
Definite look into those.
All right, so let's think about
change Mandarin and Security posture.
Security posture. A good analogy for this is something like a castle, right? This is a castle that's
got a moat around it.
maybe it has a drawbridge.
It might have other of different layers of defenses,
and that's very similar to an organization. We can think about the physical perimeter
as being the outermost
But then there are other layers that are physical as well. You've got Gates, guns and guards,
you know, locked door security cameras and so on. But they're also
security controls that are logical or technical controls,
things like firewalls and proxies and
These are all extra layers of
of protection and organizations put into place in order to better
protect their assets.
One of the most important things to deal with when you're
when you're thinking about change management or configuration, management is having a valid,
if you don't want. If you don't know what assets that you have, that it becomes very difficult to properly protect them.
And anyone who's been involved in doing inventory work probably knows it's not very much fun.
It can be very tedious.
But there are ways to make it a little bit easier by using
our code labels for asset tags and so on, using databases to or handheld bar code readers to make life a little easier.
making sure you know all their assets to begin with is a great foundational step
so that configuration management can be more effective.
It's also translates into
the documentation that the organization uses for instant response
because there could be special policies in place for certain types of assets.
You're going to protect a
critical server differently than you would protect a end user workstation, for instance,
maybe email servers are protected differently than database servers, and so
so your incident response
documentation should take those different asset types into consideration when developing your procedures based on the policies,
investigation that an organization should engaging.
I'm not going basis.
We start off with compliance on its
compliance. Audits are just what
that the basic foundation is made off your determining do our assets conform to our policies
or even to regulations or laws?
This is a good thing to verify,
because it means that you've
that you've achieved some correctness in your configurations of your assets.
This means you're you've got a password policy in place you don't have any.
And the default settings under applications,
everything any, any extraneous user accounts have been removed and all these different things.
every organization is going to have a a large list of these types of requirements
trying to achieve internally,
and especially if you are a health care orange organization, or if your financial organization
there are many external requirements which must be met for compliance on it
was your regulations and laws that
might have an annual requirement things like fisma, for instance,
after the compliance audit,
a control assessment might be considered.
Both of these things might happen based on two different triggers.
It could be that it's a time based trigger
like it's the annual time to do this. Every January we engage in a compliance on it. Every June we do a security control assessment,
and maybe every September we do a penetration test.
That could be the case for an organization.
Time based triggers are
our good minimum requirement to have,
but there's also in vet an event based trigger requirement as well.
there are suspicions that you've got a bunch of assets that are not in compliance
or you've got a bunch of security controls that haven't been assessed and they don't appear to be functioning correctly,
then you may disregard
the time based trigger. You're not gonna wait six months to go look into this problem. You're going to do it now because there's an urgent need to verify. The settings in these
controls are in place,
the compliance on it provides a bit of a foundation for security control assessment
because these are both traceable back to
pile season that were created as part of the government's model of your organization
Security Control Assessment provides a foundation for a penetration test
because of security control assessment can find vulnerabilities.
It can find weaknesses, things
that appear to be missing or incorrectly configured.
But it generally does not go
so far as to prove that damage could be done by exploiting these weaknesses. That's what the penetration test comes in.
So the penetration cash will be something that you would do after these other activities
to provide some assurance that he's either The controls are not as vulnerable as they were thought to be.
Order trying to prove that
that a breach of the perimeter of defenses or a breach of an application or operating system is actually possible
and therefore further work must be done in order to remediate that issue and
prevent it from happening again.