Guide to internal documentation on information security. What, how and why
- Tutorial
In one of our previous articles, we touched on the issue of forming a set of documents for examiners on the protection of personal data. We gave a link to our document templates , but focused 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 information protection in general. What documents should be with the operator, which are optional. Where does the demand for this or that document come from. What to write in documents and what is not worth it. Under the cut a lot of letters on this subject.
A few words in defense of "paper" security
Since the article will focus on the so-called “paper” security, I would like to immediately outline our position on this part of the information security.
For many techies working with “hands” this “paper” 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 to first get acquainted with the documentation for this miracle of technology.
The most common justification for such a dismissive position is that all these documents are done just for show in order to comply with the requirements of the law, this is a waste of time, documents must be supported, but no one will do this, etc., etc.
Unfortunately, this position is not groundless. Over the years, both among local security guards and among licensees, integrators, and other interested parties, the sad practice of the same attitude to information security documents has developed. As a result, a vicious circle was drawn - documents are rendered useless because they are neglected, and in turn are neglected because they are useless.
This is partly compounded by the fact that often information security documents are written by people who are far from information technology. After all, how can I write a section about protecting virtualization tools without understanding how this virtualization works?
In order to reverse this situation, it is necessary to make good, informative and useful documents. At the same time, these documents must comply with applicable information protection legislation. Let's see what can be done with all this.
A couple of clarifications
To begin with, in order to eliminate unnecessary questions and conjectures, we consider it necessary to clarify a few points.
- In the article we will consider only internal organizational and administrative documents (hereinafter referred to as the “ARD”) for the protection of information. Design, certification and other documents will not be considered.
- We will not consider the threat model either, although its template is here . The development of a threat model is another story. Write in the comments - do you need a manual on developing a threat model on Habré?
- The article will rely on our set of templates. It is not some kind of standard or generally accepted set. This set reflects our purely approach to the development of the ARD. Since the legislation often does not prescribe anything specific in this regard, you may have your own opinion about the completeness and content of documents and this is normal!
- There may be errors and typos in the templates. We ourselves constantly improve and refine them.
- In the context of fulfilling the requirements, the subjects of personal data (152-ФЗ and by-laws) and state information systems (17 order of the FSTEC) will be mainly affected. In addition, there is another 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 you rely on legislation to protect information, there is little to say where exactly what documents we should develop, so we have to rely on various indirect hints.
For example, we give part 2 of article 19 of the law No. 152-FZ "On personal data". The plain text will be the text of the law, in italics - the author’s notes.
2. The security of personal data is achieved, in particular:With this example, we wanted to show the difference: how the law is 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 need still follows from the text of 152-FZ, since the fulfillment of any requirement is documented.
1) by identifying threats to the security of personal data when they are processed in personal data information systems; (need a threat model)
2) by applying organizational and technical measures to ensure the security of personal data when they are processed in personal data information systems, which are necessary to fulfill the requirements for the protection of personal data, the implementation of which ensures the levels of personal data security established by the Government of the Russian Federation; (organizational measures for the most part are our documents, plus here they send us to read further by-laws)
3) by using the procedures for assessing the conformity of information protection facilities that have passed in the prescribed manner;
4) evaluation 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 machine carriers of personal data; (obviously, some kind of accounting journal and developed rules for accounting for machine carriers are needed)
6) by the discovery of unauthorized access to personal data and the adoption of measures; (it is necessary to develop certain rules for detecting incidents and eliminating their consequences, it may be necessary to appoint an incident response team)
7) by restoring personal data modified or destroyed due to unauthorized access to them;(backup and recovery rules are needed)
8) the establishment of rules for access to personal data processed in the personal data information system, as well as the registration and recording of all actions performed with personal data in the personal data information system; (development of a system of access to data can be done on the basis of roles in the system, the software itself should be able to log who and when what data was accessed)
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 certain plan for periodic monitoring, plus, probably, a journal in which the results of such monitoring will be recorded)
More specifically, the FSTEC tells us about the completeness and contents of the ARD. In 2014, this regulator issued a methodological document, Information Security Measures in State Information Systems. A document without sarcasm is excellent, if you did not understand something in the order of implementation of measures of the 17th, 21st or other orders of the FSTEC (yes, although the document is intended for GIS, but the measures for the most part coincide with the FSTEC), refer to this the document may become much clearer.
So, in this document, the FSTEC more extensively outlines measures to ensure the security of information and very often you can find such text:
The rules and procedures for the identification and authentication of users are regulated in the organizational and administrative documents for information protection. (IAF.1)Well, something already, but these rules and procedures are a whole carriage.
Rules and procedures for managing user accounts are regulated in the organizational and administrative documents of the operator to protect information. (UPD.1)
Rules and procedures for managing information flows are regulated in the organizational and administrative documents of the operator to protect information. (UPD.3)
As a result, I had to gag myself with a plate that wrote out all the requirements from all the documents and made notes and notes on fulfillment, non-fulfillment.
The main idea of this section is there is a mountain of requirements in the legislation on information protection, the implementation of many of them needs to be documented. Whether to make a separate document for each requirement or to merge everything into one big "IS Policy" is up to everyone. All the additional things that we need to register in the documents not according to requirements, but on the basis of practical necessity, are 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 ISPD.
It is also obvious that, for example, some sections or even entire documents can be eliminated if the structural and functional characteristics of the information system or other initial conditions require it. For example, we remove the provision of video surveillance, if it is not. Or we remove all sections related to the protection of virtualization tools, if it is not applied.
Our templates are divided into 4 folders:
General- documents that need to be developed for all systems (as applicable), whether it is ISPDn, GIS, automated process control system or KII object.
Only GIS - documents for state information systems or municipal information systems, there are only unique documents needed for GIS and MIS.
PD - documents on the protection of personal data and pursuant to the legislation on the protection of personal data. If, for example, we have a GIS in which personal data is processed, then we must make documents from all folders.
CIPF - documents related to the use of cryptographic tools, are needed for the implementation of regulatory documents of the FSB, are developed for all systems that use certified cryptographic means of information protection.
Let us consider in more detail the documents, where they came from and what requirements they fulfill.
Are common
01 Order of appointment of responsible persons and instructions to these persons
This order appoints: the person responsible for organizing the processing of personal data and the security administrator.
The need to appoint the first is stipulated by article 18.1 of the federal law:
1. The operator must take measures ... Such measures may include, but are notSecurity Administrator - the need for this friend is due to, for example, clause 9 of FSTEC Order No. 17:
limited to: 1) the appointment by the operator, who is a legal entity, of the person responsible for organizing the processing of personal data;
To ensure the protection of information contained in the information system, the operator appoints the structural unit or official (employee) responsible for the protection of information.These persons differ in that the “responsible” is more in the paper part, and the “administrator” in the technical part.
In order for the responsible and the administrator to understand their tasks and authorities, they are entitled to instructions.
02 Order on the designation of an information security incident response team (GRIIB) and response instructions
The abbreviation of the SRIMS, although a bit ridiculous, but quite official, was introduced by GOST R ISO / IEC TO 18044-2007 “Information technology. Security methods and tools. Information Security Incident Management. ”
The need for documents is required by a number of regulatory 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 the FSTEC.
Order of the FSTEC No. 17:The same documents close a number of organizational measures, for example, RSB.1 “Determination of security events to be recorded and their storage periods” and SSB.2 “Determination of the composition and content of information about security events to be registered”. All these things can be indicated in the incident response instructions so as not to produce separate documents.
18.2. In the course of identifying and responding to incidents:
- identification of persons responsible for identifying incidents and responding to them;
- detection and identification of incidents, including denial of service, failures (reboots) in the operation of hardware, software and information protection tools, violations of access control rules, illegal actions to collect information, introductions of malicious computer programs (viruses) and other events, leading to incidents;
- timely informing persons responsible for identifying incidents and responding to them, about the occurrence of incidents in the information system by users and administrators;
- analysis of incidents, including determining the sources and causes of incidents, as well as assessing their consequences;
- planning and taking measures to eliminate incidents, including the restoration of the information system and its segments in the event of a denial of service or after failures, the 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.
03 User manual
The main legal justification for the need for such an instruction is all the places in the legislation where it says 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 directly processing personal data with the provisions of the legislation of the Russian Federation on personal data, including requirements for the protection of personal data, documents defining the operator’s policy regarding the processing of personal data, local acts on the processing of personal data, and (or) training of these employees.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, a user who violates IS requirements will most likely not be held accountable.
As for the document itself, here we decided not to load users with nonsense that they did not need, to make the document not too difficult to understand and useful not only in relation to information security at 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 to protect information in the GIS” and about the large number of “rules and procedures” that need to be written in the ARD? Actually, the “IB Policy” is, in fact, a collection of all such rules and procedures.
Here, perhaps, it is worth stopping at the word "Politics". We are often told that our “Politics” is too targeted, but in fact a document with that name should be more abstract and high-level. It may be so, but here as security people, first of all, with the technical background, the word “Politics” is associated, for example, with group policies of the domain, which in turn is associated with specific rules and settings.
In fact, what such a document will be called is not important. If you do not like the word "Policy" you can rename it to "Rules and Procedures for Information Security." It is not important. The main thing is that these very rules and procedures should already be clearly and specifically spelled out in this document.
We will stop here in more detail.
If you open a document and start working with it, you will notice that in some places there are no specific blanks of text, but instead there is a dry “Describe”. This is because some things cannot be described so that the text is suitable for at least half of the specific information systems at the same time. For each case, it is better to describe these sections separately. That is why we are still skeptical of various automatic document fillers.
In the main text everything should be clear as a whole, I would like to dwell on applications a bit.
Application for making changes to user lists
Many people think that the procedure for tracking users and their authority in the system is highly bureaucratic, however, we often encountered situations when such an approach helped advance in the investigation of information security incidents. For example, it was necessary to establish what powers were granted to the user initially. When applications from the application to the IS policy were raised, it turned out that one account had an unauthorized increase in authority.
In any case, it is up to each operator to decide whether to do such a user registration procedure or not. Here, it’s probably worth mentioning right away that what is explicitly done exactly as described in our model of IS policy is not required by any legislative act. The document template is most likely the most severe and depressing option. And then everyone decides for himself - where to loosen the nuts, and where to tighten even more.
Regulation on the delimitation of access rights and the list of persons
Differentiation of user access rights is an obvious measure for any system administrator. Additionally, its need is supported by measures from the orders of the FSTEC: UPD.2 “Implementation of the necessary methods (discretionary, mandatory, role-based or other method), types (reading, writing, execution, or other type) and access control rules”, UPD.4 “Separation of powers (roles) of users, administrators and persons providing the functioning of the information system ”and some others.
Since in the overwhelming majority of cases it is optimal to use exactly the role model of access control, these applications to the IS policy are geared specifically for this case.
List of persons. We are often asked whether it is possible to indicate here not specific people, but positions. Especially often this question comes from representatives of large organizations with a large turnover of personnel. Our answer is you can try, but any regulator will tell you about the principle of “personal responsibility” and that the “chief accountant” cannot be punished, but “Marya Ivanovna” can.
List of permissive rules for interaction with external networks
Rules are created mainly pursuant to the UPD.3 measure “Management (filtering, routing, connection control, unidirectional transmission and other ways of managing) information flows between devices, segments of an information system, and also between information systems”.
Since, as already mentioned, the templates are tailored to the most depressing version, here too the table is often filled with “white lists”. But you can enter any other rules if the “white lists” are not stipulated by any special requirement of the law. The form of the table is also exemplary, you can redo your vision as you like.
The list of allowed software The
list is created pursuant to 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, a list must be approved.
Often the list is used to understand if the user has installed something unnecessary on his work computer. Although, in a good way, the ability to install something on their own by ordinary users needs to be eliminated.
The following are lists of software and users for remote access. Fill in if there is such access and yes, these are also requirements of the FSTEC.
The reservation procedure
Here, even the requirements of the FSTEC are probably not necessary. Everyone understands the importance of backups and everyone remembers the saying "there are 2 types of system administrators: those that make backups and those that will make backups." However, in practice, when auditing information systems, it often happens that admins say that they have backups for sure, but the questions “what exactly, where exactly and how often it is backed up” remain unanswered.
The current table from Appendix 10 to the IS policy will help to avoid such situations.
As for the requirements for redundancy (although in reality the requirements are more related to recovery), there are also many 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:Or a requirement from FSTEC:
7) by restoring personal data modified or destroyed due to unauthorized access to it;
OTT.4 Periodic backup of information to backup computer storage mediaA plan to ensure the continuity of the functioning of an information system
where we have tried to collect the preform different options
The FSTEC requirement, which we partially fulfill with this plan:
OTT.3 Monitoring the failure-free functioning of technical means, detecting and localizing operational failures, taking measures to restore failed means and testing them
06 Order on the controlled zone and regulation on the controlled zone
The need for these documents is due to the requirement of the FSTEC: ZTS.2 "Organization of the controlled area, within which stationary technical means that process information, and means of protecting information, as well as means of ensuring functioning, are constantly located."
Here we often encounter the misconception that only those rooms that are equipped with access control systems, video surveillance, etc., can be considered as a controlled zone, but this is not so. A controlled zone is a territory on which unauthorized access to information system elements by unauthorized persons is excluded. That is, in fact, it can be a room without video surveillance and ACS, but with the only instructed employee who “watches”, and when he leaves the office, expels all strangers and closes the office with a key.
07 Safety Plan ...
The action plan can be divided into 2 parts - a list of one-time IS events and a list of periodic events. Once there are 2 parts, then there are two main goals.
We are often asked the following question: “But we are a poor state organization, there are a lot of IS requirements, there is no money for their implementation, but there is a check on our nose, what should we do?” Well, if everything is completely bad, then at least make an action plan. This way you can show the reviewers 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, this is the implementation 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 must take measures ... Such measures may include,
but not limited to: 4) internal control and (or) audit of the processing of personal data by this Federal Law and regulatory legal acts adopted in accordance with it, requirements for the protection of personal data, operator’s policy regarding the processing of personal data, local acts of the operator;
08-14 Magazines ...
Magazines 08-10 are media accounting journals. According to FSTEC there are three types of such carriers:
- hard drives in stationary computers, servers, all-in-ones, etc .;
- storage media in various portable devices (laptops, netbooks, tablets, cameras, etc.);
- removable machine media (flash drives, removable HDDs, memory cards).
We really wanted not to produce different magazines and make one universal for accounting all possible storage media. But different types of media have different options. 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 magazine turned out to be overloaded, and we decided to make three different ones. Moreover, it often happens that only stationary devices are used in the information system, so the need for magazines 09 and 10 disappears by itself.
The rest of the magazines appeared more likely not from direct requirements, but for indirect reasons. We have a plan of periodic events and inspectors want to see marks 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 completing each journal. Literally for each column describe what to enter there, sometimes even with examples. This actually saved us from a huge number of identical questions to fill 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 measure to formulate information security requirements established a certain “decision on the need to protect the information contained in the information system”. And as we remember, the fulfillment of such requirements needs to be documented, so there was such an order by which 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 the state information system is a very important stage in the formation of requirements for the information security system. The number of requirements that we need to fulfill will depend on which class we install.
By order, we appoint a classification commission, and by act, this commission fixes the information system parameters and assigns the first, second or third security class based on the initial data.
The only thing you need to pay attention to is that if GIS processes, including personal data, 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 effect 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 for the protection of personal data, where we try to prescribe the maximum aspects of PD processing stipulated by law. Here we prescribe whose data, what data and for what purposes we process. Rights and obligations of PD subjects, rights and obligations of 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 law.
02 Rules for handling requests
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 and for what purpose it is being processed, ask him to stop processing his personal data, etc. The law also indicates the maximum time frame within which the PD operator must meet the answer.
Accordingly, it would be nice to have at hand an internal document regulating the rules and terms for considering such requests, as well as incorporating response templates 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 on approval of the list of persons
We need to determine who has access to which personal data. If for access to information systems we have already developed the same document as part of the IS policy, then duplication of the same thing is not required here. But you need to pay attention to the fact that here, in addition to persons admitted to the automated processing of personal data in automated systems, it is also necessary to indicate those who are allowed to handle automated personal data (for example, paper folders with personal files of employees). Here, just as in IS politics, regulators want to see surname lists.
04 Policy regarding the processing of personal data
Do not confuse with IB policy! Here you can reasonably ask: “Why do we need another policy?”.
Part 2 of Article 18.1 of the Federal Law "On Personal Data":
Оператор обязан опубликовать или иным образом обеспечить неограниченный доступ к документу, определяющему его политику в отношении обработки персональных данных, к сведениям о реализуемых требованиях к защите персональных данных. Оператор, осуществляющий сбор персональных данных с использованием информационно-телекоммуникационных сетей, обязан опубликовать в соответствующей информационно-телекоммуникационной сети документ, определяющий его политику в отношении обработки персональных данных, и сведения о реализуемых требованиях к защите персональных данных, а также обеспечить возможность доступа к указанному документу с использованием средств соответствующей информационно-телекоммуникационной сети.So, this is a document that should be developed and should be published for all comers. But we don’t want to talk too much about the measures taken to protect personal data, therefore, to fulfill the requirements of the law, we create a separate document where we describe in the most abstract way everything that can be described in the abstract.
05-06 Order to determine the level of protection of personal data and the corresponding act
Everything is the same here as with the GIS classification. Important: if we are talking about GIS with personal data, then these two documents are not needed, since determining the level of security of PD is already included in the GIS classification act. We will not dwell on the procedure for determining the security level of PDs; much has already been written on this topic.
07 Rules for processing PD without the use of automation
So for some reason it has historically developed that in matters of personal data protection a lot of attention is paid to this regarding information systems and often operators forget that there are still requirements for the protection of personal data processed without the use of automation tools.
Such processing PD is devoted to the whole decree of the Government of the Russian Federation . The internal document under consideration is precisely designed to fulfill the requirements of this resolution. The main thing here is to carefully look at which provisions relate to the real situation, and which ones do not. For example, if there is no checkpoint at which the watchman writes the people who enter the territory into the journal, then the relevant provisions regarding such magazines should be removed.
Here is another important point that needs to be clarified. Many may be stupid by the following provisions of the Government decree examined here:
1. Обработка персональных данных, содержащихся в информационной системе персональных данных либо извлеченных из такой системы (далее — персональные данные), считается осуществленной без использования средств автоматизации (неавтоматизированной), если такие действия с персональными данными, как использование, уточнение, распространение, уничтожение персональных данных в отношении каждого из субъектов персональных данных, осуществляются при непосредственном участии человека.It may seem that in many cases PD processing, including in information systems, should be considered non-automated. But this oddity was fixed by introducing the following definition into the law "On Personal Data":
2. Обработка персональных данных не может быть признана осуществляемой с использованием средств автоматизации только на том основании, что персональные данные содержатся в информационной системе персональных данных либо были извлечены из нее.
4) automated processing of personal data - processing of personal data using computer technology ;
Decree Government cannot be contrary to federal law. As a result, manual processing of personal data items is all that is outside of information systems (mainly paper media).
08 Order of the commission for the destruction of PD and the form of the act of destruction
The document for the most part relates to manual processing, that is, for example, to the destruction of personal files of employees whose shelf life has expired. It’s better to approve these documents, even if you haven’t destroyed anything yet, because inspectors often require their availability.
09 The order on the approval of storage places PD
Another manual document. Here you need to determine the storage location of the same personal files of employees in paper form and the person responsible for this storage. The storage location can be a wardrobe, a safe, a rack, etc.
10 Form of consent of the subject to the processing of its PD
For cases when it is necessary to obtain written consent from PD subjects. Here, when changing the template, the main thing to remember is that the content of the written consent to the processing of personal data is strictly regulated by Part 4 of Article 9 of the Federal Law "On Personal Data".
11 Regulation on video surveillance
Document required by reviewers if they see video cameras on the premises. Some explicit provisions of the law are not regulated. The document is simple, we determine the goals of video surveillance and other obvious things. The only thing that we have inserted here is important - this is the comment of the representatives of Roskomnadzor that the video image is not biometric PD, otherwise everyone who checks has a different opinion on this.
12 Non-disclosure agreement form
Signed by our employees who are allowed to process PD (both automated and non-automated).
13 Journal of registration of citizens
It works in conjunction with the rules for considering requests from PD subjects. We register all incoming requests - here. Validators require a log, even if there was not a single request.
Csci
Here are documents that take into account the requirements of the FSB for the treatment of cryptocurrencies. Accordingly, they are not needed if cryptography is not used. Since many of the requirements are quite old and quite stringent (one of the guiding documents already from 2001), we tried to somehow balance the internal documents so that both you and us, as they say. But our guys, who are checking from the FSB, are the most unpredictable, therefore these documents are often supplemented and changed with us.
Conclusion
We hope that this