RU2610395C1 - Method of computer security distributed events investigation - Google Patents

Abstract

FIELD: information technologies.

SUBSTANCE: invention relates to field of information protecting in computer systems. Disclosed is method, in which loading data on system events from all users computers to security server; among these events recording, at least, one system event, caused safety incident; analyzing loaded events by searching among them of such, which similar to events, preceding to already registered safety incident; performing correlation analysis of event data distributed over time and place, using additional rules, including following actions: setting background conditions and analysis depth level; generating initial plurality of rules to perform correlation analysis; performing significant rules selection into active plurality; detecting and eliminating conflicts among selected rules; checking for each of active plurality rule for conformity of actual analysis depth to specified; performing search and application of solution for elimination of consequences and safety incident prevention; generating security incident report.

EFFECT: technical result consists in reduction of number of undetected computer security incidents.

7 cl, 4 dwg, 2 tbl

Description

FIELD OF THE INVENTION

The alleged invention relates to the field of information security in computer systems and can be used to detect and investigate distributed computer security events of a destructive nature.

State of the art

A known method for predicting and preventing security incidents based on user hazard ratings [1], in which the reduction in the number of security incidents in computer systems is achieved by determining the values of user security parameters characterizing its attributes and actions, as well as its information connections, with subsequent calculation information security (IS) risks for all events reflecting the user's work, and the search for possible solutions to reduce such risks .

To do this, information is collected about the events that make up the security incident by transferring data from system logs and event logs, data on existing (created) user profiles, and other information characterizing possible user actions when working on their computer from user computers to the server. Then, sorting, counting, and comparison of numerical values for each data category is performed, and based on them, ratings (profiles) are calculated for each characteristic that reflects possible risks.

The calculated calculated risk values are subsequently used to predict the occurrence of incidents and find possible solutions to reduce such risks, thereby contributing to the prevention of computer security incidents.

The disadvantage of this method is the lack of a procedure for identifying the relationships between heterogeneous events, which does not allow using this method to detect and investigate security incidents distributed by time and place, although many information intrusions are precisely a chain of events that are often implicitly related to each other.

In well-known solutions [2, 3], the achievement of a reduction in the number of computer security incidents is based on collecting information on information risks associated with user actions and subsequent updating of the security policy, thereby allowing the prevention of similar information security incidents.

The disadvantage of these technologies is the use of only data on past events, which does not allow tracking current security events that can lead to an incident.

The closest in technical essence to the claimed and adopted as a prototype is a method for automatic investigation of security incidents [4], in which the reduction in the number of security incidents is carried out by eliminating the recurrence of system events defined as the causes of computer security incidents (violation of security policy, malware detection or incorrect operation of the protective equipment).

At the same time, data on system events from computer devices connected to the administration server are downloaded to the server, among which the system event that led to the security incident is recorded. Then, the downloaded events are analyzed to identify events preceding the identified security incident, and at least one system event that is the cause of the incident is determined. This allows you to reduce the number of security incidents by eliminating the recurrence of system events defined as the causes of these security incidents by deciding to change the corresponding security policy.

The disadvantage of this method is the implementation of the ability to track the fact of a security incident directly by means of protection from the registration data of only its own logs or logs of the operating system installed on this PC. The method does not specify the procedure for identifying possible relationships between all occurring events that affect the security of the computer, which does not allow for the effective identification of security incidents consisting of a set of distributed security events.

Disclosure of invention

The technical result is to reduce the number of undetected computer security incidents.

The specified technical result is achieved in that, in contrast to the known method for the automatic investigation of security incidents, where the reduction of security incidents in the information system (IP) is achieved by performing the following steps (Fig. 1):

• uploading data about system events from all computer devices to the administration server;

• registering among these events a system event that triggered a security incident;

• analysis of downloaded events by searching for events preceding the incident;

• determination of one system event that is the cause of the incident, an authorized user and the computer device on which the event that caused the incident was recorded;

• subsequent search and decision-making on changing the security policy with the generation of a report describing system events, their chronology and decisions made,

Additionally, at the stage of analysis of the loaded data on the signs of events, a correlation analysis of these data is performed using special rules (signatures), which includes the following actions:

• form the initial set of rules for performing correlation analysis;

• set the background conditions and level of analysis depth for each rule;

• select significant rules into the current set, on the basis of which the search for the relationships between distributed security events will be performed;

• identify and resolve conflicts in the newly formed set;

• check for each rule from the current set the correspondence of the actual analysis depth to a given one.

A comparative analysis of the proposed solution with the prototype shows that the proposed method differs from the known one by the introduction of a separate stage for identifying correlation relationships between the signs of fixed security events, based on data obtained from all the registration logs, both basic tools installed on the PC and additional security tools, as well as a special selection procedure to correlate only relevant rules and eliminate possible conflicts between them.

