RU2659740C1 - Method of automated design engeneering of hardware and software systems and complexes - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: invention relates to the automated design of a system of software and hardware and complexes. Method consists in applying a threat model and comparing it with the usage model where, based on the comparison, software and hardware are chosen to implement the elements of the system being designed, that the functionality or methods of configuring such means at least limit the uses of the system when this type of use reflects only the interests of the infringer, has limited the manner in which the threat is realized, when this type of use of the system reflects the interests of both the offender and the authorized user, but is implemented by each of the interested parties in various ways, limited the vector of the impact on the system used to implement the method of implementing the threat, when this type of use of the system reflects the interest of both the violator and the authorized user and is implemented in a similar way.

EFFECT: provided automated design of software and hardware systems ensuring the achievement of information security goals with due consideration of the interests of authorized users and functional safety requirements.

4 cl, 8 dwg

Description

Technical field

The invention relates to methods for computer-aided design of hardware and software systems and complexes.

State of the art

When designing software and hardware systems and complexes, their architecture is based on the achievement of one or more of the set goals ¹ ( ¹ GOST R ISO / IEC 15288-2005. National standard of the Russian Federation. Information technology. Systems engineering. Systems life cycle processes). The goals are formed by the interested parties (Eng. Stakeholder) - these are the parties having interest (Eng. Concern) in this system. The interests of stakeholders, according to GOST R 57100-2016 ² ( ² GOST R 57100-2016 / ISO / IEC / IEEE 42010: 2011. The national standard of the Russian Federation. System and software engineering. Description of the architecture), are expressed as a benefit or a problem. Examples of interests in relation to the system, in accordance with the mentioned standard, are: functionality, feasibility, applicability, system characteristics, system properties, known limitations, structure, behavior, functioning, use of resources, reliability, functional safety ³ (safety) ³ GOST R IEC 61508-2-2012 Functional safety of electrical, electronic, programmable electronic systems related to safety), integrity of stored data (English data integrity) guaranteed availability for I ask (English availability), etc.

Stakeholders in the design are considered only authorized users (English authorized user) or, as they are also called in the mentioned standard, right holders, which means that only users (groups, organizations) who will be allowed to perform some an operation in the system to realize an interest, or whose interest should be taken into account at the request of a standard (for example, a standard establishing functional safety requirements). As a result, a system is created that meets the requirements of authorized users and the requirements of functional safety. To ensure information security (English security) ⁴ ( ⁴ Including data security (English data security), data confidentiality (English data confidentiality), personal data security (English privacy)) of the created system, additional means will subsequently be used , which most often were not foreseen by the architecture initially, and this fact can significantly affect, when used, the realization of the interests of authorized users and compliance with functional safety requirements. Also, information security can be provided at the expense of funds that are provided for by the architecture, but without taking into account the interests of authorized users and the requirements of functional security, which subsequently can also affect the implementation of the interests of authorized users and compliance with the requirements of functional security when using the system. For example, publication US 20140090071 describes a method for automatically configuring a functioning system based on existing threat models, but does not evaluate the impact of each new configuration on the implementation of the interests of authorized users and compliance with functional safety requirements.

Thus, the technical problem is that the system architecture ensures the achievement of the goals set by authorized users and compliance with functional security requirements, but does not provide information security, and information security goals must be achieved through the use of additional tools not provided for by the architecture, or tools, provided by architecture, but as in the first case, without taking into account the interests of authorized users and the requirements of the functional flax security.

Disclosure of invention

The present invention is intended for computer-aided design of a system of software and hardware, ensuring the achievement of information security goals, taking into account the interests of authorized users and the requirements of functional security.

The technical result of the present invention is to ensure the selection of software and hardware in the process of computer-aided design of a system of software and hardware, the use of which ensures the achievement of information security goals taking into account the interests of authorized users and functional security requirements. The technical result is achieved by designing the system using the threat model ⁵ ( ⁵ The threat model contains actual threats to the designed system (reflects the interests of attackers), therefore, to achieve information security goals, these threats should not be realized.) And comparing it with the use model ⁶ ( ⁶ The use model contains relevant possibilities for authorized use (reflects the interests of authorized users and functional safety requirements), investigator but, they must be implemented by the designed system), where, on the basis of comparison, software and hardware are selected to implement elements of the designed system, so that the functionality or methods of configuring such tools are at least:

