Certification des systèmes d'information sur le principe des segments standards. Mythes et réalité

Bonjour, Habr! Aujourd'hui, nous aimerions examiner divers mythes liés à la certification des objets d'informatisation (OI) pour les exigences de sécurité de l'information sur le principe des segments standard. Et nous verrons également comment faire une telle certification correctement.

Il faut dire que les mythes à ce sujet circulent beaucoup et se contredisent souvent. Par exemple, il y a une opinion selon laquelle, selon le principe des segments standard, vous pouvez certifier tous les ISPD dans un pays (bien que la certification ne soit pas obligatoire pour les ISPD), mais d'autre part, il y a une opinion selon laquelle vous devez certifier les systèmes d'information uniquement à l'ancienne, et tous ces «segments typiques» de rusé.

Présentation

La certification de l'objet de l'informatisation est peut-être l'une des étapes les plus réglementées et les plus conservatrices de la construction d'un système de protection de l'information.

Le conservatisme réside dans le fait que la certification est soumise à un système spécifique avec une liste spécifique de moyens techniques, qui sont soigneusement réécrits dans le passeport technique à l'objet de l'informatisation et dans le certificat de conformité lui-même. Le remplacement, par exemple, d'un ordinateur brûlé d'un système d'information certifié peut impliquer au moins une longue correspondance avec l'organisation qui a effectué la certification et, à tout le moins, des tests de certification supplémentaires (c'est-à-dire les coûts).

Ce n'était pas un gros problème, alors que la certification des exigences de sécurité de l'information était soit des ordinateurs autonomes qui traitent les informations protégées, soit de petits réseaux locaux dédiés.

Mais les progrès ne s'arrêtent pas. Désormais, pour les systèmes d'information de l'État, le 17e décret du FSTEC détermine leur certification obligatoire avant la mise en service. Et les systèmes d'information d'État ne sont pas aujourd'hui un ordinateur statique ou un petit lokalka, mais de grands systèmes à évolution dynamique, souvent à l'échelle régionale ou même fédérale.

Alors, que faire dans ce cas? Une attestation est requise, mais il est impossible de certifier un système statique, car presque tous les jours de nouveaux éléments sont ajoutés et les anciens sont supprimés. Des "segments typiques" viennent à la rescousse.

Ce concept a été introduit par le 17e arrêté du FSTEC et la norme GOST RO 0043-003-2012 «Protection de l'information. Certification des objets d'informatisation. Dispositions générales »en 2013. Malheureusement, GOST est marqué «aggloméré», contrairement à la commande FSTEC, donc la norme ne peut pas être citée ici. Mais rien ne sera perdu de cela, puisque l'ordre du FSTEC dans l'ordre pour l'extension du certificat de conformité aux segments typiques est décrit de manière beaucoup plus détaillée (section 17.3), et quelques courts paragraphes y sont consacrés dans la norme.

Mythes autour de la certification de segment de type

Il existe de nombreux mythes autour de segments typiques. Ici, nous analyserons ceux que nous avons nous-mêmes rencontrés. Si vous avez des exemples de mythes ou de questions similaires (vous ne savez pas si c'est un mythe ou non), n'hésitez pas à commenter.

Mythe numéro 1. Un seul certificat sur le principe des segments standard peut certifier tous les systèmes d'information de la Fédération de Russie

Théoriquement, cela n'est pas directement interdit par les documents réglementaires, mais en pratique cela ne sera pas possible. L'une des clauses 17 de l'ordonnance FSTEC sur les segments modèles stipule que l'exécution de la documentation organisationnelle et administrative pour la protection des informations doit être assurée dans les segments standard. Ainsi, le gros problème est le développement d'une telle documentation, qui prendra en compte différents processus technologiques de traitement de l'information, différentes informations protégées, différentes exigences des régulateurs, etc. En conséquence, la documentation développée pour un système ne sera pas pertinente pour un autre.

Mythe numéro 2. Les "segments typiques" sont fournis uniquement pour les systèmes d'information d'État

Ce n'est pas le cas. Premièrement, le 17e arrêté du FSTEC lui-même permet d'appliquer ses dispositions dans le développement de systèmes de protection de l'information dans tout autre système d'information. Deuxièmement, GOST RO 0043-003-2012 utilise le concept plus large d '«objets d'informatisation» au lieu de «systèmes d'information d'État».

Mythe numéro 3. S'ils nous donnent un certificat qui peut être étendu à des segments standard, nous pouvons l'appliquer à n'importe quoi

Ce n'est pas le cas, sous le spoiler le texte complet du paragraphe 17.3 de l'ordonnance FSTEC n ° 17 pour les segments typiques, nous considérerons alors les cas où le certificat délivré ne peut pas être distribué. Ici, nous devons rester plus en détail.


De plus, nous prendrons des exemples spécifiques d'erreurs et ne citerons que les citations appropriées de cet acte normatif pour justifier pourquoi cela ne peut pas être fait.

Exemple n ° 1

Seule la partie serveur est certifiée, mais je souhaite étendre le certificat aux postes de travail (AWS). Cela peut-il être fait?



Non! La certification du système d'information est autorisée sur la base des résultats des tests de certification d'un ensemble sélectionné de segments du système d'information qui mettent en œuvre la technologie complète du traitement de l'information .

Le transfert d'informations via les canaux de communication est également une technologie de traitement. De plus, dans cet exemple, aucun poste de travail n'est certifié, nous ne pouvons donc pas étendre le certificat à un autre poste de travail standard.

Exemple n ° 2

Ici, nous avons pris en compte l'erreur précédente et inclus des canaux de transmission de données et un poste de travail typique dans le certificat. Du coup, nous avons eu besoin d'organiser un ordinateur portable pour un grand patron avec une connexion à un système certifié (via des canaux sécurisés, bien sûr). Pouvons-nous étendre le certificat de conformité à cet ordinateur portable?

Non! Un segment est considéré comme approprié pour le segment du système d'information pour lequel des tests de certification ont été effectués si les mêmes classes de sécurité et menaces à la sécurité de l' information ont été établies pour les segments indiqués ...

Ici, pour les moyens techniques mobiles, de nouvelles menaces à la sécurité de l'information apparaissent qui ne sont pas pertinentes pour les postes de travail fixes et ne sont probablement pas prises en compte dans le modèle de menace pour un système certifié.

Exemple n ° 3

Eh bien, nous avons pris en compte ce montant et ajouté des menaces au modèle de croissance, des menaces pour les appareils mobiles. Puis-je maintenant étendre le certificat à l'ordinateur portable d'un grand patron?



Non! Un segment est considéré comme pertinent pour le segment du système d'information pour lequel des tests de certification ont été effectués ...

Malgré le fait que l'outil mobile soit décrit dans la documentation de conception du système de protection des informations et que le modèle des menaces prenne en compte les menaces liées aux moyens techniques mobiles, aucun test de certification n'a été effectué pour un tel outil.

Exemple n ° 4

Comme c'est compliqué! Mais cette situation: il y a une institution médicale, il y a deux systèmes d'information - avec les employés et un système d'information médicale (MIS) avec les patients. Pouvons-nous sauvegarder, certifier le système d'information auprès des employés et étendre ce certificat aux AII?



Non! Un segment est considéré comme approprié pour le segment du système d'information pour lequel des tests de certification ont été effectués si les mêmes classes de sécurité ont été établies pour les segments indiqués ... les mêmes solutions de conception pour le système d'information .



Bien qu'il semble que tout soit compliqué ici, en fait, il vous suffit de réfléchir aux options possibles pour des segments typiques en vue de la construction d'un système de protection. Mais en fait, si vous prenez tout en compte (et qu'il n'y a pas tellement d'exigences), il n'y aura pas de problèmes avec la distribution du certificat.

Mythe numéro 4. Les segments typiques doivent être décrits dans la documentation de conception du système de protection, en commençant par le modèle de menace

Il n'y a pas une telle exigence. Bien que cela ne soit pas directement interdit, cette approche peut entraîner certains problèmes à l'avenir. Ce que la 17e ordonnance FSTEC nous dit à ce sujet:

Les caractéristiques de la certification d'un système d'information sur la base des résultats des tests de certification d'un ensemble sélectionné de ses segments, ainsi que les conditions et la procédure de distribution d'un certificat de conformité à d'autres segments d'un système d'information, sont définies dans le programme et les méthodes des tests de certification, conclusion et certificat de conformité.

Autrement dit, nous n'avons le droit de mentionner des segments typiques qu'au stade de la certification. Dans ce cas, vos segments seront typiques par défaut, si les conditions de l'article 17.3 de la commande FSTEC n ° 17 sont remplies. Mais nous avons rencontré des cas où des segments typiques ont été essayés de décrire déjà au stade de la modélisation des menaces, indiquant presque les numéros de série de l'équipement de ces segments. Le problème avec cette approche est que si un remplacement de matériel se produit ou si quelque chose change dans les technologies de traitement (par exemple, un environnement de virtualisation apparaît), les segments dans lesquels le certificat est déjà distribué peuvent devenir, disons, typiques illégitimes. Et dans ce cas, il peut être nécessaire d'effectuer non pas des «tests de certification supplémentaires», mais d'effectuer l'ensemble des tests conformément au nouveau.

En général, notre conseil est de ne pas mentionner du tout de segments typiques dans la documentation de conception. En effet, en vertu de la législation actuelle, tout segment qui remplit les conditions établies sera typique.

IMPORTANT! Si vous êtes un opérateur d'un système d'information et prévoyez de certifier un système d'information avec la capacité d'étendre le certificat à des segments standard, assurez-vous de discuter avec votre organisme de certification afin que cette possibilité soit reflétée dans les documents de certification, comme requis par la 17e ordonnance du FSTEC!

Mythe numéro 5. FSTEC ne comprend pas les "segments typiques" et si nous sommes certifiés comme ça, nous serons punis

Ce mythe semble très étrange, étant donné que les segments typiques sont décrits plus en détail dans la documentation réglementaire du FSTEC. Cette idée est le plus souvent entendue par les agents de sécurité de la soi-disant «vieille école».

En général, à l'exception de «ce n'est pas vrai», nous n'avons rien à dire ici. Au contraire, le régulateur promeut ce système de certification des systèmes d'information de toutes les manières possibles et, tout récemment, nous avons même rencontré une affirmation du FSTEC selon laquelle un énorme système d'information au niveau régional n'était PAS certifié par le principe des segments standard. Là, j'ai dû expliquer que dans ce cas particulier, ce n'était pas optimal.

Mythe numéro 6. Les segments typiques ne fonctionnent que lorsque la pièce et les segments certifiés sont la propriété d'une seule organisation

Ce n'est pas vrai. Cela n'est pas explicitement indiqué dans la législation, mais tout ce qui n'est pas interdit est autorisé. Mais, bien sûr, il existe certaines différences lorsque les segments de pièce et de modèle certifiés sont la propriété d'une seule organisation, et lorsque les segments de modèle appartiennent à des entités juridiques tierces, il y en a.

Dans le cas où tout appartient à une seule organisation, cette organisation peut indépendamment prendre des mesures pour protéger les informations sur un segment standard, nommer une commission et étendre le certificat à un segment standard.

Dans les cas où il existe un opérateur central du système d'information de l'État (par exemple, un centre régional de technologie de l'information) et des segments d'autres entités juridiques (par exemple, un système régional de gestion des documents des institutions de l'État), alors tout est un peu plus compliqué. La difficulté réside dans le fait que, conformément à la loi, l'exploitant de ces SIG est responsable de la protection des informations dans les systèmes d'information de l'Etat. Par conséquent, afin que le prochain test ne réchauffe pas l'opérateur du fait que quelque part dans l'école à 400 km du centre régional, des mesures de protection des informations ne sont pas prises, il doit documenter ce processus au moins au stade de la connexion d'un segment typique. Tout d'abord, les règles de connexion au système d'information sont créées, où l'opérateur décrit clairement et clairement les exigences de protection des informations qui doivent être respectées sur le segment connecté. Cela comprend généralement la nomination des responsables, l'approbation des documents internes pour la protection des informations (en particulier les opérateurs confus peuvent même développer et fournir un ensemble standard), l'achat, l'installation et la configuration des outils de protection des informations nécessaires, l'analyse des vulnérabilités, etc. En outre, l'organisation souhaitant se connecter effectue toutes les exigences et de la manière spécifiée dans les règlements le confirment.

En revanche, toutes les difficultés décrites sont un plan d'action approximatif que nous avons déjà inventé avec l'un de ces opérateurs. Si l'opérateur d'un SIG distribué n'a pas peur de porter la responsabilité de ne pas prouver le fait de remplir les conditions de protection des informations sur le segment distant au moins au stade de la connexion, alors il peut emprunter un chemin simplifié (comment «simplifié» cet opérateur peut décider).

Malheureusement, certains opérateurs le font parce qu'ils croient sincèrement au mythe suivant.

Mythe numéro 7. L'autorité de certification est chargée d'étendre le certificat aux segments qui ne répondent pas aux exigences.

Il est très important pour nous, en tant qu'organisme de certification, de comprendre les limites de notre responsabilité. Étant donné que la loi ne répond pas clairement à la question «qui est responsable de l'extension du certificat aux segments non conformes», nous avons écrit une lettre au FSTEC.

Le FSTEC a répondu que l'organisme de certification n'est responsable que de la qualité des tests de certification eux-mêmes. L'organisation-opérateur du système d'information est responsable de la bonne distribution du certificat aux segments typiques.

Mythe numéro 8. Les segments typiques ne nous donneront rien. Quoi qu'il en soit, vous devez attirer un titulaire de licence et lui payer de l'argent

Ce n'est pas le cas. Au moins dans les cas où le personnel de l'opérateur du système d'information dispose de spécialistes capables de mener à bien toutes les activités décrites ci-dessus.

D'autre part, nous rencontrons souvent le fait qu'on nous demande d'aider à connecter des segments standard. Quoi qu'il en soit, dans ces segments, au moins, vous devez élaborer la documentation interne, installer et configurer correctement les outils de sécurité des informations. De plus, de nombreux opérateurs de systèmes d'information font davantage confiance aux conclusions sur la conformité d'un segment type rédigées par une organisation tierce qu'au rapport du demandeur pour la connexion au système.

Mais même dans ce cas, les segments typiques permettent à l'opérateur d'économiser de l'argent, car au moins il n'est pas nécessaire de développer un modèle de menace séparé et une documentation de conception pour le système de protection des informations pour les éléments amovibles. Il n'est pas non plus nécessaire d'effectuer des tests de certification à grande échelle.

Mythe numéro 9. Dans les segments typiques, seuls les mêmes moyens techniques doivent être utilisés (par exemple, des ordinateurs avec la même carte mère, le même processeur, la même RAM, jusqu'au type, fabricant et modèle)

Cette question n'est clairement pas non plus énoncée dans la législation. Sur un plan intuitif, il est clair que la pleine conformité du fer du segment certifié et connecté n'est pas requise, sinon le tout ne vaut rien. Et lorsque nous devons clarifier une question similaire, que faisons-nous? C'est vrai - nous écrivons une lettre au régulateur. Le FSTEC devrait répondre que des solutions techniques identiques (un fabricant, un modèle, etc.) ne devraient pas être utilisées dans des segments typiques.

Pour qu'un segment soit considéré comme approprié pour le segment certifié, il est nécessaire d'établir pour lui la même classe de sécurité, les mêmes menaces à la sécurité de l'information et les mêmes solutions de conception sont mises en œuvre pour le système lui-même et pour le système de protection de l'information. Tel qu'écrit dans l'ordre 17.

Mythe numéro 10. Pour chaque segment de type amovible, vous devez créer votre propre modèle de menace.

Non. Dans le segment typique, les mêmes menaces devraient être pertinentes que dans la partie certifiée du système d'information. Par conséquent, le modèle de menace s'applique à l'ensemble du système. Si des changements technologiques significatifs se produisent dans le système d'information certifié qui pourraient conduire à l'émergence de nouvelles menaces à la sécurité de l'information, il est nécessaire de réviser le modèle général de menace et, si nécessaire, d'effectuer des tests de certification supplémentaires du système dans son ensemble.

Mythe numéro 11. Les données des segments standard joints ne doivent pas être reflétées dans le passeport technique du système d'information

Sur cette question, nous avons également interrogé le FSTEC. La réponse est que les données des nouveaux segments doivent être entrées dans le passeport technique. Mais l'opportunité de saisir de nouvelles données dans la fiche technique générale du système ou de créer un document séparé pour le segment appartient à l'opérateur. .

. – . , .