The post Typologie des intelligences artificielles appeared first on Cyriskintel.

From OWASP GenAI Security Project and NIST AI Risk Management Framework.

The post AI Security Threats, controls and life cycle appeared first on Cyriskintel.

La taxonomie dénombre une charte d’entreprise, une politique générale (ou politique de sécurité d’entreprise), des directives (Québec) ou des politiques, des normes, des procédures et des guides. On distingue les politiques traitant d’un problème ou d’une situation (en anglais issue-specific) et les politiques relatives à une technologie (en anglais system-specific).

La typologie est relative au type de contenu attendu dans chaque niveau et à sa portée. On distingue la mission et les valeurs de l’entreprise (ou d’un département ou encore un domaine), des principes et des objectifs stratégiques (ils peuvent être plus opérationnels si ce niveau dépend d’une direction opérationnelle), des exigences fonctionnelles, des règles techniques (de configuration, d’architecture, de développement logiciel) afin d’uniformiser les systèmes et les pratiques, des procédures pour permettre de réaliser les tâches comme attendu et des recommandations qui éclairent sur le contexte ou précisent de manière plus granulaire comment implémenter les règles au-dessus.

La portée peut être stratégique en décrivant les orientations, les justifications et un plan d’action à haut niveau ; elle peut être tactique, en clarifiant ce que l’organisation souhaite faire pour réaliser ses objectifs tout en respectant certains principes tels qu’énoncés dans la politique d’entreprise ; elle peut être opérationnelle, en décrivant comment on parvient à respecter les règles des niveaux précédents, étape par étape.

La structure dépend de la taille de l’organisation, des niveaux d’approbation et de l’audience-cible de chaque type de document. Mais dans tous les cas, elle doit être hiérarchique, c’est-à-dire qu’au sommet se trouvent les documents approuvés au plus haut de la hiérarchie de l’organisation (par exemple le Conseil d’administration) et en bas ceux qui sont validés localement au sein d’une équipe. En haut se trouveraient les documents obligatoires et en bas les documents non obligatoires. Par hiérarchie, on entend aussi, et c’est crucial, qu’à chaque niveau, on traite un type d’information particulier à destination d’une audience spécifique, en prenant soin de ne jamais répéter la même chose, de la même manière à plusieurs niveaux documentaires qui sont complémentaires.

La gestion d’un cadre dcoumentaire est généralement réalisée par l’équipe GRC (Gouvernance, Risques et Conformité) et c’est une tâche souvent sous-estimée, mal réalisée, par un personnel insufisamment formé. On pense à tort que c’est réservé au personnel non technique et débutant, mais c’est l’inverse. Il faut de préférence avoir fait un bon parcours, à des rôles variés, avant de se spécialiser en GRC. L’activité possède ses particularités, nécessite d’avoir un certain nombre de compétences comportementales spécifiques comme celle de la négociation (l’art de trouver le compromis), la communication aussi bien orale qu’écrite, de la rigueur et une bonne capacité d’analyse. nfin, l’équipe GRC doit avoir de bonnes connaissances des cadres et des normes de l’industrie, tout en étant familier des pratiques de cybersécurité.
L’équipe GRC fait le pont avec la haute direction, interprète les valeurs de l’entreprise, gère les risques et la conformité réglementaire appliquée aux TI et à la cybersécurité, autant d’informations qui servent d’intrants dans le processus de gestion documentaire. Elle fait la jonction entre la vision stratégique, les pratiques opérationnelles et la vision technologique. ELes spécialistes en GRC ne sont ni développeurs, ni architectes, ni pentesteurs, ni analystes d’incidents, mais bébéficient d’avoir eu des expériences précédentes plus opérationnelles et plus techniques.

Cyriskintel est une société de conseil et de formation via Cyriskacademie, spécialisée dans la GRC TI et cybersécurité.

The post Gérer un cadre documentaire de cybersécurité appeared first on Cyriskintel.

Voici quelques articles pour une mise en bouche.

https://www.6sigmastudy.com/article?title=Lean-Six-Sigma-Methodology-in-Cyber-Security-Operations

https://sloanreview.mit.edu/article/the-case-for-lean-cybersecurity-leadership

https://www.larksuite.com/en_us/topics/project-management-methodologies-for-functional-teams/lean-six-sigma-for-cybersecurity-teams

The post DMAIC de Six Sigma pour la GRC TI et cyber appeared first on Cyriskintel.

Un des exemples fréquemment rencontrés dans le domaine de la gestion des risques, c’est l’utilisation d’une 𝐠𝐫𝐢𝐥𝐥𝐞 𝐝’𝐢𝐦𝐩𝐚𝐜𝐭𝐬 métier (en France), d’affaires (au Québec), organisationnels (dans tous mes référentiels, car tout impact doit affecter l’organisation et pas seulement les affaires).

Que vous dit-on ? Une fois défini un scénario de risque, on l’évalue par rapport à l’impact (conséquence pour ISO 27005:2022) que celui-ci aurait sur l’organisation, pour que celle-ci se sente concernée. Généralement, on utilise des types d’impacts très génériques. Ce sont des « valeurs » de l’organisation qui peuvent être affectés de manière négative par les événements d’origine cyber scénarisés.

Le NIST a deux définitions intéressantes relatives à la sécurité de l’information, qui se complètent, et qui en disent tout de suite beaucoup plus que la définition de ISO 27000 :

1. La magnitude de dommage qui peut être attendue comme conséquence d’une divulgation non autorisée d’informations, d’une modification non autorisée de l’information, de la destruction non autorisée d’informations ou de la perte d’information ou d’indisponibilité du système d’informations.

2. L’effet sur les opérations, les actifs, les individus d’une organisation, les autres organisations ou la Nation résultant d’une perte de la confidentialité, de l’intégrité ou de la disponibilité d’un système d’information.

L’impact est donc l’estimation d’une conséquence. Et la conséquence est un événement (survenue d’un ensemble de circonstances attirant l’attention). Ceux qui me suivent ou qui ont suivi une de mes formations en gestion des risques, ont l’habitude de me voir dsitinguer les événements en événement causal et événement conséquent (désolé pour certains archaïsmes). Un scénario de risque n’est que la juxtaposition de ces deux types d’événements interdépendants, l’un étant la cause de l’autre. Nous refusons d’utiliser le terme plus simple de « cause » car il conduirait rapidement à identifier des faiblesses ou des vulnérabilités en lieu et place à des événements initiaux. Or une faiblesse ou une vulnérabilité décrit un état (statique) et non un événement (dynamique). Sans aller trop dans le détail, il est possible de construire des arbres entiers de causes et de conséquences en retraçant tous les événements consécutifs depuis l’état de faiblesse originelle jusqu’à l’événement final entraînant des conséquences larges sur l’organisation. C’est cet enchaînement d’événements qui constitue le scénario de risque le plus complet.

Parmi les impacts qui sont le plus souvent considérés, on trouve :

• L’impact réputationnel (notion « tarte à la crème ») : événements ayant un effet sur la réputation de l’organisation
• L’impact financier (notion très floue, tout n’a-t-il pas une conséquence financière 𝑖𝑛 𝑓𝑖𝑛𝑒 ?) : événements ayant un effet sur les finances de l’organisation
• L’impact stratégique (qu’est-ce qu’une stratégie ?)  : événements ayant un effet sur la stratégie de l’organisation
• L’impact légal ou réglementaire : provenant de la non-application des lois et des règlements applicables
• L’impact opérationnel  : événements ayant un effet sur les opérations de l’organisation (quand ce type d’impact maque, le monde semble dépeuplé)

Ces impacts définissent des types ou des catégories d’impacts. Chaque organisation a ses propres biais pour les identifier et les sélectionner. Une première ligne de défense héritera très certainement des référentiels imposés par la deuxième ligne de défense, que ceux-ci soient pertinents ou non (voir un prochain article sur les méfaits de la propagation des erreurs ou l’idée que la conformité à de mauvais référentiels doive l’emporter sur la pertinence conduisant au non respect des réféfentiels). Il y a d’emblée beaucoup de choses à dire sur cette typologie fragile, on y reviendra. Maintenant, peuvent-ils s’appliquer à un scénario de cybersécurité ?

Prenons un exemple de scénario issu du référentiel Cobit 5, qui n’est pas la meilleure source, mais certaines organisations s’obstinent à l’utiliser malgré tout : « Il y a une infection régulière des ordinateurs portables par des maliciels » (catégorie Malware) ou encore « Des utilisateurs non autorisés essayent de s’introduire dans des systèmes » (catégorie Logiciels). Nous avons bien deux scénarios différents portant sur deux événements distincts dont il faudra estimer, nous dit-on, l’impact sur l’organisation. Organisons cela en tableau pour visualiser les mises en correspondance :

Il y a ici deux problèmes : le scénario de risque est très opérationnel et il ne permet pas de déduire avec certitude le type d’impact qu’il aura sur l’organisation, mais assurément, ils traitent d’événements qui affecteront, plus ou moins, les opérations ; les types d’impacts manquent de granularité et semblent bien lointains des événements décrits par les scénarios. Ce phénomène s’accroît dramatiquement lorsque les organisations décident qu’un scénario de risque doit décrire des attaques. Premier constat : il est presque toujours impossible de déduite les conséquences précises qu’auront des événements de cybersécurité lorsqu’ils ne décrivent que des procédés techniques, des tactiques ou des vecteurs d’attaque. Deuxième constat : l’injonction théorique nous fait oublier une notion basique qu’un scénario de risque de cybersécurité est avant tout opérationnel et, comme l’énoncent les définitions ci-dessus, on s’attend à décrire et à mesurer avant tout des conséquences de sécurité. Et cette partie est souvent oubliée par les équipes en charge des analyses des risques ou de la conception des référentiels, par abus de théorie et manque de pragmatisme. Le BIA (Business Impact Assessment), dans le contexte d’une analyse de risque et non de la continuité d’activité, procède toujours de d’un SIA (Security Impact Assessment). En fait, dans la pratique, ils sont indissociables. Les dissocier est une erreur qui diminue la pertinence du travail de l’analyste.

Voici le tableau qui devrait être utilisé en premier lieu. Chaque type d’impact organisationnel issue d’un BIA est découpé en 3 critères de SIA (valables pour la sécurité de l’information) symbolisés par la triade CID (pour Confidentialité, Intégrité, Disponibilité) :

On l’interprète comme cela : « quel événements relatifs à la perte de confidentialité. intégrité et disponibilité de l’actif X auraient une conséquence notable sur l’axe réputationnel, financier, réglementaire ou opérationnel ? »

En se posant systématiquement ce type de question, on va pouvoir s’assurer aussi que le scénario de risque retenu n’est pas juste un événement de menace simple (vecteur, TTP), mais décrit des circonstances qui affectent réellement l’organisation à partir de la perte d’objectifs. Si on fait l’erreur de décrire un scénario par « risque d’élévation de privilège » il sera illusoire de le rattacher à un quelconque risque. En revanche, l’ajout de vecteurs et de TTPs dont on aura préalablement recueilli des statistiques, permettent non seulement de compléter et rendre unique un scénario, mais aussi d’estimer les probabilités d’occurrence des événements.

Mais si on voulait décrire des conséquences pertinentes, il faudrait les rendre plus granulaires et les associer à des événements conséquents qui aient un sens pour l’organisation. Par exemple, pour l’organisation Y, quels événements spécifiques pourraient affecter négativement la réputation ? D’où le tableau suivant :

Tout événement de cybersécurité (événement causal) doit être associé à une conséquence pour l’organisation (événement conséquent) qui peut être mesurable par l’organisation.

Une fois que nous avons corrigé ce premier problème, force est de constater que cette typologie très générale est conceptuellement un peu fragile. D’abord, pour une organisation, toute conséquence affecte directement ou indirectement ses capacités financières, que ce soit par une perte de revenu, une sanction administrative ou un dépassement de budget. On s’attendrait donc à ce que l’aspect financier se retrouve en filigrane dans toutes les conséquences. Ensuite, on doit distinguer les conséquences immédiates (souvent plus fréquentes, mais de moins grande magnitude) à un événement de cybersécurité, des conséquences tardives (souvent plus rares, mais de plus grande magnitude). Et pour une fois, je vais reprendre tel quel le modèle apporté par la méthode FAIR (Factor Analysis of Information Risk) qui devrait être étudiée par tous les analystes qualitatifs tant elle remet de l’ordre et du bon sens dans l’exercice de la discipline.

FAIR énonce les conséquences suivantes :

• Magnitude de Perte Primaire (PLM, Primary Loss Magnitude) associées aux réaction des parties prenantes primaires (qui sont affectées immédiatement)
  • Perte de productivité (ralentissement de la production, chômage technique)
  • Remplacement d’un bien ou correction d’un problème
  • Réaction (immédiate) à un incident (p. ex. déclenchement d’un plan de continuité des affaires, confinement d’un système, activation d’une cellule de crise)
• Magnitude de Perte Secondaire (SLM, Secondary Loss Magnitude) associées aux réaction des parties prenantes secondaires (qui sont affectées plus tard)
  • Perte d’un avantage compétitif (ou d’une part de marché)
  • Atteinte à la réputation (coûts liés aux relations publiques)
  • Amendes et décisions de justice (coûts liés à assurer une défense juridique)
  • Réaction (plus tardive) à un incident (p. ex. le coût lié à l’implication des forces de l’ordre, à la notification de régulateurs et clients)

Parce que ces conséquences sont issues d’une méthode quantitative ou le coût financier est le dénominateur commun, aucun impact financier n’est mis en exergue. La méthode offre une typologie plus pertinente.

Revenons à nos moutons cybernétiques : si le scénario sélectionné ne décrit pas un événement pouvant être associé à l’une des conséquences ci-dessus, c’est qu’il n’est pas pertinent et est inexploitable. Reprenons un des exemples de scénarios Cobit très imparfaits ci-dessus et ajoutons des informations manquantes pour construire des scénarios plus pertinents, distincts et procédant de la perte de la confidentialité, de l’intégrité et de la disponibilité :

• Il y a une infection régulière des ordinateurs portables par des maliciels (entraînant quoi pour les utilisateurs, les processus de l’organisation ?)
  • Ralentissant le poste de travail (conséquence primaire sur le système)
    • Réduisant la productivité des utilisateurs légitimes
      • Forçant les équipes informatiques à intervenir
    • Entraînant le mécontentement des utilisateurs
      • Forçant les équipes informatiques à intervenir
  • Entraînant un redémarrage inopiné d’applications (conséquence primaire sur les applications)
    • Réduisant la productivité des utilisateurs légitimes
    • Entraînant le mécontentement des utilisateurs
• Des utilisateurs non autorisés essayent de s’introduire dans des systèmes (pour faire quoi ? Avec quelles conséquences ?)
  • Dégradant le fonctionnement du système
    • Réduisant la productivité des utilisateurs légitimes
    • Entraînant le mécontentement des utilisateurs
  • Accédant en lecture à des données confidentielles
    • Entraînant une non-conformité réglementaire
      • Affectant la réputation de l’entreprise
      • Menant à une amende pour non-conformité
    • Entraînant une violation d’obligations contractuelles
      • Menant la perte d’un client important
    • Entraînant des articles de presse à grande diffusion
      • Affectant durablement la répudiation de l’organisation
        • Menant à des opérations dispendieuses de relations publiques
      • Provoquant une fuite importante de clients

Ce n’est pas exhaustif, mais cela renforce la structure et la mise en relation des événements. Ces relations peuvent être mises en évidence par des arbres de conséquences complets.

Dans les exemples incorrects provenant de Cobit 5, il est difficile de faire une association plausible. Il vaudra mieux réécrire un scénario en suivant la syntaxe suivante, plutôt que de sélectionner au hasard dans divers référentiels des mauvais exemples :

Cas 1 : l’audience principale n’est pas technique

Impact sur les CID + événement de sécurité haut niveau + actif concerné + type d’acteur (interne/externe) (+ cause supposée ou avérée) + Conséquence organisationnelle

Par exemple :
« Indisponibilité de la base de données X par suite de l’attaque par un acteur externe (rendue possible par un défaut de configuration) occasionnant une perte importante de productivité (idéalement quantifiable). »

Cas 2 : l’audience principale est technique

Impact sur les CID + TTP ou vecteur + actif concerné (+ cause supposée ou avérée) + Conséquence opérationnelle

Par exemple :
« Divulgation de données confidentielles suite à un abus de privilèges par un acteur interne permettant de visualiser le contenu d’une base de données X (rendue possible par un processus d’octroi des permissions défaillant) occasionnant une non-conformité avec la loi sur la protection des renseignements personnels (Québec) »

En résumé :

• Le choix de la typologie d’impacts (ou de conséquences) est très important et il doit avoir du sens autant pour décrire un scénario de cybersécurité que pour estimer les conséquences sur l’organisation
•  Le choix de la typologie doit influencer la manière dont on décrit un scénario de risque pour permettre de faire un lien logique et vraisemblable
• Il est impossible d’estimer une conséquence autre qu’opérationnelle pour un événement si on ne retient de lui que son aspect opérationnel et technique
• On ne doit jamais faire ce qu’une norme, un cadre ou une bonne pratique nous force ou suggère de le faire, par principe, mais parce que cela fait du sens après analyse de toutes les informations et après avoir porté un regard critique

Igor Scerbo est le fondateur de l’entreprise de services Cyriskintel, le concepteur de divers référentiels et formateur en gouvernance et gestion des risques.

The post Méfiez-vous des injonctions issues de bonnes pratiques appeared first on Cyriskintel.

Dans l’exemple ci-dessous, après avoir mutualisé certaines tactiques proches et interdépendantes, nous proposons un modèle simplifié utilisable plus rapidement.

The post Modélisation simplifiée des attaques appeared first on Cyriskintel.

The post ATTAQUES PAR DRIVE-BY / WATERHOLE appeared first on Cyriskintel.

• Usurpation d’identité (S) – Assume identity (Spoofing) menace l’identification et l’authentification
• Altération des données, fichiers et répertoires (T) – Modify data (Tampering) menace l’intégrité
• Dissimulation des activités (R) – Hide activities (Repudiation) menace l’imputabilité
• Lecture des données, fichiers et répertoires (I) – Read data (Information disclosure) menace la confidentialité
• Déni de service ou indisponibilité de la ressource (D) – (Denial of service) menace la disponibilité
  • Exécution instable (D) – DoS: unreliable execution;
  • Plantage, sortie et redémarrage – DoS: Crash, Exit and Restart
  • Arrêt inattendu– DoS: Stop
  • État inattendu – DoS: Unexpected State
  • Épuisement des ressources – DoS: resource consumption (mémoire, CPU, espace disque, réseau)
• Gain de privilèges (E) – Gain privileges (Elevation of privileges) menace l’autorisation (droits d’accès)
• Exécution non autorisée de code ou de commandes (X) – Execute unauthorized code or commands – Menace potentiellement tous les objectifs (le code peut servir à gagner des privilèges, à verrouiller des comptes, chiffrer des données, etc.)
• Contournement d’un mécanisme de protection ou des défenses (C) – Bypass protection mechanism – Menace potentiellement tous les objectifs (le code peut servir à évader les mécanismes de surveillance, de contrôle d’accès, etc.)

Tout l’intérêt de faire l’inventaire des menaces, c’est de pouvoir les associer avec des mesures de contrôle (résistance) et des faiblesses. Nous donnons ci-dessous un tableau des mesures de contrôle possible, avec l’identifiant du référentiel dont elle est issue (ici l’exemle de CSF 2.0). Pour prendre connaissance de notre propre référentiel, cliquer sur le menu « Référentiels ».

• Usurpation d’identité (S) :
  • PR.AC-1 (Gestion des identifiants et des accès)
  • PR.AC-6 (validation des identités, lien avec un moyen d’authentification, assertion)
  • PR.AC-7 (authentification)
  • RS.MI-1 (confinement des incidents)
• Altération (T) :
  • PR.AC-2 (accès physique)
  • PR-DS-1 (données au repos)
  • PR-DS-2 (données en transit)
  • PR-DS-6 (vérification de l’intégrité logicielle et informationnelle)
  • PR-DS-8 (vérification de l’intégrité matérielle)
  • PR.IP-3 (contrôle de la configuration)
  • PR.MA-1 (maintenance)
  • PR.PT-1 (journalisation)
  • PR.PT-2 (supports amovibles)
  • DE.CM-2 (surveillance physique)
  • DE.CM-4 (détection de code malveillant)
  • DE.CM-5 (détection de code mobile non autorisé)
  • DE.CM-7 (surveillance des accès non autorisés)
  • RS.MI-1 (confinement des incidents)
• Dissimulation / Répudiation (R) : [Dépendance avec le PR.AC-1, PR.AC-6, PR.AC-7]
  • PR.PT-1 (journalisation)
  • DE.CM-1 (surveillance du réseau)
  • DE.CM-2 (surveillance physique)
  • DE.CM-3 (surveillance du personnel)
  • DE.CM- 6 (surveillance des fournisseurs)
  • DE.CM-7 (surveillance des accès non autorisés)
  • RS.MI-1 (confinement des incidents)
• Divulgation (I) :
  • PR-DS-1 (données au repos)
  • PR-DS-2 (données en transit)
  • PR-DS-1 (données au repos)
  • PR-DS-5 (fuite de données)
  • PR.IP-6 (destruction des données)
  • PR.PT-2 (supports amovibles)
  • PR.AT-1 (formation du personnel)
  • PR.PT-1 (journalisation)
  • DE.CM- 6 (surveillance des fournisseurs)
  • DE.CM-7 (surveillance des accès non autorisés)
  • RS.MI-1 (confinement des incidents)
• Déni de service (D) :
  • PR.DS-4 (gestion des capacités)
  • PR.IP-4 (sauvegardes)
  • PR.PT-3 (principe de fonctionnalité minimum)
  • PR.PT-4 (contrôle des communications et des réseaux)
  • PR.PT-5 (redondance)
  • RS.MA-01 (exécution du plan de gestion des incidents)
  • RS.MI-1 (confinement des incidents)
• Gain de privilèges (E) :
  • PR.AC-3 (gestion des accès distants)
  • PR.AC-4 (gestion des privilèges)
  • PR.AT-2 (sensibilisation des comptes à privilège)
  • PR.PT-1 (journalisation)
  • DE.CM-7 (surveillance des accès non autorisés)
  • RS.MI-1 (confinement des incidents)
• Contournement (C) + :
  • PR.AC-3 (gestion des accès distants)
  • PR.AC-5 (intégrité des réseaux)
  • PR.MA-2 (maintenance)
  • PR.PT-3 (principe de fonctionnalité minimum)
  • PR.PT-4 (contrôle des communications et des réseaux)
  • DE.CM-1 (surveillance du réseau)
  • RS.MI-1 (confinement des incidents)
• Exécution de code ou commande (X) + :
  • PR-DS-6 (vérification de l’intégrité logicielle et informationnelle),
  • PR.IP-3 (contrôle de la configuration)
  • PR.PT-1 (journalisation)
  • PR.PT-3 (principe de fonctionnalité minimum)
  • DE.CM-4 (détection de code malveillant)
  • DE.CM-5 (détection de code mobile non autorisé)
  • DE.CM-09 (surveillance matérielle et logicielle, environnements d’exécution)
  • RS.MI-1 (confinement des incidents)

Idéalement, nous ajouterions une correspondance avec les faiblesses ou vulnérabilités des systèmes. Ci-dessous une tentative avec des catégories haut-niveau de OWASP (appelés TOP 10 des « risques »), mais il est préférable de sélectionner les faiblesses CWE qui sont les plus pertinentes avec le degré adéquat de pr0fondeur.

A01 – Contrôle d’accès défaillant – Broken Access Control
A02 – Échecs cryptographiques – Cryptographic Failures
A03 – Injection
A04 – Conception non sécuritaire – Insecure Design
A05 – Mauvaise configuration de sécurité – Security Misconfiguration
A06 – Composants vulnérables et obsolètes – Vulnerable and Outdated Components
A07 – Échecs d’identification et d’authentification – Identification and Authentication Failures
A08 – Intégrité défaillante des logiciels et des données – Software and Data Integrity Failures
A09 – Échec de la journalisation et de la surveillance de sécurité – Security Logging and Monitoring Failures
A10 – Falsification des requêtes côté serveur – Server-Side Request Forgery (SSRF)

Vous pouvez accéder aux détails sur le site d’OWASP :
https://owasp.org/www-project-top-ten/

Les menaces du modèle STRIDE-CX sont assez haut-niveau, mais elles gardent une certaine hiérarchie dont il faut prendre conscience. Comme on l’a vu précédemment, un cheminement d’attaque suit des phases, séquentielles au début et à la fin, non séquentielles entre les deux, car il faudra que l’attaquant s’adapte au degré de résistance qu’il rencontre jusqu’à atteindre ses objectifs tactiques et stratégiques.
Au sein de STRIDE, les TID représentent des objectifs tactiques de premier degré dans la plupart des cas (malheureusement pas tous), les SE représentent des objectifs tactiques de second degré. Il en va de même pour notre modèle STRIDE-CX ou CX sont aussi des objectifs tactiques.
Les objectifs tactiques sont des étapes intermédiaires nécessaires pour parvenir à des objectifs stratégiques. Et les objectifs tactiques de second degré sont des méthodes intermédiaires avant de passer aux objectifs tactiques du premier degré (les CID). Cette hiérarchie peut être représentée dans un « arbre d’attaques » simplifié.

Cette simplification de l’arbre d’attaques représente une combinatoire des possibles et a l’avantage de mettre en contexte les menaces du modèle STRIDE-CX pour comprendre les dépendances, mais il est imparfait. D’abord il faut comprendre que dans cette représentation, les CID s’appliquent seulement à l’actif étudié et non à tout actif faisant partie de son écosystème.
Dans nombre de cas, l’altération d’une donnée technique (comme un journal d’événements) servira au contournement des défenses. Mais on ne sélectionnera pas la menace Altération qui s’applique à un composant secondaire, on sélectionnera la menace qui représentera la conséquence, et le lie pourra être matérialisé par des tirets.
La représentation sera un peu différente si on veut schématiser un scénario spécifique au lieu d’une combinatoire des possibles, comme ci-dessous. Les menaces non utilisées (ou non mises en évidence) sont grisées pour clarifier le cheminement de l’attaque retenu.

Il faut aussi noter que des menaces de « même ordre » peuvent se succéder. On matérialisera cela par des flèches d’une menace à l’autre sans changer de niveau. C’est le cas de la dissimulation d’activités, mais ce pourrait être aussi des menaces connexes dans le schéma.

Cette présentation fait partie d’un cours d’une formation en ligne en cours de développement sur la Gestion des risques (modélisation des menaces) ou l’on explore les différentes manières de schématiser une analyse des menaces en vue d’une future scénarisation des risques.

© Copyright Services Cyber Cyriskintel Inc.

The post Modélisation des menaces avec notre modèle STRIDE-CX appeared first on Cyriskintel.

Une prise d’image de quelques unes des publications appartenant à l’écosystème ISO 27001 (sécurité de l’information, cybersécurité et protection de la vie privée.

En bleu les normes non certifiables, en rouge les exigences pouvant amener à la certification d’un organisme.

The post La famille (ou écosystème) des normes ISO 27xxx appeared first on Cyriskintel.

Voici un aperçu du guide du NIST SP800-218 qui décrit les objectifs pour encadrer le développement logiciel sécurisé en 4 étapes :

• Préparer l’organisation (PO)
• Protéger le logiciel (PS)
• Produire un logiciel bien sécurisé (PW)
• Réagir aux vulnérabilités résiduelles (RV)

Je vous en recommande la lecture. Accessible ici : https://csrc.nist.gov/pubs/sp/800/218/final

The post NIST SSDF 1.1 (SP800-218) Cadre pour le développement logiciel sécurisé appeared first on Cyriskintel.