![]()
PARTIE I
Aspects concrets de la sécurité opérationnelle
Parmi les différentes façons d’appréhender la sécurité, il y en a deux qui ressortent plus que les autres. Certains l’abordent par le management et la conformité. Ils se basent pour cela sur des référentiels tels que COBIT ou l’ISO 27001. D’autres ont une approche radicalement opposée, se fondant sur des compétences très techniques. Ils privilégient les actions techniques, affinant les paramétrages des différents dispositifs du SI, en se basant sur des guides de sécurisation technique ou sur les recommandations détaillées de consultants techniques.
Il est indiscutable que ces deux approches, bien que radicalement différentes, contribuent fortement à sécuriser le SI. Cependant, elles laissent entre elles un vide important qui rend difficile le maintien de la sécurité dans la durée. Ce vide, c’est celui de la sécurité opérationnelle. En effet, il ne suffit pas de mettre en place un dispositif de gouvernance pour assurer la sécurité, ou de paramétrer correctement un serveur pour l’empêcher de se faire pirater. C’est un ensemble de processus qu’il faut faire vivre au quotidien pour que la sécurité atteigne réellement un niveau de maturité satisfaisant.
C’est précisément ce domaine de la sécurité opérationnelle que cette partie se propose de traiter. Pour étudier cette question, nous allons commencer par présenter les différents niveaux de sécurité généralement constatés dans les systèmes d’information. Nous passerons ensuite en revue les principaux processus opérationnels liés à la sécurité. Nous conclurons cette partie en montrant les difficultés rencontrées dans leur mise en œuvre.
Chapitre 1
Les différents niveaux de sécurité
Pour appréhender la notion de sécurité opérationnelle, mettons-nous dans la situation d’un responsable de la sécurité des systèmes d’information (RSSI) prenant sa fonction dans une entreprise. Il découvre l’organisation dans laquelle il vient d’arriver, ses métiers, ses directions, les instances qui la composent et ses différentes implantations géographiques. Il se focalisera rapidement sur le système d’information (SI) pour s’en faire une idée et savoir comment le sécuriser. Pour cela, il procédera en deux étapes. La première permettra d’évaluer le niveau de sécurité réel du système d’information, en identifiant précisément les vulnérabilités les plus graves. La seconde étape consistera à élaborer un plan de traitement des risques, énumérant tous les projets à lancer pour sécuriser le système d’information. Ce n’est qu’après ces deux étapes préalables que le RSSI pourra se lancer dans la sécurisation réelle de son SI.
Connaître le niveau de sécurité réel
Pour connaître le niveau effectif de la sécurité du SI dont il prend la charge, le RSSI commencera par rencontrer ses acteurs les plus essentiels, à commencer par le DSI, puis le responsable de la production ainsi que le responsable réseau, sans oublier la personne encadrant les administrateurs, le responsable des études et la personne en charge du support de l’assistance aux utilisateurs. Il lui faudra plusieurs entretiens avant d’obtenir une vision pertinente de l’organisation du SI. Lors de ces séances, il ne se contentera pas d’apprendre comment est organisé le SI ; il demandera à chacun, selon sa fonction et ses compétences, quelles sont les pratiques en matière de sécurité.
Après ces échanges, il aura suffisamment d’éléments pour rédiger un « rapport d’étonnement », c’est-à-dire un document mettant clairement en évidence les failles de sécurité dans chaque aspect du SI. En somme, ce document précise le niveau réel de sécurité du SI.
Même si chaque cas est particulier, on distingue généralement trois niveaux de sécurité différents. Le niveau le plus bas peut être nommé la « zone d’humiliation ». Un niveau de sécurité un peu plus élevé équivaudrait au « niveau de sécurité élémentaire » et, enfin, le plus élevé serait le « niveau de sécurité maîtrisée ».
Les actions que le RSSI entreprendra et l’ordre dans lequel elles seront lancées dépendront beaucoup de ce niveau de sécurité. En effet, le travail ne sera pas le même s’il a affaire à un SI situé dans la « zone d’humiliation » ou si, au contraire, des processus de sécurité sont déjà installés avec une maturité avancée. La sécurité opérationnelle aura donc un visage différent selon le niveau.
Différents niveaux de sécurité
Il est très important de savoir à quel niveau de sécurité se trouve le SI dont nous avons la charge. Les trois niveaux de sécurité qui viennent d’être évoqués ont une typologie particulière, détaillée ci-après.
La zone d’humiliation
Le niveau de sécurité le plus bas peut être appelé « zone d’humiliation ». Qu’entendons-nous par-là ? C’est un état dans lequel le SI présente de nombreuses vulnérabilités connues, simples à exploiter (voire triviales), et ce, à tous les niveaux. Ces vulnérabilités sont autant de points d’exposition permettant à un attaquant de prendre très facilement le contrôle total du SI. Des attaques dans cette situation peuvent avoir des conséquences catastrophiques pour l’entreprise : destruction irréversible d’information, pillage en profondeur du patrimoine informationnel, perturbation durable des opérations.
Illustration
Pour illustrer la zone d’humiliation, on peut faire la comparaison avec un particulier qui se ferait cambrioler alors que la porte de son appartement n’est pas blindée, que sa serrure est simple et qu’au moment des faits, elle n’était même pas verrouillée. Dans ces conditions, aucune assurance n’acceptera d’indemniser ce particulier, car il n’aura pas pris les mesures minimales nécessaires pour sécuriser son appartement.
Aussi étonnant que cela puisse paraître, cette situation est très répandue.
Les systèmes d’information situés dans la zone d’humiliation correspondent généralement au signalement suivant.
- Le contrôleur de domaine est très en retard de ses correctifs de sécurité. Il est donc vulnérable à des attaques simples. De plus, l’organisation de l’annuaire n’a pas été revue depuis plusieurs années. Il est donc fort probable qu’il regorge de comptes à privilèges dont personne n’a connaissance.
- Les accès à Internet sont multiples. Les filiales ou les agences de l’entreprise ont leur propre accès, et certains services ont même des accès ADSL.
- Les postes de travail ne sont jamais patchés et les utilisateurs sont souvent administrateurs de leur machine.
- Les serveurs les plus exposés ne sont pas à jour de leurs correctifs de sécurité.
- Les mots de passe d’administration des serveurs, des bases de données, des applications ou des équipements réseau sont triviaux.
- Des listes de mots de passe en clair, et accessibles à tous, sont oubliées dans les serveurs de fichiers.
- Le cloisonnement des réseaux est faible et, s’il y en a un, les règles du pare-feu sont illisibles et, au final, extrêmement permissives.
- Les protocoles d’authentification sont triviaux.
- Aucune revue des droits système ou applicatifs n’est jamais effectuée.
- Aucune supervision spécifique à la sécurité n’est exercée.
- Les applications sont développées sans aucune prise en compte de la sécurité.
- Etc.
Les systèmes d’information situés dans la zone d’humiliation se contentent généralement de mesures de sécurité élémentaires telles que des mots de passe pour accéder au réseau et aux applications, des antivirus dans les postes de travail et un pare-feu pour filtrer les flux entre l’intérieur et l’extérieur du SI. Les mesures de sécurité s’arrêtent souvent là.
Ainsi, un système d’information situé dans la zone d’humiliation est extrêmement exposé aux actes de malveillance. En cas d’incident de sécurité, ni le RSSI, ni le DSI ni la direction générale n’ont la moindre excuse auprès des parties prenantes, car ils n’auront pas entrepris les actions élémentaires à mettre en place pour sécuriser le SI.
Exemple
Une entreprise s’étant fait voler son fichier clientèle suite à une intrusion réseau n’aura strictement aucune excuse si, après enquête, on s’aperçoit que le serveur web directement exposé à Internet ne s’était jamais vu appliquer des correctifs de sécurité et que les comptes pour administrer les bases de données avaient des mots de passe triviaux.
Niveau de sécurité élémentaire
Le niveau de sécurité élémentaire est juste au-dessus de la zone d’humiliation. Il permet au SI de résister aux attaques les plus triviales. Ne nous trompons pas, ce n’est pas parce que ce niveau est considéré comme « élémentaire » qu’il est à peine meilleur que la zone d’humiliation. Bien au contraire. L’effort pour passer de la zone d’humiliation au niveau de sécurité élémentaire est très important.
Voici les mesures de sécurité généralement constatées dans un SI situé au niveau de sécurité élémentaire.
- Les accès à Internet ont été rationnalisés, centralisés et contrôlés.
- Les systèmes les plus exposés à Internet ont été patchés et sécurisés.
- Les postes de travail ont aussi été sécurisés, ou sont en passe de l’être.
- Il n’y a plus de mots de passe triviaux dans les équipements les plus sensibles.
- Il existe un début de supervision de la sécurité, mais elle est encore embryonnaire. Elle se limite pour le moment à surveiller vraiment les antivirus et à jeter un coup d’œil occasionnel aux journaux du pare-feu.
- Une première revue des comptes du domaine a permis de supprimer les comptes de personnes ayant quitté depuis longtemps l’entreprise. De plus, cela a permis de retirer du groupe « administrateur du domaine » des utilisateurs qui n’avaient aucune raison d’y être.
Ces mesures contribuent à diminuer sensiblement la surface d’exposition aux menaces. Cependant, il faut être conscient qu’à ce stade, le système d’information est encore loin d’être sûr. Une personne mal intentionnée prenant le temps de le faire n’aura pas de difficulté majeure pour trouver une brèche de sécurité et concevoir une attaque ciblée.
Exemple
Prenons l’exemple d’une entreprise ayant fait l’effort de centraliser tous ses accès à Internet sur un point unique et maîtrisé, ayant sécurisé tous ses postes de travail et ayant fait en sorte que les mots de passe permettant d’administrer les serveurs soient complexes. Cette situation peut donner au RSSI une illusion de sécurité. En effet, si les hyperviseurs permettant de piloter les machines virtuelles ont été oubliés dans le projet de complexification des mots de passe (ce qui arrive souvent), il est fort probable qu’ils aient gardé des mots de passe triviaux. Aussi, malgré tous les efforts consentis pour sécuriser le SI, une personne malveillante découvrant ce mot de passe commun pourra très simplement provoquer des dégâts importants en bloquant d’un coup tous les serveurs virtuels et les traitements qui leur sont associés.
La persistance de risques résiduels sur ces SI s’explique par les carences que l’on constate généralement dans le niveau de sécurité élémentaire.
- Les règles de filtrage entre les différents réseaux et DMZ sont trop complexes, même si un premier travail de clarification a été effectué, si bien que les réseaux sont encore perméables.
- Il n’existe toujours pas de gestion fiable des identités (revues des comptes système, applicatifs, des droits, etc.). Les utilisateurs bénéficiant d’accès privilégiés aux ressources sont encore bien trop nombreux.
- Si un effort a été consenti pour adopter de bons mots de passe pour les utilisateurs, on trouve encore trop facilement des équipements système et réseau protégés par des mots de passe triviaux, ou par défaut.
- Les applications sont vulnérables aux attaques de cross site scripting, injections SQL, etc.
- Les utilisateurs et les applications accèdent toujours aux bases de données en tant qu’administrateur.
- Si les systèmes les plus exposés sont patchés, les plus sensibles ne le sont toujours pas.
- La supervision de la sécurité est encore artisanale.
En somme, il reste encore d’importants efforts pour arriver à un niveau de sécurité satisfaisant. Néanmoins, si, à ce stade, les atteintes graves au système d’information sont encore possibles, elles sont un peu plus difficiles à réaliser que dans la zone d’humiliation.
Nous pouvons dire que si, à ce niveau, le RSSI a fait le minimum indispensable pour sécuriser son SI, ce dernier est encore exposé à de trop nombreuses menaces. Sa responsabilité et celle de sa hiérarchie sont moins engagées, mais cela ne le dispense pas de poursuivre les efforts de sécurisation.
Niveau de sécurité maîtrisée
Dans le niveau de sécurité maîtrisée, tout ce qu’il était raisonnable de réaliser avec les moyens et le temps disponibles a été fait. Les propriétés listées ci-après dénotent un SI ayant atteint un tel niveau.
- Les informaticiens (administrateurs système et développeurs) ont acquis les bons réflexes. L’aspect le plus flagrant (mais pas le seul) est l’usage par tous de bons mots de passe.
- Les utilisateurs sont sensibilisés aux bonnes pratiques. Ils tombent moins souvent dans les pièges habituels (pièces jointes piégées, hameçonnage, etc.) et ils collaborent avec la DSI en cas d’incident.
- Des revues régulières sur les accès aux infrastructures (pare-feu, serveurs, bases de données, contrôleurs de baies, de disques, etc.) et sur les accès aux applications donnent une assurance raisonnable que seules les personnes habilitées accèdent aux ressources.
- Les points clés du SI sont surveil...
