Control Compliance Suite

 View Only

RISQUE, CONFORMITE, SECURITE : 3 enjeux différents 

Jun 27, 2013 07:30 AM

Commençons par bien comprendre les termes.

Le risque est un danger éventuel, plus ou moins prévisible, inhérent à une situation ou à une activité.

La conformité est l’état de ce qui présente un accord complet, une adaptation totale. On note déjà que la conformité ne définit pas un niveau de sécurité mais uniquement l’état de réponse à un standard, une charte ou une norme. La qualité de ceux-ci sera déterminante. Dans le monde de la sécurité informatique, la mise en conformité s’inspire généralement de bonnes pratiques qui permettent aux entreprises de partir sur de bonnes bases en adaptant ces pratiques à leur environnement, contraintes et métiers.

La sécurité des systèmes d’information (SSI) est l’ensemble des moyens techniques, organisationnels, juridiques et humains nécessaires et mis en place pour conserver, rétablir, et garantir la sécurité du système d'information. Il est clair que l’on parle ici de politiques de sécurité. Celles-ci découlent directement des analyses de risque effectuées en amont et répondent à la stratégie de traitement des risques. Pour chacun des scenarios de risque pour lesquels on aura décidé une réduction ou une acceptation, les politiques devront permettent de réduire le risque à la valeur du risque résiduel accepté. 

Dans le domaine de la sécurité informatique, une vulnérabilité ou faille est une faiblesse dans un système informatique, permettant à un attaquant de porter atteinte à l'intégrité de ce système, c'est-à-dire à son fonctionnement normal, à la confidentialité, la disponibilité et l'intégrité des données qu'il contient. On parle ici de tout ce qui pourrait avoir un impact sur l’entreprise. On parle souvent de vulnérabilité dans les applications, les systèmes d’exploitation mais les vulnérabilités peuvent être aussi trouvées dans notre comportement humain, le juridique et la sécurité physique. Le rôle de l’analyse des risques est de quantifier ces vulnérabilités et estimer leur impact potentiel.

Un exploit est, dans le domaine de la sécurité informatique, un élément de programme permettant à un individu ou un logiciel malveillant d'exploiter une faille de sécurité informatique dans un système d'exploitation ou dans un logiciel, que ce soit à distance ou localement, afin de prendre le contrôle d'un ordinateur ou d'un réseau, de permettre une augmentation de privilège d'un logiciel ou d'un utilisateur, ou d'effectuer une attaque ciblée. Là aussi, cela s’adresse à l’aspect technologique. Le manque de formation des personnels, l’organisation même de la sécurité, que soit physique ou organisationnelle peuvent être exploités. On sait aujourd’hui que l’un des principaux moyens d’attaque commence par l’exploitation des faiblesses humaines (Social Engineering).

Processus de gestion des risques

Il existe plusieurs méthodes d’analyse et gestion des risques informatiques.

  • EBIOS : la méthode EBIOS (Expression des Besoins et Identification des Objectifs de Sécurité) permet d’apprécier et de traiter les risques relatifs à la sécurité des systèmes d’information (SSI). Elle permet aussi de communiquer à leur sujet au sein de l’organisme et vis-à-vis de ses partenaires afin de contribuer au processus de gestion des risques SSI. Créée en 1995 par l’ANSSI et régulièrement mise à jour, la méthode EBIOS  bénéficie de ses 15 ans d’expérience dans le domaine de la gestion du risque.
  • MEHARI : MEHARI est une méthode complète d’évaluation et de management des risques liés à l'information, ses traitements et les ressources mises en œuvre. MEHARI, conforme aux exigences de la norme ISO/IEC 27005 pour gérer les risques, peut ainsi s'insérer dans une démarche de type SMSI (Système de Management de la Sécurité de l'Information) promue par l’ISO/IEC 27001.

Ces méthodes bien que différentes conduisent toute au même processus de gestion représenté ci-dessous.

4.jpg

  • ISO/IEC 27005 : La norme ISO 27005 explique en détail comment conduire l'appréciation des risques et le traitement des risques, dans le cadre de la sécurité de l'information. La norme ISO 27005 propose une méthodologie de gestion des risques en matière d'information dans l'entreprise conforme à la norme ISO/CEI 27001.

En reprenant les principes PDCA (Plan Do Check Act) d’ISO 27001, on peut détailler un peu.

Pour qui, pour quoi ?

Il est facile de comprendre qu’en fonction de sa position et son rôle dans l’entreprise, les informations nécessaires et utiles seront différentes. Un directeur général ou les membres du comité de direction ont besoin d’une vision métier basée sur les risques, les solutions mises en œuvre et le niveau atteint par rapport au risque résiduel accepté. Par exemple, en aucun cas, la faille MS 0136-12454 et le patch associé ne seront traités par eux.

A contrario, les équipes systèmes et sécurité devront répondre à l’autre partie de la gestion des risques, c'est-à-dire, la mise en application des politiques, règles et des processus de veille technologique. Ils sont garant de la bonne gestion des solutions validées lors de l’analyse des risques.

Entre ces deux extrêmes, se trouvent les responsables de la conformité. Ceux-ci ont mis en place les contrôles qui permettent de vérifier l’adéquation entre les risques, les politiques, le déploiement et maintien des solutions technologiques répondant au traitement du/des risques.

Comment répondre à ces besoins ?

La mise en place d’un programme complet de gestion des risques est clairement la meilleure méthode. La norme ISO permet de de répondre à ce challenge mais cela ne veut pas dire que cela sera simple. La mise en place d’un SMSI de type ISO 27001 requiert une maturité élevée, toutes les entreprises ne pourront pas y répondre. Il faut alors penser à ce qui est faisable. Depuis de nombreuses années, les entreprises ont appris à faire un minimum pour réduire les risques informatiques. Qui ne fait pas de backup ? Qui n’a pas un anti-virus et un Firewall ? C’est ce qu’on appelle ‘les bonnes pratiques’, qui sont généralement mises à dispositon gratuitement et ne nécessitent qu’un engagement minimum.

On commencera par la formalisation écrite des politiques de sécurité. Comment respecter une règle si elle n’est pas clairement définie ?

5.jpg

 

On formera ensuite les employés, qu’ils soient partie intégrante de l’équipe informatique ou simple utilisateur. La mesure de leur compréhension des règles est le gage numéro 1 de leur engagement dans l’application et le respect des politiques de sécurité.

Et finalement, il faudra mesurer que cela se passe bien. Des points de mesure (contrôle) doivent être mis en place afin de mesurer effectivement que le travail fait en amont donne bien les résultats escomptés. On parle ici de benchmark, qu’ils soient directement issus de bonnes pratiques (CIS par exemple) ou, pour les plus matures, le résultat d’une étude plus approfondie et répondant directement aux politiques en place.

Quels bénéfices peut-on en tirer ?

Il y a un bénéfice direct : la prévention. Il est plus facile de gérer des scénarios de risque plutôt que de devoir gérer des crises en mode réactif.

On peut noter que même si le niveau de détail et la vision sont différents pour chacun des acteurs, les données permettant de construire les métriques sont communes.

 Les ingénieurs auront besoin des informations brutes, techniques.

6.jpg

Les personnes responsables du maintien en condition, du respect des politiques de sécurité et de la conformité pourront, par agrégation des informations techniques, obtenir les rapports désirés.

8.jpg


Finalement, les responsables métiers et les RSSI pourront eux aussi mesurer leur posture de risque en combinant les informations techniques, les retours d’application des politiques, le mapping avec les normes ou Frameworks, et pourront suivre en continu le risque mesuré versus le risque résiduel accepté.

9.jpg

Note : Toutes les illustrations sont extraites du logiciel Symantec Control Compliance Suite.

 

Statistics
0 Favorited
0 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Related Entries and Links

No Related Resource entered.