Thanks to the new set of essential features in the method, it is possible to expand the range of detected computer security incidents by investigating not only simple destructive events, but also composite ones, including security events separated in time and place.

Moreover, the effectiveness of identifying correlation between distributed events is ensured by the formation of a special set of significant correlation rules, and the conflict resolution capabilities implemented in it when selecting such rules.

When some security events occur in the computer network that may violate the security policy and possibly constitute a threat to the information of the PC and the computer network as a whole, the protective equipment installed on the computers of users identifies and tracks security incidents. And specialized software agents transmit data about these events recorded in the registration logs (log-logs) to the security server, which contains:

• a data collection tool configured to download data about system events recorded on users' computers, while the data collection tool is associated with an incident analysis tool;

• an incident registration tool configured to extract at least one system event from the downloaded data that caused the security incident, while the incident registration tool is associated with an incident analysis tool and a data collection tool;

• incident analysis tool, configured to:

определения компьютера, на котором было зафиксировано событие, вызвавшее инцидент безопасности;

identifying the computer on which the event causing the security incident was recorded;

определения пользователя, авторизованного на компьютере пользователя;

definitions of the user authorized on the user's computer;

поиска событий, предшествующих зарегистрированному инциденту безопасности;

Search for events prior to a registered security incident;

определения, по меньшей мере, одного системного события, являющегося причиной возникновения инцидента;

determining at least one system event that is the cause of the incident;

• a solution search tool configured to search for a solution to eliminate the consequences and prevent a recurrence of an event corresponding to a registered security incident, while the solution search tool is associated with an incident analysis tool;

• a reporting tool designed to generate a report containing at least a description of system events, the relationship of events, a chronology of events, solutions found and solutions applied.

At the first stage (Fig. 1), data on registered security events are collected from all computer devices (element number 100 in Fig. 1; hereinafter, references to elements of figures are indicated in ordinary brackets). In this case, an elementary security event is considered to be a single entry in the registration log containing a complete set of data about the action performed on the computer, for example, intercepting commands, functions (API functions), reading memory and files, programs, and any other possible action with operating and file objects systems. By the signs of a security event is meant that set of data from the logs that uniquely identifies one or another result of an elementary action (process) that serves as the basis for this security event (for example, the result of user authentication, the fact of changing access rights to the file, etc.).

Sources of information for analysis are the log-logs of various IP components: operating systems, application and general software, as well as information protection tools, etc. Data collected includes: records of program and system logs (reports) that record user actions and program requests network requests, etc.

Since most of the logs have a different format, they bring the data to a single form by the data collection agent, which is specialized software that is separately installed on the desired host (AWP) and real-time reading of relevant information from the logs. In this case, data normalization is performed, i.e. recoding of each text line of the journal in binary form, dividing the data into two groups:

• the first group includes signs of events;

• in the second - records that ^: carry information about any external action: by the user or the system.

In addition, all the data collected from the logs is divided into categories, for each of which a priority level is determined. This is necessary to associate a specific security event with models of IP security and software vulnerabilities and determine the weighting coefficients of each feature that describes this event.

At the second stage (200), the information protection devices installed in the IS detect and monitor the totality of the signs of local security events occurring in the IS that could constitute a security incident.

If the information security means at this stage are not identified among the local security events that occurred in the IS (250), then at the next stage (300) an additional correlation analysis of the data is carried out according to the signs of distributed security events. At this stage, using the incident analysis tool, they study the registration data for the presence of hidden relationships between dissimilar security events.

This allows you to detect incidents consisting of several distributed events, including those that occurred at different times and on different IP nodes. The time period for which a retrospective data analysis is performed is selected by the security administrator. For example, an attacker is currently trying to incrementally copy a database with confidential information, provided that he has already copied the full database in advance. Therefore, in this case, the specified time interval analysis, it is advisable to increase to several weeks or months.

Thus, the inclusion of a correlation procedure in the method for investigating distributed computer security events makes it possible to detect hidden relationships between distributed security events that have a common goal [5], for example:

• attack from a compromised site;

• attack from one node to many;

• distributed DoS attack;

• attempts to establish a connection on closed ports.

As a basis for the correlation procedure, it is possible to use signature methods (based on setting rules) [6, 7]. In particular, the RBR method (rule-based reasoning), in which the relationships between the signs of events and security incidents, are determined by analysts in predefined specific rules. Moreover, the correlation rules determine how relations (signature) are of the form “condition-action”, which makes this method simple to implement and similar to the usual if-then construct. To describe signatures in correlation rules, they use the structure of XML directives, which can contain several, possibly nested, rules.

