{"id":23657,"date":"2024-12-21T00:12:34","date_gmt":"2024-12-20T20:12:34","guid":{"rendered":"https:\/\/me-en.kaspersky.com\/blog\/siem-hardware\/23657\/"},"modified":"2024-12-21T00:12:39","modified_gmt":"2024-12-20T20:12:39","slug":"siem-hardware","status":"publish","type":"post","link":"https:\/\/me-en.kaspersky.com\/blog\/siem-hardware\/23657\/","title":{"rendered":"Hardware for SIEM systems"},"content":{"rendered":"

At some point, the information security department of any large company inevitably begins to consider introducing a SIEM system \u2014 or replacing the existing one, and must therefore estimate the budget required for its deployment. But SIEM isn\u2019t a lightweight product that can be deployed within existing infrastructure. Almost all solutions in this category require additional hardware, meaning that equipment must be purchased or rented.<\/p>\n

So, for accurate budgeting, it\u2019s necessary to take into account the expected hardware configuration. In this post, we discuss how SIEM hardware requirements change depending on the company\u2019s profile and system\u2019s architecture, and provide rough parameters to help estimate the preliminary cost of such equipment.<\/p>\n

Evaluating the data flow<\/h2>\n

\nEssentially, a SIEM system collects event data from internal and external sources and identifies security threats by correlating this data. Therefore, before considering what hardware will be required, it\u2019s essential to first assess the volume of information the system will process and store. To this end, you need to first identify critical risks to the infrastructure, and then determine the data sources that must be analyzed to help detect and address threats related to these risks. These are the data sources to focus on. Such an assessment is necessary not only to determine the required hardware, but also to estimate the cost of licensing. For example, the cost of licensing for our directly depends on the number of events per second (EPS). Another important aspect is to check how the vendor calculates the number of events for licensing. In our case, we take the events per second after filtering and aggregation, calculating the average number of events over the past 24\u00a0hours rather than their peak values\u00a0\u2014 but not all vendors follow this approach.<\/p>\n

The most common sources include endpoints (Windows events, Sysmon, PowerShell logs, and antivirus logs), network devices (firewalls, IDS\/IPS, switches, access points), proxy servers (such as Squid and Cisco WSA), vulnerability scanners, databases, cloud systems (such as AWS CloudTrail or Office\u00a0365), and infrastructure management servers (domain controllers, DNS servers, and so on).<\/p>\n

As a rule, to form preliminary expectations about the average event flow, the size of the organization can serve as a guide. However, the architectural particularities of specific IT infrastructure can make company size a less decisive parameter.<\/p>\n

In general, for small and medium-sized organizations with just one office \u2014 or up to several offices with good communication channels among them and IT infrastructure located in a single data center \u2014 an average event flow of 5000\u201310\u00a0000 EPS can be expected. For large companies, making an estimate is more challenging: depending on the complexity of the infrastructure and the presence of branches, EPS can range from 50\u00a0000 to 200\u00a0000 EPS.\n<\/p>\n

Architectural components of an SIEM system<\/h2>\n

\nAn SIEM system generally consists of four main components: the management subsystem, event collection subsystem, correlation subsystem, and storage subsystem.<\/p>\n

Core (management subsystem).<\/strong> You can think of this as the control center of the system. It allows managing the other components, and provides visualization tools for SOC analysts \u2014 enabling them to easily configure operational parameters, monitor the SIEM system\u2019s state, and, most importantly, view, analyze, sort and search events, process alerts, and work with incidents. This control center needs to also support log viewing through widgets and dashboards, and enable quick data search and access.<\/p>\n

The core is an essential component and can be installed as a single instance or as a cluster to provide a higher level of resilience.<\/p>\n

Event collection subsystem.<\/strong> As the name suggests, this subsystem collects data from various sources and converts it into a unified format through parsing and normalization. To calculate the required capacity of this subsystem, one must consider both the event flow intensity and the log format in which events arrive from sources.<\/p>\n

The server load depends on how the subsystem processes logs. For example, even for structured logs (Key Value, CSV, JSON, XML), you can use either regular expressions (requiring significantly more powerful hardware) or the vendor\u2019s built-in parsers.<\/p>\n

Correlation subsystem.<\/strong> This subsystem analyzes data collected from logs, identifies sequences described in correlation rule logic, and, if necessary, generates alerts, determines their threat levels, and minimizes false positives. It\u2019s important to remember that the correlator\u2019s load is also determined not only by the event flow but by the number of correlation rules and the methods used to describe detection logic as well.<\/p>\n

Storage subsystem.<\/strong> An SIEM system must not only analyze but also store data for internal investigations, analytics, visualization and reporting, and in certain industries \u2014 for regulatory compliance and retrospective alert analysis. Thus, another critical question at the SIEM system design stage is how long you want to store collected logs. From an analyst\u2019s perspective, the longer the data is stored, the better. However, a longer log retention period increases hardware requirements. A mature SIEM system provides the ability to strike a balance by setting different retention periods for different log types. For example, 30\u00a0days for NetFlow logs, 60\u00a0days for Windows informational events, 180\u00a0days for Windows authentication events, and so on. This allows data to be optimally allocated across available server resources.<\/p>\n

It\u2019s also important to understand what volume of data will be stored using hot storage (allowing quick access) and cold storage (suitable for long-term retention). The storage subsystem must offer high performance, scalability, cross-storage search capabilities (both hot and cold), and data viewing options. Additionally, the ability to back up stored data is essential.\n<\/p>\n

Architectural features of Kaspersky SIEM<\/h2>\n

\nSo, we\u2019ve laid out the ideal requirements for an SIEM system. It probably won\u2019t surprise you that our Kaspersky Unified Monitoring and Analysis Platform meets these requirements. With its built-in capability to scale for data flows reaching hundreds of thousands of EPS within a single instance, our SIEM system isn\u2019t afraid of high loads. Importantly, it doesn\u2019t need to be split into multiple instances with correlation results reconciled afterwards\u00a0\u2014 unlike many alternative systems.<\/p>\n

The event collection subsystem of the Kaspersky Unified Monitoring and Analysis Platform system is equipped with a rich set of parsers<\/a> optimized for processing logs in each format. Additionally, the multi-threading capabilities of Go mean the event flow can be processed using all available server resources.<\/p>\n

The data storage subsystem used in our SIEM system consists of servers that store data, and servers with the clickhouse-keeper role, which manage the cluster (these servers don\u2019t store data themselves but facilitate coordination among instances). For data flows of 20\u00a0000 EPS with a relatively low number of search queries, these services can operate on the same servers that store the data. For higher data flows, it\u2019s recommended to separate these services. For instance, they can be deployed on virtual machines (a minimum of one is required, though three are recommended).<\/p>\n

The Kaspersky Unified Monitoring and Analysis SIEM storage system is flexible \u2014 allowing event flows to be distributed across multiple spaces, and specifying the storage depth for each space. For example, inexpensive disks can be used to create cold storage (where searches are still possible, just slower). This cold storage can house data that is unlikely to require analysis but must be stored due to regulatory requirements. Such information can be moved to cold storage literally the day after it\u2019s collected.<\/p>\n

Thus, the data storage approach implemented in our SIEM system enables long-term data retention without exceeding the budget on expensive equipment, thanks to hot and cold storage capabilities.\n<\/p>\n

SIEM architecture deployment using our SIEM as an example<\/h2>\n

\nThe Kaspersky Unified Monitoring and Analysis Platform supports multiple deployment options, so it\u2019s important first to determine your organization\u2019s architecture needs. This can be done based on the estimated EPS flow, and the particularities of your company. For simplicity, let\u2019s assume the required data retention period is 30\u00a0days.\n<\/p>\n

Data flow: 5000\u201310\u00a0000 EPS<\/h3>\n

\nFor a small organization, the SIEM system can be deployed on a single server. For example, our SIEM system supports the All-in-One installation option. In this case, the required server configuration is 16\u00a0CPUs, 32GB of RAM, and a 2.5TB of disk space.\n<\/p>\n

Data flow: 30\u00a0000 EPS<\/h3>\n

\nFor larger organizations, separate servers are needed for each SIEM component. Dedicating a server exclusively for storage ensures that search queries don\u2019t affect the processing of events by the collector and correlator. However, the collector and correlator services can still be deployed together (or separately, if desired). An approximate equipment configuration for this scenario is as follows:\n<\/p>\n