Fedict Règlement général de sécurité de l'information

Transcription

1 Fedict Règlement général de sécurité de l'information V 1.0 Table des matières 1 Politique de sécurité de l information 2 2 Gestion des actifs 4 3 Organisation de la sécurité de l information 5 4 Ressources humaines 11 5 Sécurité physique 13 6 Gestion des communications et opérations 15 7 Gestion des accès 16 8 Acquisition, développement et maintenance de systèmes 17 9 Gestion des incidents de sécurité de l'information Gestion de la continuité des activités Conformité 20 1

2 Ce document, approuvé par le Comité de Direction le 17 mars 2008, décrit le cadre de la politique de sécurité de l'information suivie par Fedict. Le Comité de Direction le considère comme un élément essentiel de bonne gouvernance. 1 POLITIQUE DE SECURITE DE L INFORMATION 1.1 Objectifs de la politique de sécurité de l'information Assurer aux citoyens et aux entreprises un niveau adéquat de sécurité pour les informations traitées, en particulier pour les systèmes d e-government où Fedict joue un rôle, ce qui implique une bonne disponibilité des systèmes et réseaux, et le respect de la confidentialité et de l'intégrité des données traitées. Faire respecter les dispositions légales en matière de sécurité de l information, en particulier les principes de finalité, proportionnalité et transparence prévus pour la protection des données à caractère personnel, ainsi que les règles en matière de classification de l information. Promouvoir une harmonisation de la sécurité de l'information dans les organisations publiques et privées qui collaborent avec Fedict pour rendre le service attendu. Assurer aux collaborateurs de Fedict un niveau adéquat de sécurité pour les systèmes nécessaires à leur travail. Intégrer la sécurité aux méthodes et outils de travail de Fedict. 1.2 Cadre méthodologique et structure de la réglementation Le cadre méthodologique du règlement est constitué des normes ISO et ISO , qui définissent une liste d enjeux de sécurité à maîtriser, ainsi que l organisation adéquate à cette fin. Chacun des domaines de la norme ISO fait l objet d un chapitre du présent document 2. Définition de la sécurité de l information 3 Stratégie, règles, procédures et moyens aptes à protéger l information, aussi bien dans les systèmes de transmission que dans les systèmes de traitement, en vue d en assigner la responsabilité et d en garantir la confidentialité, la disponibilité, l intégrité, la fiabilité, l authenticité et l irrévocabilité ; cette définition s applique à tout type d information, aussi bien les informations classifiées (au sens de la loi du 11 décembre 1998 et des règlements résultant de traités ratifiés par la Belgique), les informations à caractère personnel (au sens de la loi du 8 décembre 1992) ou médicales, que les informations qui ne bénéficient pas de protection légale particulière. La gestion du risque constitue le moteur de la politique de sécurité de l'information. Les mesures de sécurité sont élaborées à la suite d'une analyse de risque formalisée. Celle-ci tient compte d'une métrique de risque permettant d'évaluer la nature et la gravité des conséquences résultant de problèmes affectant la disponibilité, l'intégrité, la confidentialité ou la preuve des informations traitées Nouvelle dénomination de la norme ISO 17799:2005. Toutefois, les chapitres 2 et 3 sont inversés par rapport à la norme, dans le but de clarifier la notion d' "actif" avant de déterminer les responsabilités des différents acteurs de la sécurité. Définition proposée le 09/05/2006 par la plate-forme de concertation fédérale sur la sécurité de l information. Nature des conséquences : atteinte aux règles de classification, menace pour l'ordre public, pertes financières, conséquences juridiques, atteinte à l'image du service public, atteintes personnelles,... La notion de preuve recouvre les exigences d'imputabilité et de traçabilité. 2

3 La réglementation agit à un niveau stratégique, tactique et opérationnel :. au niveau stratégique : c est le présent document, qui donne des directives générales quant aux 11 domaines de la norme ISO 27002, et qui décrit l'organisation de la sécurité de l'information au sein de Fedict ;. au niveau tactique : ce sont des directives plus précises quant aux différents domaines de la norme ISO 27002, applicables en principe à tout système d information 5 ;. au niveau opérationnel : ce sont les règles de sécurité relatives à un système d information particulier, énoncées dans son manuel d'utilisation. Dans la suite du document est utilisée la notion d'information ou de support sensible, sans autre précision. Il s'agit de tout actif de Fedict dont l'utilisation inadéquate peut entraîner un préjudice. 1.3 Elaboration, approbation et diffusion des règlements Les projets de règlement des niveaux stratégique et tactique sont élaborés par la cellule Infosec et le conseiller en sécurité de l'information, en conformité avec les disposition légales, normes et bonnes pratiques de la profession, en tenant compte des besoins et spécificités de Fedict. Ils sont approuvés formellement par le Comité de Direction, qui les considère comme un élément essentiel de la bonne gouvernance de Fedict, et les porte à la connaissance de ses collaborateurs. Ils sont portés à la connaissance du public via le portail fédéral. Les appels d'offres en reprennent les points pertinents pour le marché envisagé. 1.4 Evaluation et adaptation de la politique de sécurité de l'information L'efficacité et l'efficience de la politique suivie sont évaluées annuellement à la lumière de l'évolution des risques et des bonnes pratiques de sécurité, des incidents constatés, ainsi que des audits effectués dans le cadre de l'arrêté royal du 02/10/2002. Cette évaluation est traduite dans le Balance Score Card de Fedict. Accompagnée de propositions, elle est présentée au Comité de Direction, qui prend les décisions utiles. Le présent document est révisé le cas échéant. 5 Chaque directive comprend des instructions destinées aux différents rôles impliqués, est généralement modulée en fonction de la sensibilité du système concerné, et contient des conseils quant à sa diffusion auprès des intéressés. 3

