Securing the network

Disclaimer: the views expressed in this article are mine alone and do not reflect the views of my employer or fellow employees or management and are expressed because we live in the and of the free where speaking your mind usually doesn't result in beheading.

After many years of navigating the information security maze I have come to the conclusion that concentrating on event log correlation from servers, workstations and network equipment and alerting on these events is not the best path to securing the network and preventing security breaches. Indeed, I believe it's defunct and outdated and will eventually fade into oblivian.

Collecting the vast amounts of logs and sifting through them only tells you what has happened in the past, or more importantly, what each log source thinks has happened. It is implausible to think that each system on the network has been programmed with event triggers for every concievable event and if we know what triggers events and alerts, then hackers also know this and may e able to navigate around and avoid these triggers. Collecting all the logs at a central location and then attempting to write triggers is also a monument opus waste of resources, as the network and systems on it continue to be upgraded, replaced or decommissioned, the event triggers need ever increasing maintenance, and their complexity morphs to a point where they no longer perform their originally intended task.

Compliance and Audit requirements often require us to continue collecting and storing and reporting on log data, but we should not rely on this same process for securing the network in real time. It is in reality only useful for after action analysis once an incident has been identified and contained.

The only way to truly know what's happening on the network is to see the traffic on the wire in its raw form, before its received by target systems and interpreted into log data. Assuming that this is our goal then there are several guidelines which must e followed to be successful

1: Use multiple LAN taps or span ports to see the entire picture. If you try to watch your network with one span port then you are one big fool. To know what happening on the network we need a span port on he outside of the firewall to see what's trying to get into the network. if there are multiple Links to the internet, then each needs a span port. Another span port is needed between the dmz and the workstations to see he traffic between then. Another span port for your wireless network. Always remember, unlike  federal spending, more is better when it comes to span ports. BUT also avoid duplication.

2: Centrally collect and monitor data from each spam port. While historical data is nice, don't over do it and try to store months of data. You have event log archiving for that istorical stuff and while its not perfect, it will do nicely.

3: Select the best system you can get that meets the following criteria.

 - from a recognizes vendor who has been in this space for several years

- has a central dashboard with drill down access and does not need the analyst to switch do other screens / applications to trace an event.

- the vendor supplies event trigger updates at least weekly

- reporting is customizable so management and technical staff can get the reports they need.

- integrates with other industry recognized solutions using non proprietary communication vectors.

- vendor supplies support and is in you time zone, but preferably 24/7 support.

NetWitness is a great solution and I have used it so can test to its ease of use, intuitive interface and its interfac is lightening fast. Unfortunately it's been acquired by RSA so I'm not sure what will happen with that.

Trisul. (Trisul.org) is a much cheaper solution and worth investigating. I have used this and seen its value. And if you onl want to be able to look back 3 days, it is free.

4. Assign dedicated staff to monitor, maintain, and run the system. (A note to management - If you jerk your staff around from one tool to another and expect them to be masters of all they will end up being good at none and the only jerk will be you. Sorry to be blunt, but it is what it is)

Finally, when your watching all that traffic on your network, you will need policies, published, backed up and preached to all by the executive management in order to get the traction you need to tighten up your network security.

Disclaimer again. This article represents my views and not those of my employer, an agent or my 5 year old son Michael. No matter how much they may agree or disagree.

Thank you

S. Russell Dyer BS CISSP CRISC

Security Analyst and Network watcher for over 20 years.