What is vulnerability analysis for OUD 4 and why is it needed

Vulnerability analysis according to OUD 4 is a mandatory service performed to assess the level of security of information systems (IS) classified as the fourth level of security in accordance with the classification of the FSTEC of Russia. DMS 4 covers IP systems that process data of limited importance and are not considered critical resources, but they still require organizational and technical protection against information security incidents.

This category includes:

• Information systems of educational institutions, municipal organizations, local IP of small and medium-sized businesses;
• Services that do not work with state secrets or personal data, but integrated into government information networks or infrastructure with limited access;
• Web platforms that interact with a limited number of registered users without access to critical data;
• IT systems that participate in public procurement, but do not directly affect the CII facility or ISPs of levels 1 and 2.

Vulnerability analysis according to OUD 4 is prescribed by the current legislation and regulations of the FSTEC of Russia. This is not a voluntary measure, but a requirement of the technical documentation applicable to organizations whose system has been classified according to the threat model and security level. Violations of the requirements may result in sanctions, suspension of activities, or rejection of IP certification.

Ignoring the procedure leads to the following risks:

• Refusal to certify the information system and inability to operate;
• Fines of up to several hundred thousand rubles under articles of the Administrative Code of the Russian Federation;
• Increased likelihood of system compromise due to unknown vulnerabilities in applications, DBMS, ISMS, web servers or storage systems;
• Undermining the trust of regulatory authorities and customers.

The OUD 4 security analysis provides a reliable picture of the current state of the system in terms of protection against unauthorized access, helps to identify critical vulnerabilities in a timely manner and document compliance with FSTEC regulations. This is a conscious risk management measure — not a formality, but a technically and regimentally verified process.

FSTEC requirements for vulnerability analysis: what needs to be done

The FSTEC of Russia imposes specific requirements for conducting vulnerability analysis at the fourth security level. They are set out in the document "Order No. 239 of the FSTEC of Russia" and related methodological recommendations. We also use up-to-date vulnerability databases, including international ones (for example, NVD) adapted to Russian realities.

The main provisions relate to the following aspects:

• Frequency: the analysis is performed at least once a year, as well as in case of significant changes in the IP configuration: software updates, new components, OS changes, network architecture.
• Data relevance: the use of fresh vulnerability databases is mandatory. The tools should identify vulnerabilities based on the current threats identified in the system-wide security model.

The form of the analysis is divided into three key approaches:

1. Static analysis: the study of the source code of a software without executing it. It is suitable for scanning web applications, internal development modules, software components with access to sources.
2. Dynamic audit: the study of IP in the execution mode. It is used when it is necessary to emulate the action of threats in an operational environment, including testing using automated scanners.
3. Manual verification: expert verification of technical documentation, manual assessment of vulnerabilities found, analysis of the impossibility of false alarms of security tools, clarification of the threat context.

The objects of the analysis are:

• Databases and management applications;
• Operating systems, drivers, service utilities;
• Components of the built ISMS;
• Configuring routers and firewalls, VPN servers;
• Technical infrastructure: cluster servers, remote connections, cloud environments;
• The code of the website or web service, if it is part of the system.

The result of the analysis is recorded in a formalized report, which includes:

• A list of identified vulnerabilities, divided by severity;
• The methods used to identify them, with an explanation of the tactics used;
• Determination of possible consequences during their operation;
• Recommendations for elimination, specifying the configuration areas and responsible components;
• Correlation of risk with the documentation of the system and the model of the violator;
• Conclusions on the compliance of the system with the provisions of the FSTEC on OUD 4.

Thus, conducting vulnerability analysis in accordance with the requirements of the FSTEC — This is not a formal bureaucratic operation, but a precise technical procedure, strictly regulated by objects, information and assessment methods.

Who is required to analyze vulnerabilities in OUD 4

Vulnerability analysis according to OUD 4 is mandatory for all organizations whose information systems are classified into the fourth level of security according to the document of Order No. 239 of the FSTEC of Russia or the relevant provisions in the framework of building information security systems according to GOST and the threat assessment methodology.

These organizations include:

