In my previous blog, I talked about the value of having a cyber incident response plan. An important factor in a plan like this is having complete visibility into the traffic that is coming across your network. As I mentioned in my previous post, using flow technologies like NetFlow and IPFIX is an effective way of providing this type of visibility. The truth is that when an incident occurs, having that level of detail is absolutely required, but what about the other 90% of your network monitoring time? How can you monitor for specific events?
Out of the box, our incident response system comes with the Flow Analytics engine, which allows you to monitor for traffic abnormalities like DDOS attacks, SYN floods and more, but the appliance can also help you exceed your compliance obligations. How? By saving 100% of the data for as long as you need it to and by providing the ability to customize your monitoring to meet the needs of your specific requirements. As part one of this series suggested, our cyber attack incident response system can help you be vigilant.
“No IRP will be effective without the ability to accurately detect and assess events and possible incidents. Typically, this requires a continuously changing array of both software and hardware necessary to detect incidents from a variety of threat vectors. “ – Harvard Law School Forum on Corporate Governance and Financial Regulations
So how is this done? Let me give you a real-world scenario where something like the above is applied. I was working with a local school system and one of their compliance requirements was to monitor for external communication activity with the student records server. The requirements were two-fold. First, they needed to monitor the traffic and be alerted if anything outside of the scope of allowed IP’s was communicating with the records server. Second, they needed to be able to prove they were, in fact, monitoring if/when an audit occurs.
Build monitors from your own reports.
In this scenario, we selected the router and interface that the server was connected to. First, I added the IP Range filter from the filter drop down. Next, I added the IP Range that was allowed to communicate on this interface; I could also create an IP Group and filter on that. IP groups give us a little more flexibility in deciding what IPs are part of the group. At this point, if I applied the filter, I would be shown all the traffic to and from the IP’s that are allowed to communicate with that device. If you click the small green plus sign, and turn it to red, you are going to exclude those IP’s. If your ACLs are working correctly, you will receive a blank report.
Turning this report into a monitoring tool is simple. Just go back to the filter list and add the thresholds filter. Make sure that you have selected “Last five minutes” under the custom time frame option and save the report. That report will now run every five minutes; if that threshold is met, then an alarm will go off. In this case, if an IP outside of the allowed range is seen, you are altered.
Build a gadget from your own reports.
Now that we have built a monitoring tool, we need to have one location where we can see the information when we log into Scrutinizer. This is where the functionality of the Dashboard becomes an asset. To do this, just click on the Dashboards icon in the menu, then choose what Dashboard view you want it to be placed on. Now when something happens, you will be able to go to one place and get the information that you need to resolve the issue.
Not only are you able to monitor for the abnormality in your traffic (as required by your compliance rules), but you are also able to prove that you are monitoring. Both of these requirements can be costly if not met. First and foremost, you can use Scrutinizer’s historical reporting to show traffic over a given amount of time. Remember, we can save all the records for as long you are required. Second, you can filter for that rule under the alarms tab to show what incidents have occurred and then report on their resolution (as per your IRP).
In part 3 of my Cyber Incident Response Plan series we will talk about how to use Flow Analytics to monitor for network traffic anomalies.