Certification of information systems on the principle of typical segments. Myths and Reality
Good day, Habr! Today we would like to consider the various myths associated with the certification of information objects (OI) for information security requirements on the principle of typical segments. And also we will understand how to properly do such certification.
Myths need to be said about this circulates a lot and often they contradict each other. For example, there is an opinion that, according to the principle of typical segments, all ISPD countries can be certified (although certification is not required for ISPD), but on the other hand, there is an opinion that information systems need to be certified only in the old manner, the wicked one.
Introduction
Certification of an informatization object is perhaps one of the most regulated and conservative stages in building an information security system.
Conservatism lies in the fact that certification is subjected to a specific system with a specific list of technical means, which are accurately rewritten in the technical passport for the object of informatization and in the certificate of conformity itself. Replacing, for example, a burned-out computer from a certified information system may entail at least a lengthy correspondence with the organization that conducted the certification, and as a maximum, additional certification tests (that is, costs).
This was not a big problem as long as certifications for information security requirements were performed on either stand-alone computers processing protected information or small dedicated local networks.
But progress does not stand still. Now for state information systems, the 17th order of the FSTEC defines their mandatory certification prior to commissioning. But state information systems today are not a static computer or a small local computer, but large dynamically changing systems, often of a regional or even federal scale.
So how to be in this case? Certification is obligatory, and it is impossible to certify a static system, since there new elements are added almost every day, and old ones are removed. Come to the aid of "typical segments."
This concept was introduced by the 17th order of the FSTEC and the standard GOST RO 0043-003-2012 “Information security. Certification of information objects. General provisions "in 2013. Unfortunately, GOST is marked “chipboard”, in contrast to the FSTEC order, so the standard here will not work out. But this doesn’t really lose anything, since in the order of the FSTEC, the rules for extending the certificate of conformity to typical segments are described in much more detail (section 17.3), and the standard is devoted to a couple of short paragraphs.
Myths around standard segment certification
There are many myths around typical segments. Here we will examine those encountered themselves. If you have examples of similar myths or questions (you are not sure whether it is a myth or not), welcome to comments.
Myth number 1. One certificate can be used to certify all information systems in the Russian Federation on the basis of standard segments.
Theoretically, this is not forbidden directly by regulatory documents, but in practice this will not be possible. One of the paragraphs 17 of the order of the FSTEC on model segments states that in model segments it should be ensured the implementation of organizational and administrative documentation on the protection of information. So, the big problem is in the development of such documentation, which will take into account different technical processes of information processing, different protected information, different requirements of regulators, etc. As a result, the documentation developed for one system will be irrelevant for another.
Myth number 2. "Typical segments" are provided only for state information systems.
This is not true. First, the 17 FSTEC order itself allows its provisions to be applied when developing information security systems in any other information systems. Secondly, in GOST RO 0043-003-2012 a broader concept of “informatization objects” is used instead of “state information systems”.
Myth number 3. If we are given a certificate that can be distributed to typical segments, then we can distribute it to anything
This is not so, under the spoiler, the full text of paragraph 17.3 of the order of FSTEC No. 17 for typical segments, then we will consider the cases when the issued certificate cannot be distributed. Here we will have to stop in more detail.
In this case, the distribution of the certificate of conformity to other segments of the information system is subject to their compliance with the segments of the information system that have passed certification tests.
A segment is considered to correspond to a segment of an information system in respect of which certification tests have been carried out, if the same security classes and information security threats have been established for these segments, the same design solutions have been implemented for the information system and its information security system.
The conformity of the segment covered by the certificate to the segment of the information system in respect of which the certification tests were carried out is confirmed during the acceptance tests of the information system or segments of the information system.
In the segments of the information system to which the conformity certificate applies, the operator ensures compliance with the operational documentation for the information protection system of the information system and organizational and administrative documents for information protection.
The specifics of certification of an information system based on the results of certification tests of a selected set of its segments, as well as the conditions and procedure for distributing the certificate of conformity to other segments of the information system are defined in the program and methods of certification tests, conclusion and certificate of conformity.
Next, we will take specific examples of errors, and cite only suitable quotes from this regulatory act as a justification for why this cannot be done.
Example №1
Only the server part is certified, but I want to extend the certificate to automated workplaces (AWP). Is it possible to do that?
Not! Certification of an information system based on the results of certification tests of a selected set of information system segments is allowed, implementing a complete information processing technology.
The transfer of information via communication channels is also a processing technology. Plus, in this example, no automated workplace is certified, so we cannot extend the certificate to another typical workstations.
Example 2
Here we took into account the previous error and included data transmission channels and a typical AWP in the certificate. Suddenly, we needed to organize a big boss laptop with connection to a certified system (via secure channels, of course). Can we extend the certificate of conformity to this laptop?
Not! A segment is considered to correspond to a segment of an information system in respect of which certification tests have been carried out, if the specified segments are set the same security classes security threats information …
Here, for mobile technical devices, new information security threats appear that are not relevant for stationary workstations and most likely are not taken into account in the threat model for the certified system.
Example 3
Well, we took this joint into account and added threats to mobile devices to the growth model, threats to mobile devices. Now you can extend the certificate to the big boss laptop?
Not! Segment considered relevant information system segment in respect of which the certification tests were conducted…
Despite the fact that the mobile device was described in the project documentation for the information protection system and the threat model, threats related to mobile technical equipment were taken into account, no certification tests were carried out for such a tool.
Example 4
How complicated it all is! But such a situation: there is a medical institution, there are two information systems – with employees and a medical information system (IIA) with patients. Can we save, certify the information system with employees and extend this certificate to the IIA?
Not! A segment is considered to correspond to a segment of an information system in respect of which certification tests have been carried out, if the specified segments are set the same security classes … the same information system design solutions.
Although it seems that everything is difficult, in fact, you just need to think through possible options for typical segments in preparation for building a protection system. But in fact, if everything is taken into account (and there are not so many requirements), then there will be no problems with the distribution of the certificate.
Myth number 4. Typical segments should be described in the project documentation for the protection system, starting with the threat model
There is no such requirement. Although this is not directly prohibited, such an approach may cause some problems in the future. What does the 17th order of FSTEC tell us about this:
Features of certification of an information system based on the results of certification tests of a selected set of its segments, as well as conditions and procedure for distribution of the certificate of conformity to other segments of the information system defined in the program and methods of certification tests, the conclusion and certificate of conformity.
That is, we are entitled to mention typical segments only at the certification stage. In this case, your segments will be typical by default if the conditions of section 17.3 of order FSTEC No. 17 are met. But we have encountered cases when typical segments tried to describe already at the stage of threat modeling, almost indicating the serial numbers of the equipment of such segments. The problem with this approach is that if equipment is replaced or something changes in processing technologies (for example, a virtualization environment appears), the segments for which the certificate has already been distributed may become, so to say, illegitimately model. And in this case it may be necessary to carry out not “additional certification tests”, but to carry out the entire complex of tests on a new one.
In general, our advice is not to mention the typical segments in the project documentation at all. Indeed, under the current legislation, any segment that meets the established conditions will be typical.
IMPORTANT! If you are an information system operator and plan to certify an information system with the ability to distribute a certificate to typical segments, be sure to discuss with your certifying authority that this possibility will be reflected in the certification documents, as required by the 17th order of FSTEC!
Myth number 5. FSTEC does not understand “typical segments” and if we certify so, we will be punished
Such a myth sounds very strange, given that the typical segments are described in more detail in the regulatory documentation from FSTEC. This idea can most often be heard from the security guards of the so-called “old school”.
In general, except for "this is not true" we have nothing to say here. On the contrary, the regulator in every possible way promotes such an order of certification of information systems, and quite recently we even faced a claim from FSTEC that a huge regional-scale information system was certified NOT by the principle of typical segments. They had to explain that in that particular case it was not optimal.
Myth number 6. Typical segments work only when the certified part and the segments are owned by the same organization.
It is not true. Directly about this in the law does not say, but all that is not prohibited is allowed. But, of course, there are certain differences when the certified part and the typical segments are owned by one organization, and when the typical segments belong to third-party legal entities, there is.
In cases when everything belongs to one organization, this organization can independently conduct information protection activities on a typical segment, appoint a commission and extend a certificate to a typical segment.
In cases where there is a central operator of a state information system (for example, a regional Information Technology Center) and segments of other legal entities (as an example, a regional document management system of state institutions), then everything is a bit more complicated. The difficulty lies in the fact that, according to the law, the operator of these GIS is responsible for the protection of information in state information systems. Therefore, in order that the next check does not heat up the operator, because somewhere in the school 400 km from the regional center, information protection measures are not taken, he needs to document this process as much as possible at the stage of connecting a typical segment. First of all, a procedure for connecting to an information system is created, where the operator clearly and clearly describes the requirements for the protection of information that must be performed on the connected segment. This usually includes assignment of persons in charge, approval of internal documents on information protection (especially confused operators can even develop and provide a standard set), purchase, install and configure the necessary information protection tools, analysis of vulnerabilities, etc. Next, an organization wishing to connect performs all the requirements and in the manner stipulated in the regulations confirms this.
On the other hand, all the described difficulties are a rough plan of action, which we have already invented together with one of these operators. If the distributed GIS operator is not afraid to be responsible for not proving that the information security requirements in the remote segment have been fulfilled at least during the connection phase, then he can take a simplified path (as far as the “simplified” one can also solve this operator).
Unfortunately, some operators do just that because they sincerely believe in the next myth.
Myth number 7. It is the responsibility of the certification body to distribute the certificate to segments that do not meet the requirements.
As the certifying authority, it is very important for us to understand the limits of our responsibility. Since the law doesn’t answer the question “who is responsible for distributing the certificate to non-compliant segments”, we wrote a letter to the FSTEC.
The FSTEC replied that the certification body was responsible only for the quality of the certification test itself. The organization-operator of the information system is responsible for the correctness of the distribution of the certificate for typical segments.
Myth number 8. Typical segments will not give us anything. You still have to attract the licensee and pay him money
This is not true. At least in cases where there are specialists in the staff of the information system operator who are able to carry out all the activities described above.
On the other hand, we often encounter the fact that we are being asked to help with connecting typical segments. All the same, in such segments, at a minimum, it is necessary to work out the internal documentation, install and properly configure the means of information protection. Plus, many information system operators trust the conclusions on the conformity of a typical segment, written by a third-party organization, rather than the report of the applicant to connect to the system.
But even in this case, typical segments allow the operator to save money, since at least there is no need to develop a separate threat model and design documentation for an information protection system for the elements to be connected. Also, there is no need to conduct full certification tests.
Myth number 9. In typical segments, only identical technical means should be used (for example, computers with the same motherboard, the same processor, the same RAM, up to the type, manufacturer and model)
This question is also clearly not spelled out in the legislation. At the intuitive level, it is clear that full compliance with the iron of the certified and connected segment is not required, otherwise the whole thing is worthless. And when we need to clarify a similar question, what are we doing? That's right – we write a letter to the regulator. FSTEC expectedly replied that the typical segments should not use the same (one manufacturer, one model, etc.) technical solutions.
In order for a segment to be considered appropriately certified, it is necessary that it be set to the same security class, the same information security threats are identified, and the same design decisions are implemented for the system itself and for the information protection system. As actually written in 17 orders.
Myth number 10. For each type segment to be attached, you need to make your own threat model.
Not. In a typical segment, the same threats should be relevant as in the certified part of the information system. Accordingly, the threat model is one for the entire system. Если в аттестованной информационной системе происходят какие-либо значительные технологические изменения, которые могут повлечь появление новых угроз безопасности информации, необходимо пересматривать общую модель угроз и, при необходимости, проводить дополнительные аттестационные испытания системы в целом.
Миф №11. Данные присоединяемых типовых сегментов не нужно отражать в техническом паспорте на информационную систему
По этому вопросу мы также спросили ФСТЭК. Ответ такой — данные новых сегментов нужно вносить в технический паспорт. Но вносить ли новые данные в общий техпаспорт на систему или сделать отдельный документ для сегмента – решать оператору. На наш взгляд на типовой сегмент удобнее делать отдельный технический паспорт.
На этом все. Если у вас остались вопросы по теме – добро пожаловать в комментарии. Надеемся, что наша публикация будет полезна и облегчит жизнь операторам аттестованных информационных систем.
