Compliance with standards and policies in vulnerability scanners and SIEM

The term compliance in English means compliance to one of the high-level standards (such as SOX, PCI DSS, Basel II, GLBA). It is necessary to check for compliance with these documents in order to determine how well your organization complies with the requirements described by these standards (the allowed length of passwords, the presence of internal regulations and policies, the time taken to eliminate vulnerabilities, etc.).



In addition to international standards, there are their domestic counterparts, corporate policies and NIST requirements. It is also necessary to conduct an assessment of compliance with these documents. Standards contain sets of requirements: meeting all the requirements of the standard actually means compliance with it. An example of a separate requirement: “There must be a disciplinary process for employees who have made a breach of protection” (ISO / IEC 2005 A.8.2.3).



Conducting a compliance check is necessary not only for reporting: the more requirements are met, the higher the level of security and the lower the risks of financial loss in case of threats. Obviously, it is necessary to ensure compliance with the standards continuously and continuously - otherwise, during the next audit, you will have to spend a lot of energy and nerves to make hasty changes in configurations and infrastructure in accordance with the requirements.

')

How to conduct a compliance check

In the course of ISO 27001 auditors, I had the opportunity to meet the employees of the information security department of one organization who, when checking compliance, used the standard 27001, but assessed compliance and calculated risks in an Excel table. The spectacle is not for the faint of heart, I confess to you.



Of course, you can check the compliance with similar images by writing out the requirements of the standard on a sheet of paper or in Excel. You can use special software in which employees responsible for certain aspects of security will answer typical questions: “Yes, no, I don't know.” But how reliable will the information received be? Are you sure that the domain administrator really set the minimum password length to 7 characters? Are you really sure that this administrator did not make a fake screenshot, and then did not return the group policy settings to the state that he (!) Considers necessary? Some of the requirements can only be verified with the help of a survey of employees, but the fulfillment of the remaining requirements can be checked with automated means.

Types of requirements

Requirements are divided into technical and non-technical. The technical requirements include the information that can be checked using automation tools (by running the command in the console, using the configuration file parser, using the registry parameter).



Let me give you a simple example of a technical requirement mentioned in most standards: PCI DSS 8.5.10 “Requirements 5.1. “Deployed anti-virus software (particularly personal computers and servers)”.



Non-technical requirements, respectively, check using automation will not work. An example of such a requirement is the above-mentioned ISO / IEC 2005 A.8.2.3.



No standard can be fully described using technical requirements alone. In the absence of automation, we can all consider them non-technical. It becomes possible to automatically check the requirement - it becomes technical. The more such requirements we can analyze (check their fulfillment in the system), the more quickly we can reduce the risks by eliminating the inconsistencies.



It is necessary to immediately clarify that the compliance verification process is generally divided into compliance (without the standard prefix; this means compliance with high-level standards by default), regulatory compliance (requirements of supervisory authorities, for example, STO BR IBBS) and policy compliance (compliance with policies, whether corporate policy or NIST). All of these terms in this article will be understood as “checking for compliance with standards (policies)”.

From standards to policies

What to do if you do not need any standards, but you want to monitor compliance with information security policies?



The concept of "compliance check" is applicable not only for high-level standards (ISO, NIST guidelines, SOX, Basel II) and NIST guidelines, but also for internal company policies. Many corporate policy requirements are made up of standards. This means that it is possible to distinguish technical requirements from the standards described in your corporate IS policy, integrate them into a policy and track it already.



Another question is how to automate the process of receiving and processing requirements to assess compliance with the standard? The answer is simple: with such automation tools as vulnerability scanners, systems of the CMS class (compliance management system), SIEM or, in extreme cases, self-written scripts.

How it works?

For CMS and vulnerability scanners in the task for scanning compliance with a specific standard, the IP addresses of the organization's information systems are determined. Then the system is scanned to determine compliance with the requirements of the selected standard (as a rule, the scanner obtains all the available data), after which an assessment is made as to whether all the technical requirements of this standard are fulfilled on the selected assets.







As a rule, the system has a list of available standard templates with a predefined set of requirements that can be selected for conformity assessment. If something is missing, you can purchase a license for the missing standards from the scanner manufacturer or develop your own.

Develop your own standard

In vulnerability scanners with the function of checking compliance with standards, it is possible to create your own standard from scratch or based on an existing one. In the creation process, you can override the values ​​that are checked within the requirements or add your own.



Adding your own requirements is possible thanks to flexible verification mechanisms. In each system, the requirements consist of one or more checks. As a rule, these checks are implemented using several scenarios with different methods and transports (WMI, RPC, etc.). With McAfee VM, for example, some of the scripts stored in the database look like Figure below.







However, we do not need to dig into the database and generally know what script it is checking. Software vendors typically provide a graphical interface for handling requirements. In our new standard or policy, we can include almost any technical requirements and redefine the values ​​of their parameters.







If there is no such interface, then at least documentation should be available for creating your own standard (for example, in XML format). A little effort - and a unique standard that reflects the requirements for information security in a particular organization, is ready.

SIEM

Now let's talk about SIEM. Some concepts related to such systems, we discussed earlier in our blog:



1) What is SIEM http://blog.ptsecurity.ru/2012/10/siem.html

2) What is the integration of SIEM and the vulnerability scanner http://blog.ptsecurity.ru/2012/10/siem_1.html

3) What are signature correlation methods http://blog.ptsecurity.ru/2012/10/siem_17.html

4) How to manage IS incidents http://blog.ptsecurity.ru/2012/11/blog-post.html



Now let's ask ourselves why, in principle, compliance checking is needed in SIEM. What does this process mean in SIEM? And why not use only vulnerability scanners and compliance management systems for such verification?



First, the standards have requirements for logging part of the events associated with accounts, access to objects, changing group policies, etc. Monitoring these requirements is also necessary, since it is possible to check whether these types of events are received in our SIEM .



Secondly, unlike various scanners, SIEM systems continuously receive information that can be used to dynamically assess conformity in real time. How quickly will you learn about disabling anti-virus protection on your server or changing the domain policy? In such situations, the launch of a scanner, as a rule, loads the network and information systems, since the process of checking compliance with a standard (for example, PCI DSS) often entails scanning for vulnerabilities (and this is a huge load that can “drop” your production system).



SIEM in this case acts as a passive source of data on compliance with a particular standard, received in real time: the problem of journal management is eliminated. At the same time, we have the opportunity, on the basis of incoming data on various events, to determine what exactly leads to a mismatch. Further, compliance with a specific requirement of the selected standard is checked, and if a discrepancy is found, a notification is sent to the administrator of the information system.



In addition, if incident management is carried out in the system, then the responsible officer will also be given the task of eliminating the inconsistencies.



Sounds nice, doesn't it? Now back to our SIEM-systems and see how they, in fact, assess the compliance with a particular standard.



High-level standards involve the collection and storage of information about certain events (listed in the table).







Taking into account individual standards, the following picture is obtained.







I repeat once again: the emphasis here is on the collection and storage. We will not see anything similar to “analysis”, “audit of the data obtained” (not to be confused with “audit of the entrance to the system”, this is ordinary data from the logs).



If you expect that the result of the control of compliance with the standard using the SIEM will be a message “Set minimum password length” with indication of the corresponding or non-relevant requirement, you are unfortunately mistaken.



After running a test for compliance with any high-level standard from the list of available in the SIEM system, the report will only receive a list of events and systems broken down by requirements or (at best) a report on events within this requirement (for example, Data flows).











From this we can conclude that SIEM-systems are not intended for conformity assessment, but are needed as a technical tool to comply with certain requirements of standards for collecting and storing events and have only the functionality of track @ report.



Of course, there are exceptions, but they are few. Some vendors are trying to partially extract useful information from incoming events that affects compliance with standards. In this case, the requirements are correlated with the SIEM correlation rules. In this case, one requirement corresponds to several rules. This is explained by the fact that a specific fact (for example, changing the minimum password length in a domain policy) may include many events from different data sources, and the content of the event itself may be different.



In addition, in the event log of each data source, a specific event can be described by various service words, with different event_id.







However, performing a compliance check in this way requires too many resources, so the SIEM developers reject this idea.



Why are there difficulties in implementing a full-fledged analysis for compliance? Briefly consider the main reasons.



The first reason . SIEM lacks the concept of an object. Here you can recall the correlation method “MBR model based reasoning”, described in a previous article . Using this method, for example, it would be possible to describe the state of an object, leading to a mismatch.





The SIEM model stores events, categories and classes of events, statistics. However, there are no facilities or assets (although this concept does not exist for the SIEM).



The second reason . In the SIEM-systems of most manufacturers, events are not normalized (they are not reduced to one standardized form), therefore, a large number of logical correlation rules need to be compiled. This, in turn, leads to the irrationality of the drafting of full-fledged standard compliance.



Why it happens? All manufacturers strive to meet the NIST 800-92 requirement (“Original event is preserved and have not changed data during normalization”) and, in order to ensure that the original events remain unchanged, they are stored in the RAW format.



What to do? Alternatively, use the CEE standard ( http://cee.mitre.org ). This will standardize events without conflict with NIST 800-92.



In SIEM, it will not be possible to describe all the technical requirements of the standards for one simple reason: the requirements values ​​are not transmitted in events from sources. Accordingly, SIEM without additional functionality of the scanner in the SIEM-agent will not receive these values. However, the trend now is the use of non-agent technology. In spite of everything, using SIEM, you can track most of the state of requirements in real time. SIEM developers need only take a step to correct errors.



I hope that in this article I managed to dispel the myth of compliance testing in SIEM systems, as well as give an idea of ​​the concepts of standard compliance, policy compliance, regulatory compliance.



See you in new publications! We are waiting for your questions and comments in the comments.



Author: Olesya Shelestova, Research Center Positive Research.