limited the use of the system when this type of use reflects only the interests of the violator;

limited the way the threat is implemented when this type of use of the system reflects the interests of both the violator and the authorized user, but is implemented by each of the interested parties in various ways;

limited the impact vector on the system used to implement the threat implementation method when this type of use of the system reflects the interest of both the intruder and the authorized user and is implemented in similar ways.

The object of the present invention is a method for designing a software and hardware system by a computer-aided design system in which CAD modules receive a formalized description of the architecture of the system being designed (hereinafter referred to as the system). Further, on the basis of the description, a usage model is built including: the type of use of the system, reflecting the interest of an authorized user; an element of the system (hereinafter the element) through which such use is realized; a way to implement this type of use through the specified element. CAD modules also receive from the threat database a formalized description of known threats for systems similar to the designed one and based on a formalized description of known threats, a threat model of the same type as the usage model is built including: the type of threat, where the threat is unauthorized use of the system that reflects the interest of the violator ; the element through which this type of threat is realized; a way to implement the threat through the specified element; system impact vector for implementing the threat implementation method. After the constructions, the threat model is compared with the use model using a comparison method designed to compare models of this type to determine the types of use of the system, reflecting:

• only the interest of the offender;

• the interest of both the violator and the authorized user, but implemented by each of the interested parties in various ways;

• the interest of both the intruder and the authorized user, and implemented in similar ways.

Based on the comparison, the CAD tool selection module selects software and hardware for implementing system elements so that at least the functionality or configuration methods of such tools are:

• limited the use of the system when this type of use reflects only the interests of the violator;

• limited the way the threat is implemented when this type of use of the system reflects the interests of both the violator and the authorized user, but is implemented by each of the interested parties in various ways;

• limited the impact vector on the system used to implement the threat implementation method when this type of use of the system reflects the interest of both the intruder and the authorized user and is implemented in similar ways.

In a particular case, CAD receives a formalized architecture description that is made in accordance with GOST R 57100-2016 and contains at least: system elements, including system components and communication between components; interests of authorized users regarding the system;

In the present invention, a system having the same purpose or at least one identical element can be recognized as similar.

In the particular case, the type of use of the system that reflects the interest of the authorized user and the method of implementation of this type of use satisfy the requirements of functional safety.

Brief Description of the Drawings

Additional objectives, features and advantages of the present invention will be apparent from reading the following description of an embodiment of the invention with reference to the accompanying drawings, in which:

FIG. 1 depicts a computer-aided design system of software and hardware systems and complexes;

FIG. 2 depicts a usage model and a threat model for a projected video surveillance system;

FIG. 3 shows a diagram of a projected video surveillance system;

FIG. 4 shows the results of comparing a usage model with a threat model;

FIG. 5 shows the results of comparing a usage model with a threat model, expressed as a model;

FIG. 6 depicts a method for computer-aided design of software and hardware systems and complexes;

FIG. 7 shows an embodiment of a projected video surveillance system;

FIG. 8 depicts an example of a general purpose computer system with which the present invention can be implemented.

The implementation of the invention

The objects and features of the present invention, methods for achieving these objects and features will become apparent by reference to exemplary embodiments. However, the present invention is not limited to the exemplary embodiments disclosed below, it can be embodied in various forms. The above description is intended to help a person skilled in the art for a comprehensive understanding of the invention, which is defined only in the scope of the attached claims.

Description of architecture (eng. Architecture description) - a work product used to express architecture. It is formalized in a particular case by means of UML (English Unified Modeling Language). According to ISO / IEC / IEEE 42010, the description of the architecture has many applications from various stakeholders throughout the life cycle of the system, a formalized description of the architecture is also used as inputs to automated tools for modeling, system simulation and analysis, for example, CAD.

Architecture (systems) (English architecture) - the basic concepts or properties of a system in the environment, embodied in its elements, relationships and specific principles of its design and development. Under the elements of the system in this invention refers to at least the components of the system and the relationship between the components. These elements may be implemented by software and / or hardware. Options for the implementation of software and hardware are determined in the process of designing the system.