Data analysis using the signature correlation method can be represented as follows. After the formation of the current set of correlation rules, a sequential check of the data collected by the agents from the registration logs is carried out. To do this, each rule is loaded into the memory of incident analysis tools and the signature described by this rule is compared with the current data collected from the collection agents. So, if event A occurred (event group), i.e. Among the registered data, its features or a set of features are identified, and the background conditions for this rule are met, then directive B is implemented, which can be of a different kind:

• add a new event to the processing;

• check some part of the IP;

• collect additional data about recorded security events;

• generate a hazard alert.

Each new event is mapped to all directives, and thus more than one alarm can be generated.

In case of coincidence of only one of the signs of a security event, include a counter that counts the number of committed events of the same type. The counter is designed to count the number of matches according to the same rule (feature) at a given analysis depth. For example, five attempts of an unsuccessful login to the operating system on behalf of one account within five minutes - an incident.

If no matches are found, the subsequent rules are loaded in turn and their signatures are checked for compliance with the data being analyzed.

Although the definition of rules is usually implemented at an intuitive level, the development of the correct set of rules in relation to a specific task is quite difficult. This is due to the subjectivity of the rules set by the security administrator, the need to take into account the various background conditions in the rules he develops, and the inability to apply ready-made rules with the same efficiency when a new (non-standard) situation arises in the IP. In this case, the security administrator must describe as many rules (signatures) as are necessary for the analysis tool to work effectively, but the number of random events in the IP is huge, and the number of possible incidents is constantly growing. All this leads to conflicts within the set of rules, when during sequential processing of rules unplanned directives can be issued, gaps may appear, or, conversely, the control algorithm will fall into the loop.

Therefore, in the proposed method, additional actions are used:

• set the background conditions and the initial level of depth of the analysis performed by the rules;

• form the initial set of rules for performing correlation analysis;

• select significant rules into the current set;

• identify and resolve conflicts among the selected rules;

• check for each rule from the current set the correspondence of the actual analysis depth to a given one.

.As the background conditions, circumstances are determined that affect the accounting (consideration) of certain signs of security events when checking the rules of correlation. Each of the background conditions, the security administrator assigns a confidence factor CF _i ,

.

For example, on the user's computer there is an account “Guest”, which allows an attacker to bypass the regular system of access control under normal conditions. However, in practice, this background condition may have a high or low confidence coefficient, depending on whether this account is enabled (enable) - confidence coefficient CF _i = 1, or disabled (disable), then the confidence coefficient CF _i = 0, respectively.

An example of a set of background conditions is the use on a network device (server) of the Linux operating system (confidence factor CF ₁ = 0.1) with the shell command interpreter bash (confidence factor CF ₂ = 0.2). Moreover, if you use the bash interpreter with versions 4.2 and 4.3 (confidence factor CF ₃ = 0.3), and the OS does not have a corresponding patch (confidence factor CF ₄ = 0.4), then the overall confidence factor CF _S for this set background conditions

CF _S = CF ₁ + CF ₂ + CF ₃ + CF ₄ = 1,

otherwise, if any of the background conditions changes, the corresponding confidence coefficient CF _{i is} set to 0. In this example, the maximum weight of all confidence factors is CF ₄ , since it has the most significant impact on the ability of an attacker to exploit CVE: 2014-6278 . Background conditions, as well as signs, are included in the rule structure (signature).

, определяющий временной интервал Т в течение которого с указанного источника данных собирается информация о событиях безопасности, и объем данных V, содержащий информацию об этих событиях. Использование параметра глубины анализа основано на той теоретической предпосылке, что одно событие, происходящее в течение определенного временного промежутка, может являться причиной другого события.In addition to the background conditions, an analysis depth parameter is set for each rule.

defining a time interval T during which information about security events is collected from the specified data source, and a data volume V containing information about these events. The use of the analysis depth parameter is based on the theoretical premise that one event occurring during a certain time period can cause another event.

Typically, the unit of time interval T is 1 minute, and a typical time interval for data collection is 1 day. The time limit is associated with the following: about 70% of the correlation rules work with events that occurred during the day, 20% - up to one week, 5% - no more than a month. The remaining - in the interval of a quarter or six months.

The data volume V for the rule is determined by the number of significant fields from the logs of this source used for correlation analysis of signs of distributed security events. At the initial stage, V is set to the minimum size. For example, the analysis of data from the security log of the Windows 7 operating system usually has V _i = 2 (Table 1), which is often enough to analyze local incidents.

This is due to the fact that in an average audit system, a stream of events equal to 8000-10000 events per second (Event per Second, EPS) is considered normal, while the total amount of data from 50-80 sources, taking into account different types of events and a set of considered fields, can reach tens of thousands of EPS, which puts a significant strain on the system.

At the same time, to identify distributed security incidents, it is often necessary to consider the extended composition of the fields of the logs, and the data volume can be significantly increased, for example, to V = 5 (Table 2).

