Sécurité des systèmes informatiques/Sécurité informatique/Le domaine SSI/Documents SSI
Politique de sécurité modifier
La politique de sécurité du système informatique est de plus en plus associée à l'acronyme PSSI, pour « Politique de Sécurité du Système d'Information ».
La structure générale d'une politique de sécurité peut aborder les points suivants :
- Organisation et responsabilités : La PSSI précise l'organisation des fonctions chargées de la sécurité au sein de l'entreprise (postes, rattachements, répartition géographique, cumul, etc.) ainsi que les prérogatives associées à ces fonctions (conduite d'audit, ouverture des services, attribution des droits, gestion des habilitations, etc.).
- Intégration et interactions de la SSI : La PSSI doit également prévoir les modalités d'intégration des fonctions SSI dans l'entreprise et notamment :
- la manière dont la SSI est prise en compte dans les projets menés par l'entreprise (notamment les projets de développement de logiciels s'il y en a) ainsi que dans les choix techniques effectués (sélection de logiciels, etc.) ;
- et la manière dont la SSI interagit avec les services chargés de l'exploitation des systèmes informatiques (priorités, indépendance ou non, acquisition des matériels, budget, etc.).
- Objectifs de sécurité : La PSSI doit définir les objectifs de sécurité de haut niveau de l'entreprise. Par exemple, c'est à ce niveau que peut être imposé l'utilisation de systèmes d'authentification à deux facteurs, la nécessité de l'agrément sécurité des serveurs pour certains domaines d'activité, la prédominance de la disponibilité sur les autres aspects de la sécurité (ou l'inverse - ce qui est quand même plus rare), etc. Les objectifs de sécurité, validés par la direction générale, révèlent les intentions de l'ensemble de l'entreprise en terme de sécurité informatique et légitiment les efforts concrets de mise en place. (C'est notamment en ce sens que la PSSI est un document « politique ».)
- Règles générales de sécurité : La PSSI doit non seulement identifier les objectifs assignés, mais également les règles de sécurité générales qu'elles imposent, parmi lesquelles on retrouve certains points récurrents : l'attribution d'un identifiant aux employés, la gestion de leurs habilitations, les règles de rattachement au réseau, la contractualisation des règles avec des partenaires extérieurs. Mais on peut également définir à ce niveau des règles spécifiques : la délégation de certains droits, les autorisations d'ouverture de services réseau, le type des systèmes d'authentification autorisés, la nationalité des fournisseurs, la gestion des obligations légales (traitement de données personnelles notamment), etc.
- Gestion des risques : Les objectifs de sécurité correspondent à des décisions volontaires, mais celles-ci sont bien entendu motivées par les risques encourus par l'entreprise. Idéalement, les objectifs de sécurité doivent correspondre aux mesures permettant de limiter tous les risques majeurs associés à des défaillances de sécurité du système d'information. Mais des risques résiduels existent généralement et la PSSI peut aborder le sujet de la gestion des risques notamment si des efforts d'analyse des risques ou d'audit interne sont menés dans l'entreprise (c'est peut-être déjà le cas, notamment vis à vis du risque financier).
Par rapport à cette structure, la PSSI peut aborder un certain nombre de thèmes correspondant aux principaux domaines techniques du système informatique et du système d'information qu'il me en œuvre. On y recense notamment les thèmes suivants :
- la protection des communications (informatiques mais aussi téléphoniques) ;
- la gestion des violations (blocage, arrêt, correction, suivi, voire sanction) ;
- les interactions avec le domaine de la vie privée - régi en France par la loi de protection des traitements de données à caractère personnel ;
- les procédures de choix et d'achats de matériels ;
- la gestion de la messagerie, notamment si celle-ci est utilisée dans des cas où l'entreprise peut se trouver engagée (par exemple vis à vis d'un sous-traitant) ;
- les procédures de maintenance et d'intervention sur les systèmes en exploitation ;
- les modalités d'enquête et de contrôle de la sécurité ;
- les règles d'identification employées dans le système d'information (les employés permanents constituent le cas le plus simple ; il est loin d'être le seul : intermittents, délégataires, machines, sous-traitants, partenaires, etc.) ;
- les systèmes d'authentification associés à la SSI ;
- les moyens de surveillance mise en place ;
- les systèmes de contrôle d’accès utilisables ;
- la manière dont les contraintes de disponibilité doivent être prises en compte ;
- les règles de gestion du réseau du point de vue de la sécurité (par exemple, point d'accès unique, etc.) ;
- etc.
Selon nous, les caractéristiques d'une PSSI de bonne qualité sont les suivantes :
- Les objectifs et les règles énoncées doivent être réalistes. Il est inutile de prescrire des obligations ou des interdictions qui gênent tellement le fonctionnement des systèmes que les utilisateurs seront obligées de les contourner pour mener à bien leur mission.
- La PSSI doit être applicable, avec des moyens nécessairement limités (notamment du point de vue humain). En général, ceci impose d'accepter certains compromis de réalisation, et même certaines vulnérabilités.
- La politique doit correspondre à une vision à long terme. Ce type de document ne peut pas être révisé tous les ans. Il doit donc être suffisamment générique pour rester en application quelques années. Les détails sont à préciser dans des documents dérivés.
- La clarté et la concision sont nécessaires à certains moments pour énoncer des règles claires. (En général, celles-ci nécessitent toutefois plusieurs paragraphes d'explication pour être bien comprises, notamment dans différents contextes.)
- La PSSI (et notamment ses règles) doit être basée sur des rôles ou des profils d'utilisateurs : les systèmes changent, la notion même d'utilisateur (au sens informatique) peut changer pour des raisons techniques, il faut s'appuyer des notions un peu plus abstraites pour définir les règles de sécurité impliquant les droits des utilisateurs.
- La PSSI doit permettre une définition claire des domaines de responsabilité et d’autorité, notamment sur les systèmes techniques. L'objectif est alors de pouvoir trancher efficacement entre des points de vue contradictoires (ce qui, dans ce domaine technique, est très fréquent).
- La PSSI doit être à jour (elle doit être revue périodiquement ou quand les évolutions de l'entreprise le nécessitent). C'est probablement assez difficile à assurer.
A notre sens, la PSSI doit être communiquée à tout le personnel pour lui permettre de comprendre dans le détail l'impact de la SSI dans son entreprise et la manière dont il a été décidé de la gérer. Cette diffusion de la PSSI peut parfois être plus difficile à réaliser, notamment si les objectifs adoptés négligent explicitement certains risques.
Analyse des risques modifier
Les principales étapes d'une analyse des risques sont les suivantes :
- Identifier les biens et leur valeur
- Attribuer des priorités aux biens
- Déterminer la vulnérabilité aux menaces et les dommages potentiels
- Attribuer des priorités à l’impact des menaces
- Sélectionner des mesures de protections rentables
La réalisation d'une analyse des risques apporte des informations très intéressantes pour la définition de la politique de sécurité. Toutefois, de notre point de vue, cette approche masque certaines des décisions qui doivent être prises pour aboutir à la définition de la politique de sécurité : la rentabilité n'est pas un critère suffisant pour décider la mise en place de certaines mesures de sécurité, par ailleurs l'évaluation des menaces et de certains dommages reste assez subjective et rend la plupart des méthodes moins mécaniques qu'elles ne l'avouent.
« Spécifications » modifier
Les spécifications de sécurité peuvent toucher à différents sujets concernant la SSI, avec l'objectif de décrire de manière précise les règles souhaitables et leurs motivations (c'est à dire les informations à protéger) :
- Clauses contractuelles : vis à vis des sous-traitants, des partenaires, etc.
- Réseau : règles d'interconnexion ou d'administration, etc.
- Système : règles d'administration, systèmes utilisables, etc.
- Utilisateurs (finaux, administrateurs, etc.) : charte d'utilisation, etc.
- Collecte des traces : cybersurveillance, protection des données, etc.
- Systèmes d’authentification : protocoles autorisés, etc.
- Relais : modalités de filtrage, surveillance des accès, etc.
- Application (A, B, C, D, etc.) : règles spécifiques de gestion pour différents types d'applications (annuaires, données financières, données bureautique, etc.).
Guides de configuration ou de recette modifier
Les guides de configuration ou de recette identifient des points de contrôles :
Ils sont déclinés précisément, par exemple par :
- Système d’exploitation :
- Serveur Web :
- Équipement :
Ils couvrent des éléments de configuration et de gestion concrets, par exemple pour certains paramètres réseau des systèmes d'exploitation suivants :
- Linux procfs
echo "0" > /proc/sys/net/ipv4/ip_forward echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
- (Open)BSD sysctl.conf
net.inet.ip.forwarding=0 vm.swapencrypt.enable=1
- etc.
Documents de mise en service et de suivi modifier
Après contrôle (réussi ou non) de la sécurité d'un système, un document de mise en service identifiant les non-conformités constatées et les vulnérabilités résiduelles du système concrétise l'autorisation de mise en service du système et doit permettre par exemple l'ouverture des accès réseau. Des failles peuvent également être constatées a posteriori par des contrôles de sécurité.
Dans chacun de ces cas, le suivi de la sécurité doit s'appuyer sur des documents identifiant les problèmes résiduels connus et permettant de maintenir ou de faire progresser la sécurité des différents systèmes. On trouve notamment parmi ces documents des matrices de conformité ou des fiches de suivi.