This paper considers the evolutionary path of indicator development in the tasks of monitoring and threat detection. The work aims to form a unified descriptive structure for behavioral indicators. The resulting description standard is designed to create an open database of behavior indicators. The base of behavior indicators shall be the basis for the user action profiling system that's developing by the authors. Prospects of application of the obtained results are also seen by the authors in the field of Threat Hunting, Threat Intelligence, and automation of correlation rules for SIEM systems. In addition, the possibilities, benefits, and methods of implementation of behavior indicators in the process of user actions profiling are considered.
threats or attempts to implement threats. When classifying indicators in information security, three types of indicators can be distinguished: indicator of compromise (IoC) indicator of attack (IoA) indicator of behavior (IoB)
Today, indicators of compromise (IoCs) are the most widely used. An Indicator of Compromise
(IoC) is an object observed on a network or an endpoint, that is highly likely to indicate unauthorized
access to the system (that is, its compromise) [
However, IoCs have not become a complete and sufficient solution for detecting all attempts to
implement threats. The major shortcomings of compromise indicators are highlighted [
In summary, the use of IoCs can help detect attacks in which attackers use already known objects (files, DNS, IP, etc.). However, IoCs remain powerless against modern targeted attacks. This led to the emergence and application of a new type of indicators – Indicator of Attack (IoA) and Indicator of Behavior (IoB).
An Indicator of Attack is a rule (chain of actions) containing a description of suspicious behavior in
the system, which may be a sign of a targeted attack [
Thus, an indicator of an attack can be a separate technique/procedure (for example T1562.002 Impair Defenses: Disable Windows Event Logging), or a sequence of techniques used within the framework of related tactics. As an example, consider running the command line (T1059 Windows Command and Scripting Interpreter) followed by modification of the registry keys responsible for autostart to persistence into the system (T1547.001 Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder).
The use of attack indicators (IoAs) to detect attempts to implement cyberthreats is more effective
than IoCs because changing TTPs (Tactics, Techniques, and Procedures) is the most difficult thing for
an attacker to do [
An Indicator of Behavior is a digital behavior monitored to understand risks within an organization
[
The following are examples of behavioral indicators: use of external media work on multiple hosts remote login work with system utilities use of RATs (Remote Admin Tools)
Indicators of behavior, therefore, have a broader scope of coverage. Behavioral indicators are applicable in the detection of internal intruders, insiders, breaches or non-compliance with established information security policies, leaks of confidential information, and others.
Specialized solutions called the Threat Intelligence Platform are used to integrate IoCs into the threat
detection process [
In turn, the attack indicators and behavior indicators currently come as paid rule sets when you
purchase the product [
Due to the lack of open IoBs databases, a general structure for describing behavioral indicators is
being developed as part of the work in order to create and populate the IoBs database. In the future, it
is planned to use this database of indicators in our own system for profiling user actions, which is being
developed [
An example XML description of a behavior indicator is given in Listing 1. <IOB> <Id>000001</Id> <Name> Using the Windows command line </Name> <Description>Command line usage may indicate an attempt to execute a system command to run scripts, change system configuration, retrieve system information, etc. Not all users need to interact with the command line when performing their work tasks.</Description> <Priority>Medium</Priority> <Category>Policy Violation, Improper Use</Category> <MITRE_TACT>Execution</MITRE_TACT> <MITRE_TECH>T1059</MITRE_TECH> <Standalone_IOA>true</Standalone_IOA> <BehaviorOn>Windows</BehaviorOn> <Detection> <Detector id="1"> <LogSourceName>Windows Security Log</LogSourceName> <EventID>4688</EventID> <Parameter>NewProcessName</Parameter> <Condition>Contains</Condition> <Value type="string">
Windows\System32\cmd.exe </Value> </Detector> </Detection> </IOB>
Semantically, the structure of the IoB description can be divided into two components: a block with the necessary descriptive characteristics of the indicator and a block with information to detect the indicator. The description and purpose of the fields are shown in the Table 1.
This field shows where the behavior indicator can be observed: on the
The resulting behavior indicator description structure includes not only descriptive fields but also typical event sources, fields, and their values required for indicator detection. This feature allows the use of the IoBs database to automate the writing of correlation rules of SIEM systems.
User Behavior and Entity Analytics is a class of information security tools for detecting threats to
information systems, based on the analysis of user, device, application, and other behavior [
In today's User Behavior Analytics/User Behavior and Entity Analytics solutions, the Scoring
method or Scoring models (counting the value, in information security, this is counting the value of the
risk) are mostly found [
This approach is combined with the time decay method. This means that when a user stops taking actions that add negative points to their risk score, the risk score will gradually decrease, e.g. every 5 minutes by 10 points. Thus, this approach is not sensitive to time-distributed attacks. This approach also lacks retrospective analysis.
Behavioral indicators can be used to build both retrospective graphs of potential actions that preceded the current behavior and predict graphs of future actions. Therefore, their use allows for decoupling from the time frame. Detection should not depend on the frequency of potentially dangerous actions but on the sequence of such actions.
Also, the quality of UEBA class solutions is highly dependent on the number of data sources used
to enrich actions with context [
Hence, a direct way of improving UEBA class solutions is to work on parsing all sorts of existing data sources, natural language text processing, etc.
The authors have chosen a different direction – increasing the number of models used.
In order to reduce false positives and increase the number of scenarios for the use of user action profiling, a multi-model approach was previously proposed. The multi-model approach, as originally conceived, consisted of the following models a user behavior model a working behavior model a security behavior model a model of a potential attacker
Previously, the multi-model approach was based on analyzing the sequence of all user actions. However, the main purpose of this class of solutions is to detect malicious intent in the user's actions. To detect malicious intent, behavior indicators and attack indicators are sufficient. Therefore, let us now consider the transformation of each model with the implementation of the behavior indicators. 6.1.
The user behavior model consists of a set of characteristics of the infrastructure with which the user interacts (e.g. IP address and work hostname) and a set of behavior indicators. The set of behavior indicators generated by user action profiling is primarily designed to avoid false positives.
Let's look at a specific example. Let's take an internal attacker as the subject. It is assumed that the internal attacker already has initial access to the system as opposed to the external attacker. However, an internal attacker may use his/her colleague's account to elevate his/her rights or hide his/her actions. To detect such attempts, let's introduce an appropriate behavior indicator - logging in under someone else's account. The entered indicator will work based on the work host specified in the user's profile. When a user logs in to a host they have never logged in to before - the system considers this behavior a possible indicator of logging in under someone else's account. generated. 3. where bij=1 if it is possible to move from stage IoB(i) to stage IoB(j).
Then, for example, putting L = 3 as the chain length required to trigger an alert, consider a case study. Introduce a behavior indicator, "use of external media", which corresponds to the Initial Access tactic of the MITRE matrix. The current chain length is 1. Next, we notice the "launching a program from removable media" indicator, which correlates with the Execution tactic. From the 'use of external media' indicator, it is possible to move to the "launching a program from removable media" indicator, so the chain length becomes 2. The next indicator observed is 'change in registry values associated with autorun'. This indicator is related to the Persistence tactic. The observed indicator can be associated with the previous one, the chain length becomes 3. Chain length reaches a threshold value - an alert is
In addition, with this matrix, it is possible not only to detect current events but also to predict expected indicators of behavior in the future. An example of such a predictive chain is shown in Figure
Reflecting on this behavioral indicator, it is possible to conclude that there are scenarios with false positives. For example, a system administrator or helpdesk employee may log on to users' hosts to resolve technical problems. Therefore, to avoid false positives, these user roles need to have another behavioral indicator in their profile - operating on multiple hosts. 6.2.
The potential attacker model is the most significant in terms of the threat posed. This model is therefore subject to particularly stringent false positives. A solution to this requirement could potentially be to set it to trigger only when a specific sequential chain of behavior indicators is detected. The fixation of behavior indicators relating to different stages of an attack is a tell-tale sign of malicious behavior on the part of the user. This concept can be represented as an IoB matrix:
The working behavior model aims to reduce false positives associated with specific infrastructure and corporate policies.
For example, in some organizations the use of remote administration tools is legitimate, in others, it is not. Therefore, if the activity is legitimate, appropriate behavioral indicators should be added to the working model.
(1) use of remote administration tools (RAT) use of telnet use of public file repositories
What is the underlying assumption for the effectiveness of this behavioral indicator approach? Three
popular models related to attacker behavior are considered:
The Kill Chain model by Lockheed Martin [
The Kill Chain model does a good job of showing the sequence of actions in an attacker's actions to achieve their goals.
The MITRE database is rich in techniques that are indeed capable of being indicators of malicious intent, as they are highlighted by analyzing the actions of multiple professional groupings (APTs).
The Diamond model shows that infrastructure features and capabilities (analogous to techniques) can identify a specific attacker (attacker attribution).
Thus, the multi-model approach combines the best practices of the three models for analyzing user behavior. The potential attacker model is based on the consistency principle of the Kill Chain model. To cover the behavior of professional attackers, the behavior indicators incorporate MITRE matrix techniques. The user behavior model adopts the Diamond model's experience of identifying a subject by infrastructure attributes and user capabilities (behavioral indicators).
Despite the perceived benefits of using best practices, the disadvantages cannot be overlooked: 1. The listed models (Kill Chain, MITRE, DIAMOND) target external attackers. To fully cover the sources of cyber threats, models need to be expanded and adapted to also target the internal attacker. As an example, Initial Access tactics from the MITRE base may be completely redundant for an internal attacker because the internal user has a priori certain access rights. 2. More relevant and precise points of contact between the behavioral indicators are needed. Building attack chains (transitions between indicators) on the basis of the attack tactics stage alone will potentially have errors of the first kind. It means detecting an attack attempt based on potentially consistent behavioral indicators, which actually come from different sources and are not related to each other. The presence of false-positive verdicts creates the need for additional manual analysis.
The next stage in the development of cyber threat monitoring and detection is the integration of behavioral indicators and attack indicators into this process. This requires not only the availability of specific tools but also the emergence of open and accessible indicator databases. To this end, attempts have been made to develop a descriptive framework of behavioral indicators to further build and populate the primary indicator base. This database will be used in its own system for profiling user actions. In addition, it is planned to place the database of indicators in the public domain, which will allow the community to use this database, for example, for the automated creation of correlation rules for SIEM systems.
In order to improve the quality of UEBA class solutions, the idea of implementing behavioral indicators in the behavior analysis is proposed. The advantage of using behavioral indicators is their focus on malicious intent. Behavioral indicator sequence analysis is able to detect time-distributed attacks, unlike the popular Scoring method.
Taking into account the implementation of behavior indicators and the basic ideas of the Kill Chain, MITRE, and DIAMOND models, an early multi-model approach to user action profiling has been redesigned. Further work will focus on developing algorithms for modeling and detecting behavioral indicators from different log events.