The H parameter for all rules is set by the security administrator. The main goal is to determine the average values of the amount of data on distributed security events that must be obtained for analysis from different sources at different time intervals (working day, night, weekend, etc.).

If necessary, at further stages of data processing, the analysis depth for each rule can be increased up to the maximum values determined by the largest number of fields in the logs and the longest period of time during which security events in the IP are monitored.

In the procedure for generating a significant set of correlation rules (Fig. 2) at the stage of deployment of the security system, the security administrator, based on his knowledge, sets the initial set of rules for identifying signs of destructive security events. To do this, form the initial list of correlation rules containing the set of possible signs (p) of the detected event or the combination of several security events (310).

In general, correlation rules are built on the basis of patterns and are expressions in the form

B = A ₁ AND ... AND A _n ,

where A ₁ ... A _n , B - predicates,

in this case, predicate B is the target (THEN ACTION) part, A ₁ AND ... AND A _n is the conditional (IF) part, combining the signs of various events (a set of events) and background conditions for a given IP.

When forming the rules, Boolean operators (AND, OR, NOT) are used.

The formation of the rules of the initial set is carried out by the security administrator on the basis of information about the structure and composition of the protected information system, the operating systems used in it, application software and information protection means, i.e. about the elements from which data will be collected. In this case, standard correlation rules, including those developed earlier, can be used.

The signs of those events that affect the general security of the entire information system or its individual element are determined as signs of security events to be detected. For example, the safety events included in the correlation rules include data:

• about attempts to change account authority;

• about the login of one user under different accounts;

• about exceeding the average connection time between nodes;

• about a large number of nodes in the organization’s network trying to connect to the same external resource.

The initial (initial) set includes three types of rules.

1. Rules that describe the symptoms of a security incident consisting of a single security event. For example, a rule issues a danger signal if a critical service is stopped (paused) on a monitored server:

2. Rules that describe the symptoms of a security incident consisting of several consecutive security events that have occurred over a given period of time. For example, if you receive a signal from an anti-virus protection tool and detect a subsequent network scan from the device (host) on which the antivirus worked. To identify such a security incident, including distributed security events, in the generated rule it is necessary to connect the signs of network scanning and virus detection:

3. Rules that identify the signs of a security incident based on the identification of deviations (anomalies) from the average activity values of a device (program) for a certain period of time. For example, a rule monitors the excess of the average antivirus response for a quarter:

At the next step, from the initial set, significant rules are selected into the current set, on the basis of which the relationship between the signs of security events will be searched.

For this, an estimate (311) of the number of rules in the original set is performed. If there is only one rule in the list, then it will immediately calculate (312) the Q score, which reflects the degree of taking into account the signs of a security event by this rule

,

,

where n is the total number of correlation rules included in the current set;

m is the total number of signs of security events taken into account by the rules from the current set;

p _i - the number of signs of security events taken into account by the i-th rule;

- весовой коэффициент k-го признака, учитываемого i-м правилом;

- the weight coefficient of the k-th characteristic taken into account by the i-th rule;

- суммарный коэффициент уверенности для всех учитываемых правилом фоновых условий;

- total confidence coefficient for all background conditions considered by the rule;

,

,

moreover

,

,

определяются заранее экспертным методом при составлении правил администратором безопасности в зависимости от используемых моделей защищенности ИС и описаний уязвимостей программного обеспечения. Таким образом, чем большее количество признаков учитывает конкретное правило, и чем они значимее, тем более весомую оценку Q будет иметь данное правило.Characteristic weights

determined in advance by the expert method when drafting the rules by the security administrator, depending on the used IP security models and descriptions of software vulnerabilities. Thus, the more features a particular rule takes into account, and the more significant they are, the more significant Q will be given by this rule.

If several rules are included in the list, then a similar estimate of Q is calculated for each of them (313), but for subsequent selection (318), rule (314) is selected, which has the highest rating among the rules being checked

Q _i = max (Q _1, ..., Q _n )

The remaining rules additionally check (315) for the presence of actual accounting in the signature of the rule for background conditions. If background conditions are used in the rule, then they are checked (316) for the correctness and completeness of the description for this IP. If the required background conditions are not completely taken into account by the signature of the rule, additional background conditions are connected (317) and Q estimate is re-calculated (312). Additional background conditions are connected by the security administrator using the expert method.

However, some rules may include a small number of signs, which may be due to both the feature of the signature of the security event being investigated and the insignificance of the rule itself. In the latter case, this leads to an unreasonable increase in the total volume of rules and, as a consequence, a decrease in the speed of data analysis.

