An example of an explanatory note for an AC technical project. Technical documentation. Resources to help you develop documentation

Below is an example (sample) of a project document " Explanatory note to the technical project for the creation of an automated system", based on guidelines RD 50-34.698-90. This document is generated by an IT specialist at the stage technical design of information system.

As an example of the development of an information system, a project for introducing an information and analytical system was used "Corporate data warehouse".

The page below shows contents of the explanatory note of the technical project in accordance with GOST, within each section briefly The content requirements and the text of the filling example are given.(distinguished by a vertical line).

Sections of the explanatory note:

General provisions

Main technical solutions

Decisions on the structure of the system, subsystems, means and methods of communication for information exchange between system components

Solutions for interconnecting the speaker system with related systems and ensuring its compatibility

Decisions on operating modes, diagnosing system operation

Decisions on personnel and their work modes

Information on ensuring the consumer characteristics of the system specified in the technical specifications, which determine its quality

Composition of functions, sets of tasks implemented by the system

Composition and placement of technical equipment complexes

Ministry of Economic Development and Trade of the Russian Federation

I APPROVED

State contract No. 000-05-07 dated October 29, 2007, concluded between the Ministry of Economic Development and Trade of the Russian Federation and CJSC PROGNOZ, to carry out work on the topic “Development of an automated module for federal monitoring of socio-economic development of constituent entities of the Russian Federation within the framework of creating a unified information system for monitoring key indicators of the socio-economic development of the Russian Federation and monitoring the performance of government bodies in achieving them.” When developing this document, the Guiding document on standardization GOST RD 50-34.698-90 was used. 1. General provisions.. 5 1.1. Full name of the system... 5 1.2. Documents on the basis of which the design is carried out.. 5 1.3. Stages and deadlines.. 5 1.4. Goals and purpose.. 7 1.5. Compliance of design solutions with safety requirements .. 8 1.6. Regulatory and technical documents... 9 2. Description of the activity process.. 10 2.1. List of tasks... 10 2.2. Main functions performed by the Module... 11 3. Basic technical solutions.. 13 3.1. Module structure, list of subsystems... 13 3.1.1. Subsystem of the Centralized Data Storage. 14 3.1.2. Interface component. 15 3.1.3. Adapter software components. 16 3.6.3. The degree of adaptability to deviations in the parameters of the automation object. 26 3.6.4. Acceptable limits for modernization and development of the system.. 26 3.6.5. Reliability requirements. 27 3.6.6. Security requirement. 27 3.6.7. Requirements for ergonomics and technical aesthetics. 28 List of works Expected results of work Development of a Centralized Data Repository (CDW) of socio-economic information used in the implementation of federal monitoring of socio-economic development indicators (PSED) of the constituent entities of the Russian Federation and municipalities Centralized Data Storage Subsystem Development of PSED data schemes and technology specification profiles describing protocols for interaction with the interface component and formats of published PSED data PSER data schemas and technology specification profiles describing protocols for interaction with the interface component and formats for published PSER data; Report on the discussion of draft specifications for data schemes and technology specification profiles, with recorded comments and suggestions from the discussion participants. Development, testing at pilot implementation sites and refinement, in accordance with identified comments, of cross-platform software for the interface component Interface components Mandatory adapter component Development of specific adapter components that provide automated retrieval of information about ER from legacy AIS data sources and its publication through an interface component in accordance with its specifications. Specific adapters must contain a verification block and check the reliability of statistical information Specific adapter components; Regulations for the automatic collection of information used in the implementation of federal monitoring and supplied from websites and from the AIS of federal ministries and departments, constituent entities of the Russian Federation, municipalities in accordance with the developed specifications of output parameters intended to provide information by these data sources Development of tools for tabular, graphical, cartographic, textual presentation of the results of monitoring and analysis of socio-economic development of the constituent entities of the Russian Federation. Subsystem for tabular, graphical, cartographic, textual presentation of monitoring data and results of analysis of socio-economic development of the constituent entities of the Russian Federation Development of a Module subsystem designed to calculate criteria for assessing the development of economic sectors of the constituent entities of the federation based on information collected in the process of federal monitoring Subsystem for calculating criteria for assessing the development of economic sectors of the constituent entities of the Russian Federation (with the ability to identify regional clusters) based on information collected in the process of federal monitoring Development of a Module subsystem designed for calculating integral indices and assessments of socio-economic development of federal subjects based on information collected in the process of federal monitoring Subsystem for calculating integral indices and assessments of socio-economic development of constituent entities of the Russian Federation based on information collected in the process of federal monitoring Development of a Module subsystem intended for publishing information about the electronic energy system in accordance with the requirements of current regulations and developed within the framework of the project, as well as specifications for the interface component Subsystem for publicly accessible publication of primary and converted information about the electronic energy system stored in the Module Administration subsystem development Administration subsystem A complete package of design documentation for the Federal Monitoring Module in accordance with the requirements of GOST 34 Carrying out acceptance tests, finalizing the Module in accordance with the Customer’s comments

