[LOGO SOUND]
So now let's start talking about what actually
goes into the process of planning out
the design for a secure architecture.
The whole design has to be built.
But there's a lot of planning that
has to go into it before you can actually have a design.
So kind of a summary of a lot of the things that
need to go into the planning process.
There are multiple steps that are
going to involve multiple people in the organization.
One of the things you need to identify
is the importance of the systems involved
that you're trying to protect.
How critical are these systems to the operation
of the business?
If we're talking about an application server that
is a key piece of the organization's revenue
generating systems, then that would
be an extremely important and critical server.
But if we're talking about a file server that
holds maybe notes from meetings related to development
of a low level application, that may not
be as critical as a system.
So you really need to identify this systems and kind of group
them into various tiers based on the importance
they have in the network, mostly relating to the business
operations, and how critical they are to the company itself.
You need to look at also the types of systems you have.
What sort of technologies are used in the organization?
This could be IT, operations, our IT systems.
This could be OT, Operational Technology systems depending
on the organization, the type of the line of business.
You need to look at the types of systems
and the types of technology that are in use,
and build that into those tiers as well
to help identify and inventory everything.
Then you go through your risk assessment and threat modeling
processes.
Go through those to identify what sort of threats
can your organization face?
What are the risks the organization faces?
And you use the output of that to kind help
determine the controls and countermeasures that
may be most important for your organization.
And then of course, there are always budget decisions
that have to be made.
A lot of those budget decisions are not
done by the security personnel.
We'll still go over a little bit of those
in this video, though, of course just
to kind of give you the background, the information
on some of the details, some of the decision points
that may be considered when it comes to budget.
And then any other generic or requirements
the organization may have.
What is upcoming for the business?
Is the business going to be going through any expansions?
Are they going to be acquiring another company?
Merging with another company?
Getting sold to another company?
And so forth.
What kind of things are happening with the business?
And of course, what sort of compliance
or regulatory requirements does this organization have to meet?
That has to go into the planning of a proper secure architecture
as well.
You've got to build in the design,
has to meet any compliance and regulations
that you're required to follow.
But of course, as always, the end goal
here is to balance security with usability of the system
to make sure it's secure, but also usable
because what use is a non-usable system to the business
if it's too secure to actually be used for business practices?
What is the point of the system?
So start off, let's talk about the inventory
and prioritization processes.
Proper inventory, again, is required.
You have to know what you have in your network,
and what systems are present in order
to know how to protect them, and what kind of controls
you might need.
You have to identify all the various systems you may have
in your infrastructure, in your network,
regardless of what they are.
Basically, if they are IT-related, or connect
to your network in any way, and sometimes in some cases
even if they don't connect to your network,
you still need to identify them.
Especially if they are specifically
offline systems that don't connect to the network,
but still are IT-based and have a function
in business processes.
Some of the things you want to identify and record
in this inventory is what sort of vendors do you have?
What are the vendors?
What is their support information?
Support contacts and contracts, purchase dates,
warranty expirations, things like that all
related to the vendor itself.
What sort of operating systems do you have in your network?
And what does each piece of--
what is each device used as an operating system?
Whether it's a Windows Server, or some sort of integrated
proprietary Linux distribution.
What operating systems are present
and how do they tie-in to the rest of the network?
And then, any software you've identified.
What are the version numbers of this software?
How is it updated?
How are patches released?
Who is responsible for patching?
All kinds of things like that.
So I said, we need to make sure we prioritize our systems.
We do this to make sure we have our efforts focused
in the right place, at the right time.
The higher the importance of the system, the more energy
and more effort should be more focused
should be driven towards those types of systems for security.
And also the more attention needs
to be focused on them when it comes
to things downtime, or any outages or anything like that.
So typically, there are a number of tiers
that you would use to kind of prioritize
and categorize these systems.
You have your tier 1 systems.
These are your most critical systems
that your business depends on to function on a daily basis.
If these systems go down, it has a direct impact
to the business, and to the money, the revenue
the business is bringing in.
So this is going to be the critically affected systems.
If they go down, it's a bad day for everyone all around.
For whatever reason they go down,
whether it's just equipment failure
or whether we're talking about an attack with ransomware,
and so forth.
Your tier 1 systems are your critical systems,
they get the priority effort.
You have your tier 2 systems.
These are still your important systems, but if they go down,
they have less of a business impact.
Maybe this system could be down for an hour,
and it wouldn't really have a huge impact on the business.
It would be an inconvenience, maybe some of the employees
would have to adjust some of their processes,
and things like that.
Maybe you have some downtime procedures, anything like that.
But it's not the end of the world if these systems go down.
If they're down for an extended period of time,
it begins to become a little more critical to bring them up.
But an outage of an hour or two isn't really
the end of the world here.
Then you have your tier 3 systems.
These are more of your supporting systems.
There might be an inconvenience, but there's real no impact
to the business.
And some of these could be, for example, a tier 3 system
might be a backup system.
Something a server that backs up a bunch of other servers,
that your primary backup systems like that.
If those go down, they don't have any impact
on the business itself.
If they remain down for an extended period of time,
it may affect your disaster recover abilities.
But they don't really have any direct impact to the business
unless they're offline for a long period of time.
If your backup systems are down for six to eight hours, usually
not a big deal.
If they're down for six to eight days,
that becomes more critical of an issue
because you don't have backups for that period of time.
So those are typically the tiering system
you use to kind of prioritize your efforts and the servers
to figure out where you should focus your efforts,
in what order.
All of these tiering will feed into assessments as well.
So your risk assessments will take note of these tiers
as well, obviously the higher the tier and the more effort
needs to be focused in the risk assessment,
and the better more attention is paid to it.
And again, with threat modeling as well.
Speaking of threat modeling and risk assessments,
that would be your next step.
After you know what all is in your network,
you need to figure out what are the threats?
What are the risks?
Risk assessment and threat modeling
are fairly closely related, but that's
the next step in the process.
Figure out what the threats are.
Go through an entire assessment and analysis process
for your risk assessments.
This identifies all risks posed.
With risk assessment identifies all risks
across the organization, not just IT.
Any risk posed, this could be technology-related,
or it could be things like natural disasters.
But knowing these risks also helps narrow down
your priorities, you're a little more--
and lets you identify controls that you
need to apply once you know what your risk is,
you can think of controls to help mitigate that risk a bit
as well.
And this also ties into our threat modeling.
Threat modeling is usually more specific to things
like cybersecurity threats.
But they are very often coupled with your risk assessments
to really fine-tune those where your efforts should be focused,
and what you should be working on mainly.
And as always, your compliance, and
your regulatory requirements, always tie into this.
They don't necessarily always tie
into things like risk assessments,
but you need to keep the compliance requirements in mind
when you're doing things like threat modeling
and things like that.
Any specific requirements you have for your organization,
whether it's laws, or anything like that,
they're going to impact what sort of countermeasures
and controls that you may choose.
You may only have certain options.
Maybe you are under very strict regulations,
and you have a certain list of vendors
you're allowed to choose from.
Maybe US federal government, or something like that.
Or maybe you have specific controls
that you're required to have in place.
So organizational requirements like
that sometimes can dictate the types of controls
you might have to have.
And of course, there's always money.
Money is always a thing.
Security controls so far--
security requirements have been identified,
we know what our risks are, we know what our threats are,
we've modeled all the threats, we
know where we need to protect things,
and we know what controls we want to put in place ideally.
But everything costs money.
Everything requires a purchase, or a license,
or a subscription, or something like that.
Almost everything costs money.
There are some control, some good controls out there
and some systems out there that are open source,
or a free to use.
And you shouldn't discount these just because they're free.
Depending on the type of organization you're in.
Maybe you don't have a very large security bucket,
some of the open source options are
free options are very good options.
They're still powerful pieces of software,
but they may not have all of the in-depth features
that some of the paid software may have,
but there are still good options if that's
what you need to look at.
And there are also sometimes good options
open source software if you want to kind of evaluate
a type of control, but you're not
quite ready to jump in with a specific vendor.
You want to test an open source.
What if we started using this type of control?
Well, here's an open source one that we can check out
for free that'll give us a better idea of whether we
want to look into actually purchasing something or not.
Your budget decisions are always going to be very tightly based
on risk assessments as well.
The organization and financial officers
will base budget decisions on what risk is posed,
and these risk assessments.
Every organization will do it differently.
So there's not one tried and true method
that financial people are going to use to do that.
But the budget decisions for where the money is spent
is usually very tightly wrapped into risk assessments,
and what risks are posed.
Especially if you are using for example, a quantitative risk
assessment or risk analysis because then,
you can do a very concrete cost-benefit analysis
with that.
You know how much money a certain risk might
cost the organization, you know how much
the control is going to cost because you've
talked to the vendor, looked at a price list.
So you can do a cost benefit analysis there.
Or the financial people can do the cost benefit analysis,
and really figure out, OK, is this worth us
spending the money on or not?
And again, there's always going to be other decisions that will
affect selection of controls.
Unfortunately, as a security engineer, security analysts,
you don't always get the controls that you want.
You may want a certain type of email filter
or certain type of email system, or a certain type of IPS
or firewall or multi-factor solution,
but the organization may not be willing to pay for it.
So you may have to go to your second choice,
or it may just be removed from the budget proposal altogether.
And a lot of times that may not be something you have
control over.
That can be due to things like the organization just
can't afford to purchase this expensive email filtering
product.
Or perhaps they have a much larger risk appetite,
and they look at the price of it and go,
we don't really want to spend that, we're just
going to take the risk and see-- and just
hope that nothing happens.
And if it does, we'll deal with it then.
And then you have all kinds of other business activities
that come into play that are going
to affect budget decisions.
Office politics unfortunately will affect things like that.
It's just a way of life, and unfortunately some things
you just have to get used to at some point.
But there's a lot of other activities and things
that happen in the organization that will affect the budget.
Maybe another department needs more money
than they usually do for more critical reasons this year.
So the security budget has to get trimmed a little bit.
There's all kinds of reasons.
So as part of planning out a secure architecture,
documentation, communication, critical as always.
But with this process, it's important
that the entire documentation and communication
process, and the entire planning process needs to be team-based.
Multiple parts of the organization
need to be involved in this process.
Now, what teams need to be involved
are going to vary based on what exactly you're working on.
What part of the design you're working on.
If you are working on a secure design for a financial service,
you're going to want to involve some financial folks.
If you're working on the HR systems,
you're going to want to involve the HR people.
It just depends on where you're working.
At a minimum, though, you always want security
and IT involved in the entire planning
process for your secure architecture design
always without exception.
And then any other area of the business
that might be affected or impacted
by any of the decisions that this design may put forward.
Any business areas that are going
to be affected by this design, or by this decision
need to be involved-- like I said,
finance for financial systems, HR for HR systems, engineering
or for HVAC systems, things like that.
So it really just depends on what
you're looking at determines who needs to be involved.
But everything needs to be documented.
All of the steps, everything that is done with this planning
process needs to be documented.
Use this for not only referencing down the road
as you go further into the process, but also
for collaboration.
You use these shared documents to work
among the different teams and between the different teams
to make sure the process is as smooth as possible,
and the planning is appropriate for what
the business needs as well.
You also keep these documents for auditing purposes.
A lot of times you're going to have audits
that may ask specifically, let me see your planning
documentation.
How did you arrive at these decisions?
So having document for the humming documentation for that
is very useful.
And even if they don't request the specific documentation,
it's very helpful to go back 3 years later after you've
designed this secure architecture
and secure infrastructure to go back and--
why did we decide to do this?
the audit people are--
auditors, not audit people, the auditors
are requesting this specific information,
and we're not exactly sure why we did this.
So you go back to your reference material,
you go back to your documentation
from when you were doing the whole planning
and you have all your answers there.
You can also use this documentation
to help reinforce and build any policies that
are going to be written around this secure architecture.
Because you always need these policies,
definitely you need procedures as well
for how the environment should be built, what kind of security
controls should be in place, and exactly how to interact
and how to use those security controls.
And then change management programs.
Change management programs are there
to assist with anything that needs to be
changed in your environment.
Not just to assist with it, but also to document it
and to keep people accountable for the changes
they make in the environment.
So having the original design very well documented.
And even the planning process, very well documented
is going to help throughout the entire change management
process.
Not just after the fact 3, 4, or 5 years down the road
after the infrastructure's all built up,
but also the change management process and program
throughout the act of building the secure infrastructure.
Because you want to document and track all the changes.
You have what your plan is, but is your plan being modified
at all when you move forward and actually
into the real implementation steps?
So there's a lot that goes in with planning out
for how to design a secure architecture.
Budget considerations, documentation, and definitely
having a good inventory because again,
you can't protect your systems if you don't
know what your systems are.