Therefore, to reduce the number of unimportant rules in the generated set, the estimate of all the selected rules Q is additionally compared (318) with the threshold level Q _threshold . The threshold assessment is set by the security administrator within 40-70% of the maximum possible value level (Q _max ), which allows limiting the growth of memory consumption - because each analyzed signature of a security event requires a separate process for its maintenance.

The rules are also compared with the threshold level if their signature does not require the use of background conditions (315) or already correctly takes into account all the background conditions required for a given IP (316).

When satisfied with the assessment of the degree of accounting for the signs of a security event for the ith correlation rule for a given requirement (318), it is included in the current set of rules (319), otherwise it is deleted from the original set (320). At the next stage, possible conflicts between selected from the initial set of correlation rules identify and eliminate potential conflicts (Fig. 3). This is due to the need to level the subjectivity of the security administrator when setting the rules, as well as to select the set of the most effective rules from the number formed earlier, taking into account changes in the configuration and structure of IP.

To this end, from the set of attributes (319) obtained after evaluating the accounting for features, those rules (331) are selected that simultaneously contain “identical” signs of a destructive event or a set of security events, and a conflicting set of rules is generated (332).

For each ith rule of the conflicting set, (333) the coefficient of "novelty" Z _{i is} evaluated, which reflects the proximity of the signs of security events considered by this rule to the signs taken into account by all other rules from this set. To do this, calculate the product of pairwise coefficients of coincidence of signs of the i-th rule with the signs of each of l rules included in the conflict set

,

,

where p _i , p _j - the number of signs of security events taken into account by the i-th and j-th rules, respectively,

- количество совпадающих признаков, включенных одновременно в j-е и i-е правила корреляции,

- the number of matching features included simultaneously in the j-th and i-th correlation rules,

l is the number of correlation rules selected in the conflict set;

The higher the rule’s value of the Z coefficient, the more features it takes into account coincide with the features taken into account by other rules. Priority is given (334) to the rules with the highest value of the coefficient Z - these rules dominate the rest and are stored in the generated set (335).

If the rules do not meet this requirement or when several rules have equal priority (337), they compare (339) the rules according to the “specificity” criterion S _i , which reflects the number of signs of security events loaded into the working memory for checking:

,

,

where p _i is the number of signs of security events taken into account by the i-th rule,

max (p ₁ , ..., p _n ) - the largest number of features taken into account by one of the rules included in the current set.

Here, preference is given to that rule, the application of which requires checking the greatest number of signs of security events (340), the remaining rules are removed from the set (338). From the selected rules, a valid (conflict-free) set of correlation rules is formed (336).

After eliminating conflicts in the formed set, the actual value of the analysis depth H is adjusted for all its rules (Fig. 4). Since the parameter H is set by the security administrator and determines the average values of the amount of data on distributed security events received for analysis from different sources at different time intervals, this procedure allows the security administrator to control and, if necessary, specify priorities in the investigation of distributed computer security events and , therefore, increase confidence in the detection of information security incidents.

и повторяют проверку (341) фактического значения глубины анализа H_i. При необходимости на дальнейших этапах обработки данных глубина анализа для каждого правила может увеличиваться вплоть до максимальных значений.At this stage, check (341) of the actual value of the analysis depth H _i for the i-th rule is performed. If a rule has an analysis depth corresponding to a given level (342), then it is included in the current set of correlation rules. If the rule being checked has an analysis depth less than a specified level, the security administrator increases the analysis depth by one step

and repeat the check (341) of the actual value of the analysis depth H _i . If necessary, at further stages of data processing, the analysis depth for each rule can increase up to the maximum values.

Then (Fig. 1) to conduct correlation analysis of the data in a random, equally probable way, from the entire valid set of rules, one significant rule is selected and the interconnectedness of the signs of events (300) is checked both within the same data set and from different (including time) sets . If a latent relationship between distributed security events (400) is detected, an information security incident warning message (500) is issued.

If during the correlation analysis of the data the interconnectedness of events is not revealed, then the following correlation rule from a significant set is applied.

Once an incident is detected, an analysis of the causes of the security incident is performed (600). The data associated with the incident is determined: computer and active network devices, on which the events that caused the security incident were recorded, and the user authorized on this computer device.

Thus, the additional use of correlation analysis allows, on the basis of a set of rules, to identify causal, complementary, parallel or interrelated relationships between various security events that are carried out with the aim of attempting unauthorized access to protected IP information resources or attacking them, thereby reducing the number of undetected ones other ways of computer security incidents. And the specialized procedures introduced: the selection of significant rules, the identification and elimination of conflicts among the selected rules, as well as the verification for each rule of compliance with the actual analysis depth given, allow you to create a valid set of significant rules for this stage.

Next, they search and apply a solution to eliminate the consequences and prevent the event (group of events), defined as the cause of the security incident (700).

