The security guard learns OUD. Application of EUD in automated process control systems. Part 1 (Safety Assignment)

1. Why?

Article (later a series of articles) is devoted to the phased development and application of safe development in the field of automated process control systems. This part talks about the projection of the methodology for developing a safety specification (GOST 15 408 Series) for an area where it is rarely (yet) used (I draw a conclusion about its rarity based on taking part in the testing of a wide range of products for industrial systems).

OUD has become very popular in the infrastructure of the Banking Regulator's sphere of activity and the procedure for certification of information security means from the FSTEC of Russia. The likelihood of its use of EDA in significant CII increases every year and sooner or later this topic will become relevant for developers of industrial automation systems and automated control systems.

According to GOST 15 408-3, the phasing of OUD implies starting with the development of documentation for the software under study, but as practice has shown, this is nothing, so we involuntarily switch to the stage of preparing for software testing, which implies preparing a security task.

I'll try not to shoulder all the exposition of the whole process at once (it's very scary there). For now, let’s start only with the “Security Assignment” stage. We will consider the remaining stages later….. I will accompany the corresponding stages with the results obtained based on the abstract example being studied.

2. Roadmap

First, let’s create a roadmap for the stage under consideration.

3. Examination

The examination is the most difficult part. If you have to work in several iterations as in the figure above, get ready for the fact that data acquisition will take place multi-iteration, and having a specialist who knows how to chat (interview developers) will be a big advantage. After receiving the first initial data about the system, it is necessary to immediately begin to identify the following paradigms for determining the object of assessment:

Part 1.

1. Why do you need an OO (you need to understand the meaning of your research);

2. Definition of modules (microservices or individual processes);

3. Determination of software components (clients, mobile applications, web portals, software packages, OS). It is convenient to denote this by subsystems;

4. The required tools for developing and supporting the OO, this can also include OS and software packages;

5. Defining role models of users and technical accounts;

6. Determining the nature of the transmitted data (PDN, technological data, trade secrets, etc.) and data transmission protocols;

We wiped off the sweat, took some nerve pills, and went to draw a structural diagram, recording the following:

Part 2.

1. We designate management functions;

2. We designate monitoring functions;

3. Possibility of data transmission/collection and direction of transmission/collection;

4. Possibility of data processing.

5. Description of existing SFRs

For all implemented functions, we immediately ask the developers to demonstrate the operation of the components in an explicit form.

Example

Part 1.

1. The server installed in the automated process control system LAN collects technological data at the CII facility.

2. Microservices: PSQL15, nginx, frontend-service (customer’s own development in python). FreeOpcUa is a separate service installed on the OO server. A set of libraries for OPC work. The user connection is made via a WEB browser. collection of technological data using SNMP/OPC UA.

3. Clients (sources of technological data), Users using the WEB portal, the Server itself. User Authorization Server, customer monitoring server (monitoring is carried out via SNMP/PING).

4. The language used is Python, which implies the presence of appropriate libraries in the OO. The operating system used is Astra Linux SE/CE version 1.6 and higher. A web browser for accessing the TOE from the user side. The OS administrator exercises control using SSH and the OS GUI interface, the administration of the software package is carried out locally (physically),

5. Automated process control system operator; industrial control system engineer; IS Auditor.

6. Technological data of automated process control systems, OPC UA.

Part 2.

We display the data obtained from points 1-4 of Part No. 2.

5.Next, it is necessary to describe all SFRs, but for example I will indicate only two:

4. Statement of conformity

We decide on the GOSTs to be used, approve the security profile used, or, more simply put, decide what indicators we are striving for and what set of documents we will actually generate. Moreover, on the Internet, a PROTECTION PROFILE for TYPE “D” FIREWALLS OF THE SIXTH CLASS OF PROTECTION from 2016 was found, which FSTEC of Russia most likely used for certification, despite the fact that OUD.1 was presented there, it was decided to go according to OUD.4 from -because of the popularity of this level and because of the peculiarities of the regulatory policy in the field of CII and the customer.

Example:

The assessment object and ST are developed in accordance with:

– GOST R ISO/IEC 15408-2;
– GOST R ISO/IEC 15408-3;
– FSTEC Order No. 239;
– Customer’s internal requirements

Confidence requirements are presented in the form of an estimated confidence level (EAL4).

5. Threat identification

Colleagues from the banking sector actively use threats from the protection profile according to the methodological document “Protection Profile of Application Software of Automated Systems and Applications of Credit Institutions and Non-Credit Financial Institutions.” But the methodology used is not close to us, and therefore we tried to form threats from the FSTEC BDU, and based on the generated model, determine the proposed protection measures.

It was decided to take a slightly more “modern” path to create threats, just as the protective measures used were determined by FSTEC resource.

Example:

In total, I received a list of measures (I listed only some of them for clarity):
AVZ.1.5 Checking, in near real time, objects (files) from external sources (removable computer storage media, network connections, including public networks, and other external sources) when loading, opening or executing such files;
AVZ.2.1 Application of anti-virus protection tools on proxy servers, mail gateways, mail servers and other access points to the information system that are susceptible to introduction (infection) by malicious computer programs (viruses) through removable computer storage media or network connections, including to networks public use (email attachments, web and other network services);
AVZ.3.1 Verification in a time scale close to real time of archived, executable and encrypted objects (files) when loading, opening or executing such files.;
…………………..

UPD.4.1 Separation of powers (roles) of users, administrators and persons ensuring the functioning of the information system in accordance with their job responsibilities (functions). Definition in organizational and administrative documents on information protection (documentation) of the powers (roles) of users, administrators and persons ensuring the functioning of the information system.”

6. We obtain the final set of technical specifications

We compare the actual TSF with the achievable security measures and voila, we get the final set of TSF. (Don't forget to add your own)

Example (I listed only a few):

7. Conclusion

I received the final conclusion of the FTB required for implementation. Basic conclusions that were drawn:

1. GOST 15 408 is a complex, incomprehensible, cloudy, but cool thing… not tasty, but I recommend it.

2. Threats and security goals from the protection profile can easily be equated to the threats and measures of the FSTEC.

3. You need to add your FTB due to the peculiarities of the automated process control system (some of them):

• FTB_001: Strengthened requirements for compatibility with SIEM (syslog cef);

• FTB_002: Requirement for compatibility with a certified OS;

• FTB_003: Availability of technical support for the solution;

• FTB_004: Compatibility with ACS Anti-Virus solutions.

8. List of terms and abbreviations

Bibliography