Guide on internal information security documentation. What, how and why

In one of our previous articles we addressed the issue of forming a set of documents for inspectors on the protection of personal data. We gave a link to our document templates , but settled on the topic of information security documentation very superficially.

In this article I would like to disclose this topic in more detail both in the context of personal data in particular, and the protection of information in general. What documents should an operator have, which ones are optional. Where does the requirement of a document. What to write in the documents, and what is not worth it. Under the cut a lot of letters on this topic.

A few words in defense of "paper" security

Since the article focuses on the so-called “paper” security, I would like to immediately indicate our position on this part of the info security.
')
For many techies who work with “hands,” this “paper-based” security often causes sharp rejection and neglect. However, oddly enough, when such a techie gets at his disposal a new piece of hardware or software (and sometimes both in one product), he wants first of all to familiarize himself with the documentation on this miracle of technology.

The most frequent rationale for such a dismissive position is that all these documents are made just for a tick in order to fulfill the requirements of the legislation, it is a waste of time, documents need to be supported, but no one will do this, etc., etc.

Unfortunately, this position is not groundless. For many years, both among security personnel in the field, and among licensees, integrators, and other interested parties, there has been a sad practice of the same attitude to information security documents. As a result, a vicious circle was drawn - the documents are rendered useless because they are treated with scorn, and in turn they are taken care of because they are useless.

In part, this is further aggravated by the fact that information security documents are often written by people who are far from information technology. After all, how can you write a section about the protection of virtualization tools, not understanding how this very virtualization works?

To reverse this situation, it is necessary to make good, informative and useful documents. At the same time, these documents must comply with current legislation on information protection. Let's see what can be done with all this.

A pair of refinements

To begin with, in order to eliminate unnecessary questions and conjectures, we consider it necessary to clarify a few points.

1. In the article we will consider only internal organizational and administrative documents (hereinafter - OSA) for information security. Project, certification and other documents will not be considered.
2. We will not consider the threat model either, although its template is here . The development of a threat model is a separate story. Write in the comments - do you need a manual for developing a threat model on Habré?
3. In the article we will rely on our set of templates. It is not a standard or standard set. This set reflects our approach to the development of OSR. Since the legislation often does not prescribe anything concrete in this regard, you may have your opinion about the completeness and content of the documents, and this is normal!
4. There may be errors and typos in the templates. We ourselves are constantly improving and refining them.
5. In the context of fulfilling the requirements, the subject of personal data (152- and by-laws) and state information systems (17 order of FSTEC) will be touched upon mainly. In addition, there is a separate story with financial organizations (requirements of the Central Bank of the Russian Federation) and various standards (ISO 2700x and others) - we will not consider them here.

Completeness of documents

If we rely on legislation to protect information, then there is little where it says - what specific documents we should develop, so we have to rely on various indirect hints.

For example, we will take part 2 of Article 19 of Law No. 152- “On Personal Data”. The plain text will be the text of the law, italics - the author's notes.

2. Ensuring the security of personal data is achieved, in particular:

1) identification of threats to the security of personal data when they are processed in personal data information systems; (need threat model)

2) the use of organizational and technical measures to ensure the security of personal data when processing them in personal data information systems necessary to meet the requirements for the protection of personal data, the performance of which ensures the levels of personal data protection established by the Government of the Russian Federation; (organizational measures for the most part are our documents, plus here we are sent to read further bylaws)

3) the use of the information security measures passed in the prescribed manner;

4) an assessment of the effectiveness of measures taken to ensure the security of personal data prior to the commissioning of the personal data information system;

5) taking into account the machine carriers of personal data; (obviously you need some kind of accounting log and developed rules for the accounting of machine carriers)

6) detection of facts of unauthorized access to personal data and taking measures; (it is necessary to develop some rules for detecting incidents and rectifying their consequences; it may be necessary to assign an incident response team)

7) recovery of personal data modified or destroyed due to unauthorized access to it; (backup and restore rules are needed)

8) the establishment of rules for access to personal data processed in the personal data information system, as well as ensuring the registration and accounting of all actions performed with personal data in the personal data information system; (development of a system for admission to data, can be done on the basis of roles in the system, as well the software itself should be able to keep logs who and when applied to which data)

9) control over measures taken to ensure the security of personal data and the level of security of personal data information systems. (we need a plan for periodic monitoring, plus, perhaps, a journal in which the results of such monitoring will be recorded)

With this example we wanted to show the difference: how the law was written and what, in fact, it requires of us. Here we do not see the direct requirement “the operator must develop a threat model”, but this necessity still follows from the text of 152-FZ, since the fulfillment of any requirement is documented.

More specifically, the FSTEC tells us about the completeness and content of the ORD. In 2014, this regulator issued a methodological document “Measures to protect information in state information systems”. A document without sarcasm is excellent, if you had something incomprehensible in the order of implementation of measures 17, 21, or another order of the FSTEC (yes, even though the document is intended for GIS, but measures for the most part coincide with FSTEC), refer to the document may become much clearer.

So, in this document, the FSTEC outlines more extensively measures to ensure the security of information, and very often you can find the following text:

The rules and procedures for the identification and authentication of users are regulated in organizational and administrative documents on the protection of information. (IAF.1)

Rules and procedures for managing user accounts are regulated in the organizational and administrative documents of the operator for the protection of information. (UPD.1)

Rules and procedures for managing information flows are regulated in the organizational and regulatory documents of the operator for the protection of information. (UPD.3)

Great, already something, but these rules and procedures are a whole car.

As a result, I had to write down to myself something like a sign, in which all the requirements from all the documents were written out and notes and marks on implementation, non-fulfillment were made.



The main idea of ​​this section - there is a mountain of requirements in the legislation on the protection of information, the implementation of many of them must be documented. It is up to everyone to make a separate document for each requirement or to merge everything into one big “IS Policy”. Everything additional that we need to register in the documents not according to the requirements, but on the basis of practical necessity, is added without any problems.

By the way, note that in the table and in the documents themselves, some sections or paragraphs are labeled “K1” or “K2 +”. This means that a section or paragraph is necessary only for information systems of class 2 and above, or for the first (maximum class). All that is not marked - is performed in all state information systems and ISPDn.

It is also obvious that, for example, some sections or even entire documents may be eliminated if the structural and functional characteristics of the information system or other initial conditions require it. For example, we remove the provision on video surveillance, if it is not. Or remove all sections related to the protection of virtualization, if it does not apply.

Our templates are divided into 4 folders:

General - documents that need to be developed for all systems (as applicable), whether it is SPIDn, GIS, automated process control system or object KII.

Only GIS - documents for state information systems or municipal information systems, there are only unique documents needed for GIS and MIS.

PD - documents for the protection of personal data and pursuant to legislation on the protection of personal data. If, for example, we have a GIS in which personal data are processed, then we must make documents from all folders.

SKZI - documents related to the use of cryptographic tools, needed for the execution of regulatory documents of the FSB, are developed for all systems that use certified cryptographic information protection tools.

Let us consider further the documents, where they came from and what requirements they fulfill.

Are common

01 Order on the appointment of responsible persons and instructions to these persons

This order assigns: a person responsible for organizing the processing of personal data and a security administrator.

The necessity of appointing the first is stipulated by article 18.1 of the federal law:

1. The operator is obliged to take action ... Such measures may, in particular, include:

1) designation by the operator, being a legal entity, responsible for organizing the processing of personal data;

Security administrator - the need for this comrade is due, for example, to paragraph 9 of the order of FSTEC No. 17:

To ensure the protection of information contained in the information system, an operator is assigned a structural unit or official (employee) responsible for protecting information.

These persons differ in that the “responsible” is more on the paper part, and the “administrator” is more technical.

In order for the person in charge and the administrator to understand their tasks and authority, they are given instructions.

02 Order on the appointment of an Information Security Incident Response Team (ISIRB) and response instructions

The reduction of GRIIB, although a bit ridiculous, but quite official, was introduced by GOST R ISO / IEC TO 18044-2007 “Information technology. Methods and means of security. Information Security Incident Management.

The need for documents is required by a number of legal documents. For example, the same article 19 of the law “On Personal Data”. But in more detail the response to incidents is disclosed in the orders of FSTEC.

Order FSTEK №17:

18.2. During the detection and response to incidents are carried out:

• identifying individuals responsible for identifying and responding to incidents;
• detection and identification of incidents, including denial of service, failures (reloads) in the operation of hardware, software and information protection tools, violations of access control rules, illegal actions to collect information, the introduction of malicious computer programs (viruses) and other events, resulting in incidents;
• timely informing the persons responsible for detecting and responding to incidents about the occurrence of incidents in the information system by users and administrators;
• analysis of incidents, including the identification of sources and causes of incidents, as well as an assessment of their consequences;
• planning and taking measures to eliminate incidents, including the restoration of the information system and its segments in the event of denial of service or after failures, elimination of the consequences of violation of access control rules, illegal actions to collect information, the introduction of malicious computer programs (viruses) and other events leading to incidents;
• planning and taking measures to prevent the recurrence of incidents.

The same documents close a number of organizational measures, for example RSB.1 "Determination of security events to be registered, and terms of their storage" and RSB.2 "Determination of the composition and content of information about security events to be registered." All these things can be specified in the incident response instructions, so as not to produce individual documents.

03 User Manual

The main legal rationale for the need for such an instruction is all the places in the legislation, where it is said about instructing users on information security issues. For example, part 1 of article 18.1 of the law “On personal data”:

6) familiarization of the operator’s employees who directly process personal data with the provisions of the Russian law on personal data, including personal data protection requirements, documents defining the operator’s policy regarding personal data processing, local acts on personal data processing, and (or) training of these workers.

An indirect need for such a document is the legal registration of user responsibility for possible information security incidents. As practice shows , in cases where such instructions do not exist and (or) the user is not familiar with it, the user who has violated the IS requirements will most likely not be held accountable.

As for the document itself, here we decided not to load users with unnecessary nonsense, to make the document not too difficult for perception and useful not only in relation to information security in the enterprise, but also in information security issues in personal life. For example, they described methods of social engineering with examples.

05 Information Security Policy

Probably one of the most voluminous documents from the entire set. Remember above we wrote about the document “Measures of information protection in GIS” and about a large number of “rules and procedures” that need to be written in the OSA? Actually, the “IS Policy” is, in fact, a collection of all such rules and procedures.

Here, perhaps, it is worthwhile to dwell on the word “Politics”. We are often told that our “Politics” is too focused, but in fact a document with such a name should be more abstract and high-level. Maybe so, but as security guards, after all, first of all, with the technical background, the word “Politics” is associated, for example, with domain group policies, which in turn is associated with specific rules and settings.

Actually, the name of such a document is not important. If you don’t like the word “Politics” you can rename it to the “Rules and procedures of information security”. It is not important. The main thing is that this document should already clearly and specifically spell out these same rules and procedures.

Here we will stop a little more in detail.

If you open the document and start working with it, you will notice that in some places there are no specific text blanks, but instead there is a dry “Describe”. This is because some things cannot be described in such a way that the text is suitable simultaneously for at least half of specific information systems. For each case, it is better to describe these sections separately. That is why we are still skeptical about the various automatic "fillers" of documents.

The main text should be generally clear, I would like to dwell a bit on the applications.

Application for changes to user lists

Many people think such a procedure for tracking users and their authorities in the system is highly bureaucratic, however, we often encountered situations when this approach helped to advance in investigating information security incidents. For example, it was necessary to establish - what powers were given to the user initially. When requests were raised from the Information Security Policy Annex, it turned out that one account had unauthorized elevation of authority.

In any case, it is up to each operator to make such a procedure for registering users or not. Here, probably, it is worthwhile to make a reservation right away what to explicitly do exactly as described in our IS policy sample is not required by any legislative act. The document template is most likely the most rigid and depressive option. And then everyone decides for himself - where to loosen the nuts, and where to tighten even more.

Regulations on the differentiation of access rights and the list of persons

Differentiation of user access rights - a measure obvious to any system administrator. Additionally, its necessity is supported by measures from the orders of the FSTEC: UPD.2 “Implementing the necessary methods (discretionary, mandate, role-playing or other method), types (reading, writing, performing or other type) and access control rules”, UPD.4 “Separation of powers (roles) of users, administrators and those who operate the information system ”and some others.

Since in the overwhelming number of cases it is optimal to use the role model of access control, then these applications to the information security policy are sharpened for this particular case.

List of persons. We are often asked whether it is possible to indicate here not specific people, but posts. Especially often this question is heard from representatives of large organizations with a high turnover of personnel. Our answer is you can try, but any regulator will tell you about the principle of “personal responsibility” and that “chief accountant” cannot be punished, and “Marya Ivanovna” is possible.

List of permissive rules for interaction with external networks

The rules are created mainly in pursuance of the measures UPD.3 "Management (filtering, routing, monitoring connections, unidirectional transmission and other management methods) information flows between devices, segments of the information system, as well as between information systems."

Since, as already mentioned, the templates are sharpened for the most depressive version, here too, the table is often filled with “white lists”. But you can enter any other rules, if the "white lists" are not due to any special requirement of the law. The form of the table is also approximate, you can customize it to your own vision.

List of permitted software

The list is created in compliance with the measure OPS.3 “Installation (installation) of only authorized software and (or) its components”. Accordingly, in order to know what software is allowed in our system, the list must be approved.

Often the list is used to understand whether the user has not installed anything unnecessary on his work computer. Although in a good way, the very possibility of installing something yourself for ordinary users needs to be eliminated.

Next come lists of software and users for remote access. Filled if there is such an access and yes, these are also the requirements of FSTEC.

Reservation procedure

There is probably no need to bring the requirements of FSTEC. Everyone understands the importance of backups and everyone remembers the saying "there are 2 types of system administrators: those that do backups and those that will do backups." However, in practice in the audit of information systems it often happens that administrators say that they have backups done exactly, but the questions “what exactly, where and how often back up” remain unanswered.

The actual table from Appendix 10 to the Information Security Policy will help to avoid such situations.

As for the requirements for redundancy (although in fact the requirements relate more to recovery), there are also a lot of them. For example, part 2 of article 19 of the federal law “On Personal Data”:

Ensuring the security of personal data is achieved, in particular:

7) recovery of personal data modified or destroyed due to unauthorized access to it;

Or requirement from FSTEC:

ODT.4 Periodic backup of information on backup machine storage media

Information System Continuity Plan

Here we have tried to collect the preparation of various variants of emergency situations and response options for them. Naturally, this is an approximate list, you can remove the unnecessary, you need to add.

The requirement of FSTEC, which we partially fulfill with this plan:

ODT.3. Control of reliable operation of technical means, detection and localization of failures of functioning, taking measures to restore the failed means and their testing

06 Order of the controlled zone and the position of the controlled zone

The need for these documents is due to the requirement of FSTEC: ZTS.2 "Organization of the controlled area, within which permanently stationary technical means that process information, and information security tools, as well as means to ensure the functioning."

Here we often meet with the fallacy that only those rooms that are equipped with access control systems, video surveillance, etc., can be considered as a controlled area, but this is not so. A controlled zone is a territory where unauthorized access to information system elements by unauthorized persons is excluded. That is, in fact, it can be a room without video surveillance and access control, but with the instructed single employee who “watches”, and when he leaves the office, he expels all outsiders and closes the office with a key.

07 Security Action Plan ...

The action plan can be divided into 2 parts - a list of one-time information security measures and a list of periodic events. Once there are 2 parts, then there are two main goals.

We are often asked this question: “But we are a poor state organization, there are a lot of requirements for information security, there is no money for their implementation, and on the nose there is a check, what should we do?”. Well, if everything is all bad, then at least make an action plan. So you can show the verifiers that you are aware of what steps you need to take, but for some reason not yet. This is about one-time events.

The second part - periodic events, is the fulfillment of a number of requirements for continuous internal control of information security. For example, part 1 of article 18.1 of the law “On personal data”:

1. The operator is obliged to take action ... Such measures may, in particular, include:

4) implementation of internal control and (or) audit of the compliance of personal data processing with this Federal Law and the regulatory legal acts adopted in accordance with it, personal data protection requirements, operator policy regarding personal data processing, operator local acts;

08-14 Journals ...

Logs 08-10 are media accounting logs. According to FSTEC, there are three types of such media:

• hard drives in desktops, servers, all-in-one computers, etc .;
• storage media in various portable devices (laptops, netbooks, tablets, cameras, etc.);
• removable computer media (flash drives, removable HDD, memory cards).

We really wanted to not produce different journals and make one universal to account for all possible media. But different types of media have different parameters. For example, with portable devices, it is necessary to note the possibility of using the device outside the controlled area. As a result, the general journal was overloaded, and we decided to do three different ones. Moreover, it often happens that only stationary devices are used in the information system, therefore the need for journals 09 and 10 is no longer necessary.

The rest of the journals appeared more likely not from direct demands, but for indirect reasons. We have a plan of periodic events and inspectors want to see notes about each event held. So there were other magazines.

And the last thing I would like to say about magazines. We considered it important to add instructions for filling in each journal. Literally for each column to describe what to write there, sometimes even with examples. This actually saved us from a huge number of identical questions on filling out.

GIS only

01 Order of the need to protect information

We are often asked why such an order is needed at all. The fact is that by the 17th order of the FSTEC, the first event on the formation of requirements for information protection was established a kind of “deciding on the need to protect the information contained in the information system”. And as we remember, the fulfillment of such requirements must be documented, and such an order has emerged that we “make a decision”.

Please note that the templates are different for state and municipal information systems.

02-03 Classification Order and Classification Act

The classification of a state information system is a very important stage in the formation of requirements for an information protection system. From what class we install, will depend on the number of requirements that we need to fulfill.

By order, we assign a classification commission, and by an act this commission fixes the parameters of the information system and on the basis of the initial data assigns the first, second or third class of security.

The only thing you need to pay attention to is that if personal data are processed in the GIS, then for them it is also necessary to determine their level of security in the same act.

04 Commissioning Order

In accordance with the 17th order of the FSTEC, the state (or municipal) information system can be put into action only on the basis of a certificate of compliance with information security requirements.

PD

01 Regulation on the protection and processing of PD

The main document on the protection of personal data, where we try to prescribe the maximum aspects of PD processing provided by law. Here we prescribe, whose data, what data and with what purposes we process. Rights and obligations of PD subjects, rights and obligations of the PD operator and so on. In general, the content of this document is largely based on the numerous wishes of the reviewers, and not on any specific requirements of the legislation.

02 Request Processing Rules

Chapter 3 of the Law on Personal Data is fully devoted to the rights of the subject of personal data. The PD subject has the right to write various requests to the PD operator, for example, to clarify what his data is being processed and for what purpose, to ask to stop processing his personal data, etc. The law also specifies the maximum periods in which the PD operator must meet the answer.

Accordingly, it would be nice to have on hand an internal document that regulates the rules and deadlines for the consideration of such requests, as well as having templates for responses to subjects (both positive and negative). This will greatly simplify the life of the person responsible for organizing the processing of personal data.

03 Order approving the list of persons

We need to determine who has access to which personal data. If we have already developed the same document as part of the information security policy on access to information systems, then duplicate the same is not required here. , , , (, ). , .

04

! : « ?».

2 18.1 « »:

, , . , - , - , , , - .

, , . , , , .

05-06

, . : , , . , .

07

- , , , .

. . — , – . , , , , .

, . :

1. , ( — ), (), , , , , , .

2. , .

, . « » :

4) — ;

. , – , ( – ).

08

, , , , . , , . . .

09

. . , , . .

10

, . , 4 9 « ».

11

, , . - . , . , — , , .

12

, ( , ).

13

. – . , .

, . , , . ( 2001 ), - , , . , .

Conclusion

, . , , , . - , . , , , , « ».