What do you think about when you hear the term network security? Chances are that the things that come to mind include firewalls, IDS/IPS, vulnerability scanners, and the like. What they all have in common is that each has a “security” function as a primary capability. All have their own clear role and are key components in a security infrastructure. In fact, they are so important that an entire industry of specialized security vendors and associated professionals has grown up around these products.
Within organizations, we see the same sort of specialization occurring with clearly defined and, unfortunately, often siloed security teams existing side by side with traditional engineering and operations teams. These segregations often extend into areas that have well understood dual roles in security and operations such as log and event management/analysis. For instance, it is not unusual to have logging from devices in the environment being collected both in a SIEM, for security analysis, and a separate log aggregation platform for operational use. In addition to extracting logs from the same physical and logical systems, these platforms often share similar, if not identical, mechanisms for the collection, storage, and even analysis and display of the log data. Yet separate teams are often responsible for the budget, planning, operations, and response to these two very similar systems.
Even more interesting are core network ser_vices and automation capabilities. They are often seen as being solely part of the operations world even though they have significant impacts on security. As such, security implications associated with them are, at best, not explored to their fullest, and, at worst, act as significant vulnerabilities for the organization. The reality is that because their primary functions are traditionally operations oriented, they have been largely dismissed in the security domain.
The importance of categories
This tendency to separate “security” from “operations” isn’t as odd as it may seem. As humans, we are hardwired to categorize things and our activity can subsequently be driven by these categorizations. It’s the same reason that we tend to recycle flat, full sheets of paper but throw out anything that is crumpled, torn, or cut up. We subconsciously categorize the flat sheets as “paper” that needs to be recycled while all the rest gets categorized as “trash” that needs to be thrown away. These categories, in our case security and operations, and their associated behavior can be modified but it requires awareness and conscious effort.
With that in mind, I think it’s worth while to talk about security that’s not security, at least not in the traditional sense. What I’m referring to are things such as network discovery, core network ser_vices (think DNS and NTP) and configuration management. Clearly these are not the first things that come to mind when someone brings up security, but they can be the Achilles heel of your network security infrastructure if you do not pay attention to them.
In what will be a collection of posts, I’m going to discuss a few of the core network ser_vices and procedures that are present in almost every network but do not always get the visibility and focus that they deserve to ensure that they do not contribute to security vulnerability in the network. We’ll kick the series off with a discussion of Network Discovery. Following this will be discussions of the Domain Name System, more commonly known as DNS, followed by a discussion of the security implications of running NTP/PTP (Network and Precision Time Protocols respectively), and finish up with a look at network configuration management.
Will this information fundamentally change the way you approach security? Probably not. But having an awareness of how these everyday network components and processes can impact network vulnerability may make you think twice about how you deal with them in future. Click here to read on with part two, Network Discovery!