38 0 31KB
Clause de contrôle A.14.1.1 Les exigences relatives à la sécurité de l'information doivent être incluses dans les exigences relatives aux nouveaux systèmes d'information ou aux améliorations apportées aux systèmes d'information existants.
Constat dans la société La socièté a défini une liste de contrôle des exigences de sécurité de l'information qui est appliquée pour tous les projets liés aux systèmes d'information. Cette liste de contrôle est requise par la politique de sécurité de l'information. Pour chaque exigence, le risque associé est évalué (élevé, moyen ou faible) et une décision concernant les actions à traiter est définie. Cependant, les critères utilisés pour évaluer les risques sont encore à définir clairement. Les exigences à appliquer sont définies et répertoriées en fonction de la nature du projet. Un comité de projet est chargé de définir les besoins et les exigences. Le CISO participe systématiquement aux comités du projet.
A.14.1.2 Les informations relatives aux services d'application passant sur des réseaux publics doivent être protégées contre toute activité frauduleuse, litige contractuel et divulgation et modification non autorisées.
Dans la liste de contrôle des exigences de sécurité de l'information, il est nécessaire que les pare-feu soient mis en œuvre afin d'empêcher la divulgation interne de la propriété intellectuelle. De plus, la socièté exige formellement que le trafic entre le réseau interne et les tiers soit chiffré à l'aide de HTTPS. Cependant, une procédure spécifique est encore à établir.
A.14.1.3 Les informations impliquées dans les transactions de service d'application doivent être protégées pour empêcher une transmission incomplète, un mauvais acheminement, une altération non autorisée des messages, une divulgation non autorisée, une duplication ou un rejouage non autorisé des messages.
N'est pas applicable:
A.14.2.1 Des règles pour l'élaboration de logiciels et de systèmes doivent être établies et appliquées aux développements au sein de l'organisation.
Les lignes directrices pour un développement sécurisé sont encore à formaliser.
Ce contrôle est hors de portée car les transactions par carte de crédit ne sont pas gérées par la socièté.
La société a adapté une norme pour le développement sécurisé dans le cadre du projet SDLC.
A.14.2.2 Les modifications apportées aux systèmes dans le cycle de vie du développement doivent être contrôlées par des procédures formelles de contrôle des changements.
Une demande est faite par l'entreprise, un formulaire est donc rempli puis il passe par le processus de gestion du changement. Les mesures concernant les changements apportés aux systèmes sont traitées formellement dans la liste de contrôle des exigences de sécurité de l'information. Il est également mentionné que les changements apportés aux systèmes dans le cycle de vie du développement doivent suivre la procédure de gestion des changements.
A.14.2.3 Lorsque les plates-formes d'exploitation sont modifiées, les Les changements sur l'environnement sont applications critiques doivent être officiellement approuvés uniquement si les examinées et testées pour contrôles de sécurité ne sont pas compromis par s'assurer qu'il n'y a pas d'impact une procédure formelle. négatif sur les opérations ou la sécurité de l'organisation.
A.14.2.4 Les modifications apportées aux progiciels doivent être dissuadées, limitées aux changements nécessaires et toutes les modifications doivent être strictement contrôlées.
Les exigences sont appliquées en fonction du jugement professionnel des développeurs
A.14.2.5 Les principes d'ingénierie Aucune règle spécifique n'a été formalisée. Il est des systèmes sécurisés doivent réalisé sur le jugement professionnel des être établis, documentés, développeurs. maintenus et appliqués à tous les efforts de mise en œuvre des systèmes d'information.
A.14.2.6 Les organisations doivent La socièté a défini plusieurs environnements établir et protéger de manière (développement, intégration, pré-production et appropriée les environnements de production). développement sécurisés pour les Il a été développé et mis en œuvre en interne un efforts de développement et système qui assure la ségrégation des d'intégration de systèmes qui environnements. Chaque développeur a accès à couvrent l'ensemble du cycle de son environnement. Toutefois, une ségrégation au vie du développement du système. niveau du projet n'est pas mise en œuvre en raison des besoins internes d'accès et d'utilisation des ressources de code par les développeurs. Il a été noté que la ségrégation de l'environnement des différents projets n'est pas considérée comme un risque à couvrir par la socièté. Une RAF doit encore être formalisée.
A.14.2.7 L'organisation supervise N'est pas applicable: et surveille l'activité de développement de systèmes La société ne sous-traite pas le développement. externalisés. A.14.2.8 Les essais de fonctionnalité de sécurité doivent être effectués pendant le développement.
Les exigences définies au paragraphe 14.1.1 ne sont pas systématiquement testées de manière formelle. Elle est effectuée au cas par cas.
A.14.2.9 Des programmes d'essais Aucun examen spécifique n'est effectué à ce jour. d'acceptation et des critères La société a acquis un outil qui sera mis en connexes sont établis pour les œuvre pour effectuer la revue de code nouveaux systèmes d'information, automatisée et assurer le respect des directives les mises à niveau et les nouvelles de développement sécurisées. versions. A.14.3.1 Les données d'essai doivent être soigneusement sélectionnées, protégées et contrôlées.
Le risque de ne pas anonymiser les données de production dans les environnements d'essais a été identifié et cela n raison de contraintes techniques. Cependant, un RAF doit encore être officialisé.
Niveau de maturité