Although not a new concept, I thought I’d remind people of the benefits of sending your security, system, and application logs across a segregated network to maintain availability. Consider the following scenario:

Your network is experiencing a horrible worm outbreak that is eating up critical bandwidth as it attempts to spread from host to host. All of this malicious traffic is causing your firewalls, intrusion systems, routers, switches, and servers to feverishly log every worm related event they possibly can. The corporate security policy dictates that all event logs are to be sent to a log management server so that no logs are lost.

This remote logging, although small when you consider the size of an individual log (A UDP syslog packet cannot exceed 1024 bytes), does impact available network bandwidth. This is especially true if thousands of logs per second are being transported to a log management or log storage solution through the same path as your regular traffic (1000 logs per second X 1024 bytes = 1,024,000 additional bytes per second — worst case of course). Similarly, a Denial of Service (DoS) or Distributed Denial of Service (DDoS) could also adversely impact the rate at which regular data, and associated logged events, flows through your network infrastructure.

You could investigate implementing QoS rules for your logs on your existing network but all this does is dedicate already sparse network resources to your logging traffic. This is a good solution if your main concern is the availability of your logs but it does nothing to help reserve bandwidth for your network traffic during the outbreak.

If you designate a separate and distinct network segment for the transmission of your logs, you can keep your critical network bandwidth available for regular operation while you mitigate the outbreak. This can be as simple as configuring an additional interface on your device for logging or as complex as creating distinct VLANs for the logging traffic (which, in all honesty, isn’t all that complex a task). Although this is a great solution for maintaining the availability of both your network traffic and your logging traffic, there is an associated infrastructure cost (switches, network interfaces, rack space, power, administration overhead, etc.). Hopefully you can see how this short-term investment will pay off in the long term.

I haven’t discussed the business case for segregating your logging for security reasons but I will in a future article. Segregating your logging for availability, however, is definitely something to think about when you’re planning your logging infrastructure 🙂