4 2 GESTION DES ACTIFS 2.1 Définition Par actif 6, on entend : tout élément ayant une valeur (matérielle ou immatérielle) pour l organisation, en rapport avec le système d information. Par exemple : informations : fichiers, bases de données, données en transit, documentation, contrats, procédures, logiciels : programmes applicatifs, logiciels de base, moyens physiques : matériels, supports d information, environnement physique : bâtiment, alimentation électrique, En particulier, un actif peut être constitué d'un composant d'architecture mis à disposition par Fedict, ou d'un système d'information complet pour lequel il joue un rôle. 2.2 Principes Pour tout actif qui intéresse Fedict est désigné un business owner 7, chargé de toutes les décisions importantes à son sujet. Le business owner peut - appartenir à Fedict (p. ex. pour un composant d'architecture e-government de son service catalog), - ou se situer dans une autre administration (p. ex. pour un système d'information destiné à supporter l'activité d'un autre service public, mais dont la réalisation a été confiée à Fedict). Sa responsabilité porte essentiellement sur les aspects suivants : respect des contraintes légales et réglementaires, exigences fonctionnelles, règles et limites d'utilisation, suivi de la gestion journalière, gestion des risques. Pour la plupart des actifs, les rôles suivants doivent généralement être définis, outre celui du business owner : - project manager, - architecte, - développeur, - opérateur, - service manager, - gestionnaire d'accès, - service desk, - utilisateur final (différents types). La liste des rôles doit évidemment être adaptée au type d'actif. Des distinctions peuvent être faites suivant le statut de l'acteur concerné (interne à Fedict, interne à l'administration fédérale, consultant, sous-traitant,...) ; il ne faut toutefois pas multiplier inutilement les rôles. Pour chaque rôle est établi un profil d'accès à l'actif concerné 8, à l'intention du gestionnaire d'accès. Les actifs sont en principe gérés en conformité avec les règles d'accès et d'utilisation énoncées. Sur demande motivée, le business owner peut toutefois accorder des dérogations. Tous les actifs intéressant Fedict sont identifiés et inventoriés, aussi bien ses actifs propres que ceux d'autres services publics pour lesquels il joue un rôle Angl. "asset" dans les normes ISO et Nl. "activa". Voir le 3.1. Voir le 7. 4

5 Les actifs dont l'utilisation inappropriée peut porter un préjudice à la Belgique ou à un autre Etat membre de l'union Européenne 9 sont classifiés conformément aux dispositions légales et réglementaires en la matière. La sous-traitance éventuelle de certains rôles ne modifie en rien la responsabilité générale du business owner. Les documents (lettres, notes internes, cahiers de charges, offres des fournisseurs, contrats,...) constituent une classe particulière d'actifs. Il est utile de faire la distinction entre l'original et les copies : - les principes énoncés ci-dessus s'appliquent à l'original : il faut un business owner, qui précise les règles d'utilisation (mise à jour, conservation, copie, distribution,...) ; - l'utilisation du document (envoi par courrier électronique,...) est assimilée à une copie, qui doit être traitée suivant les règles édictées par le business owner ; en outre, les supports physiques mobiles (papiers, CD, module de mémoire,...) suivent les règles du 5.4 ; 3 ORGANISATION DE LA SECURITE DE L INFORMATION La sécurité de l information concerne les rôles suivants. Les business owners ( 3.1). Le Comité de Direction de Fedict ( 3.2). Les directeurs généraux de Fedict ( 3.3). Le conseiller en sécurité de l information de Fedict ( 3.4). La cellule Infosec de Fedict ( 3.5). La cellule juridique de Fedict ( 3.6). La cellule FSO 10 de Fedict ( 3.7). Les senior responsible owners (SRO) de Fedict ( 3.8). OPERA ( 3.9). Les programme matrix teams (PMT) de Fedict ( 3.10). Les project boards ( 3.11). Les project managers de Fedict ( 3.12). Les architectes de Fedict ( 3.13). Les développeurs informatiques ( 3.14). Les service managers de Fedict ( 3.15). Les service desks ( 3.16). Les ICT operation managers ( 3.17). Le service d audit ( 3.18). 9 P. ex. données techniques dont la connaissance peut faciliter une intrusion, en particulier pour les systèmes traitant des informations classifiées. 10 Fedict Support Office. 5

6 3.1 Les business owners 11 Pour tout actif qui intéresse Fedict est désigné un business owner chargé de toutes les décisions importantes à son sujet : pour les actifs de Fedict (p. ex. pour un composant d'architecture e-government de son service catalog), le Comité de Direction le désigne parmi les directeurs généraux ; pour les actifs externes à Fedict (p. ex. pour un système d'information dont la réalisation a été confiée à Fedict par un autre SPF), le SRO (voir le 3.8) veille à le faire désigner et à lui faire accepter les responsabilités liées à ce rôle ; il s'agit généralement du responsable de l'activité supportée par l'actif concerné (un directeur général p. ex.). Le business owner assume les responsabilités suivantes : l'identification des contraintes légales et réglementaires ; l'établissement des spécifications fonctionnelles ; la réalisation d'une analyse de risque formalisée, destinée à identifier les risques pouvant affecter l'activité supportée par l'actif concerné ; la formulation des exigences de sécurité nécessaires pour maîtriser les risques identifiés ; l'acceptation du risque résiduel ; la gestion budgétaire et la réalisation des mesures de sécurité qu'entraînent ces exigences ; l'établissement des spécifications de test des mesures de sécurité ; l'élaboration des règles opérationnelles : - rôles impliqués dans la gestion et l'utilisation, ainsi que leur profil d'accès 12, - règles de gestion et d'utilisation (y compris les limites d'emploi),... ; la diffusion de ces règles auprès des parties intéressées, et leur acceptation par celles-ci ; le contrôle du respect de ces règles ; la réception de l'actif concerné (après examen des rapports de test) et la décision de le rendre opérationnel ; le suivi des incidents résultant des dysfonctionnements courants ; la gestion des crises pouvant résulter de dysfonctionnements graves. Les tâches impliquées peuvent être déléguées ou sous-traitées, sans que cela modifie la responsabilité générale du business owner. Des conventions écrites assurent la bonne compréhension des obligations entre les parties. Les systèmes complexes étant généralement constitués d'actifs dépendant de business owners différents, la compatibilité des différentes règles d'utilisation doit être vérifiée ; ceci relève de la responsabilité du business owner qui met le service à la disposition des utilisateurs finaux. Exemples illustratifs : ICT Shared Services ICT Shared Services met à la disposition de Fedict (notamment) une infrastructure informatique constituée - d'un réseau local, - de PC pour les utilisateurs, - de différents serveurs (pour le courrier électronique, pour l'accès à l'internet,...), - de différents logiciels bureautiques et autres (antivirus,...). ICT Shared Services est donc le business owner d'une infrastructure technique ; à ce titre, il édicte et fait respecter, par les fournisseurs et les utilisateurs, des règles d'usage destinées à préserver la qualité et la sécurité du service offert : 11 Le business owner est représenté par le "senior user " dans l'organisation de projet de Fedict. 12 Voir le 7. 6

