[MUSIC PLAYING]
Just like everything else in IT and cybersecurity,
proper documentation is critically important
when we're talking about secure architecture design.
You have to be able to document your design in order
to be able to properly implement it, and then to kind of record
and keep those records of how it was designed
and how it was actually implemented.
So let's go over some basics of just why we
want a document and some methods for documentation
for our secure design.
So really, it's going to make your implementation much
easier, to begin with.
If everything is well-documented as far
as how the design is going to look,
what devices you're going to have, what IP addresses,
things like that, it makes everything much, much easier
to really implement and to put into place.
A lot of your documents will make this easier, especially
your network layout diagram--
say that one time--
and any associated configuration settings
that you may have set for things like network devices.
You can have all of that documented ahead
of time before you really start the implementation.
This also can help you map out who
is going to be responsible for implementation, who
is going to perform what steps, and what everyone's
responsibilities are.
Also, this documentation is really
used as a form of reference material as well.
Use it a lot of times as baselines,
especially going forward after the implementation is done,
comparing to make sure settings haven't been changed
where they shouldn't have been.
Make sure the environment is still
set up as securely as it was intended to be.
And it can also really help answer questions
you have about the architecture later on.
If you have new analysts come in that are curious about, oh, how
does this server talk to this server,
or what servers are isolated, or from what workstations,
and so forth, they can look at that documentation
easily and be able to interpret and see how the layout is done
and how everything was planned.
And also, this can really help with new additions
to the organization, fitting those puzzle pieces
in as you integrate new networks into yours, potentially.
Or the organization expands, and you
need to significantly expand the network.
It makes it easier having the existing documentation
to expand off of that than to have to start from scratch.
Another place that documentation-- doesn't matter
what sort of documentation it is, documentation will always
make audits easier.
For one thing, audits, a lot of times,
may require documentation of how your environment is
setup, of what your network looks like,
and things like that.
So a lot of times, your audits can require that.
And even if they don't require it,
having that documentation readily available
makes it a lot easier to answer questions
when being audited as well.
Now, one thing about documentation--
it is sensitive information.
You only need to grant access to people who need the access.
The documentation should be available
on a need-to-know basis.
This is using least privilege, the concept of least privilege.
Only people who need access to this data for their job
should have access to it.
Your architecture documentation is
going to contain sensitive information.
If you have it wide open so that anybody can get to it,
there's a greater chance that an attacker
is going to be able to get to it and be able to easily map
your entire network, including methods
they may be able to use to pivot around the network
and do lateral movement.
And just like everything else in secure architecture,
back up your documentation.
Make sure your documentation is secure
and that it is also backed up so that, if anything happens
to the production copy of it, you still have
copies of your documentation.
So what needs to be in the documentation?
The real answer to here is, as much as you can.
Anything that you think might need to be documented,
which is going to be everything, needs
to be in the documentation.
It's better to have more things documented than you actually
need.
But at a bare minimum, you should
have things like your network layout documented.
And this should lay out and show as a picture of how
the systems in your environment and in your infrastructure
fit together as a whole.
What devices can talk to what other devices as well?
That should be the basics of a network layout.
In addition, you need to add information
about what these devices are and what they do, such as things
like, what's their IP address, what subnet are they on,
what VLAN are they on, where are they logically located
in the network, in addition to, what's
the hostname of this device, how can I talk to this device
if I need to get to it, what's running on this machine
if this is a server, what's the purpose of this server,
including vendor information.
This vendor information can be things like the manufacturer
if it's a specific type of device, contact information
for that vendor or manufacturer, support information tied
to that, any warranty information that
is relevant to that device.
All of that should be documented.
And not all of this needs to be on a network layout.
This just needs to be documented in some form.
Whatever software that's installed
on there, whatever versions of that
software are available on that machine needs to be documented.
And documentation is very often a living document,
as things are updated and changed,
because it is normal for things to be updated and changed.
As they go through a proper change management process,
this documentation gets updated with the newer information.
In addition, you want to document,
what are the backups schedules for these machines?
Are these machines backed up?
If so, what data on them is backed up?
What is the backup schedule?
How often are they backed up?
Where are they backed up to?
Are these backups encrypted?
What are the steps to restore these backups if needed?
What is the tier of this system?
Is it a priority-one system that gets restored first?
Or can this wait in the event of a major system outage--
it's a lower priority system?
In addition, who's responsible for this machine?
Who is responsible for managing this machine or device?
And who is responsible for administrating this
or maintaining this device?
Those are two different things.
You oftentimes will have an IT person
that's in charge of maintaining the device, such as system
uptime and patches and things like that.
But you may have a member of a department who
is in charge of managing what is on a server,
such as the data, or the application, or so forth.
There's a couple of different ways
you can create this documentation.
Two very common methods I'm going to bring up.
There's countless actual methods,
but there's two common methods I want to discuss here.
First is going to be your network diagram.
This is going to show the logical connections
and locations for all network devices.
Now, "all" is a wide term.
Are you going to list out every single workstation
on your network diagram?
No, probably not.
Normally, this is going to be just your network devices,
but it can be other devices.
But at very, very least, you want
to have your network devices listed out
in your network diagram.
The name seems to imply that network devices would be there.
This is going to show a lot of information
about those network devices that we just discussed.
You may have your servers in there.
Now, you're not going to list out all of your servers
in a network diagram, because it gets a very busy-looking
at that point.
But you may want to at least indicate your server VLANs.
Now, you have your finance server VLAN, your sales server
VLAN, your administration server VLAN, things like that.
Any security controls that are present on your network--
do you have any network tap set up?
Is a specific port on a switch doing port mirroring?
Where is your IPS on your network?
Where are your firewalls on your network, things like that?
Your network diagram is going to show things
like network information, host information, the IP address,
subnet information, things like that for devices
that have static IP addresses.
If they have DHCP addresses, maybe you just
show what VLAN they're on in the network diagram.
You don't show the IP address, because it changes.
This can also include physical information
about where the device is really located,
such as what building it's located in, what wiring closet
it's in.
Is it in a data center?
Where is this physically located on your organization's
property?
Is this a cloud-based device?
That's important to as well.
And then you can also have an inventory database.
This is where you list out every asset in your environment.
Regardless of what it is, you need
to keep track of your assets because, like we keep saying,
if you don't know what's in your environment,
it's impossible to properly protect it and properly secure
it.
So you list out all your assets in your environment.
This is going to contain all the information about the system,
the hostname, the IP address, manufacturer, vendor, software,
patching information, you name it.
If it's important about that device,
it gets documented in the inventory database, or asset
management system, or whatever you're using for that purpose.
And also the department it belongs to--
who is responsible for this device?
What do they need to do with this device?
Who is responsible for maintaining the device?
That needs to be in the inventory management as well.
So let's take a look at a couple of network diagrams here.
This first one-- make a little bit bigger for you.
There we go.
This first one here shows a bit of a more generic network
diagram.
This is showing more of the layout itself of our network
and not the actual information about the devices.
So you see the general flow of traffic from the internet
onto the internal network.
You have the internet at the very top,
followed up by our perimeter firewall,
and then switches, and our publicly accessible servers
in the DMZ.
Another firewall that separates that out.
And then you see we have listed here our IPS,
so another security control, followed by our workstations
and servers.
Now, again, this does not list all the workstations
and all servers.
This is just listing the logical connections for these groups
of devices in this case.
Now, let's compare this to a more in-depth network diagram.
This one is showing much more specific information
about the internal network.
So you see on this layout, we have switch information,
the hostname of the switch.
So for example, that switch in the top left-hand corner,
you have WC12 that indicates that this switch is
located in Wiring Closet 12.
You have the IP address of the switch,
so this is the IP address you would need to reach
the management of this switch.
The next switch that it connects to,
you can see how it connects to and
the IP address of the other switch
and the hostname and its physical location as well.
Oftentimes, in these network diagrams,
you may also see specific port numbers indicated, especially
between switches or routers.
In addition, you've got the workstations
below that first switch that show
the hostname of the workstation, the department they belong to,
and the VLAN that these devices are located in.
So you have your administration workstation there.
It's located in VLAN300.
But then you have a sales workstation
that's located in VLAN201.
And then we have all of our servers
that are connected to the switches.
So you can see easily we have a domain controller
with its IP address.
We have a mail server with its IP address, a database server,
and a file server.
So you can see we have all of the information documented
so you could look at this diagram
and easily be able to tell what devices connect to what
other devices, and based on VLANs, what devices can talk
to other devices, and so forth.
So it gives you a good idea of how the devices are connected,
and even how to connect to the devices
since you have the IP addresses also.
Now, really quick, let's talk about a couple
of tools you can use to create some of these.
Some of these are going to be specific tools.
Some of them are more generic.
There's a countless number of tools,
including free tools you can find online to create these.
So we're going to go through this fairly quickly.
So for a network layout diagram, one
of the most common that you see being used,
at least that I have seen in the past, is Microsoft Visio.
So not a free product, but it is a very common one.
They do have good support for creating network diagrams
like this.
You can also use any sort of presentation, or slide
software, or anything like that.
You've got multiple free utilities online.
The first diagram I showed you that was just
the generic one without the IP address information--
I made that using a free utility online.
The second one that had all the additional information--
I made that using Google Slides.
So you can see there's all kinds of different utilities
you can use to be able to create these network layouts.
There are some pieces of software
that are specifically designed for creating
network maps like that as well.
So there's countless number programs.
One of the most useful things that I
have used when looking at network information
and documenting and architecture--
it's going to be a spreadsheet program.
Now, this may not be the final form of your documentation,
but it's great for documenting as you go
and potentially documenting out inventory information as you're
collecting new devices, and things like that.
Word processing software is great for any sort of policy
write-ups, anything-- there's an endless list
of what you can do with any kind of word processing software.
And then you have all of your managed inventory programs.
There is a countless number of programs
that can help you automatically manage your inventory.
They'll go out and scan the network,
see what's out there, and using different communication
protocols, will actually talk to these devices
and get the information about what software is installed,
what patch levels, who's using the machine, the IP
address, all kinds of information like that, who were
the last five users to log into it,
how much free space is available on the hard drive,
all kinds of information about these machines.
Two ones that I have used in the past--
and these are not endorsements or anything,
these are just two that I've used in the past and have
experience with--
are going to be SolarWinds and Lansweeper.
Those are both two--
well, SolarWinds, really-- those would
be two vendors that offer pieces of software that make inventory
management a lot easier.
Again, these are paid pieces of software.
But there are plenty of free open-source options
out there as well.
Some of them fit better for different needs than others.
But once you've narrowed down what you're looking for,
you can begin to create your list there.
So documentation-- extremely important
for secure architecture design, whether it's
network layouts, inventory management, or just kind
of keep track of the whole planning process
as you're going through and planning
your secure architecture.
Again, documentation-- very useful for audit purposes,
for research purposes.
Whatever phase you're working on in your secure architecture
and in your infrastructure design,
make sure you're carefully documenting everything as
much and as often as you can.