• Government agencies, implementing IT projects without working with state secrets;
• Municipalities and services that conduct electronic document management that is not included in the critical IT infrastructure;
• Commercial companies working on government orders, including enterprises with internal management systems;
• ISPDn operator services with Category 3 or classified as general purpose information systems with local access.

Indicators, indicating the need for analysis:

1. The system has been or is being prepared for certification by subordinate authorities;
2. The information system has VPN access, gateways, or network segmentation;
3. The IP processes service information of limited distribution;
4. A security audit or updating of the threat model was carried out;
5. The system has identified critical nodes: integration buses, authorization modules, and an API interaction server.

Even in the case of the apparent "low significance" of IP, if it formally falls under the classification according to the criteria of OUD 4, the obligation to perform vulnerability analysis remains in full and with the same reporting requirements as at higher levels.

What is the difference between OUD 4 analysis and other levels

Vulnerability analysis for OUD 4 differs from OUD levels 1-3 in the degree of depth and rigor. It focuses on the use of simplified models and methods, which allows organizations to perform verification without deep intrusion into systems or shutting down productive services.

Key differences:

• The predominance of passive analysis and verification checklists;
• No need to create an isolated testing environment (in most cases);
• The permissibility of combining automated and manual methods without the mandatory deployment of code analysis tools;
• The threat level is considered limited in scope — the actual intruder is not assumed to be a highly professional attacker with access to specialized exploits.

However, this does not reduce the importance of the procedure. — Non-compliance with the requirements may indicate a disregard for technical protection measures, which is fraught with sanctions along with higher levels of security.

How vulnerability analysis is carried out for MLM 4 — step by step

Vulnerability analysis according to OUD 4 is a set of technical and organizational measures aimed at recording the current state of IP security and identifying critical areas at risk of unauthorized exposure. The procedure is structured in stages and documented in accordance with the requirements of the FSTEC of Russia.

1. Collection and analysis of initial data

Before the start of the inspection, specialists form an idea of the structure of the system.:

• The IP architecture is being studied according to the technical documentation — The exchange interfaces, main and auxiliary services are defined.
• All software and hardware are listed: versions of operating systems, application servers, databases, frameworks, ISMS.
• Information is collected about access control policies, VPN availability, firewall rules, and backup.

This phase is critical: the quality of the security model depends on the completeness of the information system description. Errors or unreliable data here affect the reliability of the entire analysis.

2. Formation of a violator model and a list of current threats

Based on the information about the IP configuration, possible attack scenarios and the intruder model are determined. It must correspond to the security level of the DMS 4, that is, it must take into account potential threats from external intruders or unqualified internal users. The provisions of the FSTEC, threat libraries, as well as accepted practices of risk assessment in information security are taken into account.

3. Selection of tools and technical analysis

The basis consists of:

• Automated vulnerability scanners using up-to-date CVE, CWE, and CVSS databases (Common Vulnerability Scoring System — vulnerability severity assessment system);
• Code scanners or static analyzers, if the source code of the software part of the IC is provided;
• Tools for analyzing the security of network services, open ports, SSL configurations, and authentication protocols;
• Tools for evaluating application settings for misconfiguration, use of outdated libraries or open APIs.

Verification can be both active and verification—based, without creating an additional burden on the productive environment. In cases where services that work with a real user base are affected, preference is given to continuous analysis outside peak hours.

4. Manual verification and vulnerability classification

The automatic result is not final — problems are checked manually:

• False alarms are eliminated and potential threat vectors are confirmed;
• The risk is assessed in the context of the system: the presence of exploits, availability in the real environment, protection functionality;
• Each identified vulnerability is classified by criticality — from low to high according to the CVSS v3.1 scale;

If a highly critical vulnerability is detected, the analysis continues until it is proven to be irrelevant or measures are taken to eliminate it.

5. Preparation of accounting documentation

The final stage is the generation of a report that contains:

• A brief description of the system and the software used;
• A list of all discovered vulnerabilities, indicating the components and the versions in which they were found;
• Detection methods (scanners, code analysis, inspection of settings);
• CVSS risk level and threat characteristics (access, attack vector, intruder capabilities);
• Troubleshooting recommendations: updating, configuring, disabling a function, replacing a component;
• Conclusion on the compliance of the system with the requirements of OUD 4 — an unambiguous result or with a note about the need for changes.

The report is prepared in accordance with the requirements of the FSTEC and can be used as an evidence base for certification or audit.

6. The accompanying package

In addition to the report, the customer is provided with:

• Work methodology (internal standard),
• Explanatory letter with interpretation of technical terms,
• Applications with templates for implementing technical recommendations (if required),
• The initial CVSS rating table for each incident.

How to understand, that the analysis was carried out correctly?

The correctness of the analysis is confirmed:

• The presence of a complete list of components and software versions in the report;
• Transparent logic of vulnerability detection and a clear description of testing methods;
• Compliance of the report structure with the provisions of FSTEC Order 239;
• The relevance of the vulnerability databases and analysis methods used at the time of verification.

The document should be logically structured, specific and ready to be presented to regulatory authorities or information security partners.

What does the final report look like?: structure and significance of the document

The final report is an official document formalized for subsequent use as part of ensuring compliance with information security requirements, as well as as an evidence base for certification, certification or verification of the system.

The structure of the report includes the following mandatory sections:

1. General information — description of the information system, the purpose of the analysis, the means used, the date of the event;
2. The violator`s card and the list of checked components — a list of software, versions, and the IT infrastructure used;
3. The vulnerability table is a key section containing:

• Vulnerability name and CVE database number;
• Technical description of the problem, applied detection methods;
• CVSS scale assessment, including time and operational metrics;
• The degree of danger and possible damage;
• Recommendations for risk reduction;

1. Security Level Report — compliance or non-compliance with the requirements of the 4th security level, explanations of inconsistencies (if any), recommendations for elimination.

The document is used for the following purposes:

• To be provided to the regulator upon request;
• Within the company — to update protection measures, update regulations, and build change management plans;
• During re-certification after changes in the system;
• As part of the documentation when connecting new software or information exchange services — especially when interacting with banks or government facilities.

The vulnerability check for ODE 4 does not end with the creation of a report. When updating components or identifying new threats for CVE, it is advisable to review the report. In the case of software updates or the introduction of new modules, it will be necessary to promptly verify compliance with the new security provisions.

Responsibility for failure to perform vulnerability analysis

Neglecting the mandatory vulnerability analysis for OUD 4 entails legal and business consequences. Articles 13.11 and 19.7 of the Administrative Code of the Russian Federation provide for administrative liability for creating threats to information security due to inadequate protection.

For organizations, this means:

• Imposition of fines — from 50,000 to 500,000 rubles, depending on the scale of the discrepancy;
• Restriction of signing new government contracts in case of repeated violations of information security provisions;
• Prohibition on the operation of internal IP until the identified violations are eliminated;
• By the presence of vulnerabilities, the FSTEC inspector may recognize the IP as inadequate in terms of the level of the management system and require its refinement or certification from scratch.

In addition to sanctions, non-compliance with the procedure is considered as an indicator of the lack of proper control in the information security segment. This often affects not only the conclusion of the regulator, but also partner activities — organizations lose their reputational positions or are rejected by customers with stricter security requirements.

Why is vulnerability analysis for OUD 4 worth doing right now

The last two years have been marked by an increase in the number of on-site audits and an increase in the control procedures for systems classified according to the 4th security level. Changes in the legal field, including reforms in the field of critical information infrastructure and the expansion of the powers of the FSTEC, have put the obligation to conduct vulnerability analysis into practice.

At the same time, the number of incidents related to the exploitation of vulnerabilities in insignificant but poorly protected systems has increased — these incidents prove that a relaxed attitude towards DMS 4 is not justified.

A well-organized analysis service for OUD 4 — This is a way not only to meet the requirements of the FSTEC, but also to systematically assess the security of your IT infrastructure and identify vulnerabilities before they become incidents. And the most important thing is to carry out the procedure in the right format, on time and without unnecessary costs.