Your Data Zen starts here.

Spying on the hackers 1 – SIEM tool

Lets spy on malicious hackers! In this post I will reveal the structure of a SIEM, Security Information and Events Management tool.
For this study, I have constructed real – life dataset.
Its complexity depicts middle size global company. Data in this mock-up are constructed as it was collected in all continents and processed in the middle Europe.

Article has two parts. First is dedicated to using of SIEM. Second part s oriented more to maintenance of SIEM itself, which is necessary part of our model Security Operation Center. {SOC}

Part I: Using of SIEM

WHAT does it do: SIEM tools can be anchors of the enterprise security. It gathers information collected within whole infrastructure and parses the information to reveal hidden activity, such as data leaks, malware breakthroughs, botnet activity and last but not least spying of competition and intelligence agencies, too.

HOW does SIEM collect information- by collection of logs from:

  • Firewalls
  • Intrusion detection and intrusion prevention systems
  • Load balancers
  • Database servers {SAP, Oracle, MySQL, }
  • Active Directory’ s domain controllers
  • Antivirus solutions
  • Smart card devices
  • Web application firewalls
  • DNS and DHCP servers, Switches, Routers, Proxies
  • Apache, IIS and other web servers
  • Microsoft System Center Configuration Manager {SCCM}
  • Threat intelligence feeds and workstation probes
  • Hypervizors for virtual hosts and server farms
  • … and basically anything else what is capable of sending logs in certain manner to the SIEM log collector.

Main components of SIEM tool deployment:
{I took into consideration the known structure of the SPLUNK and QRadar, two leading SIEM solutions on the market}

  1. A log source: Source of the information fed in form of so called logs.
  2. A log collector: Network device serving the purpose of collecting the logs, deduplicating the information and basic normalization of the field names.
  3. A log indexer / processing unit: Parses the information collected. Dimension reduction happens here as well as very detailed categorization and rules evaluation.
  4. A search head / console. Purpose of this is to control all the subsequent devices in SIEM deployment. Serves also as web server to enable security personnel use the data accessed via web application.

On picture below, there is raw structure of the SIEM tool with connected log sources.  Blue nodes are the log collectors, connected to the console in the center. Each edge stands for one source of the logs.

WHAT does it do with all the logs:

SIEM tool uses predefined rules to parse the information in the logs, based on the source of information such as IP, device and the timestamp and correlates this information in order to trigger predefined alerts.

These alerts are followed up by either IT Security analyst or other security personnel. If needed information gathered by SIEM might even involve in lawsuit.

Picture below shows the complexity of the rules in SIEM.
I have used average rules count from various security SIEM studies to generate approximate structure.

Should this picture hold the real data from some company, it would be the ultimate golden ticket for all malicious hackers trying to get in!

Explanation :
WHITE – edges – links between the rules. This shows whole logic of security built into the SIEM.
Thinner the edge, the more specific it is and catches for example only one specific malware mutation.
Thicker the edge, the more connected it is to other rules, providing complex logic as for data leaks, botnet activity and behavioral analysis and heuristic rules in general. Also, breaking one of these would significantly damage the monitoring capabilities of the SIEM itself.

RED lines  – node labels – are hypothetical rule structures depicted as regular expressions. This information is machine readable and with a bit of deep learning, this could help to generate attacks which would not be detected. Longer the red line, the more specific and compler regular expression it poses for.

I find this picture fascinating for following reason.
White color poses the known attacks, rules defined to protect the Security perimeter of a company. It is usually static, defined by experienced IT Security specialist and as a reactive activity to real world threats. What is caught here, enters the Incident Management Process.
Red color stands for actual structure of each rule itself. The one who knows it, holds the keys to company security at once.  Attack on this structure would make the company IT blind.
Black color stands for all undetected, not recognized by SIEM and other devices on security perimeter. Zero -day exploits, new malware, the best of Black Hats and much more stands here.

The “black” area is actually the reason, why every security measure can be compromised, every company can be hacked. The ultimate race between White hat hackers and Black Hats lies in the “Black”, out of the borders or “White” area of the picture.
This is the reason, why it is more than necessary to always act like the system was hacked already. To think all the time, what would be the malicious hackers after, if they were already “in”.
Reason why keeping anything secure is never ending battle with the law of probability and time. It requires the really serious learning from the “Team blue” to keep the company secure.

PART II: SIEM Maintenance activity.

In order for SIEM to be still on top of the various threats, it has to be maintained.

Areas of interest:

  • Rules creation, operation and decommission
  • Log source lifecycle

SIEM deployment devices administration

Following visualizations includes the same information as the structure above. It means log source – collectors – processors and the management console.
Additionaly, log sources were grouped also by the level of verbosity.  Some of the monitored devices are sending only simple information in the log. This is typically Unix base devices. Microsoft Windows log are on the other hand full of information. Sometimes too full:)
Rarely used switch device can send only couple of logs per month and on contrary DNS/DHCP device or the Proxies are sending from tens of thousands up to millions of logs every day.
Therefore it is necessary to weight the log source for maintenance purpose based on its expected verbosity.

Verbosity is in my study represented by value “Events per second” {EPS}. This means, how many event the device is sending each second. It value changes from 1-10 up to 4000 for really verbose sources.

First picture shows the same SIEM structure used above in PART I, only the EPS layer was added.
Blue color is for log sources, grouped by EPS.
Violet stands for SIEM deployment devices such as log collectors and indexers.
Red lines is connection between log collectors, indexers and management console.
Disruption on this layer would have catastrophic consequence on system stability and efficiency.

To provide overall structure information, above picture was re-sampled and visualized differently while it holds same information. Only, the secondary structures with EPS grouping is more visible.

In each so called “flower” there is group if devices which is sending data with same verbosity, from same location and to the same log collector.

Additionally, using the node labels I have visualized the information flow.
Note the length of the labels, suggested via the decimal logarithm value of EPS the verbosity of each device.

Circle around the central structure shows a “noise”.  Source of the noise are all the devices, which are not fully recognized by the SIEM but information from them is somewhat collected anyways.

Noise area is very interesting place for all malicious activity.
Either it can hide malicious activity, or even worse it can influence directly the functionality of the SIEM itself. As the traffic is coming from not well known sources it is very hard to monitor it and even block it.
Thus, DOS attack can be driven from here. Alternativelly, intelligence agency could spy on the SIEM from here without risking of the compromise. Malicious hackers could plant SQLi or XSS attacks to either block SIEM from viewing the alerts or to event selectively mask malicious activity.
Also, by causing flood of “false possitive” alerts the attacker could make the SIEM operators busy and lower the level of attention.


Below is the “noise” area showed even better:
{By removing labels from legit log sources, only the unknown ones remains highlighted}

It is daily task of SIEM maintenance team, to monitor the noise area with best effort and do maximum to prevent above mentioned attacks on the SIEM platform itself.

For comparison, below is the same picture with removed noise area. This would be the ideal situation in which whole company IT infrastructure was onboarded to SIEM monitoring.


  • If you are Security Analyst, always keep in mind that SIEM tool is just as smart as people who are using it and evolving it continuously.
  • If you are IT Security manager, mind the fact that regardless SIEM is priceless aid in Security Monitoring and Log management, it is necessary to use it with knowledge of its limitation. Development of security personnel as well as SIEM tool must never stop!
  • If you are company providing SIEM tool, be honest to your clients. Do not hide the fact that having a SIEM is not ultimate solution to all security issues which might happen to them.
  • Last but not least, if you are the company using SIEM tool, consider its flaws. Do not rely relentlessly on your SIEM. On the other hand, it is invaluable for actually resolving of security incidents and also to keep you compliant with all those regulations.




Next Post

Previous Post

© 2020 4n6strider

Theme by Anders Norén