7 - filtrage du spam et des accès à l'internet, - interdiction de connecter des équipements privés ou d'installer des programmes sans autorisation, - interdiction de désactiver l'antivirus, - comportement attendu en cas d'anomalie, -... Par ailleurs, le Comité de Direction de Fedict édicte et fait respecter des règles quant à l'utilisation des fonctionnalités disponibles : - PC : organisation de la gestion documentaire,... - courrier électronique : clarté, courtoisie, confidentialité, respect de la vie privée, règles de délégation, archivage, délai de réponse,... - internet : participation à des forums, limites à l'usage privé,... Ce faisant, le Comité de Direction assume le rôle de business owner du service d information offert à ses collaborateurs. Système d'information destiné aux citoyens Un SPF met en place une application destinée aux citoyens, utilisant une source authentique, ainsi qu'un middleware de Fedict. Le directeur général pour la source authentique en est le business owner ; il en formule les règles d'accès, tant fonctionnelles (usages autorisés, limites de responsabilité,...) que techniques (canaux autorisés, qualité des systèmes clients,...). Fedict est le business owner pour le middleware ; il en formule les conditions d'emploi, tant fonctionnelles (limites de sensibilité,...) que techniques (mise en oeuvre dans l'application,...). Le SPF est le business owner du service offert aux citoyens ; il veille au respect des règles émises par la source authentique et par Fedict, non seulement dans le développement et l'exploitation du système, mais aussi en promouvant un comportement adéquat chez les citoyens utilisateurs du service. 3.2 Le Comité de Direction de Fedict Le Comité de Direction prend les décisions relatives à la sécurité des actifs de Fedict, et veille à leur mise en œuvre dans les directions générales. Il décide de l'application des règlements proposés par la cellule Infosec, ainsi que des plans de sécurité proposés par le conseiller en sécurité de l information, alloue les moyens nécessaires et contrôle leur mise en oeuvre. Il désigne le business owner de tout actif de Fedict parmi les directeurs généraux. Il est le business owner des règlements de Fedict. 3.3 Les directeurs généraux de Fedict Chaque directeur général veille à ce que ses collaborateurs possèdent les connaissances nécessaires à l'exercice de leur fonction ; veille à faire appliquer les règles de sécurité par ses collaborateurs ; autorise ses collaborateurs à accéder aux locaux et ressources nécessaires à l'exercice de leur fonction ; révise annuellement son domaine de responsabilité au regard des règlements et standards de sécurité, et communique ses observations au conseiller en sécurité de l'information. 3.4 Le conseiller en sécurité de l'information de Fedict Le conseiller en sécurité de l'information se tient au courant de l'évolution des menaces, ainsi que des méthodes et outils de sécurité ; apporte une assistance méthodologique à la maîtrise des risques liés aux systèmes d'information, afin de développer les mesures organisationnelles et techniques aptes à prévenir les incidents et à en contenir les conséquences éventuelles ; 7

8 veille à la sensibilisation et à la formation du personnel en matière de sécurité de l'information afin d'encourager un comportement responsable et adéquat ; veille à la tenue de l'inventaire des actifs intéressant Fedict ; collabore avec le service manager à l'analyse des incidents de sécurité, afin d'en identifier les causes et de rechercher des solutions ; évalue dans un rapport annuel l'efficacité et l'efficience de la politique de sécurité suivie, compte tenu de l'évolution des risques et des bonnes pratiques, des incidents de sécurité constatés, ainsi que des audits effectués dans le cadre de l'arrêté royal du 02/10/2002 ; propose, en fonction de cette évaluation, un plan d'action annuel au Comité de Direction ; pilote la réalisation du plan d'action décidé par celui-ci ; collabore avec la cellule Infosec à la rédaction des règlements de sécurité de Fedict ; collabore avec les cellules FSO et Infosec en vue d'intégrer la démarche de sécurité aux méthodes de Fedict ; collabore avec ses homologues des autres institutions fédérales, afin de développer une politique et des règlements harmonisés, et de partager les connaissances et expériences (méthodes, outils, évolution des menaces,...) ; collabore avec ses homologues d'autres niveaux de pouvoir, afin de partager les connaissances et expériences ; exerce différentes fonctions en rapport avec la sécurité, prévues par la loi (officier de sécurité, conseiller en sécurité de l'information et protection de la vie privée,...). Le conseiller en sécurité de l'information rapporte au fonctionnaire dirigeant de Fedict et collabore étroitement avec la cellule Infosec. 3.5 La cellule Infosec de Fedict La cellule Infosec se tient au courant de l'évolution des menaces, ainsi que des méthodes et outils de sécurité ; tient la liste des dispositions légales en matière de sécurité de l'information 13, en collaboration avec la cellule juridique ; prépare les règlements de sécurité, en conformité avec les dispositions légales et les besoins de Fedict, et les soumet à l'approbation du Comité de Direction ; collabore avec la cellule FSO et le conseiller en sécurité de l'information en vue d'intégrer la démarche de sécurité aux méthodes de gestion de projet pratiquées par Fedict ; apporte son assistance aux directions générales de Fedict, en particulier dans le cadre des appels d'offres et de la mise en oeuvre des systèmes d'information ; étudie et évalue des méthodes et outils de gestion des risques ; prépare les dossiers de certification et d'homologation des systèmes de Fedict transportant ou traitant des informations classifiées ; collabore à la concertation en matière de sécurité de l information, tant au niveau fédéral 14 qu'avec les autres niveaux de pouvoir ; aide les services publics fédéraux - en coordonnant la collaboration des conseillers en sécurité de l information, - en élaborant des règlements de sécurité adaptés aux besoins de l'administration fédérale, - en leur apportant une assistance méthodologique, en particulier dans les domaines suivants : gestion de la continuité, gestion des risques, certification et homologation 13 Voir le Plate-forme de concertation sur la sécurité de l information, groupe de travail ENISA au sein du Comité Consultatif des Télécommunications, 8

9 des systèmes transportant ou traitant des informations classifiées, - en collaborant à des campagnes de sensibilisation à la sécurité. 3.6 La cellule juridique de Fedict La cellule juridique collabore avec la cellule Infosec à la tenue de la liste des dispositions légales en matière de sécurité de l'information 15 ; fournit tout conseil utile en la matière ; veille au respect de ces dispositions dans les contrats ; établit les avis destinés au comité sectoriel compétent en vertu de la loi relative à la protection de la vie privée. 3.7 La cellule FSO de Fedict La cellule FSO (Fedict Support Office) collabore avec la cellule Infosec et avec le conseiller en sécurité de l'information en vue d'intégrer la démarche de sécurité aux méthodes de Fedict. 3.8 Les senior responsible owners (SRO) de Fedict Chaque SRO veille à la désignation du business owner du système, et à l'acceptation de ses responsabilités 16 ; s'assure que la démarche de sécurité de l'information est correctement mise en oeuvre par le PMT (voir le 3.10). 3.9 OPERA (Fedict) Les SRO, dans le cadre d'opera, veillent à intégrer les enjeux de sécurité dans la gestion des programmes Les programme matrix teams (PMT) de Fedict Chaque PMT met en oeuvre dans son programme la démarche de sécurité définie par les cellules Infosec et FSO. Chacun de ses membres applique les règles de sécurité propres à son rôle Les project boards Le project board débat des enjeux de sécurité aux différentes étapes du projet, et en particulier de l'arbitrage entre le coût des mesures de sécurité et le risque résiduel lié au service visé, de façon à préparer les décisions du business owner Les project managers de Fedict Lors du développement d'un nouveau système d'information, ou à l'occasion de toute révision importante, le project manager s assure que les acteurs du projet (responsable d architecture, développeur, service manager, ) tiennent compte des bonnes pratiques et des dispositions réglementaires (règlements fédéraux, propres à Fedict,...) ; collabore avec le business owner à l'analyse de risque du système suivant la méthode proposée par la cellule Infosec ; 15 Voir le Voir le

10 veille à inclure les exigences de sécurité dans les appels d'offres et les contrats ; veille au dépôt des sources et de la documentation technique quand il faut se prémunir de la défaillance d'un fournisseur ; veille à la réalisation et au test des mesures de sécurité décidées à la suite de l'analyse de risque, et en fait rapport au business owner ; veille à mettre en place un suivi adéquat des vulnérabilités pouvant affecter les actifs concernés Les architectes de Fedict Chaque responsable d'architecture veille, dans son domaine, au respect des bonnes pratiques et des dispositions réglementaires (règlements fédéraux, propres à Fedict,...) ; pour les composants d'architecture du service catalog de Fedict, il en évalue la sensibilité à l'aide d'une analyse de risque, et il propose des mesures de sécurité adéquates et les règles opérationnelles (y compris les conditions et limites d'emploi) ; pour les systèmes d'information dont il conçoit l'architecture, il traduit les exigences de sécurité décidées à la suite de l'analyse de risque ; apporte son aide à la solution des incidents de sécurité et à la gestion des crises résultant de dysfonctionnements techniques Les développeurs informatiques Chaque développeur (interne ou externe) respecte les bonnes pratiques et les dispositions réglementaires et conventionnelles (règlements fédéraux, propres à Fedict, contrats,...) ; réalise les mesures de sécurité décidées à la suite de l'analyse de risque Les service managers de Fedict Chaque service manager veille, en matière de gestion de service et d'exploitation, au respect des bonnes pratiques et des dispositions réglementaires et conventionnelles (bonnes pratiques ITIL 19, règlements élaborés par le Forum, règlements propres à Fedict, contrats,...) ; veille à la mise en œuvre des mesures de sécurité décidées, et en fait rapport au business owner ; veille à la mise en oeuvre de la gestion d'accès définie par le business owner ; veille à la sécurité des sources de programme et de la documentation technique, et gère l'accès à celles-ci ; veille au respect des licences d'utilisation et des droits de propriété ; analyse les incidents de sécurité, recherche des solutions et les met en oeuvre 20 ; participe à la gestion des crises pouvant résulter de dysfonctionnements éventuels, sous l'autorité du business owner de l actif concerné ; veille à ce que l examen technique des systèmes n'en menace pas la sécurité. 17 Voir le Voir le Voir les 6, 8 et Voir les 8.6 et 9. 10