Interest (systems) (English concern) - the benefits or problems in the system related to one or more interested parties.

Interested party (eng. Stakeholder) - an individual, team, organization or their groups that have an interest in the system.

Authorized user (English authorized user) - a user representing one of the interested parties who is allowed to perform some operation in the system (use the system) to realize interest.

Usage model - a formalized description of system use cases by authorized users. Includes at least:

- type of use of the system, reflecting the interest of an authorized user;

- an element of the system (hereinafter the element) through which such use is realized;

- a method for implementing this type of use through the specified element;

Intruder (eng. Unauthorized user) - a user representing one of the interested parties who does not have rights to perform some operation in the system to realize his interest.

Threat (eng. Threat) - a potential incident that can disrupt the proper functioning of the system and thereby directly or indirectly cause damage. The types of threats are very diverse and have many classifications, in the framework of this application classifications are used according to the nature of the violation, namely:

• violation of data confidentiality;

• violation of data integrity / data spoofing;

• violation of the system (including denial of service);

• unauthorized interference with the functioning of the system;

• etc.

Threat model - a formalized description of information security threats in relation to a system. Includes at least:

- type of threat, where the threat is unauthorized use of the system, reflecting the interest of the violator;

- the element through which this type of threat is realized;

- a way to implement the threat through the specified element;

- the impact vector on the system for implementing the threat realization method (attack vector);

Method of threat realization, attack - the actions of the offender to implement a security threat of a certain type. For each element of the system, a certain type of threat can be implemented in different ways, including using other components of the system

An attack vector is a direction or a concrete way of influencing a system by an intruder when implementing a security threat. The sign “attack vector” within the framework of this application is identical to the sign “vector of impact on the system to implement the method of implementing the threat”. At least, the defining characteristics of the attack vector can be:

• source or multiple sources of attack;

• an element or many elements that are the target of an attack;

• type of exposure;

• means of influence.

The threat model and the use model may formally be no different from each other (with the exception of the attack vector) for the same system or complex. A classifying feature that distinguishes one model from another is that the use model reflects the interest of the authorized user, and the threat model is the interest of the intruder. Examples of models for real systems will be given below.

In the present invention, the technical problem indicated in the prior art is solved by designing a system using a threat model and contrasting its usage model. Thus, not only authorized users, but also violators are considered as interested parties. The interests of authorized users are opposed to the interests of violators, where the system architecture should ensure the implementation of the interests of authorized users and limit the implementation of the interests of violators.

The design of software and hardware systems and complexes is provided by a computer-aided design system (hereinafter referred to as CAD), an embodiment of which is shown in FIG. 1. CAD input receives a formalized description of the architecture of the designed system, including at least: elements of the system, including system components and communication between components; interests of authorized users regarding the system. At the output, CAD provides software and hardware for implementing elements of the designed system. CAD includes the following modules:

• modeling;

• comparisons;

• selection of funds.

CAD has at its disposal databases containing:

• information about threats (hereinafter referred to as the threat database);

• threat models and usage models (hereinafter referred to as the model base);

• results of comparison of models (hereinafter referred to as the database of results);

• options for software and hardware implementation of elements of systems and complexes (hereinafter the database of means).

In the particular case, for the implementation of the elements of the system, such hardware is also selected that belongs to the class of means resistant to physical impact, hacking, tampering (English anti-tamper, tamper resistance).

Threat database - a database that contains formalized information about threats. The threat description is carried out by listing its main characteristics.

For example:

Type of threat. System element. Method for implementing the threat: attack vector.

The specified database is constantly being updated, including analysts and information security experts, when they identify new types of threats, methods for their implementation and previously unknown attack vectors; the list of elements of the system vulnerable to a particular type of threat is also expanding. The same type of threat (unauthorized control, unauthorized access to information, denial of service, etc.) refers to the system as a whole and can be implemented in relation to various components and other elements of the system, compromising both elements individually and system as a whole. For different elements of the system, threat descriptions can be repeated, but attacks, impact on the system, risks associated with threats and counteraction to these threats can be different. For each element, a certain type of threat can be implemented in different ways, including using other components of the system. For example, to cause a denial of service for a video surveillance system camera (in the threat description, the camera is an element of the system) that has Internet access through a web server, you must first compromise the web server (see Fig. 2b WEB_VULN).

