How to reduce the cost of ownership of a SIEM system and why you need Central Log Management (CLM)
It looks creepy, but sometimes this architecture works in production. Complexity kills security, and generally kills everything. In fact, for such cases (I’m talking about lowering the cost of ownership) there is a whole class of systems – Central Log Management (CLM). About it writes Gartnerconsidering them underestimated. Here are their recommendations:
- Use CLM capabilities and tools when there are budget and personnel constraints, security monitoring requirements, and specific use case requirements.
- Implement CLM to extend the collection and analysis of logs when a SIEM solution is too expensive or complex.
- Invest in CLM tools with efficient storage, fast retrieval, and flexible visualization to improve security incident investigation / analysis and threat search support.
- Ensure that applicable factors and considerations are considered before implementing a CLM solution.
In this article, we’ll talk about the differences in licensing approaches, deal with CLM and talk about a specific system of this class – Quest InTrust… Details under the cut.
At the beginning of this article, I talked about a new approach to Splunk licensing. The types of licensing can be compared to the rates for car rental. Let’s say the CPU model is a fuel efficient car with unlimited mileage and gasoline. You can go anywhere without distance restrictions, but you cannot go very fast and therefore drive many kilometers a day. Data-based licensing is similar to a sports car with a pay-per-mileage model. You can famously pile on long distances, but you will have to pay more for exceeding the daily mileage limit.
To benefit from using load-based licensing, you need to have the smallest possible ratio of CPU cores to download GB of data. In practice, this means something like:
- The smallest possible number of requests to the loaded data.
- The smallest number of possible users of the solution.
- As simple and normalized data as possible (so that there is no need to spend CPU cycles on subsequent data processing and analysis).
The most problematic thing here is normalized data. If you want SIEM to be an aggregator of all the logs in an organization, it takes a lot of parsing and post-processing effort. Do not forget that you also need to think over an architecture that will not fall apart from the load, i.e. additional servers will be required, and therefore additional processors.
Volume licensing is based on the amount of data that is sent to the SIEM jaws. Additional data sources are punishable by the ruble (or other currency) and this makes you think about what you didn’t really want to collect. To trick this licensing model, you can bite the data before it is injected into the SIEM system. One example of such pre-injection normalization is Elastic Stack and some other commercial SIEMs.
As a result, we see that licensing for infrastructure is effective when you need to collect only certain data with minimal preprocessing, and licensing by volume will not allow you to collect everything at all. The search for an intermediate solution prompts the following criteria:
- Simplification of data aggregation and normalization.
- Filters noise and least important data.
- Providing analysis capabilities.
- Sending Filtered and Normalized Data to SIEM
As a result, targeted SIEM systems do not need to spend additional CPU power on processing and can benefit from identifying only the most important events without reducing visibility of what is happening.
Ideally, such a middleware solution should also provide real-time detection and response capabilities that can be used to mitigate potentially harmful actions and aggregate the entire flow of events into a convenient and easy-to-use SIEM quantum of data. Well, then SIEM can be used to create additional aggregations, correlations and notification processes.
That very mysterious intermediate solution is nothing more than the CLM that I mentioned at the beginning of the article. This is how Gartner sees it:
Now you can try to figure out how InTrust complies with the Gartner recommendations:
- Effective storage for the volumes and types of data that need to be stored.
- High search speed.
- Visualization capabilities are not something that basic CLM requires, but threat search is like a BI system for security and data analysis.
- Data enrichment to supplement the raw data with useful contextual data (like geolocation and others).
Quest InTrust uses its own storage system with up to 40: 1 data compression and high deduplication rates, which reduces storage overhead for CLM and SIEM systems.
IT Security Search console with google-like search
A specialized module with a web interface IT Security Search (ITSS) can connect to event data in the InTrust repository and provides a simple interface for searching for threats. The interface has been simplified to the point that it works like Google for event log data. ITSS uses timelines for query results, can combine and group event fields, and is effective in helping you find threats.
InTrust enriches Windows events with SIDs, file names, and SIDs. InTrust also normalizes events to a simple W6 schema (Who, What, Where, When, Whom, and Where From – who, what, where, when, who, and where from) so that data from different sources (native Windows events, Linux logs or syslog) could be seen in a single format and on a single search console.
InTrust supports real-time alerting, detection and response functions that can be used as an EDR-like system to minimize the damage caused by suspicious activity. Built-in security rules detect, but are not limited to, the following threats:
- Suspicious PowerShell activity, such as executing Mimikatz.
- Processes such as LokerGoga ransomware are suspicious.
- Encryption using CA4FS logs.
- Logins with a privileged account on workstations.
- Password guessing attacks.
- Suspicious use of local user groups.
Now I will show you some screenshots of InTrust itself so that I can get an impression of its capabilities.
Predefined filters to search for potential vulnerabilities
Example of a set of filters for collecting raw data
An example of using regular expressions to create a reaction to an event
PowerShell Vulnerability Search Rule Example
Built-in knowledge base with description of vulnerabilities
InTrust is a powerful tool that can be used both as a stand-alone solution and as part of a SIEM system, as I described above. Probably the main advantage of this solution is that you can start using it immediately after installation. InTrust has a large library of rules for detecting threats and reactions to them (for example, blocking a user).
In the article, I did not talk about boxed integrations. But right after installation, you can configure sending events to Splunk, IBM QRadar, Microfocus Arcsight or via a webhook to any other system. Below is an example of a Kibana interface with events from InTrust. Elastic Stack already has integration, and if you are using the free version of Elastic, InTrust can be used as a tool for detecting threats, performing proactive alerts and sending notifications.
Hopefully the article has given a minimal introduction to this product. We are ready to give InTrust to you for a test or to conduct a pilot project. The application can be left in feedback form on our website.
Read our other articles on information security:
Identifying an ransomware attack, gaining access to a domain controller and trying to resist these attacks
What can be useful from the logs of a Windows workstation (popular article)
Tracking the life cycle of users without pliers and tape
Who did it? We automate information security audit