1. general provisions;
2. description of the activity;
3. basic technical solutions;
4. events on

[from clause 2.2.1 RD 50-34.698-90]

General provisions

In the “General Provisions” section they provide:

1. design and names of documents, their numbers and date, on the basis of which the NPP design is carried out;
2. list of those involved in the system, deadlines;
3. goals, purpose and AS;
4. confirmation of compliance of design solutions with current standards and fire and explosion safety, etc.;
5. information about those used in the design;
6. information about the best practices used in the development of the project;
7. the order of creation of the system and the volume of each.

[from clause 2.2.2 RD 50-34.698-90]

Description of the activity process

In the section “Description of the activity process” they reflect the composition of the procedures (), taking into account the interrelation and compatibility of processes and activities, form the organization of work in the plant [from clause 2.2.3 RD 50-34.698-90]

Main technical solutions

In the section “Main technical solutions” they give:

1. decisions on the structure of the system, means and methods of communication for information exchange between subsystems;
2. decisions on the interconnection of the system with related systems and its support;
3. solutions for system operation;
4. decisions on the number, qualifications and functions, modes of its operation, order of interaction;
5. information on ensuring the specified consumer characteristics of the system (subsystems) that define it;
6. composition of task complexes () implemented by the system (subsystem);
7. decisions on the complex, its placement on;
8. decisions on the composition of information, volume, methods, types of computer, and documents, sequence and other components;
9. decisions on the composition, languages ​​of activities, procedures and operations and methods of their implementation.

The section provides illustrations of other documents that may be included in accordance with GOST 34.201 [from clause 2.2.4 of RD 50-34.698-90]

Measures to prepare the automation object for putting the system into operation

In the section “Preparatory measures for putting the system into operation” the following is given:

1. measures to bring information into a form suitable for;
2. activities for training and testing the qualifications of personnel;
3. measures to create the necessary units and jobs;
4. measures to change the automation object;
5. other measures based on the specific features of the systems being created.

Document title:
Document number:	1.16-78
Document type:	GOST
Receiving authority:	State Standard of the USSR
Status:	Inactive
Published:
Acceptance date:	November 30, 1978
Start date:	01 July 1979
Expiration date:	01 January 1987
Revision date:	01 January 1983

GOST 1.16-78

Group T50


STATE STANDARD OF THE USSR UNION


STATE STANDARDIZATION SYSTEM


Explanatory note to the draft standard. Construction, content, presentation and design


State system of standardization. Explanatory note to draft standard. Lay-out, contents, wording and formal presentation


Date of introduction 1979-07-01

By Decree of the USSR State Committee for Standards dated November 30, 1978 N 3205, the introduction date was set from 07/01/79

REISSUE with Change No. 1, approved in November 1981 (IUS 3-82)


This standard establishes requirements for the construction, content, presentation and execution of explanatory notes to draft state, industry, republican standards and standards of enterprises of all types.

1. GENERAL PROVISIONS

1. GENERAL PROVISIONS


1.1. An explanatory note to the draft standard is drawn up for each revision of the draft sent for review, sent for approval and submitted for approval.


1.2. An explanatory note to the draft standard must be drawn up by the organization (enterprise) that developed the standard.

If there are several developers, an explanatory note to the draft standard is drawn up by the leading organization (enterprise)-developer.


1.3. An independent explanatory note is drawn up for each standard being developed.

It is allowed to draw up one explanatory note during the simultaneous development, preparation for coordination and approval of interrelated standards of the same category for homogeneous standardization objects.

2. REQUIREMENTS FOR THE CONSTRUCTION, CONTENT AND PRESENTATION OF AN EXPLANATORY NOTE

2.1. The title of the explanatory note indicates the category and full name of the standard, the serial number of the draft standard revision and (or) information about the stage of development of the standard.

For example:


Explanatory note


to the draft state standard "Sewing threads made of natural silk. Technical conditions" (first edition sent out for review).


Explanatory note


to the draft state standard "Cartographic devices. Terms and definitions" (final edition submitted for approval)


2.2. The explanatory note to the draft standard should consist of sections that are numbered sequentially throughout the entire explanatory note and are designated in Arabic numerals with a dot at the end of the number. Section headings should be in capital letters.

If necessary, the explanatory note can be divided into subsections, paragraphs and subparagraphs according to the requirements established in GOST 1.5-68 * for standards.
________________
* The document is not valid on the territory of the Russian Federation. Replaced by GOST 1.5-85 (cancelled without replacement), hereinafter in the text


2.3. The explanatory note should consist of sections arranged in the following sequence:

basis for developing the standard;

goals and objectives of standard development;

data on the standardization of the object at the beginning of the development of the draft standard;

characteristics of the standardization object;

scientific and technical level of the standardization object;

technical and economic efficiency from the implementation of the standard;

the expected date of implementation of the standard and the expected period of its validity;

relationship with other standards;

information about distribution for feedback (for all editions of the draft standard, except the first);

information about approval (only for the final version of the draft standard submitted for approval);

sources of information;

additional information.

When compiling explanatory notes for the second and subsequent (except for the final) editions of the draft standard, it is allowed not to include sections in these explanatory notes whose content has not changed.


2.4. An explanatory note for each edition of the draft standard is drawn up based on the indicators, norms, characteristics, requirements included in this edition, with justification for their changes.


2.5. In the section "Basis for development of the standard" you should indicate the topic number according to the approved plan, the date and name of the organization that approved the terms of reference.

In the case of developing a draft standard that is not included in the standardization plan (an unplanned topic), the directive documents of higher authorities on the basis of which the standard is being developed should be indicated.


It should also be indicated in accordance with which comprehensive standardization program, if any, the standard is being developed.


2.6. In the section “Goals and objectives of developing a standard” you should indicate the final results that will be achieved by using the standard, and the tasks that will be solved during the development of the standard.


2.7. In the section “Data on the standardization of an object by the beginning of the development of a draft standard”, indicate information that the standard is being developed for the first time, or information about current standards, technical specifications, instructions, and other documents that were in force at the beginning of the development of a draft standard for this standardization object.


2.8. In the section “Characteristics of the object of standardization”, depending on the object being standardized (products, indicators, norms, characteristics, requirements of an organizational, methodological and general technical nature), category and type of standard, indicate the main indicators, norms, characteristics, requirements of the draft standard that define the scientific and technical level of the standardization object, and their feasibility study.

The main indicators, norms, characteristics, requirements of the draft standard may be the requirements of the main directions of development of the national economy of the USSR, indicators of standardization plans and technical specifications for the development of standards and indicators of the use of material resources.

This section provides information from reports on the results of research and development work carried out or links to reports indicating the location of the reports, as well as information on the results of patent research on the object of standardization, on proven domestic and foreign discoveries and inventions published for the last ten years before the approval of the standard, and the conclusion on the testing of prototypes or pilot batches of the products being standardized.


2.9. In the section "Scientific and technical level of the standardization object" a comparative analysis of indicators, norms, characteristics, requirements provided for by the draft standard is provided;

with indicators, norms, characteristics, requirements of standards (recommendations) of CMEA, ISO, IEC, and other international organizations;


with indicators, norms, characteristics, requirements of domestic and foreign standards;

with the best examples of equipment and goods of domestic production and foreign companies;

with the highest modern achievements of science, technology, advanced domestic and foreign experience in this field.

This section should reflect the compliance of the indicators, norms, characteristics, and requirements of the draft standard:

tasks defined in the main directions of development of the national economy of the USSR;

complex scientific and technical programs, including the object of standardization;

comprehensive standardization programs.

In this section, based on the above data, a general conclusion is given about the scientific and technical level of indicators, norms, characteristics, and requirements of the standardization object.

If, with the final edition of the draft standard submitted for approval, comparison tables of indicators or a map of the technical level and quality of products in accordance with GOST 2.116-71* are sent separately, then the explanatory note to this edition indicates only the results of the comparative analysis and gives a general conclusion about the scientific and technical level of indicators, norms, characteristics, requirements of the standardization object.
________________
GOST 2.116-84. - Database manufacturer's note.


2.10. In the section "Technical and economic efficiency from the implementation of the standard" you should indicate the expected economic efficiency, the economic advantages of the standardization object and the main sources of obtaining the economic effect.

If it is impossible to calculate the economic efficiency of implementing a standard, the necessary justification should be provided. This section indicates social efficiency indicators from the implementation of the standard (if any).


2.11. In the section “The expected date of implementation of the standard and the expected period of its validity” the following should be given:

justification of the expected timeframe for the introduction of the standard, taking into account the time required to carry out activities to implement the standard;

justification of the main activities for the implementation of the standard, including justification of the possibility of organizing centralized (specialized) production of products;

justification for approval of a draft standard without limitation of validity period or justification for the expected validity period of the standard.


2.12. In the section "Relationship with other standards" you should indicate:

