Il n'y a pas de systèmes d'exploitation sans vulnérabilités - la seule question est de savoir avec quelle efficacité les développeurs les identifient et les ferment. Notre système d'exploitation Astra Linux Special Edition ne fait pas exception: nous vérifions et testons constamment le code pour détecter les erreurs, les violations de logique, les autres bogues et les corriger rapidement. Sinon, le FSTEC de Russie n'aurait guère certifié Astra Linux pour le traitement de données constituant des secrets d'État. Mais nous parlerons plus en détail de la certification dans un autre article. Et dans ce document, nous allons parler de la façon dont les vulnérabilités Astra Linux sont organisées et comment les menaces de sécurité des informations sont interagies avec la base de données nationale.
Photo: Leonhard Foeger / ReutersLa première approche, architecturale
Pour améliorer la sécurité du système d'exploitation, nous utilisons deux approches. La première,
architecturale , consiste à développer et à mettre en œuvre divers outils de protection des informations au stade de la conception. Ces outils forment un
complexe d'équipements de protection (KSZ) , qui met en œuvre des fonctions de sécurité. Avec l'aide de KSZ, nous essayons de nous assurer que le système minimise déjà le risque de menaces potentielles par défaut.
Architecture de la suite de sécurité Astra LInux édition spécialeUn élément clé de la KSZ est
le moniteur d'appel , conçu pour empêcher l'accès non autorisé et la modification des composants protégés du système. Le moniteur prévoit un contrôle d'accès discrétionnaire, basé sur les rôles et obligatoire, ainsi qu'un contrôle d'intégrité obligatoire.
Qu'est-ce que
la surveillance obligatoire de l'intégrité ? Illustrons par un exemple. Un composant clé de l'OS est le noyau. En conséquence, nous sommes obligés de lui fournir le runtime le plus sécurisé du système d'exploitation lui-même afin de réduire le nombre de méthodes possibles d'attaque du noyau.
Pour ce faire, nous implémentons une surveillance d'intégrité obligatoire dans le système d'exploitation, grâce à laquelle nous segmentons le système d'exploitation par divers sous-systèmes afin que la rupture d'un sous-système n'affecte pas les performances des autres. Si un utilisateur non privilégié du système d'exploitation (niveau d'intégrité 0) ou d'un sous-système réseau (niveau d'intégrité 1), d'un système de virtualisation (niveau d'intégrité 2), d'une interface graphique (niveau d'intégrité 8) ou d'un autre composant est piraté, cela n'entraînera pas le discrédit de l'ensemble du KSZ (niveau d'intégrité) 63).
Il convient de noter que ces niveaux ne sont pas hiérarchiques, c'est-à-dire qu'ils ne sont pas situés les uns au-dessus des autres et sont complètement isolés les uns des autres en termes de possibilité de droits d'écriture. Le moniteur d'accès détermine l'accessoire d'un objet à l'un ou l'autre niveau d'intégrité par le masque binaire.
Pour que les niveaux d'intégrité ne soient pas perçus comme hiérarchiques - c'est-à-dire, par exemple, "le niveau 8 a plus de droits que le niveau 2", ce qui est faux - chacun des niveaux tire son nom. Ainsi, par exemple, le huitième niveau d'intégrité est appelé «Graphic Server», le niveau d'intégrité maximal possible de l'administrateur dans le système est «High» et le niveau zéro d'intégrité (utilisateur) est «Low».
Le moniteur d'appel, décrit dans notre
article précédent, contrôle et élimine la possibilité d'influence les uns sur les autres avec des étiquettes de différents niveaux d'intégrité.
Ainsi, le système d'exploitation reçoit un ensemble de règles sur la façon d'isoler les processus système les uns des autres et comprend désormais quels processus, même ceux lancés par un utilisateur avec des privilèges élevés, n'ont pas le droit d'écrire dans d'autres processus ou fichiers.
Par conséquent, si à la suite de l'exploitation d'une vulnérabilité (y compris zero day), un attaquant prend le contrôle d'un processus dans le système et augmente son autorité à un utilisateur privilégié (par exemple, root), sa marque d'intégrité restera la même et, par conséquent, il ne recevra pas la capacité d'influencer les processus du système, de modifier les paramètres ou de masquer votre présence dans le système.
Principe de fonctionnement des niveaux d'intégrité isolésAinsi, l'ensemble du système d'exploitation ne devient pas une cible importante pour un attaquant, mais uniquement le noyau durci et le moniteur d'accès le plus compact, ce qui réduit déjà considérablement la surface d'attaque.
En plus de l'obligation, il existe également un contrôle d'intégrité dynamique et réglementaire. Ils sont utilisés pour exclure le lancement et l'utilisation de logiciels non fiables ou tiers, ainsi que des contrôles périodiques de l'intégrité du système.
Le contrôle dynamique calcule et vérifie la signature numérique électronique des fichiers exécutables au moment de leur lancement. S'il n'y a pas d'EDS ou s'il est incorrect, le lancement des programmes sera refusé. Dans une certaine mesure, il s'agit d'une mise en œuvre du concept de listes blanches, mais grâce à l'utilisation d'une hiérarchie de clés délivrées aux développeurs de logiciels.
Travailler avec le contrôle d'intégrité dynamiqueLe contrôle de routine vérifie l'intégrité et l'immuabilité des fichiers clés d'un système en comparant leurs sommes de contrôle aux valeurs de référence. Il peut s'agir de fichiers de configuration ou de tout autre.
Ainsi, le système d'exploitation utilise une protection en couches contre les vulnérabilités des applications et leur substitution, minimisant ainsi les dommages causés par les menaces de sécurité, y compris celles qui utilisent des vulnérabilités zero-day.
La seconde, l'approche processus
Parallèlement à l'architecture, nous utilisons simultanément l'approche
processus : nous identifions et collectons constamment des informations sur les vulnérabilités, travaillons à travers ces informations et transférons les résultats à la banque de données de vulnérabilité du FSTEC Russie. Nous préparons et publions donc des mises à jour du système d'exploitation planifiées et opérationnelles. Nous recherchons des vulnérabilités à la fois dans les sources ouvertes et de manière indépendante - en particulier dans les parties du logiciel que nous développons entièrement nous-mêmes. Nous obtenons beaucoup d'informations de partenaires engagés dans des recherches similaires - tester et étudier la sécurité des systèmes d'exploitation.
Gestion des vulnérabilitésLes études de sécurité sont principalement menées en relation avec les composants qui font partie de l'Astra Linux Special Edition (Smolensk). Dans le même temps, les vulnérabilités sont également fermées pour Astra Linux Common Edition, à la fois dans le cadre des mises à jour de sécurité et dans le cadre d'une mise à jour programmée des composants du système.
Dès que nous recevons des informations sur la vulnérabilité, nous vérifions sa pertinence pour nos utilisateurs.
Si la vulnérabilité n'est pas critique, nous la décrivons dans le prochain numéro du bulletin de sécurité sur le site officiel. Des notifications sur l'émission des bulletins de vote sont envoyées à l'utilisateur par e-mail, dont l'adresse est obligatoirement indiquée dans le contrat de licence.
Pour les vulnérabilités critiques, des directives sont émises sur plusieurs jours : comment pouvez-vous le réparer vous-même sans attendre une mise à jour de sécurité cumulative. Dans la
liste des bulletins
de sécurité, ils sont marqués des lettres MD (direction méthodique).
Une vulnérabilité est un bon exemple ici, dont les informations ont été
publiées ici sur Habré. Soit dit en passant, l'auteur de cet article ne nous a pas contactés à l'avance et n'a pas notifié au préalable qu'il avait identifié cette vulnérabilité et préparait du matériel. À titre d'illustration, nous avons décidé de citer le calendrier des travaux sur la vulnérabilité à partir du moment où le texte a été publié sur la ressource.
Donc, la nuit, à 4 heures du matin, le 9 juillet 2019, l'article lui-même a été publié, que lorsque vous manipulez la taille de l'écran d'une machine virtuelle, vous pouvez voir les fenêtres sous le verrouillage de l'écran.
Il convient de noter que pour exploiter la vulnérabilité démontrée sur la vidéo, vous devez effectuer un certain nombre d'étapes supplémentaires: vous devez d'abord installer des packages supplémentaires sur la machine virtuelle Astra Linux, puis sur la machine invitée, qui sont chargés de modifier la résolution de la machine virtuelle à la volée, mais pas font partie d'un système d'exploitation certifié.
Le 10 juillet 2019, des informations sur les vulnérabilités ont été
publiées dans l'EDR FSTEC. La gravité de la vulnérabilité a été définie comme moyenne (le score de base pour la métrique CVSS 2.0 était de 4,9, pour la métrique CVSS 3.0 - 4).
Le 12 juillet, nous avons publié le bulletin de sécurité n °
20190712SE16MD pour Astra Linux Special Edition version 1.6 et le bulletin de sécurité n °
20190712SE15MD pour Astra Linux Special Edition version 1.5. Une mise à jour de sécurité similaire a été reçue par Astra Linux Common Edition.
Ainsi, moins de 4 jours se sont écoulés depuis la publication d'informations sur la vulnérabilité de niveau moyen à la sortie du correctif pour toutes les versions d'Astra Linux (où la virtualisation est possible).
Schéma de mises à jour en direct pour Astra LinuxAu moins une fois par trimestre, nous publions des mises à jour de sécurité -
des mises à jour opérationnelles qui éliminent les vulnérabilités précédemment inconnues, y compris les logiciels d'application, les bibliothèques et les fonctions du système d'exploitation qui ne mettent pas en œuvre les exigences de sécurité. Si les menaces de sécurité mises en œuvre à l'aide de la vulnérabilité ne peuvent pas être exclues par des mesures compensatoires, des travaux sont en cours pour finaliser le système d'exploitation. Une fois le développement et les tests de la mise à jour de sécurité terminés, le site Web publie également la newsletter et la mise à jour elle-même. Au cours des six premiers mois de 2019, deux mises à jour cumulatives pour la version 1.6 d'Astra Linux Special Edition ont été publiées, couvrant des centaines de vulnérabilités différentes. Maintenant, le troisième est en préparation pour la sortie.
Enfin, nous interagissons activement avec la communauté des développeurs:
- Nous informons les bugtrackers du projet des erreurs auto-détectées;
- nous transférons aux projets des corrections toutes faites des lacunes que nous avons fermées;
- nous faisons appel à la communauté pour aider à éliminer les carences - la connaissance de la logique du programme vous permet d'obtenir un ordre de grandeur de correction plus rapide que la rétro-ingénierie effectuée seule;
- Nous utilisons et incluons dans nos mises à jour tous les correctifs publiés par la communauté. Nous comprenons cela améliorant ainsi la qualité du produit. Dans le même temps, nous appliquons les méthodes de contrôle et de renforcement de la confiance décrites dans l'article précédent .
L'ouverture est importante
Étant donné que notre système d'exploitation est certifié par le FSTEC de Russie, nous ajoutons tout d'abord des informations sur les vulnérabilités trouvées dans la banque de données des menaces de sécurité de l'information (DBU) du FSTEC pour publication officielle: si vous allez à la
DBU , vous trouverez des informations sur plus de 350 vulnérabilités corrigées dans différentes versions d'Astra Linux ainsi que des informations détaillées à leur sujet.
Ainsi, nous garantissons l'ouverture au travail. Grâce à cela, les utilisateurs - y compris le régulateur - peuvent être dans une certaine mesure convaincus que la sécurité est en effet sous contrôle. Il ne suffit pas d'obtenir une mise à jour, vous devez comprendre quelles vulnérabilités spécifiques il a fermées.
Jusqu'à présent, notre approche architecturale et de processus pour maintenir la sécurité du système d'exploitation est pleinement justifiée - nous maintenons avec succès un niveau élevé de sécurité pour les systèmes d'information avec Astra Linux Special Edition OS. Et l'accès ouvert aux informations sur les vulnérabilités via le panneau de contrôle FSTEC augmente le niveau de confiance dans notre produit.
Nous serons heureux de répondre aux questions sur la sécurité de notre système dans les commentaires. De plus, si vous êtes intéressé à apprendre quelque chose de nouveau sur le système, laissez vos souhaits - nous les prendrons en compte lors de la poursuite de la collaboration avec le blog.