Baseline implementation for threat identification

Why security tools are needed? The general answer is that “They easily identify the suspicious traffic / activities and generate automatic alerts”. But who defines which traffic is normal and which traffic is suspicious? The process of identifying the nature of the traffic is  crucial for effective security tool implementation. No security tool works out of the box and starts generating meaningful alerts. Also, there are no universal set of rules which can be applied to all networks. The security analyst needs to collect input from various event sources and analyze it to identify normal nature of the network. Then a benchmark should be set which defines the nature of the traffic. All the rules and alerts should be created by using this benchmark as the baseline.
Let’s consider one scenario. One of the most common and meaningful alert which is used for SIEM (security incident and event management) is “No. of event logs generated per sec”. If there is a sudden spike in the number of events generated from a particular log source, then this can be considered as a suspicious event and should be investigated. But does this mean that every spike on the dashboard is suspicious or if the spike is not there, can it be considered as safe? The answer is “No”.
Figure: Illustration of event per sec graph
The above spike and variations in the graph for events per second need not be a suspicious activity. There might be some scheduled activity which is taking place on every weekend or any particular day, which might be spiking the events per second from that device. Therefore, multiple graphs with same time period need to be pulled out from the system for multiple weeks and see the nature of the graph which is generated. If the spikes are similar every week, then it is a normal traffic. Thus baselining helps analysts to segregate the normal traffic from a suspicious one. At first, the baseline should be defined and then security analyst needs to operate using the defined baseline. The baseline should be defined in SOP document or Runbook. For example,
  • How shall the normal dashboard look like?
  • What is the expected shape of the graph?
It is not only the shape of the graph that matters, but security analyst should also monitor the values plotted in X and Y axis. What are the normal average values which commonly appears in X axis and Y axis? Since the tool is automatically plotting the graph with the help of the inputs received from the logs, there are chances that the range of values in X-axis and Y-axis will differ and no visible spikes will be there in the dashboard. The graph shape might look normal, but actually, the values might be something completely different.
The above scenario is an example quoted for only one common rule. Similarly, for all the rules baselining should be performed and fine-tuned as per infrastructure to generate meaningful alerts. The initial effort being put on baseline will help reduce the workload to a greater extent at later stages. 
Authored by Yadukrishnan J S
TCS Enterprise Security and Risk Management
Rate this article: 
Average: 1 (3 votes)
Article category: