Network History a Key to network success!
The task of knowing exactly what has happened on a network isn’t always easy, but perhaps even more perplexing to IT organizations is determining who is actually responsible for culling this crucial information. Particularly, should network recording and flow collector tools be operated by the security team or by the networking operations team?
The cop-out here would be to say, “It depends on the organization,” and then move on to the next question. After all, both network and security groups need to use network history data, and both groups generally have the right skills to operate network recording equipment. Additionally, you could find examples of successful deployments from both directions. So to say there is a concrete answer that fits each and every situation would be presumptuous, however there are pretty compelling arguments that suggest the network operations side should likely own the task. Let’s take a closer look.
In point of fact, there is a clear trend here: Network history is becoming a core network service, and as such, the best practice in most organizations is for it to be owned by the network operations group. Forward-looking network operations teams are keeping network history for their own purposes – to respond to difficult issues and understand network traffic patterns – and they are providing appropriate access to security teams and cooperating with them to deal with security incidents. From the security side, we see more and more teams expecting and demanding network history to be provided by the network itself and deploying their own network history equipment only when the network operations team absolutely can’t be convinced.
Why is this so? Here are a few of the reasons we have encountered:
- Network monitoring points are most commonly placed deep inside a corporate network – in data centers and at aggregation trunks. While security is relevant everywhere, most security groups still spend a lot of their energy on the network perimeter.
- In best-practice organizations, there is a standard design for monitoring and recording at each layer of network infrastructure. Every network infrastructure project– whether greenfield or upgrade– incorporates the company-standard monitoring and recording design that’s appropriate at that part of the network. Involving the security group in every such project is possible, but in many situations it adds overhead that’s difficult to justify.
Security teams are generally designed to import raw data but not to export it — and rightly so. Network operations teams generally have better processes for bidirectional sharing. Network history data are enormously valuable, and no one wants to incur the expense of collecting it twice, so sharing it across groups is nearly always the right answer.
There are two common counter-arguments we hear as well:
- Network history data – especially full packet captures— is so sensitive that only the security team can access them. This is a big topic, (one that deserves an article regarding best-practices on how organizations secure the data itself) but for now, let’s observe that network operations staff has access to an enormous amount of sensitive information already, so the addition of properly-managed network history generally doesn’t change your risk profile materially.
- The network operations team doesn’t have budget (in either money or time) to provide network history. We have certainly seen this scenario, and sometimes the only recourse for a security group is to take on the task themselves, and monitor the points in the network of greatest interest to them, either for the long term or until network operations sees the light. That being said, if the budget exists to make this the responsibility of the network operations team, it is likely the wisest move.
Again, this isn’t an attempt to diminish or question the skills of network security teams. Without question, the overall livelihood of any network is greatly dependent on their insight. However, assigning the task of tracking data history to the network operation side of the organization is likely the most prudent move for most organizations.
Spencer Greene joined Endace in October 2011 from Juniper Networks to head up Product Management and Marketing. He has more than 20 years’ experience in the computer networking industry and is widely regarded as both an expert in his field and a visionary.Spencer was originally the founder of Layer 5 networks which was sold to Juniper Networks in 1999. Between 1999 and 2011 he held a range of senior posts within Juniper including VP Product Management, VP Corporate Development and VP Junos OOPS. He is widely quoted in the industry, has a significant number of technology patents to his name, and is based in Silicon Valley, California.
Recent Comments