L’utilisation de Linux en tant que système d’exploitation flexible, transparent et hautement sécurisé semble de plus en plus devenir un choix de premier plan au sein d’entreprises,d’institutions d’enseignement et de secteurs gouvernementaux. Avec des préoccupations de sécurité nationale qui ont atteint un niveau record aux États-Unis, il semble que la mise en œuvre de Linux pourrait effectivement répondre aux besoins critiques du gouvernement américain en matière de sécurité pour le développement et les installations d’applications.
En raison de ses racines open source, Linux est considéré fondamentalement comme étant sécurisé, fiable et incroyablement adaptable. Linux intègre une approche de « défense en profondeur » de la sécurité, ce qui signifie que des mesures de sécurité robustes sont mises en œuvre à tous les niveaux de développement et de déploiement. Notons que Linux met l’accent sur la sécurité par la transparence.
Pour être approuvés pour une utilisation dans des fonctions gouvernementales essentielles, les logiciels et applications doivent être certifiés pour garantir qu’ils répondent à certaines normes de sécurité. Common Criteria, FIPS 140-2 et Secure Technical Implementation Guidelines (STIG) sont trois certifications de sécurité requises par le Département de la Défense des États-Unis. Ces certifications indiquent que la technologie répond aux protocoles de sécurité normalisés et que les outils cryptographiques implémentent correctement leurs algorithmes. Linux a été certifié pour répondre à tous ces critères.
Common Criteria : les critères communs (CC) sont un ensemble de normes (ISO 15408) internationalement reconnu dont l’objectif est d’évaluer de façon impartiale la sécurité des systèmes et des logiciels informatiques. Également dénommé Common Criteria, ce référentiel est né d’un partenariat entre le Canada, les États-Unis et l’Europe. Grâce au cadre offert, les utilisateurs de technologies de l’information vont pouvoir utiliser des profils de protection pour spécifier les exigences fonctionnelles de sécurité attendues et les évaluateurs pourront vérifier que les produits sont bien conformes au niveau d’assurance requis.
La mise en œuvre des Critères Communs décidée par les signataires d’un accord de reconnaissance mutuelle facilite grandement l’acceptation des certificats de sécurité des technologies de l’information émis par l’un des pays signataires. Le produit certifié en toute impartialité par une autorité compétente peut être utilisé sans nécessiter une évaluation plus poussée.
Bien que présentant de nombreux avantages, l’application de cette norme s’avère coûteuse, difficilement compréhensible pour un non initié et souvent compliquée à mettre en œuvre. C’est la raison pour laquelle plusieurs méthodes d’utilisation ont vu le jour.
FIPS : FIPS (Federal Information Processing Standard) 140-2 est une norme établie par le gouvernement des États-Unis relative au chiffrement et aux conditions de sécurité à respecter dans la conception des produits informatiques destinés à traiter des données sensibles, mais non confidentielles. Cette norme vise à garantir que les produits mettent en œuvre des pratiques de sécurité saines, à savoir des méthodes et des algorithmes de chiffrement puissants et approuvés. Elle précise également comment autoriser des personnes et des processus à utiliser le produit et comment concevoir les modules et les composants de manière à sécuriser leurs interactions avec d’autres systèmes. La norme FIPS 140-2 s’applique à tout produit susceptible de stocker ou de transmettre des données sensibles. Cela inclut des matériels tels que périphériques de cryptage des liens, disques durs, disques Flash ou autres supports de stockage amovibles. Les logiciels qui chiffrent les données transmises ou stockées y sont également inclus.
Secure Technical Implementation Guidelines (STIG) : Il s’agit d’une méthodologie de cybersécurité pour normaliser les protocoles de sécurité au sein des réseaux, des serveurs, des ordinateurs et des conceptions logiques afin d’améliorer la sécurité globale. Une fois mis en œuvre, ces guides améliorent la sécurité des architectures logicielles, matérielles, physiques et logiques afin de réduire davantage les vulnérabilités.
La configuration d’un ordinateur de bureau ou d’un serveur d’entreprise est un exemple où les STIG seraient utiles. La plupart des systèmes d’exploitation ne sont pas intrinsèquement sécurisés, ce qui les laisse ouverts aux criminels tels que les voleurs d’identité et les pirates informatiques. Un STIG décrit comment minimiser les attaques basées sur le réseau et empêcher l’accès au système lorsque l’attaquant s’interface avec le système, soit physiquement sur la machine soit sur un réseau. Les STIG décrivent également les processus de maintenance tels que les mises à jour logicielles et les correctifs de vulnérabilité.
Les STIG avancés peuvent couvrir la conception d’un réseau d’entreprise, couvrant les configurations de routeurs, de pare-feu, de serveurs de noms de domaine et de commutateurs.
Pour ces raisons, Linux n’est pas seulement un système d’exploitation qui peut servir au développement d’applications gouvernementales à sécurité critique, mais l’ouverture et la flexibilité inhérentes à Linux en font également un candidat intéressant pour les installations qui exigent le plus haut niveau de sécurité et de précision. Cependant, il convient de noter que, comme pour tout système d’exploitation, Linux doit d’abord subir des tests et un développement rigoureux supplémentaires avant d’être intégré dans l’infrastructure informatique du gouvernement américain.
SELinux: sécurité renforcée grâce aux contrôles d’accès
Security-Enhanced Linux, abrégé SELinux, est un Linux Security Module (LSM), qui permet de définir une politique de contrôle d’accès obligatoire aux éléments d’un système issu de Linux. SELinux embarque des concepts dont certains s’appuient sur des projets de la National Security Agency des États-Unis, parmi lesquels des recherches sur l’architecture de contrôle d’accès obligatoire (MAC) basée sur Type Enforcement qui a donné naissance au Flask. Une implémentation de référence de cette architecture a été initialement intégrée dans un système prototype SELinux pour démontrer la valeur des contrôles d’accès obligatoires flexibles et comment ces contrôles pourraient être ajoutés à un système d’exploitation. L’architecture a été reconnue pour ses avantages en termes de sécurité et a depuis été intégrée au système d’exploitation Linux traditionnel.
SELinux impose la séparation des informations sur la base des exigences de confidentialité et d’intégrité, ce qui permet de traiter les menaces et de limiter les dommages qui pourraient être causés par des applications malveillantes ou défectueuses. Son architecture dissocie l’application de la politique d’accès et sa définition. Il permet notamment de classer les applications d’un système en différents groupes, avec des niveaux d’accès plus fins. Il permet aussi d’attribuer un niveau de confidentialité pour l’accès à des objets systèmes, comme des descripteurs de fichiers, selon un modèle de sécurité multiniveau (MLS pour Multi level Security).
Au départ, SELinux était le sujet de controverse. Nombreuses étaient les personnes qui se disaient préoccupées par l’insertion de code NSA dans Linux, malgré sa transparence. Les rumeurs selon lesquelles la NSA incorporait des portes dérobées et une technologie capable de compromettre la confidentialité des utilisateurs ont proliféré pendant de nombreuses années. Toutefois, cette vague de controverse semble s’être calmée et SELinux est désormais reconnu pour l’amélioration de la sécurité globale de Linux.
Open source
Cette dernière décennie, le gouvernement américain s’est vu utilisé de plus en plus de logiciels open source pour déployer de manière économique des technologies avancées hautement sécurisées. Le 8 août 2016, le DSI de la Maison-Blanche a publié une politique fédérale sur le code source qui appelle à la création, au partage et à l’adaptation de nouveaux logiciels à l’aide de méthodes open source afin de tirer parti d’un code « sécurisé, fiable et efficace pour objectifs nationaux ».
Le département américain de la Défense reconnaît les principaux avantages associés au développement open source et fait confiance à Linux comme système d’exploitation. En fait, l’armée américaine est la plus grande base installée unique pour RedHat Linux et la flotte de sous-marins nucléaires de l’US Navy fonctionne sur Linux, y compris leurs systèmes de sonar. De plus, le ministère de la Défense a récemment recruté Red Hat, Inc., le plus grand fournisseur mondial de solutions open source, pour aider à améliorer les opérations de l’escadron et la formation au pilotage.
Les défenseurs des logiciels propriétaires ont suscité un débat sur la pertinence d’utiliser Linux en matière de défense nationale. Ils estiment que la disponibilité du code source pour les applications open source et les origines inconnues du code peuvent conduire à placer délibérément du contenu subversif dans des codes critiques, mettant en danger la sécurité du pays tout entier.
Cette argumentation ne prend pas en considération le fait que tout système choisi devrait être ajusté et retravaillé pour correspondre aux besoins informatiques uniques et critiques du gouvernement. Cependant, en supposant que le gouvernement se tourne vers Linux pour les applications de défense nationale, les défenseurs de l’open source estiment que la disponibilité du code source est exactement ce qui fait de Linux le choix évident. Linux et d’autres applications open source offrent la liberté de personnaliser des programmes pour répondre à des exigences spécifiques, une liberté qui n’existe pas vraiment au sein des systèmes propriétaires d’après eux. Si la sécurité fournie par une installation particulière est insuffisante, elle peut être modifiée pour garantir les niveaux de protection les plus élevés.
De plus, le gouvernement des États-Unis, en particulier le ministère de la Défense, a des normes extrêmement élevées en matière de sécurité et de confidentialité. Par conséquent, tout code choisi pour les systèmes gouvernementaux ou militaires doit être certifié selon Common Criteria, FIPS 140-2 et Secure Technical Implementation Guidelines (STIG) et subir d’innombrables heures d’analyse et d’évaluation de la vulnérabilité avant même qu’il puisse être pris en compte pour les tests.