Many organisations are faced with challenges with regards to collecting events and logs, correlating these and setting up alerts to identify anomalous behaviour in networks. The issue is, what events should be monitored closely? What thresholds should be set in terms of alerting for these events? How do you tune these appropriately to get rid of network noise? These are all questions that organisations need to answer through careful observation, tuning and product purchase.
But firstly, and mostly importantly, organisations need to identify the types of risks that they are facing in order to know which types of events to look out for and which to take less interest in. Let’s take an example. Imagine you are a large company with a lot of employees. During your risk assessment you have identified that you have a significant risk from insiders, concluded from numerous attempts to breach information. Firstly, you would tighten up your HR policies to ensure that employees are appropriately vetted but also receive appropriate training. But this would not reduce the risk to your data.
One of your key controls in identifying anomalous behaviour is through audit and monitoring controls. Now if you take the example of the malicious insider, what events would be of interest to you as a company? Well, firstly I think you would want to monitor user account activity and alert any behaviour deemed as suspicious. Suspicious behaviour is going to vary from business to business but this usually constitutes mass data exfiltration, e.g. copying whole DB’s onto removable media or emailing mass amounts of records. However, this may also be business as usual for some companies.
The best way to approach this is to establish a baseline of expected behaviour and alert any activity that falls outside of this baseline, focusing on user accounts. So, for example, you may collect Windows event logs and alert any mass file transfer or dumps identified in the log. You may also alert when a user tries to modify these logs as this indicates anomalous behaviour and the attacker attempting to cover up. You should also consider monitoring boundary devices for large data transfers in case the attacker wishes to upload to dropboxes or email out themselves. Collecting these logs into a centralised SIEM will help with correlation and automatic alerts can be sent if thresholds are hit.
In conclusion, monitoring can be a tricky aspect in network security. But always start with the risks to enable a proportionate response. Aspects of the business that are low risk do not require as much monitoring and can be omitted if needs be. In contrast, high areas of risk should be afforded further granular monitoring controls. Do not hold logs for the sake of it (unless required to for DPA or compliance reasons). Tune the monitoring system so that it is as automated as possible.
Author Bio: Lee Hazell is an information security consultant and owner of Cyber security news, a cyber security news site that features information security articles and advice.