Not so long ago, Splunk added another licensing model - infrastructure-based licensing (). They count the number of CPU cores under Splunk servers. Very reminiscent of Elastic Stack licensing, they count the number of Elasticsearch nodes. SIEM systems are traditionally not cheap, and there is usually a choice between paying a lot and a lot. But, if you use ingenuity, you can assemble a similar design.
It looks creepy, but sometimes this architecture works in production. Complexity kills security, and in general, it kills everything. In fact, for such cases (I'm talking about reducing the cost of ownership) there is a whole class of systems - Central Log Management (CLM). About it considering 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 log collection and analysis when a SIEM solution is too expensive or too complex.
- Invest in CLM tools with efficient storage, fast search, and flexible visualization to improve security incident investigation/analysis and threat search support.
- Ensure that applicable factors and considerations are taken into account before implementing a CLM solution.
In this article, we will talk about the differences in approaches to licensing, deal with CLM and talk about a specific system of this class - . Details under the cut.
At the beginning of this article, I talked about a new approach to licensing Splunk. The types of licensing can be compared to car rental rates. Let's imagine that the model in terms of the number of CPUs is an economical car with unlimited mileage and gasoline. You can go anywhere without distance restrictions, but you cannot go very fast and, accordingly, travel many kilometers a day. Data-based licensing is like a sports car with a daily 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 licensing, you need to have the smallest possible ratio of CPU cores to the number of GBs of data being loaded. 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 the normalized data. If you want SIEM to be an aggregator of all the logs in an organization, it requires a lot of effort in parsing and post-processing. Do not forget that you also need to think about an architecture that will not fall apart under load, i.e. additional servers and therefore additional processors will be required.
Data volume licensing is based on the amount of data that is sent to the mouth of the SIEM. 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 normalization before injection is Elastic Stack and some other commercial SIEMs.
As a result, we have that licensing by infra 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 leads to the following criteria:
- Simplify data aggregation and normalization.
- Filtering out noise and less important data.
- Providing analysis capabilities.
- Sending filtered and normalized data to SIEM
As a result, target SIEM systems will not need to spend additional CPU power on processing and can benefit from identifying only the most important events without reducing the visibility of what is happening.
Ideally, such an intermediate solution should also provide real-time detection and response capabilities that can be used to reduce the impact of potentially harmful actions and aggregate the entire flow of events into a convenient and simple data quantum towards SIEM. Well, then SIEM can be used to create additional aggregations, correlations and notification processes.
That mysterious intermediate solution is nothing more than CLM, which 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 Gartner recommendations:
- Efficient storage for the amount and type of data you need to store.
- High search speed.
- Visualization capabilities are not what basic CLM requires, but threat detection 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 native storage with up to 40:1 data compression and high deduplication speed, which reduces storage overhead for CLM and SIEM systems.
IT Security Search console with google-like search
A specialized web-based IT Security Search (ITSS) module can connect to event data in the InTrust repository and provides a simple interface to search for threats. The interface is simplified to the point that it works like Google for event log data. ITSS uses timelines for query results, can merge and group event fields, and effectively assists in the search for threats.
InTrust enriches Windows events with SIDs, filenames, and security login IDs. InTrust also normalizes events to a simple W6 schema (Who, What, Where, When, Whom and Where From - who, what, where, when, whom and where from) so that data from different sources (Windows native events, Linux logs or syslog) could be seen in a single format and on a single search console.
InTrust supports real-time alerts, detections, and responses 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 detecting the following threats:
- password spraying.
- Kerberoasting.
- Suspicious PowerShell activity, such as executing Mimikatz.
- Suspicious processes, such as LokerGoga ransomware.
- Encryption using CA4FS logs.
- Logins with a privileged account on workstations.
- Password guessing attacks.
- Suspicious use of local groups m users.
Now I will show a few screenshots of InTrust itself, so that you can get an impression of its capabilities.
Predefined filters for finding 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 Scanning Rule Example
Built-in knowledge base with descriptions of vulnerabilities
InTrust is a powerful tool that can be used as a standalone solution or 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 immediately after installation, you can configure sending events to Splunk, IBM QRadar, Microfocus Arcsight, or through a webhook to any other system. Below is an example of the Kibana interface with events from InTrust. Integration with Elastic Stack is already there too, and if you use the free version of Elastic, InTrust can be used as a tool for detecting threats, performing proactive alerts, and sending notifications.
I hope the article gave a minimal idea about this product. We are ready to give InTrust to you for a test or to conduct a pilot project. Application can be made in on our website.
Read our other articles on information security:
(popular article)
Source: habr.com