SIEM depths: out-of-box correlations. Part 3.1. Event categorization

    Is it possible to categorize all the events arriving in the SIEM, and which categorization system to use for this? How to apply categories in correlation rules and search for events? We will examine these and other questions in a new article from the series on the methodology for creating out-of-the-box correlation rules for SIEM systems.

    Event categorization

    Image: Worktrooper

    The article was prepared in collaboration with Mikhail Maximov and Alexander Kovtun .

    We warn you: the article is large, as it describes the construction of a system of categorization and our chains of reasoning. If you are too lazy to read it entirely, then you can immediately go to the section with conclusions - there we summarized everything we talked about in the article, and summarized the results.

    In a previous article, we found out that events contain a lot of important information that cannot be lost in the normalization process. The description of the interaction scheme refers to this kind of data. To systematize the types of interaction, we did the following:

    • identified the main schemes inherent in any type of event;
    • determined exactly which entities are involved in the schemes;
    • formed a basic set of fields necessary to describe all the entities found in the original event and the channel of interactions between them.

    As a result of analyzing the logs from various types of software and hardware, we were able to distinguish entities: Subject, Interaction Object, Source and Transmitter.

    Now let's talk about the semantics of the interaction of these entities and its reflection in the categorization of events. Before describing the approach to the formation and the category, you need to answer two questions: why do we need to define the categories of the event and what properties the catheterization system should have.

    To begin with, we will define why we need to categorize events. In short: categorization is necessary in order to work equally with semantically similar events, regardless of the type of source. To the types of sources we include the main purpose of the source: network equipment, operating systems, application software. For the phrase “to work in the same way with semantically similar events” it is necessary to understand the following:

    1. Semantically similar events from any type of source have a common category.
    2. For the events of each category, clear rules for filling in the fields of the scheme are defined. So we effectively fight the chaos that occurs at the stage of normalization of events and often leads to multiple false positives correlation rules.
    3. Handling categories allows you to not make unnecessary checks in the code correlation rules to understand the semantics of the event. For example, there is no need to check certain fields for data to determine that an event describes a user’s login, and not a system backup.
    4. Categorization is a common terminology base that helps when writing correlation rules and investigating incidents, to operate with a single set of terms and their common meanings. For example, to clearly understand that changing the network configuration and changing the software configuration are completely different types of events that carry a completely different meaning.

    To get all this, you need to create a system of event categorization and use it when writing correlation rules, investigating incidents, and in cases where more than one person works with an SIEM system.

    With regard to the requirements for the system of categorization, it must satisfy four properties:

    1. Unambiguity . The same event should be assigned to one and only one category.
    2. Compactness . The total number of categories should be such that they can be easily remembered by an expert.
    3. Hierarchy . The system should be built according to a hierarchical scheme and consist of several levels, since this is the most simple structure to memorize. At the same time, the hierarchy should be based on the principle “from the general to the particular”: at the first level there are more “general” categories, and at the last level - highly specialized ones.
    4. Extensibility . The principles on which it is built should allow to make updates to the categorization system when new types of events appear, requiring separate categories, without changing the basic approach.

    Let us proceed to the description of the categorization system: let's start with two large domains, which include event sources connected to SIEM and in which they generate events.

    Source and Event Domains


    The introduction of SIEM often begins with the connection of sources that generate heterogeneous events. An important feature of these events is that they reflect the functionality of the sources themselves.

    There are two global domains:

    1. IT sources are system-wide application software and hardware that spawn IT events.
    2. IB sources - specialized software and hardware of the company's information security, generating IB events.

    Consider the fundamental differences between the events of these domains.

    IT sources report the occurrence of any events in an automated system, without their assessment of the level of security - “good” or “bad”. Examples: applying a new device configuration, backing up data, transferring a file over the network, disabling the network port on the switch.

    Unlike IT sources, information security sources have additional external knowledge of how to interpret certain events from a security point of view, namely, policies. Thus, the use of policies allows IB sources to make decisions - whether the observed phenomenon is “good” or “bad” - and report this to the SIEM through the generated IB events.

    Consider the following example: Thus, in general, a neutral file transfer event over the network is regarded by the Next Generation level firewall as “bad”: it turns out that the file is a Word document transmitted from the company's internal network to an external server via FTP, and the configured policy prohibits such informational interactions. Disabling the network port is treated as an access violation by the decision to control the actions of administrators: since the port is disabled by the user Alex, who does not have the rights to do so, it happens during his non-working time, according to the configured security policy.

    However, it is not quite true to say that information security sources generate only information security events. IB sources generate IB and IT events. IB sources generate IT events, as a rule, when they report changes in their state: configuration changes, cluster nodes switching, backup. In general, these events can be attributed to the internal audit of actions and the status of the source. At the same time, when activity concerns the application of security policies, the same source already generates information security events, thereby reporting the results of their application.

    We deliberately described in such detail the differences between the two domains. The events of each domain carry their own meaning and, at times, can fundamentally differ from each other. These differences led to the existence of two separate event categorization systems responsible for IT events and information security events.

    Categorization of events.  Event Domains
    Event Domains

    There is another rare type of sources that generate events of a separate, third domain — the attack domain. Events of this domain can be received from the endpoint protection level sources (Endpoint Protection), other downstream SIEM (if they are arranged in a hierarchy), or other solutions that can determine from the analysis of IT and (or) information security events that an automated system or its part is under attack.

    As part of this series of articles, we will use the following concepts when separating attacks and information security events from final protections:

    1. Attack - the malicious sequence of actions of the attacker, aimed at achieving a specific goal within the company.
    2. An attack can consist of one or several events - chains of information security events and / or IT events that are violations of information security policies.

    There are several approaches to categorizing attacks, for example, MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT & CK) , which is gaining popularity , but we will not discuss this domain in our articles.

    The system of categorization of IT events


    System-wide application software and hardware, which we refer to as IT-sources of events, is designed to implement or support certain processes to perform its tasks. In the course of solving them, the committed facts are recorded by separate IT events. They can be attributed to the process in which each of them occurred.

    By highlighting the processes occurring in IT sources, it is possible to form the first level of categorization (later we will call it a context). It will define a semantic field that allows you to correctly interpret IT events.

    When analyzing events, it becomes clear that each of them describes the interaction of several entities within an already defined process. Selecting as the main one of these entities as an object of interaction, we form the second level of categorization.

    The nature of the behavior of the main entity in an event within a specific process will play the role of the third level of categorization of IT events.
    Total, at the output we got the following levels:

    1. The context (process) within which the event occurred.
    2. The object (main entity) described by the event.
    3. The behavior of the object within a given context.

    Thus, we have formed three levels of categorization of IT-events, allowing to conveniently operate on semantically similar events from different types of sources in the IT-infrastructure.

    To ensure the unambiguity of the resulting categorization system, we will form separate domains at each level.

    Categorization of IT events.  First level.
    The system of categorization of IT-events. First level.

    A similar process approach to working with IT systems is used in ITSM (IT Service Management, management of IT services), which postulates some of the basic processes that take place in IT services. We will rely on this approach in the formation of possible processes, or in another way - contexts, when considering IT sources of events.

    Select the main processes at this level:

    • Business Continuity Management (operations continuity management) - events associated with operations to maintain continuous operation of systems: the processes of replication, migration and synchronization of virtual machines, databases and storage, backup and restore operations;
    • Users And Rights Management (management of users and rights) - events associated with working with groups and user accounts;
    • Access Management - events related to the processes of Authentication, Authorization, Accounting (AAA) and any attempts to access the system;
    • Availability Management - events associated with any actions to start, stop, turn on, turn off, interrupt the operation of entities, including informational messages from the systems for monitoring accessibility of the entity;
    • Deployment Management (management of deployment) - events associated with the introduction of new entities into the system from the outside, as well as with the removal of the entity from this system;
    • Network Interaction Management (network interaction management) - events associated with the transfer of data through the network, including the establishment of connections, opening and closing of tunnels;
    • Network Management - network stack related events: including any actions with policies and network filtering rules;
    • Virtual Infrastructure Management ( Virtual Infrastructure Management ) - events related to the virtualization infrastructure;
    • Database Management (database management) - events related to the functioning of the DBMS and the actions of users and processes in it;
    • System Management (system management) - events associated with the operation of the operating system and software, which is part of the operating system;
    • Generic Application Management (management of other applications) - events related to the operation of other applications installed by the user and not part of the OS.

    It is important to understand that different processes can occur on the same IT source. For example, in a DHCP service deployed in Unix OS, both the Network Management process can occur (generating, for example, an update event of the IP address of the nodes), and the System Management process, generating a service restart event or configuration file parsing errors.

    The second level of categorization of IT events (entities)


    System for categorizing information security events.  The first and second levels.
    System for categorizing information security events. The first and second levels.

    The second level reflects the interaction object described in the event. Note that the event can describe several entities. For example, take the following event: “the user sent a request to issue a personal certificate to the certification server”. In events of this kind, it is necessary to choose one, the main entity as an object of interaction, which is central to the event. Here we can determine that the main entity is a “request to the certification server”, since the user is obviously the subject of the interaction, and the personal certificate is the result of the interaction of the subject and the object. By collecting and analyzing a large array of events, you can select groups of entities:

    • identifying : user account, user group, certificate - entities that allow you to identify the user or the system;
    • executables : an application, an executable module — everything that can be started by the operating system and contains a specific algorithm;
    • rules and policies : any rules, access policies, including Windows OC group policies;
    • information storage entities in the OS : file, registry key, directory group object — everything that can act as a repository of application-level information;
    • network connections : sessions, flows (flows), tunnels - entities that carry data flow from one node to another;
    • entities of network identification of a node : network address, socket, the network node itself - all those entities without which no monitoring system can do;
    • network L5-L7 : mailing, media stream, mailing list - entities that transmit information at the L5-L7 levels of the OSI model;
    • service network : DNS zone, routing table. These entities are responsible for the correct functioning of the network, without carrying a payload for the end user;
    • entities of fault-tolerant configurations : RAID, cluster network elements;
    • entities of virtualization systems : virtual machines, virtual hard disks, virtual machine snapshots;
    • database entities : tables, databases, DBMS;
    • physical equipment : connected devices, access control elements (turnstiles, IP cameras);
    • other operating system entities : a command in the management console, a system console, a system log — those operating system entities that do not fit into other categories;
    • other network entities : network interface, public network resource - those network subsystem entities that do not fit into other categories.

    These groups do not claim to be comprehensive, but cover the main tasks for assigning second-level categories. If necessary, the presented groups can be expanded.

    The third level of categorization of IT-events (the nature of the interaction)


    The system of categorization of IT-events.  The first, second and third levels.
    The system of categorization of IT-events. The first, second and third levels.

    Within the framework of a specific process, the nature of the behavior of the main entity can be reduced to the following values:

    • Control - interaction that affects the functioning of the entity;
    • Communication - communication between entities;
    • Manipulation - actions to work with the entity itself, including the manipulation of its data;
    • Embedding - interaction, as a result of which a new entity is added to the context (or the entity is removed from the context);
    • State - informational events about changes in the state of an entity.

    The latter domain stands out among others: it includes events that actually do not describe any interaction, but contain information about the entity or transitions of the entity between states. For example, an event describing only the current state of the system (about the current system time, a change in the state of a product license).

    Events describe not only the interaction itself, but also its result. It is important to understand that the context, the main essence, the nature of the object's behavior within the context does not depend on the result of the interaction. As a result, there can be “success” and “failure”. The event can also describe the ongoing process of the still incomplete interaction. Let's call this status “current”.

    Formation of a data set based on three levels


    For each domain of each level, you can select a specific set of data containing events.

    Let us examine an example of an event:



    It can be interpreted as “the connection from node 10.0.1.5 to node 192.168.149.2 was broken.” Looking at the context of the event, you can see that it describes the network connection. Accordingly, we fall into the context of "Network Interaction Management".

    Next, we define the main entity in the event. It is obvious that the event describes three entities: two nodes and a network connection. Based on the above recommendations, we understand that the main entity in this case is the network connection, and the nodes are the participants of the interaction, the endpoints that perform actions on the entity. Total we get the main entity from the "Network Connections" domain, and the action performed on the entity - "closing the communication channel", which can be attributed to the Communication domain.

    However, we still have quite a lot of data that could be saved from the event. So, the second level entity set “Network Connections” has common properties:

    • connection initiator (address + port + interface);
    • recipient (target) of the connection (address + port + interface);
    • the protocol by which the connection is made.

    Also, for example, the action of the third level of categorization “connection closure”, belonging to the Communication domain, may contain the following data, regardless of what kind of connection was closed and what source informed about it:

    • the number of bytes sent / sent;
    • the number of packets sent / sent;
    • duration

    Another example is the set of basic entities “Entities of information storage in the OS”, which are characterized by the following data:

    • entity name;
    • path location of the entity in the OS;
    • entity size;
    • entity access privileges.

    The set of actions related to this entity, for example, “copying”, which is included in the third level domain “Manipulation”, can be characterized by the following properties:

    • new entity name;
    • new path location of the entity;
    • new entity access privileges.

    Optionally, we can get all this data from the event. The main thing is that the category we have defined allows us to isolate a specific set of data that can be extracted from an event, knowing in advance that these data will be semantically similar.

    And in this respect, categories become a convenient tool. By comparing each level of domains with a specific set of such data, we are able to save semantically similar data into the same fields of a normalized event, regardless of the manufacturer and model of the source of the event. This greatly simplifies the search for data in a large volume of events, and, consequently, the implementation of correlations for such events.

    Examples of use of the categorization system


    Situation 1: It is necessary to find all the events that describe the connection and disconnection of peripheral devices from any sources.

    Each of the sources generates events, after normalization of which the Level 1 (first level of categorization), Level 2 (second level) and Level 3 (third level) fields contain categories. In the described situation, all events of interest will contain categories:

    • Level 2: Physical equipment;
    • Level 3: Embedding.

    The first-level domain is not so important, since operations with equipment can occur in different contexts.

    Thus, to display the required events, it is enough to write the following query:

    Select * fromeventswhere Level2 = “<один из элементов из сущностей физического оборудования>” and Level3 = “Embedding” andtimebetween (<временной диапазон>)

    Situation 2: It is necessary to find all the events that describe the attempt to modify the filesystem objects with the name beginning with “boot”.

    Sources connected to the SIEM can produce completely different file modification events. However, the assignment of appropriate categories of events allows you to select the necessary from the entire array:

    • Level 1: System Management;
    • Level 2: Entities for storing information in the OS;
    • Level 3: Manipulation.

    In addition, a condition is specified by file name: using predefined datasets, we can expect that for this category the file name will be in the object.name field. Therefore, to select events, you can form the following request:

    Select * fromeventswhere Level1 = “SystemManagementand Level2 = “<один из элементов из сущностей хранения информации в ОС>” and Level3 = “Manipulation” and (object.name like “boot.%”)

    If the entity was copied, we will find information about it and that it was copied from another entity - this will give impetus to further investigation.

    Situation 3: It is necessary to provide simple profiling of network connections on the border routers of various manufacturers installed in the company's branches. SIEM receives events from each of these border routers.

    Each of the routers generates IT events, after normalization of which there are categories in the Level 1, Level 2, Level 3 fields. In the described example, for profiling it is necessary and sufficient to analyze the events about opening and closing of network connections. According to the presented categorization system, such events will contain the following category fields:

    • Level 1: Network Interaction Management;
    • Level 2: Network Connections;
    • Level 3: Communication.

    Additionally, for opening and closing operations, you can specify the “open” and “close” actions, as well as the status of the “success” action.

    In addition, having data sets for each of the category levels, you can be sure that the start of this connection will be recorded in the event of opening a connection, and the event of closing the connection will contain information about the nodes participating in the network interaction, and also “The number of transmitted bytes”, “the number of transmitted packets” and “duration” will be placed corresponding data on the duration of the connection and the amount of transmitted information, respectively.

    Thus, filtering the flow of events by the specified categories and actions, you can select only the necessary events for the profiling operation, without the need to specify a list of specific event identifiers.

    System for categorizing information security events


    Before we talk about the system of categorization, we note that we will consider only the events coming from the means of protection. Categorizing hacker attacks, as chains of malicious actions, is a separate area with its own categorization system.

    The system of categorizing information security events is based on a certain paradigm. It is formulated as follows: any incident that occurs in an automated system is reflected in one or several environments at once: the level of a particular host, the level of the network, the level of the physical environment.

    Remedies operating at these levels reveal the incident or its “echoes” and generate information security events that arrive at the entrance to the SIEM.

    For example, the transfer of a malicious file over the network to a specific host can be detected at the network and host levels, while network traffic is being processed by network protection tools or by analyzing memory areas with the corresponding anti-virus protection modules.

    Unauthorized physical access to the premises can be detected at the physical environment level by means of access control systems and at the host level, by means of GIS from unauthorized access when authorizing a user to a host during off hours.

    When dealing with security events, it is often necessary to understand the environment in which the incident was recorded. And proceeding from this, build a further path of investigation or form the logic of the correlation rule. Thus, the detection environment is the first level of the categorization system.

    The first level of the system of categorizing information security events


    System for categorizing information security events.  First level.
    System for categorizing information security events. First level.

    • Host violations (violations of the host level) - events coming from protection tools installed on the final workstations and the server. As a rule, IB-events of this level describe the triggering of security policies as a result of analyzing the internal state of the host by means of protection. Under the analysis of the internal state here refers to the analysis of running processes, data in the areas of RAM, files on the disk.
      Types of event sources : anti-virus protection tools, integrity control systems, host-level intrusion detection systems, access control and access control systems.
    • Network violations (network level violations) - events coming from systems that analyze network traffic and apply to it a set of established security policies.
      Types of event sources : firewalls, intrusion detection and prevention systems, DDoS detection systems. Some host security tools also have separate network traffic analysis modules. For example, antivirus protection and some domestic DSS from unauthorized access.
    • Physical violations are events from physical security.
      Types of event sources : perimeter security systems, access control systems, information leakage systems for vibro-acoustic channels and PEMIN channels.
      This category also includes incidents identified by the physical or economic security service in the course of internal events and brought into the company's internal bases, information from which can be collected by the SIEM. For some organizational reasons, this is an extremely rare, but still possible case.

    The second and third level of the system of categorizing information security events


    The second level of the categorization system is associated with the first, but it has the features due to the following prerequisites:

    • Information security incidents do not always occur in the physical environment;
    • incidents in the physical environment are not always associated with information security incidents, but there are also intersections;
    • Network and endpoint incidents often have similar structure and semantics.

    Therefore, at the second level, a group of categories is allocated, corresponding to violations of the physical environment level, and groups of categories common for network and host level violations.

    The third level of the categorization system specifies the second one and describes directly the violations themselves, the essence of which is reflected in the information security events.

    We analyzed IBM QRadar, Micro Focus Arcsight, and Maxpatrol SIEM event categorization systems for network and host level violations. Following the results, they concluded: they are all very similar, and eCSIRT.net mkVI can serve as the most complete and unifying categorization system . It was she who was taken as a basis in the categorization system below.

    System for categorizing information security events.  Violations of the host level and network level.
    System for categorizing information security events. Violations of the host level and network level.

    • Abusive Content (malicious content) - content delivered in a legal way to the end user, prompting for illegal actions (intentional or not intentional) or containing malicious / garbage data.
      Third level categories : Spam, Phishing.
      Types of event sources : proxy servers with content control (Microsoft Threat Management Gateway), web traffic protection tools (Cisco Web Security Appliance, Check Point URL filtering blade), mail protection tools (Cisco Email Security Appliance, Kaspersky Secure Mail Gateway), End host protection tools with built-in web and email control modules (McAfee Internet Security, Kaspersky Internet Security).
    • Information Gathering (data collection) - the collection of data on the object of protection from public and private sources of information, using active and passive methods of collection.
      Third level categories : Fingerprinting, Sniffing, Scanning, Bruteforce.
      Types of event sources : as a rule, network security tools, namely: firewalls (Cisco Adaptive Security Appliance, Checkpoint Firewall blade), intrusion detection and prevention tools (Cisco Firepower Next — Generation IPS, Check Point IPS blade).
    • Availability ( Availability Violation) is a malicious or accidental violation of the availability of individual services and systems as a whole.
      Third level categories : DDoS, DoS, Flood.
      Types of event sources : firewalls and intrusion detection and prevention systems, as well as systems for detecting and blocking network DoS attacks (Arbor Pravail APS, Arbor Peakflow SP, Radware DefensePro, MFI Soft APK “Perimeter”).
    • Vulnerability Exploration (detection of vulnerability) - the identification of vulnerabilities or groups of vulnerabilities. It is important to note that this category describes precisely the IB-events on the detection of vulnerability, but not its operation.
      Third level categories : Firmware, Software.
      Types of event sources : events from the integrated SIEM or integrated external security and audit scanner (Tenable Nessus Vulnerability Scanner, Positive Technologies Maxpatrol 8, Positive Technologies XSpider, Qualys Vulnerability Scanner, Burp Suit).
    • Vulnerability Exploitation — identifies a targeted negative impact on a system or the exploitation of a system's vulnerability. In this case, often the third level categories may include separate attack techniques, given in MITER ATT & CK (reference) and defined by means of protection.
      Third level categories : XML External Entities, Cross Site Scripting, Insecure Deserialization, Routing Poisoning, etc.
      Types of event sources: Network Intrusion Detection and Prevention Systems (Positive Technologies Network Attack Discovery, Positive Technologies Web Application Firewall, Imperva Web Application Firewall, Cisco Firepower Next Generation IPS, Check Point IPS blade,) or host level (Carbon Black Cb Defense, HIPS anti-virus modules protective equipment, OSSEC).
    • Hacktool (hacker utilities) —the use of utilities used to hack systems or take other unlawful actions to obtain confidential information and to circumvent protection.
      Third level categories : Scanner, Bruteforcer, Exploit Kit, Password dumper, Vulnerability scanner, TOR client, Sniffer, Shellcode, Keylogger.
      Types of event sources : intrusion detection and prevention systems at the network level and host level, security and audit scanners, anti-virus protection tools.
    • Malicious Code (Malicious Code) - identifying the use of malicious code.
      Third level categories : Virus, Worm, Botnet, Rootkit, Bootkit, Trojan, Backdoor, Cryptor.
      Types of event sources : any network and host anti-virus protection tools, network level intrusion detection and prevention systems.
    • Compliance (violation of compliance) - identification of the facts of non-compliance with the checks defined in compliance policies. In this case, compliance policies refer to the requirements of PCI DSS, FSTEC Order No. 21, and corporate security standards.
      Third level categories : Integrity control, OS settings control, Application settings control.
      Types of event sources : security and audit scanners.
    • Information Leak (information leakage) - identification of leakage of confidential data through any communication channels.
      Third level categories : Email, Messenger, Social net, Mobile device, Removable storage.
      Types of event sources : Data leakage prevention systems (Rostelecom — Solar Dozor, InfoWatch Traffic Monitor).
    • Anomaly (anomalies) - significant deviation of the parameters of the object of protection or its behavior from the previously established norm.
      Third level categories : Statistical, Behavioral.
      Types of event sources : next generation network protection tools (Next Generation), data leakage prevention systems, User and Entity Behavior Analytics class systems (Splunk User Behavior Analytics, Securonix User Analytics, Exabeam Advanced Analytics).

    System for categorizing information security events.  Violations of the level of the physical environment.
    System for categorizing information security events. Violations of the level of the physical environment.

    Violations in the physical environment, meaningful from the point of view of information security, have their own separate “branch” in the categorization system. It is important that in this case the categorization system has only one level.

    Such a “truncated” view of the categorization system is primarily due to the extremely rare cases of integrating SIEM with physical security features. Exceptions are access control and accounting systems (ACS) that are often connected to the SIEM. Otherwise, in compiling this “branch” of the categorization system, we did not have enough statistical data to systematize this particular direction.

    • Theft (theft) - theft of physical media or computing facilities (laptops, tablets, smartphones) with confidential information from the territory of the company or from company employees.
      Types of event sources : physical security incident database, personnel systems.
    • Intrusion (physical penetration) - unauthorized or unregulated bypass of the physical protection system.
      Types of event sources : physical security incident database, perimeter security system.
    • Damage (damage) - targeted damage, destruction, reduction of the life of the equipment or communication channels.
      Types of sources of events : physical security incident database.

    Examples of use of categorization systems


    Let us apply the described categorization system for writing high-level correlation rules and searching for events in the investigation process. Consider two situations.

    Situation 1 : by means of the correlation rule, it is necessary to detect the leakage of confidential information as a result of the hacking of the assets of the automated system. SIEM receives events from the following protections:

    • data leak prevention systems;
    • network level intrusion detection and prevention systems;
    • host-level intrusion detection and prevention systems;
    • anti-virus remedy.

    Each of them generates IB-events, after normalization in the fields Level1 , Level2 , Level3 of which contain the marked categories.
    The text of the correlation rule on pseudocode may look like this:

    # В потоке находим события от любых подключенных систем защиты. Назовем это событие «Host_poisoningevent Host_poisoning»:
        # Нам важно смотреть на события на каждом хосте в отдельности, поэтому мы их сгруппируем по заданному полюgroupby dst.host # В этом поле лежит hostname/fqdn/ip хоста, на котором происходят нарушения
        filter {
            Level2 = “Malicious Code” OR
            Level2 = “Vulnerability Exploitation”
    }
    # Теперь в потоке событий находим событие от системы предотвращения утечек данных:event Data_leak:
        groupby dst.host
        filter {
            Level2 = “Information Leak” AND
            Level3 = “Email” # К примеру попробуем выявить утечку через почту
        }
    # Описание самого правила с именем Host_poisoning_and_data_leakage: ждем событие «Host_poisoning», а потом «Data_leak» в течение 24 часов на одном и том же хосте:
    rule Host_poisoning_and_data_leakage: (Host_poisoning —> Data_leak) within 24h
    emit {
        # Делаем что—то полезное при срабатывании
    }

    Situation 2: we are investigating the incident on a specific host - alexhost.company.local. It is necessary to understand what happened to him in the period from 04:00 to 06:00 08.11.2018. During this time, in the SIEM itself there are about 21,600,000 events from this host (the average event flow is 3000 EPS). It is now 11:00 on 09.11.2018, all events lie in the SIEM database, at the time of the incident, not a single correlation rule was established in the SIEM.

    Obviously, analyzing all events manually is a bad idea. It is necessary to somehow reduce their volume and localize the problem. Let's try to look for events of interest to us in this set. For example queries, SQL-like syntax will be used.

    1. We find out that "saw" remedies at this time:
      Select * fromeventswhere Level1 in (“Host violations”, “Network violations”, “Physical violations”) and dst.dost=“alexhost.company.local” andtimebetween (<временной диапазон>)

      Suppose we received 10,000 events from the Host violations and Network violations domains for this request. Anyway, a lot for manual analysis.
    2. Let us try to understand whether the hacking of the host could have occurred during the incident, and it doesn’t matter to us what means the defense took out.
      Select * fromeventswhere Level2 in (“Vulnerability Exploitation”) and dst.dost=“alexhost.company.local” andtimebetween (<временной диапазон>)

      Suppose that on this request we received 500 events from network and host level intrusion detection and prevention systems. Fine! With this you can already work manually.
    3. During the investigation, we realized that the hacking occurred from inside the company. Let's try to find out if any of the security tools “saw” the installation or the execution of hacking tools on any of the company's hosts.
      Select * fromeventswhere Level3 = “Exploit kit” andtimebetween (<последние 3 дня>)

    findings


    We described the principles of building a system for categorizing events and put forward requirements that defined the approaches and principles of its formation. Based on the specifics of the sources of events connected to the SIEM, the categorization system was divided into two directions: the categorization of events from IT sources and the categorization of events from information security sources.

    The IT event categorization system was formed on the basis of the following principles:

    1. IT events reflect the stages or details of IT processes that are supported or implemented by event sources.
    2. The categorization system consists of 3 basic levels and one additional, determining the success or non-success of the action described in the event.
    3. At the first level, IT processes are distinguished within which the source of events operates.
    4. The second level describes the main entities that are involved in this process.
    5. The third level determines what actions are performed by this or on this entity in the framework of the process.
    6. An additional level describes the status of these actions (success, failure).

    The system of categorizing information security events is based on the following principles:

    1. The categorization applies exclusively to information security events collected from protection tools and does not affect the categorization of attacks on automated systems. The differences between attacks and information security events were given at the beginning of the article.
    2. The categorization system consists of 3 levels.
    3. At the first level, there are domains in which violations of information security can be detected: violations of the host level, network and physical environment.
    4. The second level of categorization is formed by concrete classes of violations.
    5. The third level is formed by specific types of violations defined within the framework of a given class.

    The article also gave examples of the use of this categorization system when writing correlation rules and investigating incidents.

    General scheme of the categorization system
    The general scheme of the categorization of the

    Methodology of supporting sources of events will be a separate article. The methodology will combine everything that has already been described and will show how to approach the normalization of events from the standpoint of unification. Its application eliminates the correlation rules from errors in the data received in them in the form of normalized events, thereby increasing their accuracy.



    Cycle of articles:

    SIEM depths: out-of-box correlations. Part 1: Pure marketing or unsolvable problem?

    SIEM depths: out-of-box correlations. Part 2. The data scheme as a reflection of the model of the "world"

    Depth of SIEM: correlations out of the box. Part 3.1. Event categorization ( This article )

    SIEM depths: out-of-box correlations. Part 3.2.

    SIEM Depth event normalization methodology : out-of-box correlations. Part 4. System model as a context of correlation rules.

    Depth SIEM: out-of-box correlations. Part 5. Methodology for developing correlation rules

    Also popular now: