Définition des exigences de sécurité
Les exigences de sécurité servent de lignes directrices aux membres de l’équipe de développement durant tout le cycle de développement du logiciel.
Ces exigences sont à formuler sous la forme d’objectifs qualitatifs. Il ne s’agit pas de définir de mesures techniques. Parmi ces exigences, on trouvera :
- Les points essentiels de la méthode choisie pour développer le logiciel.
- Les aspects de la sécurité de l’information jugés comme prioritaires en fonction du contexte d’utilisation du logiciel.
- Les exigences en termes de qualité et de sécurité que le logiciel doit atteindre avant sa diffusion.
Analyse des risques
Le niveau de risque est souvent estimé en combinant les conséquences d’un événement et sa vraisemblance, ou plus simplement, en multipliant la probabilité par l’impact de l’événement. Une analyse de risque se déroule en plusieurs étapes. Le déroulement de l’analyse proposé dans les lignes suivantes est adapté au contexte particulier d’un projet de développement logiciel tout en étant fondé sur la norme ISO 27005 [ISO/IEC 27005 (2011)].
Processus de gestion des risques (©ISO Organisation internationale de normalisation, 2011)
La première étape consiste à établir le contexte de l’analyse. En premier lieu, il convient de définir les critères d’évaluation des risques en matière de probabilité, d’impact et de domaine d’impact (financier, légal, réputation…).
Il convient ensuite, de déterminer les contraintes auxquelles le logiciel est soumis :
- Le cadre légal, comme la loi sur la protection des données [LPD] et la loi sur le droit d’auteur [LDA].
- Le cadre normatif, comme ISO 27001 [ISO/IEC 27001 (2013)] et ISO 27002 [ISO/IEC 27002 (2013)], si le logiciel est destiné à être exploité par un service informatique certifié ou PA-DSS [PA-DSS (2013)], si l’application est destinée à être exploitée en relation avec des émetteurs de cartes de crédit.
- L’environnement légal, normatif, culturel et économique de l’entreprise produisant le logiciel.
- L’environnement légal, normatif, culturel et économique de l’entreprise utilisant le logiciel.
- Les contraintes budgétaires.
La seconde étape consiste à identifier les risques. Pour identifier les risques, il convient :
- D’identifier les données collectées, traitées ou générées par l’application (actifs informationnels de l’application).
- D’identifier les menaces potentielles telles que l’usurpation d’identité, la divulgation ou l’altération d’information.
- D’identifier les vulnérabilités potentielles du logiciel au niveau des entrées et des sorties de celui-ci, mais aussi au niveau de chacun de ses composants.
- D’identifier les conséquences au niveau de l’exploitation du logiciel, mais aussi au niveau du fournisseur et de l’utilisateur de celui-ci.
La troisième étape concerne l’analyse du niveau des risques. L’estimation du niveau des risques s’effectue selon deux axes :
- Les conséquences
- La vraisemblance
Les estimations peuvent être quantitatives, ou qualitatives.
La quatrième étape consiste à évaluer les risques en fonction du niveau de chacun des risques et des critères établis lors de la définition du contexte.
La cinquième étape consiste à établir un plan de traitement des risques. En fonction de l’évaluation des risques et du contexte quatre options existent pour le traitement du risque :
- La réduction du risque par la mise en œuvre de mesures spécifique.
- Le maintien du risque lorsque celui-ci est considéré comme acceptable.
- Le refus du risque lorsque le risque identifié est trop élevé et que les mesures de réduction sont trop coûteuses. Dans ce cas, il convient de revoir la partie du logiciel d’où provient le risque ou d’en abandonner la réalisation.
- Le transfert ou le partage du risque consiste à transférer la partie du logiciel source du risque à une entité apte à traiter plus efficacement le risque lié à cette partie.
Le plan de traitement des risques sera ensuite utilisé dans la phase de modélisation des menaces, plus particulièrement pour valider l’analyse au niveau des données importantes de l’application et pour préciser et valider les mesures de réduction des risques.
La sixième étape consiste à accepter les risques. Cette étape consiste en une acceptation formelle de plan de traitement des risques et des risques résiduels.
Durant la réalisation de l’analyse de risque, il convient d’informer et d’inclure dans le processus les différents membres de l’équipe de développement et les éventuelles autres parties prenantes.
Il convient de passer en revue l’analyse de risques périodiquement et de l’adapter en fonction de l’évolution du contexte ou des modifications fonctionnelles de l’application.
Parmi les nombreuses méthodes d’analyse de risques disponibles gratuitement, la plus simple et la plus approprié dans le cadre de ce document est sans doute la méthode OCTAVE Allegro [OCTAVE ALLEGRO (2007)].
Définition d’un niveau de référence pour la sécurité (security baseline)
Dans certaines conditions les méthodes d’analyse de risques ne permettent pas d’obtenir un résultat exploitable ou seulement un résultat partiellement exploitable pour la suite du développement logiciel.
L’analyse de risques est particulièrement difficile, voire impossible, si le logiciel à développer est destiné à différents clients, qui pour des raisons qui leur sont propres, ont des besoins, en matière de sécurité de l’information, très différents.
Dans ce cas de figure, on réalise une analyse de risque en ne prenant pas spécifiquement en compte les besoins des clients. On accompagne cette analyse par la définition d’une référence de sécurité (security baseline).
Pour définir une référence de sécurité, il est possible d’utiliser la technique suivante :
- On choisit un référentiel d’audit de la sécurité de l’information, par exemple, CobiT 4.1 [COBIT 4.1 (2007)] disponible gratuitement et en français.
- On détermine dans quels processus, décrits dans le référentiel, l’utilisation du logiciel a une implication pour l’utilisateur final du logiciel.
- Pour chacun des processus retenus, on détermine, quels sont les objectifs de contrôle que le logiciel doit satisfaire impérativement ou optionnellement.
- Pour chacun des objectifs de contrôle impératif ou optionnel, on détermine la ou les mesures de sécurité les plus appropriées.
- On établit ensuite un classement des mesures à implémenter en fonction du caractère optionnel ou impératif de l’objectif de contrôle et en fonction des relations de dépendance entre les mesures à implémenter.
Ce classement permet de définir les mesures de sécurité que doit offrir le logiciel.
Les mesures choisies pour répondre aux objectifs de contrôle, ne doivent pas avoir d’impact opérationnel pour les clients ne souhaitant pas les utiliser.
Ensuite quand les besoins des clients deviennent plus clairs, il est possible de reprendre l’analyse de risques en y incluant les besoins du client.
Cette technique permet également de répondre, a posteriori, aux besoins plus spécifiques de certains clients. En effet, des mesures supplémentaires peuvent s’appuyer sur les mesures préalablement implémentées dans le logiciel.
Établir le dialogue avec le service informatique
Le développement d’un nouveau logiciel nécessite la mise en place d’un environnement de travail. Cet environnement a toujours un impact sur le service informatique de l’entreprise. Il convient d’instaurer au plus vite un dialogue à ce propos avec le service informatique.
De plus l’expertise développée au sein du service informatique, en matière de sécurité de l’information, peut s’avérer très utile pour l’analyse des risques. Il convient donc, si cela est possible, de solliciter cette expertise.