A solution to eliminate the consequences and prevent a security incident corresponding to an event (group of events) is at least one of the measures:

• change in security policy;

• removal of malicious code or backup software recovery;

• blocking the actions of the violator;

• changing the configuration of user computer protection means.

At the final stage, a computer security incident report (800) can be generated, including a description of the incident itself and the events that led to its occurrence, as well as the adopted and recommended protection measures.

Brief Description of the Drawings

In FIG. 1 shows a flowchart of a method for investigating distributed events in information systems with a separate step in the correlation analysis of data on distributed security events.

In FIG. Figure 2 shows a flowchart of the procedure for generating a meaningful (effective) set of rules for the data correlation procedure in the investigation of distributed information security incidents.

In FIG. 3 shows a flowchart of a conflict resolution procedure in the generated set of rules for investigating distributed computer security events.

In FIG. 4 shows a flowchart of a procedure for increasing confidence in the detection of information security incidents.

The implementation of the invention

Consider an example of implementations of the proposed method in a network information system including a security server and user computers, as well as active switching equipment.

As a security server, you can use a regular computer or a computer in the server version, having an increased amount of RAM and hard disk and a server operating system.

The means of collecting data from users' computers, analyzing security events, recording security incidents, and finding solutions that are part of the security server are software-based and are a complex of security application software (KPPOB) installed on the server. KPPOB provides the necessary functions required to implement the proposed method, and can be developed by a programming specialist (programmer) based on the information about the purpose of the functions.

The agents for collecting data from the registration logs (OS and information protection means) and transferring them to the security server, which are part of user computers, are also software-based and are application software (software) installed on the user's computer. The software provides the necessary functions required to implement the proposed method, and can be developed by a programming specialist (programmer) based on the information about the purpose of the functions.

For an example of the implementation of the proposed method for investigating distributed computer security events, we consider the use of a data correlation procedure to identify a distributed (network) security incident based on exploitation of vulnerabilities CVE 2014-6271, CVE 2014-6277, CVE 2014-6278, CVE 2014-7169, CVE 2014-7186. The essence of the vulnerabilities is that the bash shell allows you to set environment variables within itself that define the definition of functions. And after defining the function, the bash interpreter continues to process all the commands. As a result, the attacker gets the opportunity to carry out an attack with the introduction of destructive code on a computer running a Unix-like OS. However, this attack is not recorded by separate means of information protection, since it is a distributed security incident, including several stages of implementation, which explicitly do not have internal logical connections.

At the first stage of the proposed method for investigating distributed computer security events, for the formation of the initial set of correlation rules, it is necessary to determine the background conditions with the corresponding confidence coefficients, therefore, for example, the following are selected as such:

1. Application on a network device (server, host) of the Linux operating system (OS X, Unix, etc.), confidence factor CF ₁ = 0.1.

2. The use of the bash shell in this OS, confidence factor CF ₂ = 0.2.

3. Using bash shell version 4.2 or 4.3, confidence factor CF ₃ = 0.3.

4. The absence in the installed OS of a patch that eliminates the vulnerability of the bash interpreter, confidence factor CF ₄ = 0.4.

, выполняемого правилами. При этом могут быть выбраны:Next, determine the depth of analysis

executed by the rules. In this case, the following can be selected:

time interval for data collection: T = 1 min, so this attack is often carried out simultaneously, without spacing in time, and, therefore, immediately set a large depth is impractical;

the amount of data obtained from the Linux OS logs (OS X, Unix, etc.), V = 5. Depending on the type of OS, the fields of the corresponding logs may be different, but they should contain information about the execution of the process (for example, starting the bash shell or changing file access permissions):

Event Code, Keywords, System Time, User, Process ID

) могут быть определены:Then form (Fig. 2) the initial set of rules (signatures) for correlation analysis by setting the set of sets of signs of distributed destructive security events that describe the exploitation of vulnerabilities (310). As such signs (with corresponding weighting factors

) can be defined:

• single character sequences of executable code:

; (весовой коэффициент w=0,1);(1) to search for vulnerabilities

; (weight coefficient w = 0.1);

(весовой коэффициент w=0,1);(2) to search for vulnerabilities

(weight coefficient w = 0.1);

; или

; (весовой коэффициент w=0,1);(3) to search for vulnerabilities

; or

; (weight coefficient w = 0.1);

• repeated repetitions

- символа «EOF» или слова «done» (весовой коэффициент w=0,1).(4) to search for vulnerabilities

- the symbol “EOF” or the word “done” (weight coefficient w = 0.1).

In addition, if the incident aims to attack the web server, then the following can be additionally defined as signs:

(весовой коэффициент w=0,05);(5) character sequence -

(weight coefficient w = 0.05);

(6) IP address of the server included in the protected IP (weight coefficient w = 0.05).

