Now each ISPD needs to be connected to the SOC?
Probably, many of you saw in the media at the end of December 2020 headlines like “About 100 new laws signed” and perhaps even read compilations of new rules changes from various spheres of life, coming into force on January 1, 2021.
One of these signed documents was the Federal Law of December 30, 2020 No. 515-FZ “On Amendments to Certain Legislative Acts of the Russian Federation in terms of ensuring the confidentiality of information about protected persons and on the implementation of operational-search activities.” It would seem – how are the operational-search activities, any ISPD (personal data information system) and SOC (Security Operation Center) connected?
The fact is that this law, among other things, amended clause 6 of part 2 of article 19 of the Federal Law No. 152-FZ “On Personal Data” and now this clause looks like this:
2. Ensuring the security of personal data is achieved, in particular:
6) detection of facts of unauthorized access to personal data and taking measures, including measures to detect, prevent and eliminate the consequences of computer attacks on personal data information systems and to respond to computer incidents therein; (new in bold).
Wasn’t it necessary to identify computer incidents and respond to them in the ISPDN before?
For the technical side of the requirements of 152-FZ, the order of the FSTEC of Russia dated 18.02.2013 No. 21 is responsible, where the appendix contains a suitable measure with the RSB.5 index: Monitoring (viewing, analyzing) the results of registration of security events and responding to them.
The inconsistency here is that this measure, according to FSTEC, is basic (read – mandatory) for ISPD of the first and second levels of security (the highest). And most of the usual “1C-ok” of small enterprises is, as a rule, ISPD of the fourth security level. And quite large ISPDs (containing personal data of more than 100,000 subjects) are often classified according to the third level of security (if it does not contain special categories of personal data, for example, health information).
That is, it turns out that most of the ISPD fell out of the mandatory requirements of the organization for identifying computer incidents and responding to them, but now this requirement has been introduced into the Federal Law, which in the hierarchy of governing documents is higher than the order of the FSTEC.
So what is it, now any small entrepreneur who maintains an excel database of its 10 employees and 20 clients should organize a SOC or connect to an external one? Let’s figure it out.
Is it just SOC attack detection?
In fact, in the version in which it is formulated in the legislation, it is not necessary, if you focus on a purely formal approach.
What is SOC? In short, this is a set of some technical solutions for registering events within the controlled area. Most often it is presented in the form of an analyzer of events (logs) from various sources, their storage and correlation based on predefined rules (SIEM systems) plus the personnel of the first, second and third lines that process incidents “caught” by SIEM systems.
But in the legislation, that in the Federal Law, that FSTEC has no direct indication of either SIEM systems, or the correlation of security events, or the staff of the above specialists. In 152-FZ it is “detection of computer attacks”, and according to FSTEC “monitoring (viewing, analysis) of the results of registration of security events.” And of course “reacting to them” (to attacks and events, respectively).
As our experience shows, the most difficult task in this matter is still detecting a computer incident (unless it is, of course, something like WannaCry, which immediately screams about itself from the screens of monitors), and even reacting in any form in any case will follow.
On the issue of incidents less visible to the naked eye. Recently, we received a request for assistance in eliminating the consequences of the incident and further support of information security from a commercial organization, which was issued an order by the FSB of Russia. The order was issued for the fact that a botnet was caught in this organization, which in turn had already attacked an object of critical information infrastructure in another region of Russia. It was ordered to eliminate the violations, and the person responsible for information security received an administrative procedure under Part 6 of Art. 13.12 Administrative Code of the Russian Federation.
By the way, the wording of the FSTEC is further aggravated by the RSB.1 and RSB.2 measures (which are already mandatory for ISPD of all security levels), according to which the operator of personal data himself determines composition of security events subject to registration and their storage periods.
Thus, if the task is to “shake off the check”, then that very small entrepreneur can establish the composition of the registered security events in internal documents:
antivirus triggers;
records of failed logins.
How do we detect attacks? The system administrator comes once a week and looks at these events with his “eyes”. Found something suspicious? We react! Do we formally fulfill the requirement? We carry out. Does the measure actually work? Of course not. And what a sin to hide, most likely, the system administrator does not even watch these events once a week.
If the issue of detecting attacks is not approached from the formal side, then it quickly becomes clear that two sources are clearly not enough. In a full-fledged information system, in order to catch at least some information security incidents, you need to analyze events from at least the following sources:
operating systems (Windows Event Log, Syslog);
directory service (Windows Event Log);
antivirus software;
Smart firewalls (NGFW, UTM, WAF);
intrusion detection and prevention systems.
The SIEM system will help us with this. But then the question arises – who will maintain this system, who will write and improve correlations in order to reduce false-negative and false-positive responses, who will analyze the identified incidents? That’s right, specialists, and SIEM + specialists = SOC whatever one may say.
How the regulators will act (so far assumptions)
As we know, in the field of personal data protection, we have three main regulators – Roskomnadzor, FSTEK and FSB. And if from the first it is quite likely to dismiss the new requirement 152-FZ according to the above scheme, since they check more of the legal side of the issue, then from the second and third it will hardly work.
Due to the freshness of the new requirement, it is impossible to speak for sure about any practice of inspections and law enforcement associated with it. But what we can say for sure from our own experience, the FSTEC and the FSB have taken a course to shift the emphasis from “paper” information security to the real one.
As for non-governmental organizations, FSTEC is still unlikely to come there to check the issues of personal data protection. A couple of years ago, we would have said the same about the FSB, but in recent years we have had several cases of inspections of organizations that have nothing to do with the state by this regulator. So keeping abreast of the latest changes in legislation will not hurt.