11 3.16 Les service desks Les service desks (internes ou externes) enregistrent les incidents de sécurité qui lui sont rapportés, et en avertissent les service managers potentiellement touchés, ainsi que le conseiller en sécurité de l'information Les ICT operation managers Chaque ICT operation manager (généralement externe à Fedict) respecte les bonnes pratiques et les dispositions réglementaires et conventionnelles (règlements fédéraux, propres à Fedict, contrats,...) ; applique les mesures de sécurité décidées à la suite de l'analyse de risque Le service d audit En rapport avec les missions définies par l arrêté royal du 02/10/2002, le service d audit contrôle la conformité des mesures de sécurité aux dispositions légales et réglementaires. 4 RESSOURCES HUMAINES 4.1 Catégories de collaborateurs Les collaborateurs de Fedict relèvent d'un des statuts suivants : 4.2 Probité fonctionnaires fédéraux, statutaires ou contractuels (relevant de la fonction publique), employés EGOV (relevant d'un contrat de travail passé avec l'asbl), consultants et autres travailleurs (utilisés dans le cadre de contrats passés par Fedict), divers : stagiaires, étudiants,... Les collaborateurs de Fedict doivent présenter une conduite compatible avec leur fonction. Pour les fonctionnaires, cette condition est vérifiée conformément au statut de la fonction publique. Pour les employés EGOV, ceci est vérifié à l'engagement de façon analogue. Pour les consultants, dans les cas jugés nécessaires, le cahier des charges et le contrat imposent au soumissionnaire de garantir l'absence d'un antécédent judiciaire révélateur d'un comportement incompatible avec la mission envisagée. 4.3 Respect des valeurs de Fedict Les collaborateurs ont constamment à l'esprit les valeurs de Fedict : innovation, loyauté, intégrité, proactivité, orientation résultat, collégialité, orientation client. 4.4 Définition des responsabilités Les responsabilités des collaborateurs sont définies dans une description de fonction précisant leur(s) rôle(s) et les attentes qui y sont liées, notamment les compétences nécessaires. 21 Voir les 8.6 et 9. 11

12 4.5 Gestion des compétences Les collaborateurs doivent posséder les compétences nécessaires à l'exercice de leur fonction, ce dont s'assure le directeur général responsable. Ces compétences résultent d'une qualification acquise préalablement, complétée par des formations suivies chaque année et par l'expérience acquise sur le terrain. La qualification initiale est vérifiée avant l'entrée chez Fedict. 4.6 Attention portée aux risques Les collaborateurs pensent aux conséquences de leur négligence éventuelle, et adaptent leur comportement en conséquence. Exemples de comportements à risque (liste non exhaustive) : - documents sensibles laissés sans surveillance (bureau inoccupé, documents laissés sur une imprimante,...), - oubli du verrouillage physique (locaux, armoires,...) ou logiciel (signoff, PC lock,...), - communication d'informations à un correspondant inconnu ("social engineering"), - communication d'information sensible par courrier électronique, - perte de supports d'informations sensibles (documents, mémoires électroniques,...), - lecture de documents sensibles dans un lieu public. - installation non autorisée de logiciel, - désactivation ou reconfiguration de logiciel (antivirus, options de browser,...), - écriture de mots de passe sur des documents aisément accessibles, choix de mots de passe "faibles",... Le conseiller en sécurité de l'information sensibilise les collaborateurs à ces risques et propose des comportements adéquats. 4.7 Communication des incidents de sécurité Dès la constatation d'un incident de sécurité, le collaborateur prend immédiatement les mesures de bon sens qui s'imposent, et avertit le service desk de Fedict, ainsi que son responsable hiérarchique Gestion des droits d'accès L'accès des collaborateurs aux actifs de Fedict (systèmes, informations,...) est géré conformément aux principes exposés au 7 ("Gestion des accès"). En particulier, les droits d'accès sont adaptés en cas de changement de fonction, et sont désactivés lors du départ du collaborateur. Le directeur général du collaborateur concerné est responsable de l'application de ces règles. 4.9 Sanctions Les fautes des fonctionnaires (et employés EGOV) sont sanctionnées dans le respect des règles de leur statut (ou convention collective). Les sanctions applicables aux consultants sont explicitées dans les contrats Habilitations de sécurité Les collaborateurs qui ont accès à des actifs dont l'utilisation inappropriée peut porter un préjudice à la Belgique ou à un autre Etat membre de l'union Européenne sont habilités conformément aux dispositions légales et réglementaires en la matière. Pour les fonctionnaires et les employés EGOV, la procédure d'habilitation est gérée par le conseiller en sécurité de l'information. Pour les consultants, la présentation d'un certificat d'habilitation est 22 Voir le 9. 12

13 prévue au cahier des charges Devoir de discrétion Les informations recueillies ne peuvent être utilisées et communiquées que dans le strict cadre du travail. Même dans ce cas, le collaborateur pense aux conséquences possibles de la divulgation d'informations sensibles. Les informations classifiées ne peuvent être communiquées que dans le strict respect des dispositions réglementaires en la matière 23. En cas de départ, le collaborateur rend, efface ou détruit tout support contenant de telles informations. Le devoir de discrétion persiste au-delà de la période de collaboration avec Fedict. 5 SECURITE PHYSIQUE 5.1 Locaux Les locaux administratifs de Fedict, ainsi que les salles informatiques abritant ses actifs, sont organisés en zones circonscrites par des périmètres : - périmètre 1 : entre l'espace public et la zone 1 du bâtiment ; - zone 1 : zone d'accueil du bâtiment ; dans la mesure du possible, des salles de réunion y sont disponibles pour les visiteurs 24 ; - périmètre 2 : entre la zone 1 et la zone 2 ; - zone 2 : locaux administratifs de Fedict ; - périmètre 3 : entre la zone 2 et la zone 3 ; - zone 3 : salle informatique abritant des actifs de Fedict ; - périmètre 4 : entre la zone 3 et la zone 4 ; - zone 4 : locaux ou armoires à sécurité renforcée 25. Ces zones sont munies de systèmes de détection et de protection contre les menaces physiques (incendie, inondation, intrusion,...), adaptés à leur sensibilité. Une intrusion dans une zone 1 n'est possible que moyennant une effraction visible du périmètre 1. Une intrusion dans des zones 2 à 4 déclenche une alarme entraînant l'intervention rapide du service de gardiennage. Les périmètres 3 et 4 sont physiquement renforcés de façon à retarder significativement l'action d'un agresseur éventuel. Si une zone n'existe pas, les contrôles prévus à ses périmètres extérieur et intérieur sont fusionnés en choisissant le niveau de protection le plus élevé. L'accès à toute zone nécessite un contrôle d'identité. Le contrôle effectué à un périmètre extérieur peut être réutilisé à un périmètre intérieur si la fiabilité peut être assurée. 23 Contrôle de l'habilitation du destinataire et de son besoin d'en connaître, sécurité de la transmission, De façon à réduire le nombre de visiteurs en zone P. ex. local abritant des informations classifiées ou des équipements traitant de telles informations. 13

14 L'accès aux différentes zones est réglé comme suit. Fonctionnaire / EGOV (Fedict) Autre collaborateur (Fedict) Visiteur Zone Contrôle d'identité préalable Accès soumis à autorisation préalable * Autorisation limitée au temps nécessaire Enregistrement des accès * Autorisation signée par un directeur général de Fedict ou un collaborateur mandaté. Les visiteurs sont accompagnés d'un collaborateur de Fedict (fonctionnaire ou EGOV) durant tout leur séjour en zones 2 à 4. Les armoires situées en zone 2 sont verrouillées en dehors des heures de présence des collaborateurs, qui veillent à la conservation sûre des clés. Un double des clés est conservé en zone 3. Les armoires situées en zone 3 et 4 sont verrouillées en permanence ; les clés et/ou codes d'accès sont conservés de façon sûre. Le cas échéant, il faut se conformer aux instructions relatives à la protection des informations classifiées. Les journaux d'accès sont tenus et conservés de façon à en assurer l'intégrité. Leur consultation nécessite une autorisation écrite préalable du conseiller en sécurité de l'information, qui veille au respect des règles en matière de protection de données à caractère personnel. Il est interdit d'emporter en zone 3 et 4 des équipements et supports informatiques non strictement nécessaires (laptop, GSM, appareil photo, mémoires électroniques,...). L'utilisation de tels équipements et supports est soumise à l autorisation écrite d un directeur général de Fedict. L'accès aux zones 3 et 4 fait l'objet de rapports transmis au conseiller en sécurité de l'information. Ces modalités s'appliquent aux zones 3 et 4 résidant dans une autre organisation, mais celle-ci peut gérer elle-même l'accès de ses propres collaborateurs en zone Connectique Les équipements connectiques sont placés dans des armoires dont l'accès est géré comme une zone 3 ou 4. La connexion de tout équipement nécessite une procédure formelle de changement Alimentations L alimentation des équipements (électricité, refroidissement, ) est assurée au niveau de qualité adéquat. 5.4 Supports physiques d'information Les supports physiques mobiles (papiers, CD, modules de mémoire,...) sont des actifs au sens du 2.1. Outre les éventuelles dispositions légales 27 et les instructions édictées par le business owner des informations qu'ils contiennent, il convient de respecter des règles générales pour leur conservation, leur utilisation et leur transport. Conservation Les supports d'information sont conservés dans des armoires verrouillées en zone 2, ou en zone 3, en fonction de leur sensibilité. Les supports sensibles ne peuvent pas être abandonnés sans surveillance. Une attention particulière est requise pour les documents sortant d'une imprimante. En fin de journée, les espaces de travail doivent être libres de tout support d'information ("clear desk policy"). 26 Voir le Règles relatives à la classification de l'information p. ex. 14

15 Utilisation Les supports sensibles - ne peuvent être utilisés qu'avec précaution dans des espaces non protégés (lieu public p. ex.), - ne peuvent pas être utilisés au moyen d'équipements dont la sécurité n'est pas assurée (PC privé p. ex.). Transport Les supports sensibles doivent être transportés dans des conditions qui garantissent leur confidentialité et leur intégrité, ainsi que la traçabilité des personnes responsables. La perte ou le vol d'un support d'information doit être enregistré en tant qu'incident de sécurité Equipements mobiles (PC portables, assistants personnels, téléphones mobiles,...) L'utilisateur se conforme aux règles édictées par le business owner de l'équipement mobile (PC portable, PDA, ) 29. En particulier, il vérifie la conformité de sa configuration et signale toute déviation éventuelle en tant qu'incident de sécurité 30. En outre, les équipements mobiles sont soumis aux règles des supports physiques Elimination d'équipements ou de supports d'information Les équipements et supports déclassés doivent être détruits ou effacés de façon à éviter tout risque de divulgation. Les papiers non sensibles peuvent toutefois être jetés à la corbeille. 6 GESTION DES COMMUNICATIONS ET OPERATIONS La gestion des communications et des opérations est réalisée dans le cadre de la gestion de service suivant le référentiel ITIL. En complément de ce référentiel, le service manager veille au respect des mesures de sécurité décrites dans la norme ISO 27002, en particulier les aspects suivants 32 : procédures et responsabilités opérationnelles, gestion du service délivré par des tiers, planification et réception de système, protection vis-à-vis des programmes nocifs et mobiles, sauvegardes, sécurité des réseaux, traitement des supports d'information, échange d'informations, commerce électronique, monitoring. En particulier, il veille à inclure les dispositions adéquates dans les contrats de sous-traitance, et suit leur bonne exécution, en conformité avec les décisions prises par le business owner à la suite de l'analyse de risque. 28 Voir le Pour un laptop p. ex. : utilisation d'un boot password, d'un screen saver sécurisé, d'un antivirus mis à jour, d'un firewall, Voir le Voir le ISO 27002, 10.1 à

16 7 GESTION DES ACCES 7.1 Principes généraux Le business owner assume la responsabilité de la gestion d accès aux actifs dont il est responsable. Le business owner définit les règles d accès des différents profils d utilisateurs intéressés par l actif concerné : project manager,, opérateur,, utilisateur final 33. Tout autre accès est interdit, sauf obligation légale 34. Les utilisateurs et leurs droits d accès sont gérés suivant une procédure formelle conforme aux règles définies par le business owner. Le business owner gère lui-même les droits d accès des utilisateurs conformément aux règles définies, ou délègue cette mission à un tiers. Dans ce dernier cas, une convention explicite est signée entre les deux parties, permettant au business owner de contrôler à tout moment le respect des règles. Les privilèges spéciaux sont gérés de façon restrictive et leur bon usage est contrôlé. La gestion des mots de passe et autres crédentiels 35 fait l objet de règles précises. Les droits d'accès sont adaptés en cas de changement de fonction, et sont désactivés lors du départ du collaborateur. Ils font aussi l objet de révisions périodiques conformément aux règles définies par le business owner. 7.2 Responsabilités de l utilisateur final L'utilisateur respecte les bonnes pratiques pour les mots de passe et autres crédentiels (mot de passe difficile à deviner, changement régulier, saisie à l abri des regards indiscrets, ). L'utilisateur protège les équipements mobiles et les supports d'information physiques 36. L'utilisateur bloque l accès aux équipements qu il quitte temporairement. 7.3 Architecture de contrôle d'accès L'architecte veille au respect des mesures de sécurité décrites dans la norme ISO 27002, en particulier pour les aspects suivants 37 : procédures et responsabilités opérationnelles, gestion d'accès système, gestion d'accès applicative. 7.4 Equipements mobiles (PC portables, assistants personnels, téléphones mobiles,...) Voir les 5.4 et 5.5. L'utilisateur veille à ne pas transmettre d'information sensible sur un réseau non protégé 38. L'information traitée sur ces équipements est copiée dès que possible dans l'environnement normal de Fedict, de façon à limiter les conséquences de perte accidentelle. Les informations sensibles sont effacées de l'équipement mobile dès que possible. 33 Voir la liste type au Sur mandat de l autorité judiciaire p. ex. 35 Information liée à une personne, comportant souvent un élément secret (mot de passe, clé privée PKI, ) lui permettant, généralement à distance, de prouver son identité (authentification) et/ou ses qualités et pouvoirs (fonctionnaire, notaire, ). 36 Voir les 5.4, 5.5 et ISO 27002, 11.4 à Internet, réseau sans fil,... 16

17 L'installation d'applications privées est interdite. 7.5 Télétravail Le télétravail n'est autorisé que moyennant un contrat passé entre Fedict et le collaborateur. Le collaborateur assure une protection physique des locaux privés équivalente aux locaux administratifs de Fedict. Le traitement d'informations sensibles à l'aide d'un équipement privé est interdit. La connectique et la gestion d'accès font l'objet de mesures de précaution (analyse de risque, règles, procédures,...) au même titre que tout composant du système d'information. 8 ACQUISITION, DEVELOPPEMENT ET MAINTENANCE DE SYSTEMES 8.1 Exigences de sécurité des systèmes d'information Les risques pouvant affecter l'activité supportée par le système d'information doivent être analysés et maîtrisés dès son développement. Le business owner pilote un exercice formel d'analyse des risques consistant à - évaluer les conséquences des problèmes pouvant affecter la disponibilité, l'intégrité, la confidentialité ou la preuve des informations traitées, - déterminer les exigences de sécurité nécessaires pour ramener le risque à un niveau acceptable. Le project manager veille à la réalisation et au test des mesures de sécurité décidées à la suite de cet exercice, et en fait rapport au business owner. Ce processus est intégré aux méthodes de gestion de projet pratiquées par Fedict. 8.2 Sécurité applicative Les bonnes pratiques générales et les exigences de sécurité particulières décidées à la suite de l analyse des risques sont intégrées aux spécifications du système à développer. 8.3 Cryptographie Les exigences de sécurité peuvent nécessiter l'utilisation de la cryptographie (chiffrement, signature électronique,...). La cellule Infosec apporte un support quant aux dispositions réglementaires à respecter lors de la mise en oeuvre de moyens cryptographiques, en particulier pour la protection d'informations classifiées. 8.4 Sécurité des fichiers techniques du système d'information Les programmes sont installés suivant des procédures strictes, en conformité avec les principes ITIL, sous la responsabilité du service manager. Les données de production ne peuvent être utilisées dans le cadre de tests que si une protection adéquate est mise en place, et dans le respect des dispositions légales relatives à ces données P. ex., dans le cas de données à caractère personnel, l'accès aux données de test ne peut être accordé que dans le respect des finalités déclarées. 17

18 8.5 Sécurité du développement et du support Les changements au système d'information sont mis en oeuvre suivant des procédures strictes, en conformité avec les principes ITIL 40, ce dont s'assure le service manager. Le project manager veille au respect des bonnes pratiques et à l'exécution des tests de sécurité spécifiés, et en fait rapport au business owner. Le service manager - veille à la sécurité des sources de programme et de la documentation technique, et gère l'accès à celles-ci dans le respect des règles du 7, - veille au respect des licences d'utilisation et des droits de propriété. Le project manager veille au dépôt des sources et de la documentation technique dans les cas où il faut de prémunir contre la défaillance d'un fournisseur. 8.6 Gestion des vulnérabilités Les vulnérabilités pouvant affecter les actifs font l'objet d'une gestion attentive. Le project manager veille à faire respecter des pratiques de développement aptes à réduire les vulnérabilités 41, veille à mettre en place un suivi adéquat des vulnérabilités pouvant affecter les actifs concernés ; les informations nécessaires à ce suivi sont recueillies auprès des fournisseurs informatiques et des centres d'alerte et sont transmises au service manager. 9 GESTION DES INCIDENTS DE SECURITE DE L'INFORMATION 9.1 Définition Un incident de sécurité est constitué de tout événement portant (ou risquant de porter) préjudice aux actifs de Fedict, y compris ceux dont le service est sous-traité. Exemples de tels événements (liste non exhaustive) : - comportement suspect d'inconnus dans les locaux, - anomalie de contrôle d'accès, - désactivation ou mise à niveau incorrecte de composant informatique lié à la sécurité (antivirus,...), - suspicion de virus ou d'intrusion dans un système, - disparition d'actif physique, - information relative à une vulnérabilité pouvant affecter un actif. 9.2 Enregistrements des incidents de sécurité Tout incident de sécurité est immédiatement signalé au service desk compétent, qui l'enregistre avec un code approprié, et avertit immédiatement les service managers concernés, ainsi que le conseiller en sécurité de l'information. L'accès à la documentation des incidents est géré de façon restrictive. Les membres du Comité de Direction, le conseiller en sécurité de l'information et la cellule Infosec y ont un accès complet et permanent. Les autres collaborateurs n'ont accès qu'aux incidents relatifs à des actifs pour lesquels ils jouent un rôle. 40 Voir le Programmation défensive, immunité à l'injection de code,... 18

19 9.3 Traitement des incidents de sécurité Les service managers concernés et le conseiller en sécurité de l'information évaluent la situation et recherchent des solutions le cas échéant ; à cette fin, ils peuvent recourir en urgence à tout collaborateur de Fedict, en particulier aux architectes compétents pour les actifs concernés. Les solutions sont évaluées, testées et mises en oeuvre suivant les procédures de gestion de changement 42, avec l'accord des business owners des actifs concernés. Les business owners gèrent les crises pouvant résulter de dysfonctionnements graves. 9.4 Collecte de preuves Dans le cas d'incidents de sécurité résultant d'actes délibérés, les éléments de preuve pouvant étayer une sanction ou une action judiciaire doivent être préservés. 9.5 Synthèse des incidents de sécurité Le conseiller en sécurité de l'information synthétise les incidents de sécurité et leurs conséquences dans son rapport annuel adressé au Comité de Direction. 10 GESTION DE LA CONTINUITE DES ACTIVITES 10.1 Référentiel La gestion de continuité est basée sur le processus "IT service continuity management" du référentiel ITIL Organisation Pour les systèmes en développement, la maîtrise de la continuité fait partie des exigences normales du projet. Les exigences de continuité résultent de l'analyse de risque produite par le business owner de l'actif concerné, et les étapes suivantes font partie du développement normal du système, coordonné par le project manager. Dans le cas de systèmes en service pour lesquels il n existe pas encore de plan de continuité, le Comité de Direction désigne un project manager chargé de coordonner les différentes étapes du processus décrit au 10.1, en collaboration avec les parties intéressées (business owner, service manager, ) Qualité des plans de continuité Le conseiller en sécurité de l information révise régulièrement les plans de continuité et les résultats de test, de façon à en détecter les lacunes et incohérences, et propose des améliorations dans son rapport annuel adressé au Comité de Direction. 42 Voir le 6. 19

20 11 CONFORMITE 11.1 Responsabilités Le business owner d un actif est responsable en premier ressort du respect des dispositions légales et réglementaires y relatifs. Il identifie celles-ci, les traduit en règles opérationnelles, qu il diffuse aux parties concernées et dont il contrôle le respect. Le contrôle de conformité aux dispositions légales et réglementaires fait partie des missions du service d audit institué conformément à l arrêté royal du 02/10/2002 relatif à l audit interne au sein des services publics fédéraux 11.2 Conformité aux dispositions légales La liste des dispositions légales relatives à la sécurité de l information est tenue par la cellule Infosec, avec l'aide de la cellule juridique. Le collaborateur qui copie, installe ou utilise des actifs informationnels doit s assurer du respect des droits intellectuels qui y sont éventuellement attachés. Les licences nécessaires doivent être acquittées, dans le respect des règles relatives aux marchés publics. Les informations dont la conservation répond à des exigences légales doivent être préservées sous une forme garantissant leur utilisation sur toute la période nécessaire. La cellule juridique procure le conseil et l encadrement nécessaires au respect des dispositions légales en matière de traitement des données à caractère personnel. Le conseiller en sécurité informe et sensibilise le personnel à leur respect. L utilisateur doit être informé des limites d emploi des moyens mis à sa disposition, et plus particulièrement des usages illégaux ou inadéquats. La mise en oeuvre de moyens cryptographiques peut être soumise à des contraintes réglementaires, pour lesquelles la cellule Infosec assure un support Conformité aux règlements et standards de sécurité Les directeur généraux révisent annuellement leur domaine de responsabilité au regard des règlements et standards de sécurité, et communiquent leurs observations au conseiller en sécurité de l information, qui les utilise dans son rapport annuel destiné au Comité de Direction. Un examen technique détaillé de la sécurité des systèmes est effectué suivant un planning établi par le Comité de Direction. Les service managers veillent à ce que de tels examens ne menacent pas la sécurité des actifs concernés. 20