• Article

Histoires de BureauSécurité contre conformité

Wes Miller

En tant que professionnel de l'informatique, vous êtes confronté à des objectifs qui doivent se compléter, mais qui à la place se font concurrence. La sécurité et la conformité sont deux exemples d'objectifs organisationnels de ce type, pour lequel la réussite de l'un devrait améliorer l'autre. Ce n'est hélas habituellement pas le cas. Mon but, au travers de cet article, est de vous donner

un aperçu général des raisons pour lesquelles la sécurité n'est pas nécessairement synonyme de conformité aux initiatives exigées de vous, et des raisons pour lesquelles la conformité n'est souvent pas synonyme de sécurité, ou tout du moins de la sécurité obtenue si la conformité allait véritablement de pair avec la sécurité.

La sécurité n'est pas une case à cocher

Ressources SDL

La conformité implique généralement des exigences (en termes de personnes, processus, infrastructure, technologie, etc.) imposées à une organisation, un secteur, une entreprise ou un produit extérieur. Parfois, la conformité a trait aux normes promulguées au sein du secteur (comme les normes de sécurité des données du secteur des cartes de paiement ou PCI-DSS). Dans l'idéal, il s'agit d'initiatives qui s'alignent sur la manière dont votre organisation fonctionne déjà, tout du moins jusqu'à un certain degré. Tandis que l'adoption d'une norme s'étend, vous vous retrouvez dans l'incapacité de l'ignorer, pour pouvoir continuer vos activités. En fin de compte, vous devez faire le saut et essayer d'en tirer profit au maximum.

C'est l'autre type de conformité qui pose habituellement plus de problèmes. Je fais ici référence aux initiatives mises en œuvre par le gouvernement, comme les lois Health Insurance Portability and Accountability Act (HIPAA) et Sarbanes-Oxley, pour lesquelles la mise en œuvre et la planification font rarement l'objet d'un choix.

Le point essentiel à comprendre en ce qui concerne la conformité aux réglementations est qu'elle est souvent synonyme d'une approche « de haut en bas ». Il existe généralement un modèle de forme complexe qui définit l'initiative et vous devez examiner vos produits et vos processus pour tâcher de voir dans quelle mesure ils peuvent s'adapter au modèle qui vous a été donné. Vous devez rester conscient non seulement des intentions de l'initiative de conformité mais, ce qui est peut-être plus important, des ramifications légales ou financières lorsque celle-ci n'est pas mise en œuvre ou n'est pas réussie (si celles-ci existent).

Bien que nous puissions tous être d'accord avec les intentions de nombreuses initiatives de conformité, leur mise en œuvre est souvent difficile et peut ne pas répondre à l'objectif désiré. Hélas, nombre d'entre elles n'ont aucun pouvoir (c'est-à-dire qu'aucune conséquence légale ou financière ne peut être imposée en cas d'échec).

Je peux par exemple vous dire que, en tant que patient, je ne peux pas décrire complètement les avantages directs pour moi du HIPAA. Ce que je peux vous dire, c'est qu'il est synonyme pour moi d'un travail administratif beaucoup plus important lorsque je rends visite à un docteur. Les conséquences imprévues peuvent être pires. Avez-vous déjà essayé de transférer des informations médicales d'un docteur ou cabinet médical vers un autre ? Sans autorisation écrite, cela ne se produira pas, quelle que soit l'urgence de la nécessité des informations.

Pour résumer, de nombreux points de vue, certaines initiatives de conformité deviennent des initiatives à cases à cocher. C'est-à-dire que vous concevez ou modifiez votre processus ou votre produit uniquement pour répondre aux initiatives de conformité. Comme je le demande souvent à mon enfant de trois ans, « Est-ce vraiment une bonne idée » ?

La sécurité, d'un autre côté, est une initiative du bas vers le haut, lorsqu'elle est effectuée correctement. Si vous concevez un produit logiciel ou l'architecture du nouveau réseau de votre entreprise, le concept essentiel est de se rappeler de prendre deux fois la mesure et de couper une seule fois. Lorsque vous concevez l'architecture d'un produit, par exemple, tout comme une bonne passe initiale décrirait la communication, la localisation, les versions, etc., vous devez décrire les éléments de sécurité qui doivent être intégrés à l'application dès le premier jour (et ceux que vous devez continuer à examiner et peaufiner tout au long du développement).

Si vous travaillez avec une application ou une architecture que vous avez héritée (je suis sûr que c'est le cas pour la plupart d'entre-vous), il est tout aussi essentiel d'effectuer le type d'examen de sécurité approfondi que je mentionne souvent dans cette rubrique. Si vous ne comprenez pas comment quelque chose fonctionne, comment pourriez-vous comprendre à quelque point il est ou non sécurisé ? Pour plus d'informations sur le Cycle de vie de développement de la sécurité Microsoft® (Security Development Lifecycle, SDL), voyez l'encadré « Ressources SDL ».

Une vue d'ensemble

Je me souviens avoir très tôt été instruit du fait que la sécurité ne se résume pas à implémenter simplement le chiffrement, les listes de contrôle d'accès (ACL) ou TLS, ou encore l'infrastructure de clé publique (PKI). La véritable sécurité est la compréhension de la vue d'ensemble : comprendre pourquoi cette version de ce protocole a été abandonnée ou n'a même jamais été prise en charge, pourquoi ce nouveau bout de plomberie arrête les attaques de type man-in-the-middle, en quoi votre mise en œuvre pour le produit version 2 est beaucoup plus sécurisée que la version 1, même si la version 1 était beaucoup plus rapide. Il est également nécessaire que vous compreniez comment s'assemblent toutes les parties de votre infrastructure.

La conformité, d'un autre côté, signifie prendre votre technologie et vous assurer que l'infrastructure que vous avez créée répond à certains critères. Certaines initiatives, telles que les normes de sécurité des données du secteur des cartes de paiement (PCI-DS) ou le North American Electric Reliability Council, ont un objectif louable et peuvent en fin de compte engendrer de véritables modifications de la sécurité. Mais en fin de compte, avec un plateau varié d'initiatives de conformité que vos devez broder à vos projets particuliers, ainsi qu'un nombre de ressources limité, les initiatives de sécurité perdent du terrain.

La sécurité a longtemps été l'enfant négligé du développement de logiciel. Nombre d'entre vous ont certainement déjà été dans une entreprise dans laquelle la sécurité était quelque chose « que nous ferons plus tard ». Eh bien, les initiatives de conformité sont maintenant appelées à demeurer, car cette croyance, que la sécurité peut attendre, ne fonctionne pas et n'a jamais fonctionné.

Suffisant

J'ai récemment changé d'emploi. Je travaille maintenant dans une startup d'Austin, au Texas, qui crée une technologie de création de liste d'applications autorisées quelque peu similaire à la technologie que nous avons créée à Winternals avec notre produit Protection Manager. Je trouve intéressant de savoir à quel point les clients pensent que leurs technologies actuelles sont sécurisées ou, plus particulièrement, à quel point ils estiment que l'ensemble de technologies qu'ils utilisent rend leur infrastructure sécurisée. Même s'il est probable que la plupart d'entre elles soient sécurisées et non remplies de failles ouvertes aux vulnérabilités de sécurité, la réponse que j'entends souvent et qui me fait quelque peu grimacer est qu'un système est « assez sécurisé ».

Les initiatives de conformité sont amusantes. Vous pouvez les respecter ou ne pas y arriver. Cette responsabilité vous appartient. Le coût du manquement à une initiative est habituellement une amende, une pénalité ou la résiliation d'une organisation. Il n'est souvent pas suffisant de s'assurer que quoi que ce soit change véritablement.

Dans le cas d'une initiative commandée par l'administration, je rencontre régulièrement l'attitude, « assez bonne pour plaire à l'auditeur, » ou la volonté de fonctionner sans mettre une infrastructure de conformité en place car la législation d'arrière-plan (à l'image de HIPAA) ne subventionne pas suffisamment la mise en œuvre, ce qui signifie qu'il est beaucoup moins coûteux de fonctionner sans assurance et de faire face aux conséquences potentielles plus tard.

La sécurité bute souvent sur le même barrage, mais je pense qu'elle est au moins plus concrète. Si vous, en tant que développeur ou en charge de la mise en œuvre, dites activement à votre administration que laisser la section X hors de la spécification rendra le produit beaucoup plus vulnérable, vous pourrez au moins après la sortie du produit ou une fois le déploiement terminé, dire « je vous l'avais dit ». En ce qui concerne les initiatives de conformité, j'ai souvent constaté que leur adoption s'effectue souvent trop rapidement, avec un budget aussi limité que possible. L'objectif est simplement de répondre au minimum requis par l'initiative, en répondant peut-être plus tard à l'objectif de l'initiative mais rarement à son esprit, à mon avis.

Décidez où vous vous trouvez

Ressources de sécurité et conformité

Bien qu'il puisse être idéaliste de ma part de dire que vous devriez rendre votre produit et votre organisation aussi sécurisés que possible, dans la réalité la plupart des initiatives de conformité sont en fait un compromis résultant d'une ingénierie passable, ou plus souvent, d'autosatisfaction. Nous vivons dans un monde dans lequel « suffisant » est, malheureusement, suffisant. Dans le monde de la sécurité, cependant, il est rarement sage de se contenter d'un « suffisant ». Nous autres professionnels de l'informatique pouvons prendre à cœur les initiatives de conformité et essayer d'y répondre dans l'esprit et la mise en œuvre, mais devons tout de même nous assurer que l'infrastructure que nous mettons en place n'est pas simplement aussi sécurisée que possible, mais aussi sécurisée qu'elle doit l'être. En d'autres termes, elle doit être conforme à une véritable sécurité et non répondre seulement à l'initiative.

Il est important de regarder en arrière et d'examiner la technologie que vous créez, qu'il s'agisse d'un élément de logiciel commercial ou d'un ensemble de technologies que vous cherchez à intégrer dans un système de plus grande taille. Je ne peux pas insister assez sur l'importance de la compréhension des parties complémentaires du système, de la manière dont les éléments fonctionnent ensemble et des plus grandes menaces auxquelles votre système doit faire face.

En fonction du secteur dans lequel vous travaillez, différentes initiatives de conformité peuvent jouer un rôle dans votre travail. Vous pouvez les rencontrer dans votre vie quotidienne ou seulement lorsque vous concevez de nouveaux projets ou technologies. Il est également possible qu'elles interviennent uniquement dans votre travail pendant des revues ou audits de conformité désignés spécifiquement. Peu importe. Je ne pense pas que ces initiatives de conformité devraient être ignorées, mais je vous mets au défi de défier le statu quo, et au lieu de chercher uniquement à répondre aux initiatives de conformité qui vous sont affectées, effectuez un examen complet de la sécurité pour comprendre votre technologie de bout en bout, et modelez-la pendant votre revue de conformité.

Qu'avez-vous à perdre ?

En fin de compte, les pénalités en cas de non-conformité à une initiative peuvent sembler ambiguës. Le manque de conformité vous met à la merci du scénario précis pour lequel l'initiative a été mise en place afin de vous protéger. Les conséquences peuvent sembler vagues ou distantes, mais elles sont vraies. Elles peuvent ne pas non plus être vos conséquences (personnelles). Soyez pragmatique, mais gardez toujours à l'esprit les scénarios les plus catastrophiques.

Si vous examinez le même espace, du point de vue strict de la sécurité, la menace doit être évidente et, ce qui est plus important, vous devriez être à même d'identifier tout de suite le coût potentiel de la vulnérabilité si elle reste ouverte.

De nombreuses personnes avec lesquelles j'ai discuté de ce sujet ont souligné le fait que ces initiatives de conformité sont mises au placard, puisque celles-ci laissent souvent une grande partie ouverte à l'interprétation. Une fois vous avez mené une revue de sécurité, cependant, cela ne devrait plus être vrai en ce qui concerne toute omission de sécurité. Les menaces immédiates de sécurité ignorées doivent être clairement visibles. Si elles ne le sont pas, il peut être souhaitable de réexaminer qui est impliqué dans les revues de sécurité. Il est possible que vous ayez besoin d'un membre clé pouvant aider à trouver les véritables problèmes de votre solution.