belonging of the draft standard to a set of standards included in the system;

data on the relationship of the draft standard with other standards, as well as standards and recommendations of CMEA and other international organizations;

reasonable proposals on the need to revise, develop changes or cancel existing interrelated standards.

In the event of a revision of a product standard, information is provided on the interchangeability of products according to the developed and current standards and measures to ensure the operation and repair of products manufactured according to the current standard.


2.13. In the section "Information about mailing reviews" you should indicate:

the number of organizations (enterprises) to which the draft standard was sent;

number of organizations (enterprises) that sent reviews;

a brief generalized description of the reviews;

results of reviewing reviews.


2.14. In the section "Information on approval" you should provide information about the approval of the draft standard with interested organizations (enterprises); on holding conciliation meetings; give a brief description of the issues discussed; indicate disagreements that remained during the development of the draft standard.

If the draft standard does not require approval, then the explanatory note should indicate that the standard is not subject to approval.


2.15. In the “Sources of Information” section you should indicate the sources of information used in developing the draft standard, including:

normative acts of current legislation;

regulations of ministries, departments, associations and enterprises;

domestic standards and technical specifications (their designations);

foreign and international standards and other documents of international organizations (their designations and names);

patent research reports;

reports on completed research and development work and others.


2.16. In the "Additional Information" section, if necessary, you can include:

options for resolving some issues and (or) individual questions regarding the draft standard with a request to organizations (enterprises) to which the draft standard is sent for review to express their opinion;

and other questions.


2.17. The explanatory note should be presented in accordance with the requirements established in GOST 1.5-68, section 1, for standards.

3. REQUIREMENTS FOR COMPLETING AN EXPLANATORY NOTE

3.1. The explanatory note to the draft standard should be printed in accordance with the requirements of GOST 6.38-72*.
________________
* The document is not valid on the territory of the Russian Federation. GOST R 6.30-2003 is valid. - Database manufacturer's note.


3.2. An explanatory note to the draft state, industry, republican standard must be signed by the head (deputy head) of the leading organization (enterprise)-developer, the head of the standardization service, the head of development (topic) and performers.

The explanatory note to the draft enterprise standard must be signed by the head of the developing department (division), the head of development (topic) and the performers.

The signatures are located on the last page of the explanatory note to the draft standard.


3.3. The explanatory note to the draft standard must have independent page numbering and not contain a cover.


Electronic document text
prepared by Kodeks JSC and verified against:
official publication
State system
standardization: Collection of GOSTs. -
M.: Standards Publishing House, 1983

GOST 1.16-78 GSS. Explanatory note to the draft standard. Construction, content, presentation and design (with Change No. 1)

Document title:	GOST 1.16-78 GSS. Explanatory note to the draft standard. Construction, content, presentation and design (with Change No. 1)
Document number:	1.16-78
Document type:	GOST
Receiving authority:	State Standard of the USSR
Status:	Inactive
Published:	Official publication. State standardization system: Collection of GOSTs. - M.: Standards Publishing House, 1983
Acceptance date:	November 30, 1978
Start date:	01 July 1979
Expiration date:	01 January 1987
Revision date:	01 January 1983

27.10.2016 09:57:23

This article discusses the technical project stage, which relates to one of the stages of the information security system (ISS) life cycle - the “design” stage, which, in accordance with the domestic standard GOST 34.601-90, immediately follows the development of the Terms of Reference for the information security system.

1. Development of technical design documentation for NIB

The life cycle of an information security system (hereinafter referred to as ISS) in general consists of the following stages:

• analysis of requirements for information security systems;
• design;
• implementation;
• implementation;
• exploitation

This article discusses the stage of the technical project, which belongs to the “design” stage and, in accordance with the domestic standard GOST 34.601-90, immediately follows the development of the Terms of Reference for the information security system.

1.1. Why develop documentation for NIB at all?

The answer to this question should be considered in two planes: in the plane of the owner of information resources (for the protection of which an information security system is created) and in the plane of the direct developer of the information security system.

For the owner of information resources, it is important to obtain the result in the form of a functioning information security system that reduces the risks of compromising restricted access information in the organization. The technical project in this case serves to develop the fundamental principles of the future system, namely, it includes a description of how the ISS will be built and function, what measures and means will ensure information protection, what are the possibilities for developing and improving the system. Upon completion of the development of a technical project for an information security system, the Customer receives a comprehensive set of documentation for the information security system, describing all the technical nuances of the future system.

For the direct executor, at the stage of the technical project, it is necessary to lay down the most suitable ISS architecture, as well as make the right choice of measures and means of protecting information in the organization. It is also important to ensure that the characteristics and properties of the system comply with the technical specifications, or to justify, with the participation and consent of the Customer, the adjustment of the requirements specified in the technical specifications in order to increase the efficiency of the system being created.