Model database - a database that contains constructed usage models and threat models. This database is filled both in the process of modeling, performed directly by the CAD modeling module, and from the outside, when already built models are loaded into the database, they are only brought into the modeling module in the form necessary for further comparison. Usage models and threat models have the same form, for example, to describe a threat, an example of which is given above, tree models are used, where the characteristics separated by dots represent the nodes of the tree.

In FIG. 3 shows a diagram of a projected CCTV system, where CCTV cameras are connected to video servers that receive, dispatch, and store video streams from these cameras. Storage is used for storage. Access to the video streams in the repository by authorized users is possible both from the inside (through the terminal), and from the outside, through the web server. Access to the video server to control the system is possible through the terminal. System components are connected through network equipment. Thus, the use model includes the following uses (as reflected in the model of Fig. 2):

• system management, implemented through a video server from the terminal through authentication on a video server;

• access to video streams contained in the repository, implemented through the repository, through authentication on a web server;

• video recording realized through:

камеру, посредством аналогово-цифрового преобразования оптического сигнала (видеопотока) камерой (сокр. англ. ADC, на Фиг. 2 ADC);

a camera, by analog-to-digital conversion of an optical signal (video stream) by a camera (abbr. English ADC, FIG. 2 ADC);

видеосервер, посредством приема и обработки преобразованного сигнала (на Фиг. 2 RECEPTION/CONVERT);

video server, by receiving and processing the converted signal (in FIG. 2 RECEPTION / CONVERT);

хранилище, посредством сохранения принятого и обработанного сигнала (на Фиг. 2 SAVE).

storage, by storing the received and processed signal (in Fig. 2 SAVE).

In FIG. 2 shows an example (the example is simplified and is intended to help a person skilled in the technical field to have a comprehensive understanding of the invention) using models of FIG. 2a and threat models FIG. 2b for the design system shown in FIG. 3. The threat model for this system will be considered when considering the modeling module.

The database of results is a database that contains the results of comparing the use model with the threat model, the form of the result contained in the database depends on the type of models and the method of comparison. For example, for tree models, these will be nodes and branches, an example in FIG. 4. In FIG. 5 shows an example of a comparison result (made by crossing) of the models shown in FIG. 2a and FIG. 2b, which is also a tree model. These examples will be considered in the description of the comparison module and the tool selection module.

Means database - a database that contains a description of software and hardware and methods for configuring such tools to select the implementation of elements of the designed systems. The description includes the tool itself, its configuration options, and the functionality that the tool provides, configured in a specific way, both separately and in connection with other tools. The description of the tools also contains information about what types of threats / attacks they are / are not exposed to and in combination with what tools can provide resistance to a particular type of threat / attack.

The simulation module is designed to build usage models and threat models based on the description of the architecture of the designed system. The construction of a model is necessary to bring the description of threats and description of use to one form in order to make comparisons. The module constructs a usage model based on the interests of authorized users regarding the system (in the particular case of system requirements) received at the CAD input in a formalized architecture description. Such interests for the designed system of the example in FIG. 3, as can be understood, is an operational interest involving the following use by an authorized user:

• video recording;

• management of a video recording system;

• access to saved video streams.

Also, the description of the architecture points to the elements through which the mentioned use is implemented and implementation methods. Based on this, the modeling module compiles the uses and constructs a model, an example of which is shown in FIG. 2a.

The modeling module constructs and models threats based on the interests of violators regarding the system. The interests of violators are expressed by threats contained in the threat database. Threats are selected based on the characteristics of the designed system (system elements, the purpose of the elements and the system as a whole), so the simulation module extracts known threats from the threat database for systems similar to the designed one (for systems with the same purpose) and separately for elements that the designed one contains system. The interest of violators regarding the designed system, as can be understood from the example, is also operational interest, which implies the following use by the violator:

• unauthorized management of the video recording system;