If the incident is carried out through the implementation of the code using the SMTP protocol, then the following can be additionally defined as signs:

(весовой коэффициент w=0,1).(7) code sequences -

(weight coefficient w = 0.1).

If the security incident involves executing an active load on the user's computer, then additional command signatures can be defined as signs

(весовой коэффициент w=0,2);(8) to increase the permissions for the executable file -

(weight coefficient w = 0.2);

(весовой коэффициент w=0,1);(9) to run this file for execution -

(weight coefficient w = 0.1);

(весовой коэффициент w=0,01).(10) to delete a file after execution -

(weight coefficient w = 0.01).

Rules are drawn up in any format convenient for automatic processing, for example, XML format.

Let 3 rules be included in the initial set of correlation rules based on the selected features.

Rule No. 1 is a typical one, focused on identifying the signs of any security events that use these vulnerabilities:

Rule No. 2 - specialized, aimed at identifying signs of distributed security events that use these vulnerabilities to infect a web server (including through email services):

Rule No. 3 - specialized, aimed at identifying signs of distributed security events that use these vulnerabilities to implement and execute arbitrary code on a user's computer:

Next, the security administrator sets the threshold value Q _threshold = 0.3, and for each rule, a Q score is calculated that reflects the degree to which the signs of security events are taken into account by this rule: Q ₁ = 0.096, Q ₂ = 0.18, Q ₃ = 0.513.

Rule No. 3, as having the highest score, which at the same time exceeds the threshold value (318), is immediately included in the current set of correlation rules (319).

For the rest of the rules, the actual accounting is checked in the signature of the background conditions (315). Due to the fact that both rules (No. 1 and No. 2) already contain background conditions, they are additionally checked for correctness and completeness (316) of the description of background conditions for this IP. According to the results of the verification, background condition No. 4 is connected to each of the rules and the estimate is re-calculated, which reflects the degree of accounting for the signs: Q ₁ = 0.16, Q ₂ = 0.3.

Evaluation of rule No. 2 after connecting an additional background condition at the same time also meets condition (318), therefore this rule is also included in the current set of correlation rules.

Due to the fact that both rules (No. 2 and No. 3) contain “identical” signs of a set of security events, they form a conflicting set of rules (332) and evaluate the “novelty” coefficient Z for each of them (333). But there are only two rules in the conflict set, therefore both have equal priority: Z ₂ = 0.67, Z ₃ = 0.67. And at the next stage, these rules are compared according to the “specificity” criterion (339): S ₂ = 0.667, S ₃ = 1.

According to the results of the assessment, which reflects the number of signs of security events loaded into the working memory, preference is given to rule No. 3, and rule No. 2 is removed from the conflict set (338).

, и затем повторяют проверку (341) фактического значения глубины анализа H₃. Цикл повторяют два раза, чтобы достичь заданной глубины анализа Н_зад. После чего правило включается в действующее множество значимых правил корреляции (343).After resolving the conflicts in the generated set for the selected rule, the actual value of the analysis depth H ₃ is adjusted (Fig. 4). Since rule No. 3 has an analysis depth less than a specified level, the security administrator increases the analysis depth (344) by one step

, and then repeat the check (341) of the actual value of the analysis depth H ₃ . The cycle is repeated two times to achieve a given analysis depth H _ass . After that, the rule is included in the current set of significant correlation rules (343).

The main stage of the implementation of the method is as follows.

First, the information system is launched.

After the launch, the information protection tools installed on users' computers and active network equipment independently detect and monitor, based on the algorithms built into them by the developers, the signs of local security events known to them that could constitute a security incident. At the same time, data collection agents from the software on users 'computers and active network equipment begin to download data on system events from all users' computers, network devices, and security equipment into the data collection tool of the security server (for example, using the Syslog protocol).

The collected data is transmitted to a data analysis tool for subsequent analysis of security events by searching for events preceding the incident.

All data collected from the logs lead to a single view through normalization and are divided into categories, for each of which determine the priority level. This is necessary to associate a specific security event with IP security models and vulnerable software rests.

In this case (example), priority will be given to data from the logs for registering network security devices (firewall, intrusion detection tool, i.e., analyzing network traffic), as well as operating systems installed on the web server and user's computer.

If a security incident is registered, the information security tool that identifies the incident sends an alarm to the security server. A means of analyzing security events from the structure of KPPOB determines one system event that is the cause of the incident, an authorized user and the computer device on which the event that caused the incident was recorded. And then a subsequent search and decision is made to change the security policy with the generation of a report describing system events, their history and decisions made.

If the information security means at this stage are not identified among the local security events that occurred in the IS, then the security event analysis tool additionally conducts a correlation analysis of the collected data according to the rules, including signs of distributed security events.

