When we deal with configuration management,
it's focusing on maintaining an up-to-date documentation
of our network configuration.
Now, I can't count the number
of times I've gone into a network
to conduct an incident response
and asked to see their diagrams and their diagrams
look nothing like what the real network looks like.
In your network,
you need to have a lot of different procedures
to make things run,
and these will include things like asset management,
baselining, cable management,
and network documentation, updating.
Now, having all these policies together,
you can maintain a good configuration management
over your network,
but if you don't know what your network looks like,
hopefully the bad guys don't either,
because if they do, they're going to be way ahead of you
as you're trying to conduct that incident response,
and you really don't want that to happen, right?
So when we look at asset management,
this becomes a formalized system
of tracking your network components
and managing the components lifecycle.
Now, you need to prepare
and budget for all these different items in your network,
and this means you have to gather all the requirements
so you know what you're going to be buying
and when you're going to be buying it.
Then you need to plan
and determine what components you're going to buy
and when you're going to buy those things.
This is all part of your network design.
You need to determine the best configuration
for all of these different devices.
You need to implement it by installing it and purchasing it
and configuring it and putting it into your network,
into operations.
You need to operate and maintain it,
and that way people can actually use your network
on a daily basis and you need to provide support to it.
Again, this is where you're going to spend 70%
of your time operations and maintenance,
so you need to optimize it.
You want to make sure it runs smoothly,
efficiently, and reliably.
And to do this, you need to improve the network design
by implementing new devices over time
or reconfiguring the ones you already have.
All of this fits inside of the world of asset management.
Now, the next thing you need
to do is you need to create a baseline.
So this is going to have you install the entire network
and then collect data under normal conditions.
This becomes your baseline.
It becomes really useful because if there's an incident
or you're trying to troubleshoot something, you can go,
well, this is what normal looks like
and this is what it looks like now.
Now what's the difference between these two?
That's the thing that's wrong and we need to go fix it.
And so if you don't know what normal looks like ahead
of time, you're never going to know what abnormal is
because it doesn't look any different to you
because you didn't know what normal was,
and this is why creating a baseline is really important
to your troubleshooting efforts.
Next, we have the concept of cable management.
This is the process of documenting
your network's entire cable infrastructure.
That's going to include things like your diagrams,
how you label your cables,
where you use your punch down blocks,
and where they're located,
the source of all your different cable locations
and which closets they're in,
and the destinations of all your cable
as it goes throughout the building.
This is an example of good cable management.
You can clearly see each cable coming
out and going into the run on the left.
You can then see how each cable has been labeled.
Each router and switch here has been labeled as well.
Now we understand which one is which.
This is extremely important when you're dealing
with large environments.
If you're dealing with a small network, like a small office
where you have one router and one switch,
and it'd be 10 computers, yeah,
cable management isn't nearly as important
because you can just hand over hand
and trace where that cable goes and figure it out.
It wouldn't be too difficult.
Now, if you're doing this in a large network
with hundreds of thousands
or tens of thousands of devices on it,
you really need to understand where all those devices are
and label every single piece appropriately.
Now, when you label things, how should you do it?
Well, I recommend using a standard naming convention.
For example, if it's in the HR department,
I would have it labeled as HR_ D_RM102_ 0012.
Now, what does that tell me?
This tells me it's in the HR department,
it's a desktop machine, it's in room 102,
and it's the 12th connection inside of that switch.
This gives me a lot of information just seeing
how that's labeled, and by using
that standard naming convention,
I can do that throughout the entire building.
And so if I go look in IT, for instance,
I would see something that says IT_L_RM205_0004,
which would be the IT department.
It's a laptop, it's in room 205,
and it's the fourth device.
This is a common way of doing your numbering by having it
as a building or department number, a room number,
and then a device number.
Giving it this unique serial ID
for every single device is essentially
what we're doing here by doing this cabling.
If it's a switch, I might have an S in it.
If it's a router, I might have an R in it.
It's a firewall, I might have an F in it.
You get the idea.
You can use whatever system you want,
but you just need to make sure you label everything
and make sure your diagrams are updated
and you understand what that scheme is.
Next, we have network documentation.
As I've already been saying, it's really important
to keep your network documented
and keeping it updated appropriately.
You have to keep these things up to date
because changes occur when I update a new machine
that changes the network, and that changes the topology
and the vulnerabilities that we have.
And so I want to make sure I document it.
Now by documenting it,
that means we all understand that change was made.
This is going to include all sorts of things
beyond your normal diagrams as well.
Even though we're going to have things like our diagrams
that get updated and our wiring schematics also need
to make sure we have things like our contact information
for our network administrators.
Who do I call when something goes wrong?
I need to have that inside my policies.
And when I think about those policies,
what are those policies that govern my network?
I need to have my network maps.
I need to have my diagrams.
I need to have my policies,
and I need to know where all that documentation is.
Part of that will also be my vendors.
Who do I call when something breaks?
Is that router or switch still under warranty?
All this stuff becomes part of your documentation,
and if I have all of those things together,
I have my wiring schematics and my network diagrams
and my standard operating procedures and my instructions
and my warranties, I know where it all is
in times when I need to get it quickly
and I can go pull that off the shelf, look at it
and get the answers I need.
Now, let's say I wanted to upgrade a switch.
How am I going to do that?
Well, most companies are going to have a procedure for that.
If I have a procedure for that, that's going to be helpful
to whatever junior technician is on duty
that night at midnight
and has to upgrade that switch for us
because something went wrong.
Now we can take the time upfront
to put all this together and document it
and put it in a big binder or a share drive
or a SharePoint site or something like that.
Whatever we're going to use as our knowledge base,
we need to make sure we know where it is
and our technicians need to know where it is as well.
Because without being able to put our hands on it
and know exactly where it is, it doesn't do us much good.