• unauthorized access to saved video streams.

Also, it may be of interest to bring the system to an inoperable state - a denial of service.

In a particular case, the model database or the threat database may already contain a simulated description of the threats for the system being designed, in which case the simulation module will rebuild the specified model in the form necessary for comparison.

The description of the threat (as mentioned above when describing the threat base) indicates the elements through which the threat is realized and how the threat is realized (attack), as well as attack vectors. Based on this, the simulation module builds a model, an example of which is shown in FIG. 2b. For the designed system of the example depicted in FIG. 3 threats are:

• unauthorized control implemented through a video server due to:

похищенного пароля (AUTHPWD) авторизации на видеосервере, где векторами атак для данного способа являются:

stolen password (AUTHPWD) authorization on the video server, where the attack vectors for this method are:

эксплуатация уязвимости веб-сервера (WEB_VULN) для проникновения во внутреннюю сеть;

exploitation of a web server vulnerability (WEB_VULN) for penetration into the internal network;

с последующим перехватом упомянутого пароля внутри сети (SNIFF);

followed by interception of the mentioned password within the network (SNIFF);

• unauthorized access through the repository, due to:

похищенного пароля (WEBAUTHPWD) авторизации на веб-сервере, где векторами атак для осуществления данного способа являются:

stolen password (WEBAUTHPWD) authorization on a web server, where attack vectors for implementing this method are:

перехват упомянутого пароля (SNIFF) при прослушивании соединения между уполномоченным пользователем, получающим доступ из внешней сети, и веб-сервером;

Intercepting the mentioned password (SNIFF) while listening to the connection between an authorized user accessing from an external network and a web server;

эксплуатации уязвимости веб-сервера (WEBVULN);

exploitation of a web server vulnerability (WEBVULN);

• denial of service implemented through the camera due to:

исчерпания канала (CHANNEL EXHAUSTION), где векторами атак для данного способа являются:

exhaustion of the channel (CHANNEL EXHAUSTION), where the attack vectors for this method are:

эксплуатации уязвимости сетевого оборудования, в частности веб-сервера (WEB VULN) для прямого доступа к камерам из внешней сети;

exploitation of a vulnerability of network equipment, in particular a web server (WEB VULN) for direct access to cameras from an external network;

с последующей распределенной атакой на камеры (DDOS) прямой доступ к которой получен.

followed by a distributed attack on cameras (DDOS) which is directly accessed.

The comparison module is designed to compare the usage model and the threat model. The method of comparison itself depends on the type of models. For tree models, an intersection is used, the result of which is presented in the figures, where the result of the comparison is the model (Fig. 5) or parts of the models (Fig. 4) that indicate:

- types of use of the system, reflecting only the interest of the violator (Fig. 4a);

- types of use of the system, reflecting the interest of both the intruder and the authorized user, but implemented by each of the interested parties in various ways (Fig. 4b);

- types of use of the system, reflecting the interest of both the intruder and the authorized user, and implemented in similar ways (Fig. 4c);

The comparison result also contains implementation methods (requirements for a system element) reflecting the interest of an authorized user (shown in Fig. 4 and shown in dashed lines in Fig. 5).

In FIG. 4a shows a use that reflects only the interest of the intruder. There is no such type of use as denial of service in the use model, but denial of service is realized through an element of the camera system, the camera is used in the use model to realize the interest of an authorized user, therefore, the comparison result is supplemented with information about the method for realizing the interest of an authorized user (in FIG. 4a is ADC), this will be taken into account by the funds selection module. Denial of service is implemented through an attack on the exhaustion of the channel (in FIG. 4a CHANNEL_EXHAUSTION), which is possible by exploiting a vulnerability of network equipment, such as a web server (in FIG. 4a WEB_VULN) for direct access to the camera from an external network, after which distributed attack on the camera (in Fig. 4a DDOS)