To do this, use a significant rule (No. 3), previously included in the current set. The specified rule is loaded into the memory of the incident analysis tools and the signatures of the attributes contained in this rule are compared with the data sets collected from the logs.

If only one of the signs of the security event coincides, they include a counter that counts the number of matches according to the same attribute (for example, attribute No. 4) during the time period in accordance with the specified analysis depth. If during this period of coincidence of signs no longer identified counter is reset. At the next match, the counter turns on again.

If, among the registered data, all the signs that are included in the signature of the correlation rule are identified and all background conditions for this rule are fulfilled, then the data analysis tool sends a hazard warning signal.

If no matches are found, the subsequent rules are loaded in turn and their signatures are checked for compliance with the data being analyzed.

After the distributed incident of computer security is detected by means of the analysis of security events from the KPPOB, all system events that cause the security incident, computer devices on which the events that caused the incident were recorded are determined. And then a subsequent search and decision is made to change the security policy with the generation of a report describing system events, their history and decisions made.

It should be noted that the information provided in the description are only examples that do not limit the scope of the present invention described by the formula. One skilled in the art will recognize that there may be other embodiments of the present invention consistent with the spirit and scope of the present invention.

Information sources

1. RF patent No. 2477929, 2011, IPC G06F 21/30

2. US Patent No. 7647622, 01/12/2010

3. US Application No.20100125911, 05/20/2010

4. RF patent No. 2481633, 2009. IPC G06F 21/55

5. Kruegel Ch., Valeur F. Intrusion Detection and Correlation. Challenges and Solutions. Springer Science + Business Media, Inc., 2005. ISBN: 0-387-23398-9. [Access Mode]: http://link.springer.com/book/10.1007%2Fb101493

6. Suslov V.I. Econometrics, Novosibirsk, SB RAS, 2005.

7. Mat Jani, N. Applying case reuse and rule-based reasoning (RBR) in object-oriented application framework documentation: Analysis and design. - Human System Interactions, 2008 Conference, pp. 597-602, ISBN: 978-1-4244-1542-7. [Access Mode]: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4581508&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4581508

Claims (38)

1. A method for investigating distributed computer security events in an information system including a security server and user computers, the security server comprising: data collection means configured to download data about system events recorded on users' computers, wherein the data collection means is associated with an incident analysis tool; incident registration means configured to extract at least one system event from the downloaded data that caused the security incident, wherein the incident registration means is associated with an incident analysis means and a data collection means; incident analysis tool configured to: identifying the computer on which the event causing the security incident was recorded; definitions of the user authorized on the user's computer; Search for events prior to a registered security incident; determining at least one system event that is causing the incident; solution search engine configured to search for a solution to eliminate the consequences and prevent a recurrence of an event corresponding to a registered security incident, wherein the solution search engine is associated with an incident analysis tool; reporting tool designed to generate a report containing at least a description of system events, the relationship of events, a chronology of events, solutions found and solutions applied; moreover, the method consists in the fact that: upload data about system events from all user computers to the security server; register among these events at least one system event that caused the security incident; analyze downloaded events by searching among them for events that are similar to events preceding an already registered security incident; carry out a correlation analysis of data on events distributed by time and place, using additional rules, including the following actions: set the background conditions and level of analysis depth; form the initial set of rules for performing correlation analysis; select the relevant rules into the current set; identify and resolve conflicts among the selected rules; check for each rule from the current set the correspondence of the actual analysis depth to a given; search and apply a solution to eliminate the consequences and prevent a security incident; if a correlation between the distributed events is detected, then a search and application of a solution is also carried out to eliminate the consequences and prevent the event or group of events identified as the cause of the security incident; generate a report on the security incident, including a description of the incident itself and the events that led to the occurrence of the security incident, as well as the measures taken and recommended. 2. The method according to claim 1, in which data on system events downloaded from user workstations are stored in binary form. 3. The method of claim 1, wherein the security incident is at least one of the events: violation of security policies; malware detection; detection of unauthorized access to information resources; attempts to establish a connection on closed ports; attack from a compromised host. 4. The method according to claim 1, in which, in order to conduct correlation analysis of the data in a random, equally probable way, from the entire valid set of rules one significant rule is selected and with its help the relationship of the signs of events is checked both within the same data set and from different sets. 5. The method according to p. 1, in which if during the correlation analysis of the data the interconnectedness of the events is not detected, then the following correlation rule from the current set is applied. 6. The method according to claim 1, in which, if correlation analysis of the data reveals a relationship between security events, then their relationship with a possible security incident is also recorded. 7. The method according to claim 1, in which the solution to eliminate the consequences and prevent a security incident corresponding to an event or group of events is at least one of the measures: security policy change; malware removal or software backup recovery; blocking the actions of the violator; changing the configuration of security features on users' computers.

Images