The foundation of good network security is understanding what makes up your environment, where it’s located, what it does, and why it’s there. In essence, the Five W’s (Who, What, When, Where, and Why) play a critical role in understanding and safeguarding your enterprise. Various types of documentation allow us to capture this information and share it with others within our organization. Having this information enables us to respond quickly to operational issues, make strategic architecture decisions, identify and mitigate potential vulnerabilities, as well as provide context and background to those who are new to an organization.
We’re going to look at some of the many types of documentation that should be utilized within your environment. The proper amount and specific formats are going to differ depending on the scope, as well as guidelines and requirements that are specific to your organization or industry. The main types we will cover are diagrams, inventory lists, IP/hostname lists, data flows, PPP’s (plans, policies, and procedures), and configurations.
Diagrams
I’m a Microsoft Visio guy. I’ve always enjoyed putting together network/system architecture diagrams. I realize that I am in the minority who enjoy doing so. Diagrams can be tedious to create and even more so to maintain. However, one of the first questions that new engineers/administrators ask (as well as auditors) is do you have any diagrams I can review. This type of information is critical to gaining an understanding of any IT system. In my mind, there are a few different types of diagrams that you should have depending on the size and scope of your environment.
High Level Diagrams
High level diagrams provide a non-technical overhead perspective of the environment. If you are at all familiar with DoDAF (Department of Defense Architecture Framework), this would be like your OV-1 diagram. These should tell a high level story and be easily explainable to someone who is new/and or non-technical.
Network Level Diagrams
Network level diagrams show logical connectivity between all nodes/devices in the environment. When doing these diagrams, I like to include the IP and Hostname of the devices being shown. Other details to include in these is VLAN information, system/authorization boundaries, as well as any unique information that might make sense to overlay on the diagram. For instance, I like to take a base-level network diagram and overlay unique security controls in callout boxes. This in turn makes a useful infosec diagram identifying and explaining security attributes at key locations to share with auditors or approval authorities.
Physical Network Connection Diagrams
Sometimes it is necessary to document where all the physical connections are going for a given system. This is especially important when you need to get some type of approval or accreditation of your system. I’m one who believes this is better suited in a spreadsheet (It also makes labeling cables in a data center 100 times easier.). However, you might run into a situation where there is a specific requirement for putting that information into a diagram. This is probably one of the harder diagrams to put together specifically if the environment is large and has a lot of components with connections. Likewise, it is difficult to maintain from a configuration management perspective.
Service Level Diagrams
Sometimes, a specific deep dive is needed on a particular service you have in your network. For instance, maybe you have an application service that is opened up to an user on the Internet. It would be good to document the service flow of this service both for engineering and infosec personnel. In this case, I would utilize a diagram showing the full logical connectivity and data flow from a potential user on the Internet, through the premise equipment into the organization’s DMZ, terminating on a proxy/load balancer, and then connecting to an internal application server which has a connection to a back-end database. Laying this out so you can see the data flows between each segment can help identify potential service and security impacts. Often times, diagrams like these are required in organizations that have change review board (CRB.)
Inventory Lists
Knowing what assets you have in your environment is key to understanding what you need to do to protect it. Ideally you should be aware of all physical and virtual devices, circuits (Internet or private), and software. There are tools that can be used to scan for both devices and software. Some of these are vulnerability scanners, like Tenable’s Nessus scanner, others might be monitoring tools using SNMP or other protocols to gather information about hosts on your network.
Automation will help you out here a lot, especially in larger environments, where things continue to grow and change through the normal interactions in an environment’s lifecycle. However, if you can’t afford the tools to do that, at least attempt to keep a manual list of devices and software/licenses. Equally important is documenting support coverage (warranties) and contact information for each of your vendors. Having it at hand is helpful, as it can be frustrating to track it down in the middle of a service-impacting incident when you need it the most.
IP/Hostname Lists
IP address and hostname information is absolutely critical to managing an ongoing engineering effort, maintaining proper security controls, and enabling optimized troubleshooting. If you don’t keep this information accessible, it can cause a lot of problems when trying to deploy new devices/services (IP conflicts/wrong VLAN assignments/DNS record issues.) I like to break down my IP documentation into two different tabs in a spreadsheet (yes, I use automated tools to verify information, but I like to maintain an authoritative document that is maintained off of the system.)
The first tab is used for the overarching network address space and VLAN assignments.
| Name/Description | VLAN | Subnet |
| Domain Controllers | 25 | 10.0.1.0/24 |
| Email Servers | 26 | 10.0.2.0/24 |
| Workstations | 27 | 10.0.3.0/24 |
| Network Devices | 28 | 10.0.4.0/24 |
| … | … | … |
| External Public Subnet | 8.8.8.0/24 |
The second tab is used for breaking down the specifics of each individual VLAN/Subnet and the hosts in each.
Data Flows
Data flows are another important type of documentation to understand. However, most organizations don’t do a very good job of tracking what should be known and allowed communications. In large environments, if this is not tackled from the beginning, it will spiral out of control quickly. It’s also easy to fall into the trap of supporting rapid deployment of applications with no one really knowing what ports and protocols are needed to allow the proper communications.
I see data flows as the documentation of any communications paths between hosts. These should include all of the required ports and protocol information, such as internal/external communication, inter-VLAN communication, and intra-VLAN communication (which organizations often times do not limit, control, or monitor).
Since I’ve already documented IP addresses/hostnames (in a separate tab of the same spreadsheet), I don’t need to be as specific in the data flows section. I’ll normally use just hostname, logical groupings of hostnames, or a name associating all devices in the VLAN. This makes it much easier when adding new devices of the same type that will be using the same rules/ data flows. I only then need to update the IP list and not the data flows. When documenting all of these rules, I like to keep track of data flows from a VLAN (or security zone perspective). I’ll document intra-VLAN rules first for a particular VLAN followed by the inter-VLAN rules for that same VLAN. I like to do this by identifying the source device, destination device, protocol, port, and reason for the rule, as seen below.
Plans, Policies, Procedures
Plans, policies, and procedures can be overwhelming and probably the least favorite documentation to write of most engineers. There are a multitude of requirement drivers behind these, both for functionally usable documents or strictly compliance driven. This comes down to understanding the audience of your documents. It helps to start from an understanding of what documents you need in your environment. Even going through the exercise of creating documents you may not think you need, might bring about some ideas or areas that do need to be addressed.
If you have policies derived from governance requirements, then you need to follow the formats and specifications that must be met. If you get to (or need to) start from scratch, I’m pretty comfortable in recommending the NIST 800-53 Security Controls Traceability Matrix (SCTM) as a solid starting point to determine the policies and procedures that may be applicable to your environment. The matrix is broken down into various control families- each family with their own requirements for various policies and procedures. However, once implementing other technical controls in the matrix, you will derive further documents that need to be created. It’s also good to understand that not all of these control families are IT related (i.e. only write documents that fall in your area of responsibility), but there is overlap with all of them with IT systems in some way, to include:
- Access Control
- Audit and Accountability
- Awareness and Training
- Configuration Management
- Contingency Planning
- Identification and Authentication
- Incident Response
- Maintenance
- Media Protection
- Personnel Security
- Physical and Environmental Protection
- Planning
- Program Management
- Risk Assessment
- Security Assessment and Authorization
- System and Communications Protection
- System and Information Integrity
- System and Services Acquisition
A fun aside note, when talking about the SCTM, I like to do it in the vocal styling of Christopher Walken… “the S…C…TM”
Configurations
Some people may not see configurations as documentation, but in reality they are the best exhibit about the operational statue of your systems and devices. From my perspective, there are three main things you want to ensure with your configurations.
First, you need to ensure you are backing them up properly. There needs to be a process (hopefully automated) that ensures you are not left scratching your head in the event of a device failure. Also, it’s important you establish baseline configurations for your environment. You do this by securing and configuring all devices according to a guideline (NIST, DISA STIG, CIS, etc…) This helps you avoid any existing configuration deviations from the standard in place. Additionally, knowing the expected baseline supports identifying potential risks that need mitigations put in place.
Lastly, you need to implement some type of monitoring of these configurations from a compliance and change management perspective. You want to ensure changes are documented and approved by an authorized individual.
The Documentation Wrap-Up
There’s a lot to the documentation covered here. The main takeaway that I would preach to folks is: start these as early in the system lifecycle as possible. It is very painful to jump into a system that has no documentation. If you are able to start working on these from the beginning, you can establish your templates and ensure that these various documents are updated accordingly over time. I can’t tell you how many hours have been lost to engineers trying to recreate needed documents because there wasn’t a properly implemented process (or existing at all) to aid collecting supporting (and sometimes regulatory required) documentation.
Here are some decent references to some of the topics discussed above:
- https://en.wikipedia.org/wiki/Department_of_Defense_Architecture_Framework#Operational_Viewpoint_(OV)
- https://www.cisecurity.org/
- https://public.cyber.mil/stigs/
- https://nvd.nist.gov/800-53
Next in the six-part series on the basic network security principles (The Fab Five), we’ll be discussing Network Segmentation and Isolation.
Find out more about J.B.C.’s Cyber&Sight™ blog here.