Documentation and configuration management can be a life saver when things go wrong. In this video, you’ll learn about network diagrams, baseline configurations, standard naming conventions, and more.
<< Previous Video: Security Teams Next: Protecting Data >>
One of the challenges with information technology is keeping up with all of the changes that are constantly occurring with your configurations. For example, you’re going to have new operating systems, patches to those operating systems, upgrades to applications, modifications to the network. And new applications are going to be installed all the time.
One of the primary goals for the information technology team is to document all of these updates and changes so that you have a way to look at where the configurations are for all of these systems. Whenever there are changes to the application, you have to modify and update the documentation that you’ve created for that application. With good documentation, you should be able to rebuild the entire application instance from the very beginning by only referring to the information you have in your documentation.
Part of the documentation you’ll create will be the network diagram. It’s important to know what devices are connected to other devices. And it’s also important to know where these devices may be physically located in the network. This might involve a map that shows what devices are connected to each other.
Or if you really want to get down to exact physical location, you could create a diagram of exactly what happens to be in a particular rack. And if you want to get detailed about where things may be connected, you may also want to include information about patch cables and patch panel locations so that you can identify and track exactly the path the wire takes from beginning to end.
In a data center, you can have equipment spread across many different racks. And they’re all connected to each other with wires that go under the floor. Make it very difficult to see when you’re looking at all of these systems. In this data center, someone has even documented what’s in an individual rack. You can see there is a picture diagram of the rack that has been created. And they have documentation there that explains exactly what’s on the inside of that particular rack.
Not only do we need to understand more about the way the network is designed, we also have to document the way the application is designed. So we’ll want to create a baseline of this application and understand the firewall settings, what patch levels are configured for the operating system and the application itself, what operating system version is in use to have this application work properly. And you may, of course, need to update this documentation any time any one of those components is updated.
To see if you’ve done all of this documentation properly, you’ll want to occasionally perform an integrity measurements check to see if all of the details in your documentation match what is running in that particular application. You should be able to check against these well-established baselines that you originally created. If you do happen to find a deviation from the previous baseline that was created, you need to understand exactly what the deviation is and what you may need to do to correct that.
It’s also good to have a standardized naming and numbering format for the devices and cables in your environment. That way, you can refer to those in a document or change control meeting. And everyone understands exactly where that equipment is located. This means that you can give a task to someone in a data center, and they’ll know exactly what rack to go to because you provided an exact asset tag, the name of the computer, a location, and perhaps even a serial number.
For network equipment, it’s good to have switches and routers that are clearly labeled and interface names and patch panel numbers on each one of those. It’s also a good idea to have a standardization for the usernames that are used in your environment and the email addresses that will be used in your email servers.
If we look at this picture of a data center again, you can see they’ve done extensive documentation. Each aisle has a letter associated with it. And each rack itself is labeled so that someone can cross-reference from information that’s provided to them in other documentation.
On the network interface or distribution panel side, you can find exactly what module is in use and the port numbers associated with those modules. And if we look at devices that are in the rack, we might find labels that are attached to those devices. Or in this case, there are tags that are physically attached to the devices with barcodes.
There might also be standardization for IP addressing in your organization so that you know exactly what addresses are used at which locations. This might allow you to create a standardization for the number of subnets that would be associated with a particular IP address range and the number of hosts that would be on that subnet, and then you might assign different IP ranges to different networks or different locations. And those locations can then subnet from there.
Some organizations will also reserve certain IP addresses so that on a particular subnet, you know that the dot 1 address is always the default gateway. Or you might have other reserved addresses for printers, routers, and other devices that are always going to be found on these subnets.