Se mordre la queue

Dans un article de l'année dernière portant sur la sécurité, j'ai parlé de « Comment ne pas perdre vos données » (technet.microsoft.com/magazine/cc162325). Dans le courant de l'année, davantage de systèmes ont été compromis, davantage de portables non chiffrés ont été perdus et davantage d'informations personnelles ont été placées entre des mains douteuses. Il est difficile de dire si un progrès quelconque a été effectué. Pourquoi sommes-nous toujours dans la même situation ? Les projets sont souvent en retard, avec un budget réduit, des ressources ridiculement surexploitées, en essayant de livrer trop de fonctionnalités en un temps trop court.

Ce type d'environnement, malheureusement, mène à un autre dans lequel le minimum de travail devient la norme. Cela n'est certainement pas une manière de garantir qu'une solution sera sécurisée ou conforme, et pas non plus fatal pour le planning ou les coûts d'un projet.

Personnellement, je crois fermement que :

  1. vous ne devriez pas créer une solution si vous n'êtes pas prêt à la sécuriser.
  2. Chaque fois que vous ajoutez de nouvelles fonctionnalités, vous devez concevoir leur sécurité avant de commencer.
  3. Si votre entreprise ne souhaite pas intégrer la sécurité en tant qu'étape de votre processus d'ingénierie, vous devez remettre en question votre entreprise ou ses objectifs organisationnels généraux.

Les entreprises possèdent de plus en plus de données personnelles de clients ou partenaires qu'elles ont la responsabilité de conserver en sécurité. Il est malheureux que nous vivions dans un monde dans lequel, trop souvent, la sécurité n'est pas un choix par défaut et dans lequel les employés n'osent pas remettre en question l'engagement de l'entreprise envers la qualité.

Un échec de la sécurité (et non de la conformité) devient bien trop souvent un signal indiquant « qu'il est grand temps de sécuriser le système » et « l'assurance contre l'usurpation d'identité » est devenue une tactique de responsabilité standard pour apaiser clients, élèves, patients et employés dont les données personnelles, et leur bien-être financier potentiel, ont été compromis.

On nous demande à tous trop souvent d'en faire beaucoup, souvent pour trop peu, et habituellement dans un temps trop court. Mais il est de notre responsabilité en tant que professionnels de l'informatique de nous interroger sur le fait que la sécurité n'est pas le point central, des raisons pour lesquelles trop souvent l'administration pense uniquement à la sécurité lorsqu'elle fait face à des initiatives de conformité ou, plus probablement, à une défaillance de la sécurité et ses menaces légales potentielles ou véritables (qui pourraient potentiellement gêner ou mettre à risque l'organisation).

Relevez mon défi

Plus que tout, je vous invite à défier le statu quo. S'il vous est seulement demandé de répondre aux objectifs de conformité, essayez de vous assurer, pendant que vous le faites, que vous ne gaspillez pas seulement du temps à respecter le concept de sécurité de quelqu'un d'autre. Assurez-vous, plutôt, que votre objectif est de sécuriser le système et, en cours de route, définissez une partie assez importante du processus ou de votre infrastructure pour respecter l'initiative de conformité. Pour plus d’informations sur ce sujet, consultez l’encadré « Ressources de sécurité et conformité ».

Pour résumer, rappelez-vous que cette conformité n'est pas nécessairement une voie vers la sécurité. La sécurité, cependant, si elle est mise en œuvre et utilisée correctement, peut souvent s'avérer être un chemin vers la conformité.

Wes Miller est responsable de produit technique pour CoreTrace (www.CoreTrace.com) à Austin au Texas. Il a auparavant travaillé chez Winternals Software et comme responsable de programme pour Microsoft. Vous pouvez contacter Wes à l’adresse suivante : technet@getwired.com.

© 2008 Microsoft Corporation and CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable..