Requirements for the protection of personal data 1119

The hands that have long been reaching for the keyboard in connection with the new masterpiece of regulatory regulation have already been beaten to the bone. I can no longer restrain myself and endure it. I'll have to write. Moreover, today Resolution No. 1119 of November 1, 2012 “On approval of requirements for the protection of personal data during their processing in personal data information systems,” which repeals Resolution No. 781 of November 17, 2007, comes into force. Seven days expire from the date of publication.

To be honest, the reaction of colleagues from the professional community to the new resolution, which actually defines the system for building technical security for the processing of personal data in information systems, did not just surprise me, but rather puzzled me. Some, and not a few, liked it because, in their opinion, it does not contain anything fundamentally new, and does not tighten the nuts any further, and the number of requirements compared to PP-781 is even reduced. Other colleagues criticize the document, but very generally, mainly for the lack of specifics.

I have a slightly different opinion about the requirements; I briefly expressed it at today’s webinar, conducted by our agency together with the Security Code company, and the number of questions received about this matter finally pushed me to write this post.

In order to systematize my vision, I came up with several shelves along which I will organize my assessment of the document. Sorry, there will be a lot of letters. Very. I carefully selected the words, so the reading category could be 0+.

Shelf one. Compliance with the law. The release of PP-1119 is a direct requirement of paragraphs 1 and 2 of part 3 of article 19 of the new edition of 152-FZ “On Personal Data”. This is what allows me to very sharply assess the state of affairs on this shelf. The Government resolution does not comply with the law. The law prescribed that security levels and requirements for them should be determined depending on five factors:

· possible harm subject of personal data,

· volume of personal data processed,

· the type of activity during which the processing is carried out Personal Information,

· relevance of threats to the security of personal data.

Types of activities, and, most importantly, harm to the subject, are generally absent as qualifying features in the adopted document. In paragraph 7 of the Requirements, the operator is “not at all humane”, I can’t say otherwise, it is proposed to independently determine the type of threats to the security of personal data relevant to the information system, taking into account the assessment of possible harm, guided by the currently non-existent documents of the FSB and FSTEC. Those. the head of a kindergarten or the head of the automation department of a pipe-rolling plant (since there is simply no one else to deal with such problems in such organizations) will assess the harm from disclosing the data of staff, pupils, visitors and their relatives. In the complete absence of methodological developments on this problem in the country. Anyone who has encountered similar issues at least a little knows that the problem of determining the amount of harm in case of violation civil rights is one of the most difficult in jurisprudence and legal proceedings. But, apparently, remembering the classic postulate about the capabilities of every cook, the authors decided that the problem could be solved by crowdsourcing. Operators, according to Roskomnadzor, are about seven million. Look what they invent. Classic example shifting problems from one head to another, you know which ones.

The types of activities are also tricky. Taking into account that new edition The law does not leave room for industry standards for working with personal data; these same types will have to be taken into account in only one way - by inventing for them additional security threats to those invented by the FSB and FSTEC, which, in fact, is spelled out in parts 5 and 6 of the same Article 19 of the law. Dot. Only to identify new threats, and not to provide for any relaxations similar to those that the Ministry of Health once agreed with FSTEC in its methodological documents.

The second shelf. Methodology. The shelf is…poorly hung. Because the methodology contains the most important, key problems of the document. Declaring the main threats inevitably leading to the establishment higher levels security (see Table 1), undeclared (undocumented) capabilities in system and application software, the Requirements do not offer any methods or methods for neutralizing them at all. Because such methods can only be to check this very software for the absence of bookmarks and other bad habits. And no one demands this from operators, at least in PP-1119.

Table 1

They offer treatment for logic bombs, backdoors and other evil spirits using old proven methods - an enema with gramophone needles and plaster casting of unbroken limbs. See Table 2.

table 2

How using certified firewalls and assigning a responsible department (or responsible person) can help prevent exposure operating system Apparently, only the authors know about the data being processed.

The third shelf. Terminology. And this is the most mysterious part of the document. Where did “operator employees” come from and why are they not employees? legal status which are clearly described Labor Code- the question is simple and obvious. But what is an “electronic message log” (clause 15) and how does it differ from the “electronic security log” (clause 16), if it differs at all - it is a great mystery. I guess that we're talking about about logs. Logs of what? OS? DB? Butt? SZI? All together or something separately? Unanswered questions.

The Decree introduces the concept of an information system that processes publicly available personal data, which is absent in the law, and considers such to be obtained only from publicly available sources of personal data created in accordance with Article 8 of 152-FZ.

And if they are received differently, for example, if this is information that is subject to publication and mandatory disclosure, such as information from the Unified State Register of Legal Entities and the Unified State Register of Individual Entrepreneurs, which is publicly available in accordance with Federal law O state registration legal entities and individual entrepreneurs. Or information about affiliates of the issuer of securities. Or personal data of candidates for deputies subject to publication. What to do with them? Again a question that has no answer.

Finally, compliance assessment. The term, which has no explanation in relation to information security in any act other than the closed Resolution No. 330, continues to roam throughout regulatory framework. But even if the operator has seen this Resolution, he is not able to understand how compliance is assessed during state control and supervision. And evaluate the consequences of waiting for the inspector to arrive and his behavior when he sees uncertified funds, too. Well, let’s not forget that in the new version of the law, regulations relating to the processing of personal data are subject to official publication.

Shelf four. Applicability. The resolution can come into effect in full only after the adoption of the relevant acts of the FSB and FSTEC, provided for in Part 4 of Article 19 of 152-FZ, as well as by the federal executive authorities performing the functions of developing public policy and legal regulation in the established field of activity, government bodies of the subjects Russian Federation, the Bank of Russia, bodies of state extra-budgetary funds, other government bodies in terms of identifying current threats to the security of personal data (Part 5 of Article 19 152-FZ, Clause 2 of the Requirements), which are absent and it is unknown when they will be adopted. Under these conditions, it is almost impossible for the operator to meet the established requirements. I return to the head of the kindergarten and the head of the automation department of the pipe-rolling plant. Who will be the first to explain what “undeclared capabilities of the system” are? software“And by what criteria will it assess the relevance of this threat? What can force the latter to recognize these threats as relevant for his plant and take upon himself additional problems? How will they evaluate the harm that was written about when dismantling the first shelf? Let's wait for the documents from the FSB and FSTEC. Something tells me that it will not be possible to simply refuse to neutralize undeclared capabilities. Banks and telecoms will figure this out eventually. What should the rest of us do that do not have specialized specialists and FSB/FSTEK licenses - schools and universities, hospitals and clinics, registry offices and employment centers, etc., etc.? Such a document can cause them nothing but confusion.

I won't write a resume. And so everything is clear.

The hands that have long been reaching for the keyboard in connection with the new masterpiece of regulatory regulation have already been beaten to the bone. I can no longer restrain myself and endure it. I'll have to write. Moreover, today Resolution No. 1119 of November 1, 2012 “On approval of requirements for the protection of personal data during their processing in personal data information systems,” which repeals Resolution No. 781 of November 17, 2007, comes into force. Seven days expire from the date of publication.

To be honest, the reaction of colleagues from the professional community to the new resolution, which actually defines the system for building technical security for the processing of personal data in information systems, did not just surprise me, but rather puzzled me. Some, and not a few, liked it because, in their opinion, it does not contain anything fundamentally new, and does not tighten the nuts any further, and the number of requirements compared to PP-781 is even reduced. Other colleagues criticize the document, but very generally, mainly for the lack of specifics.

I had a slightly different opinion about the requirements; I briefly expressed it at today’s webinar, held jointly with the Security Code company, and the number of questions received on this matter finally pushed me to write this post.

In order to systematize my vision, I came up with several shelves along which I will organize my assessment of the document. Sorry, there will be a lot of letters. Very. I carefully selected the words, so the reading category could be 0+.

Shelf one. Compliance with the law. The release of PP-1119 is a direct requirement of paragraphs 1 and 2 of part 3 of article 19 of the new edition of 152-FZ “On Personal Data”. This is what allows me to very sharply assess the state of affairs on this shelf. The Government resolution does not comply with the law. The law prescribed that security levels and requirements for them should be determined depending on five factors:

· possible harm to the subject of personal data,

· volume of personal data processed,

· the content of the personal data being processed,

· the type of activity during which personal data is processed,

· relevance of threats to the security of personal data.

Types of activities, and, most importantly, harm to the subject, are generally absent as qualifying features in the adopted document. In paragraph 7 of the Requirements, the operator is “not at all humane”, I can’t say otherwise, it is proposed to independently determine the type of threats to the security of personal data relevant to the information system, taking into account the assessment of possible harm, guided by the currently non-existent documents of the FSB and FSTEC. Those. the head of a kindergarten or the head of the automation department of a pipe-rolling plant (since there is simply no one else to deal with such problems in such organizations) will assess the harm from disclosing the data of staff, pupils, visitors and their relatives. In the complete absence of methodological developments on this problem in the country. Anyone who has at least a little encounter with such issues knows that the problem of determining the amount of harm in case of violation of civil rights is one of the most difficult in jurisprudence and legal proceedings. But, apparently, remembering the classic postulate about the capabilities of every cook, the authors decided that the problem could be solved by crowdsourcing. Operators, according to Roskomnadzor, are about seven million. Look what they invent. A classic example of shifting a problem from one head to another, you know which ones.

The types of activities are also tricky. Taking into account that the new version of the law does not leave room for industry standards for working with personal data, these same types will have to be taken into account in only one way - by inventing for them additional security threats to those invented by the FSB and FSTEC, which, in fact, is spelled out in parts 5 and 6 of the same article 19 of the law. Dot. Only to identify new threats, and not to provide for any relaxations similar to those that the Ministry of Health once agreed with FSTEC in its methodological documents.

The second shelf. Methodology. The shelf is…poorly hung. Because the methodology contains the most important, key problems of the document. Declaring the main threats that inevitably lead to the establishment of higher levels of security (see Table 1) are undeclared (undocumented) capabilities in system and application software, the Requirements do not offer any methods or methods for neutralizing them at all. For such methods can only be to check this very software for the absence of bookmarks and other bad habits. And no one demands this from operators, at least in PP-1119.

Table 1

They offer treatment for logic bombs, backdoors and other evil spirits using old proven methods - an enema with gramophone needles and plaster casting of unbroken limbs. See Table 2.

table 2

We have waited, the document Resolution of the Government of the Russian Federation dated November 1, 2012 No. 1119 “On approval of requirements for the protection of personal data during their processing in personal data information systems” has been released. I deliberately did not write anything about the first version of the document (more precisely, 2 documents), I wanted to see what changes would be made to the final version.

Document in Once again“sausages” systems and procedures for protecting personal data. It establishes requirements for the protection of personal data during their processing in ISPD and the levels of security of such data.
Let's look at the document more carefully and try to understand what PD operators should change/modify in their SPPD.

Here are the main points:

1. The document invalidates Resolution No. 781. Accordingly, we can no longer fulfill his requirements. This means that the status of order 55/86/20, order of the FSTEC of Russia No. 58 and documents on cryptography in the ISPDn from the FSB of Russia are now “in limbo”...
2. The main emphasis of the document is on the requirements for neutralizing CURRENT threats to personal data. The document gives a rather contradictory definition (“Current threats to the security of personal data are understood as a set of conditions and factors that create the current danger of unauthorized, including accidental, access to personal data during their processing in an ISPD, the result of which may be...”), claims against which goes because of the presence of a random access link.
   In general, a situation is emerging in which “games” with the threat model will bear fruit in the form of a reduction in the list of requirements for the ISPD. It turns out if you look from the point of view common sense, then AU1 and AU2 (current threats associated with the presence of undocumented (undeclared) capabilities in system and application software, respectively) will be present in almost all ISDN (of course, if you do not evaluate ALL application and system software for NDV). At the same time, the operator makes an assessment taking into account the possible harm to the subject, which means he can make an incorrect, but appropriate conclusion according to the norms of PP1119, that the device is type 3, because harm/damage is minimal.
3. PD security is ensured by the Operator or an authorized person(authority to process personal data on behalf of). The decision to outsource the functions of protecting personal data may well be justified for many Operators, however, they act in the legal field associated with the operator’s order for processing, with all the ensuing requirements...
4. Selection of information protection system for SZPDn in accordance with regulatory standards legal acts FSB of Russia and FSTEC of Russia. This is expected, however, please note that in this version of the document these special services are written only once and the FSB of Russia is written first, while in PP781 they are mentioned more often, but with an emphasis on the FSTEC of Russia. Blanket tugging? By the way, we are waiting for new documents...
5. There are several types of ISPD based on the type of PD and the type of PD subjects. In general, it is clear and convenient to work with them. The 1st classification involves the selection of:

• ISPDn, in which processing special categories of PDn(information related to racial, nationality, political views, religious or philosophical beliefs, health conditions, intimate life subjects of personal data). Please note that although this list coincides with 152-FZ, the corresponding article of the law (Article 10 152-FZ) contains a mention of information about a criminal record and requirements for it, and PP 1119 says nothing about this.
• ISPD in which biometric PD is processed. Now pay attention to two points:

• ..."if it processes information that characterizes the physiological and biological characteristics of a person, on on the basis of which his identity can be established And which are used by the operator to establish the identity of the subject PD". Another argument in favor of the fact that photographs in the access control system are not biometrics.
• "...and information related to special categories personal data." The question is not the most critical, but still. Now the position of the regulators is clearly visible that special categories of personal data are more critical than biometric personal data.

• ISPDn, in which publicly available ISPDn are processed. Moreover, the basis for public availability is receipt from publicly available sources created in accordance with 152-FZ.
• ISPDn, in which other categories of PD are processed

  The second type of classification involves distinguishing:

• ISPD, in which the personal data of only specified employees are processed. A logical question is, “specified where”? In job orders? In the employee handbook? 1C database? One more subtle question may become a contract/GPC. Having quickly looked through the Labor Code of the Russian Federation, I have not definitely resolved this issue for myself.
• ISPD, in which the personal data of subjects who are not employees of the operator are processed.

• Develop/Implement if not already done:
• Determine the list of personal data carriers and requirements for their storage, use, transportation and destruction.
• Ensure the physical security of PD carriers and access control to PD processing premises. It is good practice to have an approved list of people allowed into the server room. Sometimes regulators also ask about the list of persons allowed into all premises where PD is processed, but, in my opinion, this is unnecessary.
• Assign executive(employee) responsible for ensuring the security of personal data in the ISPD. Please note that, as I wrote earlier, it is necessary to distinguish between those responsible for processing and those responsible for ensuring the security of personal data.
• Make amendments to the regulations on the structural unit responsible for ensuring the safety of personal data.
• Develop and approve a list of persons allowed to process personal data.
• For SZPDn use SZI, have passed the conformity assessment procedure.
• Determine a procedure for regular checks of compliance with the requirements for CPPD (internal control procedure).
• Revise/Modify taking into account new data (do it if you haven’t done it already):
• It is possible to revise the protocol significant damage to personal data subjects.
• Review and update ISPD Classification Acts taking into account security levels.
• Be ready to review and improve
• Be prepared to revise the ISPD threat model.
• Be prepared to review the entire SZPD and purchase new SZD.
• Start thinking about an electronic journal (what it is and what technologies are used) and ensure its security :)))