In FIG. 4b reflects the type of use of the system, reflecting the interest of both the intruder and the authorized user, but implemented by each of the interested parties in various ways. This type of use as access reflects the interest of both the intruder and the authorized user. But the way the threat is implemented differs from the way the implementation of the use reflects the interest of the authorized user. To implement the threat, exploitation of web server vulnerabilities is used (in FIG. 4b it is marked as WEB_VULN). The storage is used in the use model for realizing the interest of an authorized user (video recording), therefore, the comparison result is supplemented with information about the method for realizing the interest of an authorized user (in Fig. 4b this is SAVE), this will be taken into account by the means selection module when determining requirements for the means functionality.

In FIG. 4c reflects the types of use of the system, reflecting the interest of both the intruder and the authorized user, and implemented in similar ways. This type of use as control reflects the interest of both the intruder and the authorized user. And this use is implemented in similar ways, through authorization with a password on the video server (in FIG. 4B AUTH_PWD), the difference is how this password is received. This password is obtained by violating the vulnerabilities of the web server (WEB_VULN), which allows penetrating into the network connecting the components of the video surveillance system with the subsequent interception of this password on the network (SNIFF). Like WEB_VULN and SNIFF, in FIG. 4c, attack vectors are marked. This type of use as access reflects the interest of both the intruder and the authorized user and can be implemented by the violator, including (and Fig. 4b shows another possible implementation method - exploiting the vulnerability of the web server) in a manner similar to the way the authorized user is used through authorization using password on the web server. This password is obtained by the intruder due to traffic interception (SNIFF) going to the web server from the external network from an authorized user.

The tool selection module is designed to select the tools by which the elements of the system will be implemented, the selection is made based on the results of model comparison. Software and hardware for the implementation of system elements are selected in such a way that these tools ensure the realization of the interests of authorized users, but at the same time the functionality or configuration methods (including setting security policies) of such tools at least:

- restricted the use of the system when this type of use reflects only the interests of the violator;

- restricted the way the threat is implemented when this type of use of the system reflects the interests of both the violator and the authorized user, but is implemented by each of the interested parties in various ways;

- limited the impact vector on the system used to implement the threat implementation method when this type of system use reflects the interest of both the intruder and the authorized user and is implemented in similar ways.

Thus, for the case reflected in FIG. 4a, it is necessary to limit (in a particular case, completely exclude) the type of use (threat) that reflects the interest of the violator, but since this type of use is implemented through the "Camera" element, which is also used to realize the interests of authorized use (video recording), this must also be taken into account ( in Fig. 4a ADC). Using these requirements, the tool selection module contacts the tool database with a request that indicates what should be implemented (in this case ADC) and what should be limited (in this case DDOS or WEB_VULN or CHANNEL_EXHAUSTION) or directly excluded (type of use - Denial of service). In response to this request, the tool database gives possible options, in this example it could be a BNC camera (Bayonet Neill-Concelman), which, in principle, is not subject to the CHANNEL_EXHAUSTION attack.

For the case shown in FIG. 4b, it is necessary to limit (in a particular case, completely exclude) the way the threat is implemented, such as exploiting web server vulnerabilities. Using these requirements, the tool selection module contacts the tool database with a request that indicates what should be limited in the system (in this case WEB_VULN). In response to a request, the database of tools can offer to use the update management tool (Eng. Patch Manager) or the anti-exploit tool (Eng. Exploit Prevention.) Or DMZ ⁷ ( ⁷ GOST R ISO / IEC 27033-1-2011).

For the cases shown in FIG. 4c, it is necessary to limit (in the particular case, completely exclude) the vector of the impact on the system used to implement the method for realizing the threat. When restricting attack vectors, one of the components of the attack vector is blocked or becomes impossible to implement, which is also its characteristic:

• source or multiple sources of attack,

• an element or many elements that are the target of an attack;

• type of exposure;

• means of influence.

So the tool selection module turns to the tool database with a request stating what should be implemented (in this case, the connection between an authorized user from the external network and the web server) and what should be limited (in this case, the interception of the authorization password on the web server). In response, the database tells you to use a secure connection (use encryption) between the authorized user and the web server, thus the attack vector will be limited, traffic can still be intercepted, but it is not possible to extract the password from it.

The system depicted in FIG. 1, is used to implement a method for computer-aided design of a system of software and hardware. This method 600 is depicted in FIG. 6. First, at the input of CAD at step 610 receives a formalized description of the architecture of the designed system (hereinafter the system), including at least:

- elements of the system, including system components and communications between components;

- interests of authorized users regarding the system.

Based on the description obtained, at step 620, a usage model is built by the modeling module including:

- type of use of the system, reflecting the interest of an authorized user;

- an element of the system (hereinafter the element) through which such use is realized;

- a method of implementing this type of use through the specified element.

The built-in model is stored in the model base by the modeling module. At step 630, a formalized description of known threats for systems similar to the designed one is obtained from the threat database and, based on the threat description, at step 640, the modeling module builds a threat model of the same type as the usage model including:

- type of threat, where the threat is unauthorized use of the system, reflecting the interest of the violator;

- the element through which this type of threat is realized;

- a way to implement the threat through the specified element;

- the vector of the impact on the system for implementing the method of implementing the threat.

Next, at step 650, the comparison module extracts the built models from the model database and compares the threat model with the use model using the comparison method designed to compare models of this type to determine:

- types of use of the system, reflecting only the interest of the violator;

- types of use of the system, reflecting the interest of both the violator and the authorized user, but implemented by each of the interested parties in various ways;

- types of use of the system, reflecting the interest of both the intruder and the authorized user, and implemented in similar ways;

At step 660, based on the comparison, the software and hardware tools are selected by the means selection module for implementing system elements (allowing to realize the interests of authorized users) so that the functionality or methods of configuring such tools are at least:

- restricted the use of the system when this type of use reflects only the interests of the violator;

- restricted the way the threat is implemented when this type of use of the system reflects the interests of both the violator and the authorized user, but is implemented by each of the interested parties in various ways;

- limited the impact vector on the system used to implement the threat implementation method when this type of system use reflects the interest of both the intruder and the authorized user and is implemented in similar ways.

In a particular case, the functionality or methods of configuring such tools should provide not only the realization of the interests of authorized users, but also the implementation of functional safety requirements. In some cases, functional safety requirements are the interests of one of the interested parties.

An embodiment of the elements of the designed system from the example is shown in FIG. 7. In order to ensure the interests of authorized users and the inability to realize threats by violators, the key means in the implementation of the architecture are:

• BNC cameras;

• a secure channel between an authorized user and a web server;

• DMZ zone in which the web server is located.

In the present invention, CAD modules in the present invention are understood to mean real devices, systems, components, a group of components implemented using hardware such as integrated circuits (application-specific integrated circuit, ASIC) or field programmable gate array programmable gate array (FPGA) or, for example, as a combination of software and hardware, such as a microprocessor system and a set of software instructions, as well as on neuromorphic chips (English neurosynaptic chips) Functionality of CAD modules It is implemented solely in hardware, as well as in a combination where the functionality is implemented in software and hardware part. In some embodiments, part of the CAD modules may be executed on a general-purpose computer processor (for example, which is shown in Fig. 5). Databases can be implemented in all possible ways and contained both on one physical medium and on different ones, located both locally and remotely.

FIG. 8 is an example of a general purpose computer system, a personal computer or server 20 comprising a central processor 21, a system memory 22, and a system bus 23 that contains various system components, including memory associated with the central processor 21. The system bus 23 is implemented as any prior art bus structure comprising, in turn, a bus memory or a bus memory controller, a peripheral bus and a local bus that is capable of interacting with any other bus architecture. The system memory contains read-only memory (ROM) 24, random access memory (RAM) 25. The main input / output system (BIOS) 26, contains basic procedures that ensure the transfer of information between the elements of the personal computer 20, for example, at the time of loading the operating ROM systems 24.

The personal computer 20 in turn contains a hard disk 27 for reading and writing data, a magnetic disk drive 28 for reading and writing to removable magnetic disks 29, and an optical drive 30 for reading and writing to removable optical disks 31, such as a CD-ROM, DVD -ROM and other optical information carriers. The hard disk 27, the magnetic disk drive 28, the optical drive 30 are connected to the system bus 23 through the interface of the hard disk 32, the interface of the magnetic disks 33 and the interface of the optical drive 34, respectively. Drives and associated computer storage media are non-volatile means of storing computer instructions, data structures, software modules and other data of a personal computer 20.