Thus, as a result of the development of technical design documentation, the Customer will have answers to the following questions:

• what is the general architecture of the NIB;
• what measures and means will be used to implement information protection requirements;
• how the NIB will function;
• what changes in the organization necessary to increase the level of information security will follow as a result of the implementation of the ISS;
• will the Customer's requirements (business requirements) and the requirements of regulatory legal acts in the field of information security be taken into account when developing and implementing the information security system and, if so, how.

In the process of developing technical project documentation, the contractor will receive the following results:

• a basis for the transition to the next stages of building an ISS, namely the stages of working documentation and implementation;
• understanding of the architecture, technologies and tools used, the order of building the system;
• how the Customer’s requirements (business requirements) and regulatory documents in the field of information security are implemented for the system.

1.2. Review of approaches to developing technical project documentation

The development of a technical project for an information security system is most often carried out on the basis of relevant standards and guidance documents. Moreover, their use is mandatory for government institutions, but recommended for commercial institutions. In practice, commercial organizations also use state standards when developing technical project documentation for the following reasons:

• a repeatedly tested approach to creating information systems;
• thoughtful structure and content of documents;
• a set of documents sufficient for the development and description of almost any system.

To develop documentation for the technical project (TP) stage of the NIB, state standards and guidance documents of the 34 series are used:

• GOST 34.201-89 “Types, completeness and designation of documents when creating automated systems.” This standard specifies:
  • types and names of documents at the TP stage;
  • completeness of documentation;
  • accepted document designations;
  • rules for designating information systems and their parts.
• GOST 34.003-90 “Terms and definitions”;
• GOST 34.601-90 “Automated systems. Stages of creation." The standard specifies:
  • list of stages of work carried out at the technical stage;
  • detailed description of the work carried out at the technical stage;
  • list of organizations participating in the creation of the ISS;
• RD 50-34.698-90 “Automated systems. Requirements for the content of documents." This guidance document specifies the requirements for the content of documents at the TP stage.

It is important to understand that according to the 34 series of standards, technical design is a stage of creating a system, and not just a set of documents. In practice, this stage is often combined with the preliminary design stage, which serves to develop several preliminary solutions and justify the most suitable one. Such a combination is allowed by the standard, but it must be taken into account that this does not negate the need to achieve the goals of the preliminary design stage.

Most often, the preliminary design stage is developed in the case when the requirements of the technical specifications for the system can be implemented in several fundamentally different ways, and also when among these methods there are no clearly preferable ones.

However, it is worth noting that the above standards are too general and mainly implement design and general structural functions. To develop the substantive part of the technical project stage documents, designers use information from the following sources:

Current regulatory documents (RLA) regulating the requirements for the protection of certain restricted access information. These regulations present requirements for measures to protect information in information systems, describe the nuances of implementing these measures and additional strengthening measures. Among the current legal acts are the following:

• Order of the FSTEC of Russia dated February 18, 2013 No. 21 “On approval of the composition and content of organizational and technical measures to ensure the security of personal data during their processing in personal data information systems”;
• Order of the FSTEC of Russia dated February 11, 2013 No. 17 “On approval of requirements for the protection of information that does not constitute a state secret contained in state information systems”
• order of the FSTEC of Russia dated March 14, 2014 No. 31 “On approval of requirements for ensuring information security in automated control systems for production and technological processes at critical facilities, potentially hazardous facilities, as well as facilities that pose an increased danger to the life and health of people and for the natural environment;
• methodological document “Measures for protecting information in state information systems”, approved by the FSTEC of Russia on February 11, 2014.

Requirements for the protection of restricted access information and lists of protective measures vary for information systems of different levels/classes of security. If the information in an organization is not protected in accordance with the federal laws of the Russian Federation (for example, official secrets), then the owner of this information can use the approaches proposed in these regulatory legal acts for building a corporate information security system.

Russian and foreign standards describing various approaches to ways of implementing the stages of the life cycle of building an ISS, including the technical design stage:

• a series of state standards GOST R ISO/IEC 2700X, identical to international standards ISO/IEC 2700X. These standards describe the PDCA (Plan, Do, Check, Act) process approach to the implementation of the life cycle of the information security management system, which is an integral part of the information security system;
• NIST SP 800-64 is a US National Institute of Standards and Technology standard that describes the information systems development life cycle;
• NIST SP 800-37 is a US National Institute of Standards and Technology standard that provides guidance for integrating risk management into the information systems development life cycle.

Manufacturer's operational documentation for information security equipment and auxiliary equipment. These documents contain comprehensive technical information about the tools used in the construction of information security systems, including those directly related to the implementation of information security measures not related to, for example, servers, data storage systems, virtualization tools and others. The general set of such documents varies from manufacturer to manufacturer and depends, among other things, on the implementation of a particular tool (hardware/software). Below is a standard set of operational documentation for information security tools used to develop documents at the technical project stage:

• general description (datasheet);
• administrator's guide (may include local and centralized management guide);
• user manual;
• Quick Installation and Deployment Guide (for hardware information protection systems);
• operator's manual;
• Guidance for deployment in virtual infrastructure (for software information security systems);

General information about existing SIS architectures, best practices in terms of building ISS, guidelines for security and integration of information security systems with each other, information about problems in the interaction of certain information security systems. Examples of such information may include the following documents:

• guides on information security system architectures, for example: Defense-in-Depth, Cisco SAFE, Check Point SDP and others;
• best practices in the field of information security, for example, available at these links (https://www.sans.org/reading-room/whitepapers/bestprac/, http://csrc.nist.gov/publications/nistpubs/800-14 /800-14.pdf). These documents are most often presented in English, however, any Russian manufacturer of protective equipment has its own best practices for implementing security measures and can provide them upon request;
• security guidelines for information security and operating environments. An example is the “Security” section on the official Microsoft portal (https://technet.microsoft.com/ru-ru/library/dd637672.aspx).

1.3. Development of a technical project for NIB in accordance with GOST 34

The development of documents at the technical project stage for ISS is most often carried out by integrators of these services and is implemented mainly in accordance with the following plan:

Determining the list of documents to be developed - this information is indicated in the technical specifications for the ISS. In some cases, the document developer, in agreement with the Customer, may expand or reduce this list, if this possibility is provided for in the technical specifications;

Development of document templates for the TP stage - the structure is used in accordance with RD 50-34.698-90 and GOST 2.106 (for some documents), formatted in accordance with GOST 2.105-95;

Development of the substantive part of documents. Requirements for the system are established in the technical specifications for the NIB. In accordance with these requirements, a list of protective technical and organizational measures required for implementation in the system is determined. Protection measures can be determined in the relevant regulations (depending on the type of information being protected), corporate standards and information security policies, as well as based on the presence of current security threats identified during the development of the organization's threat model. Based on the list of protection measures, the IS developer selects appropriate information security tools and develops the functional structure of the information security system (subsystems, components). Further, the technical design documents describe the practical implementation of protection measures based on the selected security protection or organizational measures in the organization's infrastructure.

Coordination of the developed documentation and the solutions presented in it with the Customer of the system.

When developing technical project documentation, most often it is not necessary to develop a complete list of documents specified in GOST 34.201-89, since this standard is outdated and some of the documents do not take into account the development trends and technologies of modern information systems. The minimum set of documents required to describe the information security system is as follows:

• technical design statement;
• explanatory note to the technical project;
• functional structure diagram;
• structural diagram of a complex of technical means;
• organizational structure diagram;
• list of purchased items.

At the Customer’s request or in the event that the ISS is a complex multi-component system, the following documents can also be additionally developed:

• automation scheme;
• description of automated functions;
• description of the information support of the system;
• description of the complex of technical means;
• software description;
• description of the organizational structure.

It should be noted that GOST 34.201-89 allows for an expansion of the range of documents at the TP stage, but in practice there are more than enough of these documents.

Technical design sheet

Designation: TP.

This document is intended to describe the list of documents developed at the technical project stage. The number of pages of each of the developed documents is also indicated.

Explanatory note to the technical project

Designation: P2.

This document is the main one for the TP stage and includes a description of the ISS architecture, technical and organizational measures, ISS functions, software and hardware systems, and other things. According to the standard, it consists of four main sections:

• general provisions;
• description of the activity process;
• basic technical solutions;
• measures to prepare the automation object for putting the system into operation.

Functional structure diagram

Designation: C2.

This document describes the logical structure of the ISS, namely:

• logical subsystems and components included in the ISS;
• functions implemented by means of subsystems and components;
• information connections between logical elements of the ISS and types of messages during exchange.

Structural diagram of a complex of technical means

Designation: C1.

This document includes a description of the following elements of the ISS:

• technical means as part of logical subsystems and components of information security systems;
• communication channels and exchange between technical means indicating transport protocols.

Organizational chart

Designation: C0.

This document describes the organizational structure of the organization in terms of ISS management, namely:

• divisions and responsible persons of the organization involved in the functioning of the ISS;
• functions performed and connections between departments and responsible persons.

List of purchased items

Designation: VP.

This document includes a list of all software and hardware, as well as licenses used to create an information security system. Developed in accordance with GOST 2.106.

Note. It is also worth noting here that the guiding document RD 50-34.698-90 allows for the addition of any document at the TP stage (the inclusion of sections and information different from those proposed), the merging of sections, as well as the exclusion of some individual sections. Decisions about this are made by the developer of documents at the TP stage and are based on the features of the created NIB.

1.4. Rules for developing documentation

• structural compliance with state standards;
• strict compliance with the requirements of the technical specifications for the system;
• application of document templates (use of uniform styles, markup, fields, etc.);
• an individual approach and the simultaneous use of existing developments when filling out sections of documents.

Explanatory note to the technical project:

• document development is carried out in Microsoft Word; after development is completed, it is recommended to convert the document to PDF format for convenience;
• terms and abbreviations must be consistent throughout all sections of the document;
• It is recommended to avoid obvious repetitions and unnecessary increase in the length of the document;
• technical solutions must be described in as much detail as possible, indicating:
  • architecture and technologies used;
  • locations of software and hardware in the organization’s infrastructure;
  • used information security tools with a description of their characteristics, implemented functions, information about certification;
  • basic settings of information security tools in terms of protection mechanisms, addressing, routing, interaction with related systems and tools, etc.;
  • controls, methods of access to them and places of their installation;
  • diagrams (structural, functional, organizational):
    • develop diagrams in Microsoft Visio;
    • after development, insert diagrams into the document using the “Paste Special” dialog in EMF format (Windows metafile);
    • develop separate diagrams for the system, subsystems and components of subsystems;
    • make the design of the diagrams uniform, using the same elements, abbreviations, icons, text styles, etc.

1.5. Resources to help you develop documentation

The Internet contains a huge amount of information that, to one degree or another, can help in the development of technical project documentation. Key resources are presented in the table below.

Table. SIS Technical Design Resources

Resource type	Information	Examples of resources
Internet portals of federal executive authorities	Regulatory documents, methodological recommendations, registers (including certified information security systems), databases (including databases of vulnerabilities and threats)	fstec.ru clsz.fsb.ru minsvyaz.ru/ru/
Internet portals of information security manufacturers, distributors of information security solutions	Description of information security solutions, operational documentation for information security, analytical materials and articles	securitycode.ru kaspersky.ru/ drweb.ru/ ptsecurity.ru/ infowatch.ru/ infotecs.ru/ cisco.com/c/ru_ru/index.html checkpoint.com altx-soft.ru
Specialized information security resources	Comparison of information security solutions, review articles on information security solutions, tests of information security solutions, in-depth technical information about information security technologies	anti-malware.ru bis-expert.ru safe.cnews.ru securitylab.ru/ vulners.com/ csrc.nist.gov itsecurity.com owasp.org sans.org


1.6. Examples of technical project stage documents

To understand the requirements for the content of documentation at the TP stage, below are examples of filling out the main documents (sections of documents).

1.6.1. Explanatory note to the technical project

The explanatory note is a fairly voluminous document, so here is an example of the content of the section “Main technical solutions” in part of one of the SIS subsystems - the security analysis subsystem.

ISS security analysis subsystem

Structure and composition of the subsystem

The security analysis subsystem (SAS) is designed to systematically monitor the security status of automated workstations (AWS) of personnel and organization servers. The basis of the ESD is the “Test” software tool produced by Information Security LLC. SZI Test is certified by FSTEC of Russia for compliance with technical specifications (TU) for information security and for the 4th level of control over the absence of undeclared capabilities.

The ESD includes the following components:

• Test Server management server;
• Test Console management console.

A description of the subsystem components is presented in the table below.

Table. ESD components

Component	Description
Test Server Management Server	Provides management of scanning tasks, performs functions of monitoring the security status of workstations and servers of the organization. Scanning parameters are set by the information security administrator on the Test Server management server. All collected information about scan results is stored in the Test Server server storage based on the Microsoft SQL Server 2008 database management system
Test Console	Allows the information security administrator to connect to the Test Server, view and change its configuration, create and modify scanning tasks, view information about the progress of tasks and the results of their execution. The management console is installed on the information security administrator's workstation

Providing functions

The ESD provides the following functions:

• implementation of proactive protection of the organization's workstations and servers by monitoring the status of information security;
• automation of processes for monitoring compliance with internal policies and certain security standards;
• reduction of costs for auditing and security control, preparation of status reports;
• automation of resource inventory processes, vulnerability management, monitoring compliance with security policies and change control.

Solution for a complex of hardware and software tools

The list of used ESD software and hardware is given in the table below.


Table. ESD software and hardware

ESD control server

Technical means

The physical server used as an ESD management server must meet the technical requirements for the software and OS installed on it, given in the table below.

Table. OS and software requirements for the ESD control server

Software	Technical requirements
	CPU	RAM, MB
Microsoft Windows Server 2008 R2	3000 MHz, 4 cores	8192
Microsoft SQL Server 2008 R2
Test Server Software

Software tools

Management server OS

Windows 2008 R2 OS is installed on the management server in the normal manner from a boot distribution.

The management server OS is managed both locally from the console and via the RDP protocol.

Management server DBMS

The Microsoft SQL Server 2008 R2 database is installed under an account with local administrator rights using the standard installation wizard from the distribution kit supplied by the product developer.

Test Server Software

Test Server software is installed on the management server using the standard installation wizard.

The initial setup and subsequent management of Test Server software in normal mode is carried out using the Test Console management console installed on the IS administrator's workstation.

IS administrator's workstation

Technical means

The existing workstation of an employee of the organization's department responsible for providing information security, running the Microsoft Windows family of operating systems, is used as a platform.

The technical means of the information security administrator's workstation must have the following hardware configuration characteristics (at least recommended):

• CPU 2 GHz;
• RAM 4 GB;
• HDD 80 GB.

Software tools

Test Console Software

The information security administrator's workstation on which the Test Console software is installed must operate under one of the following OS:

• Microsoft Windows 7, 32- and 64-bit;
• Microsoft Windows 8/8.1, 32- and 64-bit.

In addition, for the Test Console management console software to work correctly, Microsoft .NET Framework version 3.5 SP1 or higher must be installed on the information security administrator's workstation, and the security settings of the operating system used must allow access to the Test Server.

Installation of Test Console software on the ESD administrator's workstation is carried out using the standard Test Server software installation wizard with the selected option to install the Test Console management console and other default settings.

Interaction with adjacent systems

For ESD, adjacent are:

• firewall subsystem tools;
• Active Directory directory services;
• Workstation and servers of the organization.

To ensure network interaction with adjacent systems and directly between the ESD components themselves, the passage of the necessary network traffic must be organized.

To ensure the ability to receive updates to the knowledge base and Test software modules for the Test Server scanner, it is necessary to provide access to the update.com web server of the Information Security LLC company via port 443/tcp.

When scanning in PenTest mode, interaction between the Test Server scanner and the workstation and the organization's servers is carried out via the IP protocol. When scanning in Audit and Compliance modes, remote management protocols WMI, RPC, etc. are used. To scan hosts on devices with firewall functions, you must allow connections from the Test Server to the scanned hosts via IP. Accordingly, the Test Server must be provided with access to the network ports of the scanned hosts using the appropriate remote control protocols.

Since ESD, when scanning in Audit and Compliance modes, uses remote control protocols for analysis, Test software scanning tools must undergo authentication and authorization on the scanned node. In ESD, to scan nodes in the Audit and Compliance modes, accounts with administrative privileges are used in each type of node (workstation, server, application systems, DBMS, etc.).

All registered information security events are stored in the Microsoft SQL DBMS. These events can be sent to the information security event monitoring subsystem using special connectors.

Operation and maintenance of ESD

Subsystem users

Operation and maintenance of ESD tools is carried out by employees of the organization with the functional role of “IS administrator”.

An information security administrator is defined as a specialist whose tasks include:

• determining the scanning parameters of the organization’s nodes;
• setting up and launching scanning tasks;
• analysis of scan results for the presence of vulnerabilities in information systems, configuration errors or non-compliance with technical standards;
• control over the elimination of vulnerabilities;
• formation of standards and requirements that apply to ensuring the security of automated workplaces and servers of the organization.

System operating modes

Normal operating mode

In normal operation, the ESD operates 24 hours a day, 7 days a week.

In normal operation, the information security administrator performs:

• scheduled and unscheduled scanning of nodes;
• generating reports;
• updating knowledge bases and Test software modules.

Emergency operation

If the performance of the safety equipment is disrupted, the functioning of the subsystem is disrupted. Failure to operate ESD equipment does not affect the functioning of the organization's automated workstations and servers.

1.6.2. Functional structure diagram

Functional diagrams can be developed for the entire information security system or for part of it, for example, a subsystem or component.

An example of a general functional diagram of an ISS is shown in the figure below.

1.6.3. Structural diagram of a complex of technical means

The block diagram of a complex of technical means can be developed both for the entire ISS and for its parts - subsystems and components. The feasibility of developing diagrams for parts of the information security system is determined by the scale of the system and the required detail.

An example of a block diagram of a complex of technical information and security systems is presented in the figure below.