La sécurité, dans le monde de l'informatique, représente beaucoup de disciplines différentes. De l'infrastructure, aux réglementations en passant par l'outillage, les termes techniques et obscurs rendent ce domaine assez complexe à appréhender. Avec mon parcours de développeur puis tech lead, donc de non-spécialiste, je vous propose un tour d'horizon de ce qu'on peut entendre dans le terme sécurité des SIs.
Nous allons aborder ici principalement ce que qui gravite autour du système d'informations, nous n'aborderons pas la cybercriminalité par exemple. Restons dans le technique et dans nos capacités à faire.
Avant de rentrer dans le vif du sujet, un point de vocabulaire. Dans le monde de la sécurité informatique, on peut adopter deux approches distinctes, correspondant à deux équipes (teams). La première consiste à chercher les failles, à attaquer ou à pirater un système : dans ce cas, on parle de Red Team ; la seconde vise à protéger le système : on parlera alors de Blue Team.
Bien que partageant quelques pratiques et outils, ce sont deux univers différents. Il est intéressant, pour les deux parties, de connaitre les pratiques de l'autre. La sécurité, c'est un jeu du chat et de la souris : il vaut donc mieux connaitre les habitudes de son adversaire pour être efficace.
Ce n'est pas pour rien que l'on compare et utilise le vocabulaire de la médecine et militaire : la protection des SI comme défense et les attaques et malwares en tout genre comme virus.
Nous nous positionnerons d'un point de vue Blue team ici et nous parcourrons ce sous-ensemble des couches hautes vers les couches basses. J'en profiterai pour définir quelques termes obscurs que vous avez déjà probablement déjà rencontrés.
Commençons par le domaine que je maîtrise le moins : la gouvernance cyber.
La gouvernance cyber : spécialiste de la sécurité d'un point de vue générale
Quand nous parlons de sécurité d'un point de vue entreprise, un des premiers points qui me vient en tête est la réglementation. Il existe plusieurs textes auxquels sont soumis les organisations et entreprise. Que ce soient des réglementations, DORA par exemple, des directives ou des lois, elles ont des impacts techniques sur le SI d'une entreprise mais pas uniquement.
Globalement, ces textes vont surtout imposer des process, de rendre des comptes à des organismes de contrôle et donner des principes à appliquer. Ils sont rarement clairs d'un point de vue technique et vont surtout demander de justifier de pratiques pour respecter ces règles.
Par exemple, ils peuvent exiger la protection des chaines fabrications. Cette expression reste floue, mais les organisations, au travers de leurs experts cyber, devront pousser/vérifier/justifier des pratiques mise en place pour répondre à cette exigence. Pour ce faire, ils échangeront avec les différentes directions pour s'assurer que les projets en réalisation la respectent bien. Et ce sont souvent les directions qui feront appel aux profils techniques pour mettre en place les outils techniques permettant d'y répondre.
Un autre exemple, non technique au premier abord : la gestion des assets physiques. Quelles sont les règles concernant le recyclage du matériel d'un point de vue sécurité ? Comment assure-t-on que seules les personnes autorisées puissent accéder au réseau de l'entreprise ?
Les équipes traitant de la gouvernance de la cyber ne sont pas des "techniques" : en tout cas, pas au sens développement. Ce sont des spécialistes des réglementations et process autour de l'ensemble de problématique de sécurité d'un SI. Ils agissent principalement auprès des RSSI et de la direction.
Pour la blague, j'ai connu un excellent cyber qui ne connaissait pas l'OWASP.
DICT : la clé de voûte de la sécurité
L'acronyme DICT ou CIA, pour son homologue anglo-saxon, définit le "niveau" sécurité nécessaire à un système/une fonctionnalité. Il est indispensable de le définir et de le retrouver dans les dossiers d'architecture. Il va permettre aux équipes de savoir quels outils, process et mécanismes il est nécessaire de mettre en place pour garantir le bon niveau de sécurisation ce qu'ils réalisent.
Le DICT est généralement représenté par 4 notes, pour chaque item, de 0 à 4. Il n'y a pas de standard, certaines entreprises ont leur propre système de quotation, mais l'idée est toujours la même. Une petite recherche dans Google image vous donnera des exemples.
Cet acronyme signifie Disponibilité, Integrité, Confidentialité, Traçabilité.
Disponibilité
L'accès aux ressources du système d'information doit être permanent et sans faille durant les plages d'utilisation prévues. Les services et ressources sont accessibles rapidement et régulièrement. (https://fr.wikipedia.org/wiki/S%C3%A9curit%C3%A9_des_syst%C3%A8mes_d%27information)
Souvent, on va le retrouver dans les SLA de nos systèmes : ce fameux 99,9999% de disponibilité. Autant pour certains systèmes, une rupture de service n'est pas très important, par exemple pour un site institutionnel ; autant pour une centrale nucléaire, c'est indispensable. On va préférer avoir un système qui fonctionne à une protection contre un vol de données.
C'est avec des contraintes de disponibilité forte qu'on va entendre parler de mode dégradé. On va trier entre les fonctionnalités vitales, critiques et les autres pour assurer le fonctionnement de ces premières, que ce soit en terme de répartition de ressources techniques que de ressources humaines.
Intégrité
Les données doivent être celles que l'on attend, et ne doivent pas être altérées de façon fortuite, illicite ou malveillante. En clair, les éléments considérés doivent être exacts et complets. Cet objectif utilise généralement des méthodes de calcul de checksum ou de hachage.(https://fr.wikipedia.org/wiki/S%C3%A9curit%C3%A9_des_syst%C3%A8mes_d%27information)
L'intégrité, ou autrement dit la non-corruption des données, est un élement vital pour certains domaines. Le premier exemple est le domaine bancaire, mais on peut aussi penser aux communications militaires. Une négation oubliée ou un ordre corrompu peut avoir des conséquences désastreuses ; alors que l'intégrité des données indexées du moteur de recherche d'un site de e-commerce ont une importance moindre, la priorité étant la performance et pertinence de la recherche.
Typiquement, la mise en place de checksum, les blockchains, les systèmes de contrôles de données, etc. sont des mécanismes permettant de s'assurer que les données sont correctes. On va aussi retrouver les signatures et tiers de confiance, pour s'assurer que les données que l'on reçoit sont légitimes et proviennent bien de la bonne source d'information. Le fonctionnement des certificats dans le cadre du HTTPS en est un parfait exemple.
Dans les cas où l'intégrité des données est très importante, on va privilégier les contrôles à la performance d'accès ou d'écriture.
Confidentialité
Seules les personnes autorisées peuvent avoir accès aux informations qui leur sont destinées (notions de droits ou permissions). Tout accès indésirable doit être empêché. (https://fr.wikipedia.org/wiki/S%C3%A9curit%C3%A9_des_syst%C3%A8mes_d%27information)
Le contrôle d'accès ne se limite pas qu'aux données. Il va aussi considérer les accès à certains systèmes, que ce soit physiquement ou numériquement. C'est dans ce cadre en particulier que l'on va parler de sécurité défense et données médicales : au-delà de l'aspect technique du contrôle d'accès, les agrégations et les criblages pour accéder à ces informations et systèmes permettent de restreindre les accès à ces éléments aux profils de "confiance".
Les réseaux fermés, techniques d'authentification et d'identification sont un exemple des techniques permettant d'assurer la confidentialité des systèmes.
Traçabilité
Garantie que les accès et tentatives d'accès aux éléments considérés sont tracés et que ces traces sont conservées et exploitables. (https://fr.wikipedia.org/wiki/S%C3%A9curit%C3%A9_des_syst%C3%A8mes_d%27information)
Les logs, l’identification des utilisateurs, les identifiants de corrélation, au-delà des intérêts de monitoring, permettent de savoir qui fait quoi et à quel moment sur un système. Il existe beaucoup de réglementations autour de la traçabilité ; une partie du RGPD traite de ces sujets. Dans certaines situations, la justice peut demander l’accès à ces informations, en particulier dans des cas d’enquête.
Les logs et la traçabilité ne concernent pas seulement les applications web, mais aussi les accès physiques, les connexions d’administration et toute autre interaction avec le système. Au-delà de contrôler des actes malveillants, ils permettent également de vérifier que les permissions et les actions des utilisateurs sont légitimes, afin de se prémunir contre de mauvaises manipulations non volontaires.
Contrairement à ce que l'on pense, la gestion correcte de la traçabilité peut être complexe. L'un des buts des pirates étant d'effacer leurs traces, la façon dont on traite ces informations doit être mûrement réfléchie et surtout en lecture seule (Read-Only).
Une règle d'or sur les logs est l'externalisation : on ne stocke pas les logs sur les systèmes qui les émettent. Un exemple classique mais efficace : si votre système est inaccessible, vous aurez besoin des logs pour en connaitre la raison, mais le système est inaccessible.
Où retrouver ces informations
Les dossiers d'architecture peuvent avoir une partie spécifiquement liée à la sécurité, le DAS: Dossier d'Architecture de Securité. Vous trouverez peut-être d'autres façons d'aborder ces items, CAID, DICP, etc. Le principe restera le même avec quelques variantes et ajouts.
A vous de voir l'acronyme qui vous parle le plus.
Dans tous les cas, l'aspect sécurité et la mise en place des mécanismes de protection découleront de ces quelques éléments de très haut niveau.
La définition du DICT se fait généralement sur un système complet, mais dans l'idéal, il devrait se faire sur les fonctionnalités. Cette approche permet d'identifier réellement les fonctionnalités critiques de ce dernier et de pouvoir mettre en oeuvre des modes dégradés et prioriser les ressources sur les sous fonctionnalités essentielles auxquelles doit répondre ce système.
Conclusion
Le premier article de cette série permet d'entrevoir la sécurité informatique d'un point de vue gouvernance et architecture. Ces aspects sont indispensables pour comprendre et apprendre les mécanismes techniques et procéduraux que nous verrons dans les articles suivants.
Le prochain sujet que nous aborderons sera l'approche multi-niveaux de la sécurité, des pratiques courantes dans les SI à la sécurité physique en passant par la sécurité applicative.
Top comments (0)