The present description discloses an implementation of a system that uses a hard disk 27, a removable magnetic disk 29, and a removable optical disk 31, but it should be understood that other types of computer storage media 56 that can store data in a form readable by a computer (solid state drives, flash memory cards, digital disks, random access memory (RAM), etc.) that are connected to the system bus 23 through the controller 55.

Computer 20 has a file system 36 where the recorded operating system 35 is stored, as well as additional software applications 37, other program modules 38, and program data 39. The user is able to enter commands and information into personal computer 20 via input devices (keyboard 40, keypad “ the mouse "42). Other input devices (not displayed) can be used: microphone, joystick, game console, scanner, etc. Such input devices are, as usual, connected to the computer system 20 via a serial port 46, which in turn is connected to the system bus, but can be connected in another way, for example, using a parallel port, a game port, or a universal serial bus (USB). A monitor 47 or other type of display device is also connected to the system bus 23 via an interface such as a video adapter 48. In addition to the monitor 47, the personal computer can be equipped with other peripheral output devices (not displayed), for example, speakers, a printer, etc. .

The personal computer 20 is capable of operating in a networked environment, using a network connection with another or more remote computers 49. The remote computer (or computers) 49 are the same personal computers or servers that have most or all of the elements mentioned earlier in the description of the creature the personal computer 20 of FIG. 8. Other devices, for example, routers, network stations, peer-to-peer devices or other network nodes, may also be present on the computer network.

Network connections can form a local area network (LAN) 50 and a wide area network (WAN). Such networks are used in corporate computer networks, internal networks of companies and, as a rule, have access to the Internet. In LAN or WAN networks, the personal computer 20 is connected to the local area network 50 via a network adapter or network interface 51. When using the networks, the personal computer 20 may use a modem 54 or other means of providing communication with a global computer network such as the Internet. The modem 54, which is an internal or external device, is connected to the system bus 23 via the serial port 46. It should be clarified that the network connections are only exemplary and are not required to display the exact network configuration, i.e. in reality, there are other ways to establish a technical connection between one computer and another.

In conclusion, it should be noted that the information provided in the description are examples that do not limit the scope of the present invention defined by the claims. 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.

Claims (16)

1. A method for designing a software and hardware system by a computer-aided design system (hereinafter referred to as CAD), in which CAD modules: a) receive a formalized description of the architecture of the designed system (hereinafter the system); b) based on the description, a usage model is built, including the type of use of the system, reflecting the interest of an authorized user; an element of the system (hereinafter the element) through which such use is realized; a way to implement this type of use through the specified element; c) receive from the threat database a formalized description of known threats for systems similar to the projected one; d) on the basis of a formalized description of known threats, a threat model is built of the same type as the use model, including the type of threat, where the threat is unauthorized use of the system that reflects the interest of the violator; the element through which this type of threat is realized; a way to implement the threat through the specified element; system impact vector for implementing a threat realization method; e) compare the threat model with the use model by the comparison method designed to compare models of this type to determine the types of use of the system, reflecting: - only the interest of the offender; - the interest of both the violator and the authorized user, but realized by each of the interested parties in various ways; - the interest of both the violator and the authorized user, implemented by similar methods; e) on the basis of comparison, choose software and hardware for implementing system elements, so that the functionality or methods of configuring such tools, at least: - restricted the use of the system when this type of use reflects only the interests of the violator; - restricted the way the threat was realized when this type of use of the system reflects the interests of both the violator and the authorized user, but implemented by each of the interested parties in various ways; - limited the impact vector on the system used to implement the threat implementation method, when this type of use of the system reflects the interest of both the intruder and the authorized user, implemented by similar methods. 2. The method according to p. 1, in which a formalized description of the architecture is made in accordance with GOST R 57100-2016 and contains at least system elements, including system components and communication between components; interests of authorized users regarding the system. 3. The method according to claim 1, wherein a system having the same purpose or at least one identical element is recognized as similar. 4. The method according to p. 1, in which the type of use of the system, reflecting the interest of an authorized user, and the method of implementation of this type of use satisfy the requirements of functional safety.

Images