Martin Roesch needed something quick and easy to look at data packets as they were going across the wire. In 1998, he created Snort, a free and Open Source Network Intrusion Detection System (NIDS) and Network Intrusion Prevention System (NIPS). Snort changed information security and given us visibility of real-time traffic in, out and around the networks.

In addition to network intrusion detection and prevention systems, there are next-generation firewalls, runtime analysis platforms, and web and mail content filters. With all this technology and ability to see into a network why are we not stopping security events from happening versus just detecting them?

I understand that balancing the confidentiality, availability and integrity triad is a delicate act, but I think it's time to start taking more action. I find it amazing with all that is available in the information security market today, organizations are still buying NIPS products and not installing them to block traffic.

They have no problems with their firewalls blocking thousands, if not millions of packets a day. If, however, they are asked to change a couple of NIPS rules for blocking, they freak out.

People have major concerns that legitimate traffic is going to be dropped. As an example, I asked a Chief Information Security Officer (CISO) why they did not want to go into blocking mode. She shared that they weren't comfortable with it because they feared something would get blocked that needed to go through. This would not be the case if the system is tuned properly. As with all tuning, there will be some legitimate traffic that is dropped but with log reviews, this can be detected and remediated.

All these platforms have the capability to detect and alert prior to moving into a blocking mode. With a well laid out security strategy, organizations can efficiently move from detection to blocking. Of course, availability means money and for many organizations, allocating more funds for a security budget can be challenging.

The strategy should involve installing an NIPS in-line from the get-go. It allows your organization to have the visibility required to detect anomalous traffic and alerts. Over several months, the device should be tuned so that it does not alert on legitimate business traffic. You should still be getting alerts for traffic that cannot be explained or are intrusion attempts.

Focus on a few rules to put the device into blocking mode. Pull trends for these rules, review investigation notes for the alerts that happened in the past, and investigate top sources and destinations for these rules.

After reviewing this data, ensure you have the appropriate exceptions in place. When creating an exception, be as specific as possible. For example, you do not want to disregard all traffic from an entire /16 netblock, when only one or two addresses need to be ignored. If your exceptions are too broad, you will lose visibility of anomalous traffic that requires investigation. Continue to monitor traffic and alerts for several weeks to ensure you have created your exceptions properly and alerts are only generating bad activity that require further investigation. If possible, generate traffic that you know will cause an alert to ensure your exceptions are not too broad.

You should now have fairly high confidence rating that all your exceptions are in place and only receiving alerts on malicious traffic. Flip that switch and block something. Start taking action on those malicious packets and drop them.

You can continue this process to focus on more and more rules. Many vendors include focused rules that have a very low false-positive rate. These should be monitored and put into blocking mode, but don't be afraid to customize the rules if you can make them more effective.

Now that you're in blocking mode, there is less likelihood that you will need to tell the board of directors or the CISO that there was an intrusion and that it costs a large amount of money to clean up. Instead, you can give them a report of all the threats that attempted to gain access to your systems and were stopped.

I would much rather tell someone that we prevented an intrusion from happening, than tell them that we detected an intrusion and had to spend several hours and dollars cleaning it up.

Wouldn’t you?