Jusqu’à présent, les attaques liées à l’ingénierie sociale (Social Engineering) étaient en tête sur la liste des vecteurs de compromission initiale. C’était sans compter sur l’IA (Intelligence Artificielle) qui est en passe de faire exploser les records !

Une accélération des attaques

Depuis fin 2022, le nombre de phishing a été multiplié par 12 et le nombre de phishing lié au vol de compte a quant à lui été multiplié par 10. Il faut savoir que 68% des e-mails de phishing sont basés sur du texte et l’efficacité de ces derniers se voit nettement renforcée par l’usage de l’IA générative.

L’IA générative en quelques mots

L’Intelligence Artificielle générative (GenAI) est une catégorie d’IA qui se concentre sur la création de données et de contenu de façon indépendante. Elle est capable de reproduire la capacité cognitive humaine de manière globale.

On peut différencier 2 grands types de GenAI :

• L’IA générative généraliste
Ces modèles sont entrainés sur un corpus de données publiques très vaste et ont vocation à répondre à des demandes ou des questions. Tous les prompts et les retours des utilisateurs viennent nourrir l’algorithme qui motorisent l’IA.

• L’IA générative privée
Ces modèles sont destinés à n’interroger que les données d’une organisation. Ils sont généralement pré-entraînés pour répondre à un cas d’usage précis. Les échanges n’entraînent que l’instance privée.

Qu’est-ce que cela implique ?

Les attaques sont plus facilement personnalisables et adaptées à leurs cibles. Par exemple, l’intégration du logo de la société visée peut être réalisée automatiquement. Les pages web de phishing sont de plus en plus ressemblantes aux pages officielles et semblent plus vraies que nature.

Ces attaques sont-elles plus difficiles à reconnaître ?

Pas nécessairement. Les attaques générées à l’aide de l’IA sont certes plus ciblées, comportent moins de fautes d’orthographe ou de grammaire. Toutefois on y retrouve toujours les mêmes vecteurs d’exploitation :

• Des URL pointant vers des domaines inconnus
• Des fichiers souhaitant se faire passer pour ce qu’ils ne sont pas (un fichier PDF avec une extension .EXE par exemple)
• Des adresses d’expéditeurs plus que suspectes

Gardez vos bonnes habitudes !

1- Toujours vérifier l’expéditeur
Même si l’e-mail semble provenir d’un expéditeur connu, contrôlez l’adresse e-mail et son nom de domaine.

2- Toujours vérifier les pièces jointes et les liens
Ce mail ou ces éléments sont-ils attendus de la part de cet expéditeur ? Si un doute se présente, contrôlez en contactant l’expéditeur par téléphone.

3- Toujours signaler un mail malveillant identifié
Dans Outlook, pensez à bloquer les e-mails malveillants : courrier indésirable > bloquer l’expéditeur

Vous avez malencontreusement ouvert un lien ou un fichier malveillant ? Coupez immédiatement la connexion internet de votre poste. Contactez ensuite le plus vite possible votre manager et le RSSI avec le maximum des informations dont vous disposez.

Mieux vaut prévenir que guérir

On ne peut pas tout contrôler, mais on peut se prémunir ! Des outils adaptés et une bonne connaissance des risques informatiques peuvent éviter bien des déboires. Nous pouvons vous accompagner pour la mise en place d’un outillage efficace et la formation de vos équipes en matière de cybersécurité.

L’impact de l’IA sur la cybersécurité vous intéresse ?

L’IA générative, bien que très puissante, n’en est qu’à ses débuts. Pourtant elle engendre déjà de nombreux bouleversements dans le monde de l’IT. Ce sujet sera à l’honneur au forum International de la Cybersécurité, qui se déroulera à Lille, du 26 au 28 mars 2024.
Nous serons présents ! Venez nous rencontrer sur notre stand E1-7, situé dans l’espace CFI.

Cet article Les IA font évoluer les attaques est apparu en premier sur iDNA.

Cette méthode, qui gagne en popularité, offre une perspective unique et pragmatique pour évaluer et gérer les risques de manière plus efficace et précise.

Cet article revient sur les principes fondamentaux de la méthode FAIR et son application concrète.

FAIR: Factor Analysis of Information Risk

Le standard FAIR est un modèle analytique permettant d’évaluer et de quantifier les risques financiers de manière objective et reproductible. Il propose une approche structurée pour évaluer les risques liés à la sécurité, à la conformité réglementaire, aux pannes techniques, aux interruptions de la chaîne d’approvisionnement, et bien d’autres.

Contrairement aux approches traditionnelles, qui se basent souvent sur des évaluations subjectives, la méthode FAIR se fonde sur une analyse factuelle et une compréhension détaillée des facteurs constitutifs des risques.

L’un des principaux avantages de la méthode FAIR réside ainsi dans sa capacité à fournir une vision claire et chiffrée des risquesauxquels une entreprise est exposée, dans un contexte où les incidents opérationnels peuvent avoir un impact significatif sur la productivité et la rentabilité.

Que permet-elle concrètement ?

En adoptant la méthode FAIR, les entreprises peuvent :

1. Comprendre et hiérarchiser les risques par leur impact financier : La méthode FAIR permet d’identifier les risques les plus critiques en se basant sur des données factuelles et des estimations probabilistes. Cela permet aux entreprises de se concentrer sur les risques réellement importants et d’allouer les ressources de manière efficace.

1. Prendre des décisions éclairées: en utilisant des données tangibles, la méthode FAIR aide les dirigeants à prendre des décisions éclairées en matière d’investissement, de politique de sécurité, de gestion des fournisseurs et de planification stratégique car ils connaitront en termes financiers les impacts des potentiels incidents et les couts de remédiation ou prévention.

3. Renforcer la confiance des parties prenantes : en adoptant une approche objective et reproductible pour évaluer les risques, les entreprises industrielles renforcent leur crédibilité et gagnent la confiance des clients, des partenaires commerciaux et des régulateurs.

Une méthode complémentaire

Contrairement aux méthodes traditionnelles plus faciles à déployer, la méthode FAIR s’avère souvent longue à mettre en œuvre car elle nécessite la mobilisation de nombreuses équipes transverses pour collecter l’ensemble des données financières et techniques. Il faudra se poser la question de sa pertinence par rapport aux méthodes qualitatives et la réserver pour des scénarios concernant des actifs critiques qui engagent la responsabilité financière de l’organisation, ou devant justifier des investissements stratégiques.

Dans la pratique, la méthode FAIR intervient donc en complément des méthodes traditionnelles. À savoir que les informations collectées lors des analyses déjà réalisées pourront être réutilisées par la suite sur d’autres scénarios. Autrement dit, plus la méthode sera déroulée, plus son usage en sera facilité.

Notre retour d’expérience 

1. En permettant de quantifier financièrement des scénarios de risques, FAIR permet de faire le lien entre les experts cybersécurité, les responsables métiers et la direction générale.

2. L’utilisation d’une taxonomie des facteurs distincts qui composent le risque apporte une de la clarté dans l’analyse et évite des interprétations ou des malentendus. Aussi la manière dont ces facteurs sont liés entre eux (relations).

3. La collecte des informations est un process long et manuel, d’habitude associé à de longues réunions de travail dans lesquelles les parties prenantes doivent être accompagnées par des experts.

4. Attention à la qualité de la collecte de données lors de l’analyse. En effet, il est nécessaire de collecter des informations pertinentes, qui soient défendables devant un Comité de Direction.

Contactez-nous :

Notre entreprise dispose d’experts en gestion des risques, prêts à accompagner les entreprises dans une démarche adaptée à leurs besoins.

Si vous êtes intéressé(e) par l’implémentation de la méthode FAIR et que vous souhaitez bénéficier de l’expertise de nos équipes, n’hésitez pas à nous contacter. Nos experts sont disponibles pour discuter de vos besoins spécifiques et vous guider tout au long du processus de mise en œuvre.

Ne laissez pas les risques compromettre votre succès.

En adoptant la méthode FAIR en complément des méthodes qualitatives, vous pouvez améliorer la gestion des risques au sein de votre entreprise, renforcer votre position concurrentielle et assurer la pérennité de vos activités face aux défis du marché actuel.

Cet article La méthode FAIR : un guide vers une gestion efficace des risques pour votre entreprise. est apparu en premier sur iDNA.

DORA : Digital Operational Resilience Act

Dans un contexte de plus en plus marqué par la transformation numérique, l’interconnexion grandissante des réseaux et la multiplication des cyberattaques, les services financiers doivent redoubler de vigilance.

La nouvelle réglementation DORA s’inscrit dans ce constat et a pour finalité de garantir la stabilité financière et la protection des consommateurs en cas de cyberattaque.

Son objectif : améliorer la résilience opérationnelle informatique des entités financières. Comment ? Grâce à un cadre de gouvernance et de contrôle interne spécifique, qui vient renforcer les normes et directives existantes (comme ISO27001 ou encore NIS2).

Le règlement DORA a été publié au Journal Officiel de l’UE le 27 décembre 2022 et entrera en application le 17 janvier 2025.

Qui est concerné par DORA ?

DORA concerne tout le secteur bancaire et financier des entités financières, de toutes tailles et opérant au sein de l’Union-Européenne (établissements de crédit, entreprises d’investissements, établissements de paiement…).

Elle impacte également les prestataires TIC (Technologies de l’Information et de la Communication), qui leur fournissent des services.

La réglementation se compose de 5 piliers :

• Pilier 1 : La gestion des risques liés aux TIC
• Pilier 2: La gestion et le reporting des incidents TIC et des cybermenaces
• Pilier 3: Les tests de résilience opérationnelle numérique
• Pilier 4: La gestion des risques liés aux prestataires de services TIC
• Pilier 5: Le partage d’informations et de renseignements en matière de cybersécurité

Nous avons choisi de concentrer cet article sur les piliers 3 et 4 de la réglementation : les tests de résilience et la gestion des risques liés aux tiers.  Les autres piliers feront l’objet d’un article spécifique.

Focus sur les tests de résilience opérationnelle numérique (Pilier 3)

Qu’est-ce que ça implique ?

Toutes les entreprises concernées sont désormais dans l’obligation de mettre en place un programme spécifique complet pour adresser les nouvelles exigences de la réglementation. Ce programme intègrera une série d’évaluations, de tests, de méthodologies, de pratiques et d’outils, tout en mettant l’accent sur les tests techniques.

Son objectif : mettre en place des contrôles afin de s’assurer de l’efficacité des systèmes qui garantissent la résilience du SI.

À l’issue de ce programme, les entreprises devront se faire auditer et se verront délivrer un certificat de conformité.

Les entreprises classifiées critiques selon la réglementation devront organiser un test de pénétration complémentaire à grande échelle tous les 3 ans (exercice de type « Red Team »).

Ce test devra être réalisé par des testeurs indépendants et couvrira les services critiques en impliquant les tiers du secteur des TIC basés dans l’UE. Le scénario devra être approuvé en amont par l’autorité de régulation.

Le défi est lancé !

Pour être en conformité en janvier 2025, les entreprises concernées par la réglementation devront prévoir une campagne d’évaluation de la résilience de leurs systèmes d’informations critiques avec récupération des preuves d’ici la fin de l’année 2024.

Cet enjeu nécessitera beaucoup de préparation et une charge de travail importante. Le fait que cette campagne implique obligatoirement les tiers critiques dans le domaine des TIC signifie aussi que ces derniers devront participer à cette préparation.

Focus sur la gestion des risques liés aux prestataires de services TIC (Pilier 4)

Ce pilier a pour vocation de veiller à ce que les organismes financiers disposent d’un niveau approprié de contrôle et de surveillance de leurs sous-traitants et ressources externes liés aux TIC, en particulier ceux qui sous-tendent des fonctions critiques.

Qu’est-ce que ça implique ?

Les organismes financiers seront dans l’obligation de disposer d’une stratégie et d’une politique définies en matière de risques des tiers liés aux TIC. Le directeur des risques et conformité ou un membre de l’organe de gestion en sera propriétaire.

Devra être établi un registre standard d’informations contenant la vue complète de tous leurs fournisseurs concernés ainsi que les services qu’ils fournissent et les fonctions qu’ils traitent. Un rapport sur les modifications apportées à ce registre devra être remis au régulateur tous les ans.

Les fournisseurs de services TIC devront être évalués selon certains critères avant la conclusion d’un contrat (ex : leur niveau de sécurité, le risque de concentration, le risque de sous-traitance…).

En prévision d’une éventuelle défaillance d’un fournisseur, une stratégie de sortie devra avoir été définie dès le départ. À savoir que la réglementation DORA contient également des lignes directrices concernant le contenu des contrats et les raisons de leur résiliation (qui doit être liée à un risque ou à une preuve de non-conformité).

Avec ce nouveau cadre de surveillance, les fournisseurs essentiels feront aussi l’objet d’évaluations annuelles au regard des exigences de résilience, telles que la disponibilité, la continuité, l’intégrité des données, la sécurité physique, les processus de gestion des risques, la gouvernance, les rapports, la portabilité, les tests…

Ces évaluations seront directement effectuées par le régulateur et impliqueront des sanctions en cas de non-conformité.

Encore un défi !

Rassembler les informations de tous ses fournisseurs TIC, et pas seulement les plus importants, comprenant les services fournis et les fonctions qu’ils sous-tendent est une tâche fastidieuse.

Les grandes organisations financières dépendent généralement de milliers de petits et grands fournisseurs et de systèmes de gestion d’anciens contrats qui peuvent compliquer considérablement l’extraction des données.

Une mise en place plus ou moins difficile

DORA s’applique à la totalité du secteur bancaire et financier et concerne toutes les tailles d’entreprises : de la TPE au grand groupe.

Certains chantiers liés aux exigences de DORA vont nécessiter beaucoup de temps et d’efforts aux équipes impliquées et toutes les entreprises ne sont pas égales face à la mise en place de cette réglementation. En effet, toutes ne disposent pas forcément des moyens d’analyse et de contrôle nécessaires, il leur faudra alors sûrement se faire accompagner.

Pour en savoir plus, n’hésitez pas à nous contacter.

Nos experts peuvent vous faire bénéficier de leurs expériences en termes d’exigences et de bonnes pratiques liées à la résilience opérationnelle numérique, et peuvent vous accompagner de la révision de votre existant à la mise en conformité aux exigences de DORA.

Cet article La nouvelle réglementation DORA : qu’implique-t-elle ? est apparu en premier sur iDNA.

Bonjour Nacer, peux-tu te présenter en quelques mots ?

N : Je suis consultant en cybersécurité depuis environ 5 ans. Mon expérience porte sur l’identification des problèmes de sécurité, l’évaluation des risques et la mise en oeuvre de solutions pour se prémunir contre les menaces qui pèsent sur les entreprises.

J’ai rejoint iDNA cette année, parce que c’est une entreprise à taille humaine spécialisée dans la cybersécurité. Actuellement je suis consultant spécialisé dans la sécurité du Cloud chez un de leurs clients : un grand groupe du secteur bancaire.

Peux-tu nous en dire plus sur ta mission actuelle ?

N : Je réponds aux besoins et aux sollicitations des interlocuteurs tels que les devops,  coachs,  chefs de projets… Ces besoins concernent l’utilisation des services AWS (Amazon Web Services). Je veille aussi à ce que son utilisation fasse l’objet d’une supervision appropriée.

J’ai des tâches en mode « RUN » :
Je gère les accès et les permissions des utilisateurs (AWS / Azure), également la réponse aux problématiques d’applications induites par le déploiement de certaines mesures de sécurité.

Je joue le rôle d’interface avec le Groupe :
En tant que représentant du département Cyber, j’interviens sur des sujets d’infrastructures partagées (type Landing Zone) et je fais évoluer les designs (modèle d’interconnexion hybride, OS Factory, vulnerability management, jogging…).

Actuellement je participe à l’étude Cloud-Native Application Protection Platform (CNAPP). J’identifie les besoins prioritaires en matière d’outils du CNAPP pour notre BU (Business Unit).

Je participe à des ateliers (Proof of Concept) organisés par les éditeurs pour identifier la solution la mieux adaptée aux besoins de notre BU et du Groupe en général.

Je représente l’équipe au sein des communautés de sécurité :
Ces dernières servent à prendre des décisions Groupe sur des sujets d’études précis.
En ce moment, je participe aux communautés de transformation dont l’objectif est d’identifier les analyses de risques réalisées par le Groupe sur les services Cloud (storage account, certificate manager, cloudfront…) pour être en mesure de challenger les contrôles préconisés, si besoin.

Je prends en charge les études et projets sécurité, comme l’AWS Data Perimeter, une réponse au risque de fuite de données « data leakage ». Nous veillons à ce que seules les identités de confiance du Groupe accèdent à des ressources de confiance, à partir de réseaux de confiance.

Il y a aussi l’IAM ROLES. On applique le principe du moindre privilège en fonction des services trustés par le Groupe, des demandes des utilisateurs, mais aussi de votre propre évaluation. On centralise le processus de création des rôles et la gestion des demandes d’exception.

Comment est organisée ton équipe ?

N : Mon équipe se compose d’un Team Leader, d’un Scrum Master et d’experts.

Le Team Leader coordonne nos projets et veille à ce que les objectifs soient atteints dans les délais impartis.
Le Scrum Master quant à lui fait en sorte que notre équipe reste efficace et alignée sur ses objectifs.
Nous sommes plusieurs experts dans le domaine du Cloud, que ce soit sur Azure ou sur AWS.

De quoi se compose une journée type ?

N : Je réponds aux demandes des interlocuteurs. Je gère les aspects opérationnels liés à la sécurité du Cloud. Je participe à des réunions ou des ateliers et je travaille sur des projets de sécurité.

Quels sont tes challenges ?

N : Je dois réussir à vulgariser les scénarios de risque pour convaincre les chefs de projets et les développeurs de mettre en œuvre rapidement les mesures de sécurité nécessaires.

Je dois également rester à jour des dernières évolutions en matière de sécurité Cloud.

Cet article Consultant en Cybersécurité Cloud : en quoi ça consiste ? est apparu en premier sur iDNA.

Cette icône est destinée à indiquer que la connexion entre le navigateur et le site web ne peut pas être altérée ou écoutée par un tiers.

Elle n’indique en aucun cas que le site web en question est fiable. En effet, presque tous les sites de phishing utilisent le protocole HTTPS et affichent l’icône de verrouillage.

En 2021, une étude menée par Google a démontré que seulement 11% des personnes interrogées comprenaient correctement la signification précise du verrou. Nombre d’entre eux ne savaient d’ailleurs pas que cliquer sur l’icône affichait des informations et des contrôles importants.

Google a donc expérimenté le remplacement de l’icône par un symbole plus neutre. Il s’est avéré que les utilisateurs cliquaient beaucoup plus et exprimaient nettement moins de confusion à son égard.

En conséquence, Google a décidé de remplacer officiellement l’icône de verrouillage par le symbole suivant :

Cette icône n’incite plus à penser que le site web est digne de confiance. Elle est également plus facilement cliquable puisqu’elle est plus généralement associée à des paramètres ou à un centre de contrôles.

Par ce nouveau symbole, Google compte donc éradiquer le malentendu selon lequel l’icône du verrou signifie qu’une page web est sécurisée.

Chrome continuera évidemment d’alerter ses utilisateurs lorsque leur connexion n’est pas sécurisée.

La nouvelle icône devrait être lancée dans la version Chrome 117, dont la date de sortie est prévue en septembre 2023.

Lien de l’article complet sur le blog Chromium (en anglais) :

https://blog.chromium.org/2023/05/an-update-on-lock-icon.html

Cet article Chrome remplace l’icône de verrouillage des adresses URL  est apparu en premier sur iDNA.

« Une rançon fixée à 10 millions d’euros »

Le 21 août 2022, aux alentours d’une heure du matin, le Centre Hospitalier Sud Francilien (CHSF) est victime d’un ransomware.

L’attaque bloque tous les logiciels métiers de l’hôpital, les systèmes de stockage et le système d’information relatif aux admissions des patients. Les pirates leur réclament 10 millions de dollars.

Un ultimatum est fixé : le centre hospitalier doit payer la rançon au plus tard le 23 septembre. S’il ne paye pas, une série de données concernant leurs usagers, leur personnel et leurs partenaires sera publiée.

La gestion de la crise

L’établissement se mobilise pour répondre à cette situation de crise en déployant un plan blanc (plan de crise spécifique aux établissements de santé). De nombreux patients sont alors adressés à d’autres hôpitaux et le personnel reprend papier et stylo pour effectuer les tâches quotidiennes.

L’hôpital saisit également l’Agence Nationale de la Sécurité des Systèmes d’Information (ANSSI), qui mandate des experts pour intervenir rapidement.

« L’hôpital refuse de céder au chantage »

La date fatidique approche. Les pirates informatiques bradent la rançon jusqu’à 1 million de dollars, mais l’hôpital ne cède pas.

Le délai expiré, les hackers diffusent une partie des données volées.

Parmi elles, figurent certaines données administratives dont des numéros de sécurité sociale, mais aussi des données de santé telles que des comptes-rendus d’examens.

Pour en limiter les effets, l’hôpital prévient immédiatement les individus concernés par cette extorsion et leur rappelle d’être particulièrement vigilants. Mais le mal est fait.

Et maintenant ?

Le CHSF souhaite renforcer son infrastructure informatique. Quelques mois après l’attaque, l’établissement a annoncé un chantier de 12 à 18 mois en collaboration avec l’Agence Régionale de Santé (ARS). L’objectif étant de pouvoir résister aux cyberattaques et de limiter leurs conséquences.

Une menace de plus en plus sérieuse

« Seulement 40% des entreprises (hors PME) investissent dans leur cybersécurité »

Les cyberattaques peuvent toucher tout type d’organisations, à tout moment. Le coût moyen d’une cyberattaque pour une TPE est de 18 000 euros, pour les entreprises plus conséquentes, les rançons peuvent atteindre plusieurs millions d’euros.

Malgré ce constat, seulement 40% des entreprises (hors PME) investissent dans leur cybersécurité (selon le baromètre de la cybersécurité en entreprise CESIN 2022).

La protection et la sécurité des données est un enjeu actuel majeur !

Comment se prémunir face à cette menace ?

Dans un contexte où les cyberattaques augmentent constamment, il est de plus en plus nécessaire de prendre la mesure de la menace et de s’en prémunir.

Mais comment ?

Une première solution sera de mettre en place un processus interne de gestion et de sécurisation des données. La première étape consiste à segmenter l’infrastructure en séparant vos assets vitaux de vos assets non-critiques. La suite peut s’avérer fastidieuse et nécessite des ressources conséquentes ainsi qu’un personnel suffisamment expert.

Une deuxième solution sera d’entièrement déléguer la mise en place de ce processus à un tiers spécialisé. Ce dernier pourra considérablement renforcer votre protection face à la cybermenace.

Dans un premier temps, vous pouvez également demander un audit de l’existant afin de détecter d’éventuelles solutions insoupçonnées déjà présentes dans votre entreprise.

Pour cela, tournez-vous vers un partenaire de confiance.

Discutons-en 

Cet article Une rançon de 10 millions de dollars pour le Centre Hospitalier Sud Francilien (CHSF). est apparu en premier sur iDNA.

Pour Wikipedia un Indicateur de Compromission ou IOC (Indicator of Compromise) est un artefact observé sur un réseau ou dans un système d’exploitation qui indique, avec un haut niveau de certitude, une intrusion informatique.

Les Indicateurs répondent à la question ‘Comment détecter’ une attaque. Voici quelques exemples d’Indicateurs :

• Spécification du modèle (pattern) d’un ensemble spécifique de caractéristiques statiques ou dynamiques (hash d’un fichier, connexions de réseau, valeur des cés de registre, etc.) qui sont uniques d’une famille de malware particulière et qui indique sa présence
• Spécification du modèle (pattern) d’un ensemble spécifique de caractéristiques statiques ou dynamiques (i.e. traces spécifiques dans les logs) qui indiquent l’exécution d’un modèle d’attaque particulier
• Spécification du modèle (pattern) d’un ensemble particulier d’adresses IP utilisées comme infrastructure C2 (Commande et Contrôle) du malware

Toutefois, nous allons voir qu’une défense informatique basée sur la détection des IOC est une approche plus fragile car ces IOC risquent d’être changés facilement par les attaquants.

Par le passé, uniquement les attaquants avec des moyens importants ou appartenant à des états étaient en mesure de pénétrer des systèmes de détection basés sur les IOCs, mais l’accès à des outils plus performants et moins coûteux, permettant de muter lessignatures des attaques, empêche que la protection basée sur des IOCs soit encore une défense très solide.

Nous devons donc mettre en place un autre type de défense, ou du moins, mettre en place un complément à la défense basée sur les IOC. C’est ici qu’intervient l’approche TTPs, une défense basée sur les Tactiques, Techniques et Procédures.

Les TTPs analysent le fonctionnement d’un acteur malveillant, elles décrivent comment les cyber attaquants orchestrent, exécutent et gèrent les attaques opérationnelles. Les TTPs contextualisent une menace. Elles révèlent les étapes ou les actions prises par des acteurs malveillants lors de l’attaque.

• Tactique: Ensemble des moyens coordonnés que l’on emploie pour parvenir à un résultat. Une tactique serait par exemple l’ingénierie sociale qui a pour but d’accéder aux données sensibles à travers des accès non autorisés, afin de compromettre un site internet ou de réaliser des mouvements latéraux dans un réseau.
• Technique: outils et compétences utilisés. Par exemple, si l’objectif est de compromettre un site internet, alors la technique peut être SQL injection.
• Procédure: séquence des actions réalisées par les attaquants pour exécuter l’attaque.

Dans notre exemple du site internet cité précédemment, la procédure peut être celle de scanner le site internet à la recherche de vulnérabilités, exécuter une injection SQL avec du code malicieux dans un formulaire non sécurisé, pour obtenir le contrôle du serveur web.

Les TTPs ont une nature descriptive et nous aident à répondre aux questions liées au comportement de l’attaquant « Comment et Quoi » : Qu’est-il en train de faire et comment il le fait.

Quelques exemples de TTPs:

• Caractérisation particulière d’une certaine famille de malware
• Caractérisation d’une forme particulière d’attaque (i.e. utilisation de certaines variables d’environnement pour exploiter une vulnérabilité)
• Caractérisation du choix des victimes (i.e. réseaux sociaux)

L’Attaque

Les IOCs sont détectés pendant la phase d’analyse après une attaque (forensics), ce qui implique qu’il y a eu déjà une compromission des systèmes. Les IOCs trouvés par les équipes de sécurité permettent de comprendre le type d’attaque et l’étendue de la compromission. Ces artefacts sont partagés avec la communauté de la sécurité et les organisations pour mettre à jour les systèmes de détection et antivirus, afin d’essayer de contrer les nouvelles attaques.

Mais quel est donc le problème associé aux IOCs dans la lutte contre les attaques informatiques?

Les systèmes de détection et les antivirus peuvent être configurés, mis à jour avec les informations relatives aux empreintes des outils des attaquants mais ceux-ci ont aussi la possibilité de modifier ces IOCs relativement facilement, par exemple changer les IPs, les valeurs hash et les signatures.

Les attaquants peuvent aussi utiliser les IOCs  pour détourner l’attention de la véritable attaque, celle menée avec des outils plus sophistiqués et complexes. Une équipe sécurité qui n’utilise que des IOCs statiques pour protéger l’organisation croira avoir trouvé et contré l’attaque alors qu’en réalité ce n’est pas du tout le cas.

Et les TTPs dans tout ça?

L’approche TTP nous apporte l’identification des éléments de comportement associés à une attaque, parce que justement, ces éléments sont beaucoup plus difficiles à modifier par les attaquants, à différence des IOCs mentionnés plus haut.

Avant une attaque, les cyber criminels préparent et mettent en place la stratégie, les techniques et les procédures à suivre pendant l’attaque et ceci en fonction des outils à leur disposition. Changer ces éléments sera donc beaucoup plus difficile pendant l’attaque, même lors d’une nouvelle attaque car ce changement demande beaucoup de ressources et de temps (i.e. développer un nouvel outil d’attaque).

Il est vrai que les attaquants ont habituellement plus d’un outil dans leur arsenal mais le nombre d’outils reste limité et en développer de nouveaux leur pose des problèmes. Le process utilisé par les attaquants pour développer de nouveaux outils n’est pas plus différent que celui utilisé par le développeur de logiciel traditionnels. Dans tous les cas de figure, il faut entreprendre une phase de recherche et développement, création d’un POC ou d’un prototype, réaliser des tests et packager le résultat final. Ceci peut prendre très longtemps et beaucoup de ressources (humaines, matériels et financières). Ces efforts sont aussi vrais pour la mise en place des TTPs associées au nouvel outil.

Pour consolider leur défense, les équipes sécurité devront alors tenir compte des ‘comportements’ des cybercriminels pour identifier les attaques. Ceci passe par une compréhension des différentes combinaisons de TTPs : des informations sont disponibles auprès des organismes de recherche en sécurité de l’information (OWASP : Open Web Application Security Project, CTA : Cyber Threat Alliance) qui vous aideront à concevoir une réponse automatisée avec vérification humaine.

Pour illustrer ces concepts, prenons comme exemple APT19, un groupe de cyber criminels basé en Chine qui a ciblé ses attaques dans les secteurs de la défense, finance, énergie et pharmaceutique parmi d’autres.  Si vous êtes une entreprise de l’un de ces secteurs, vous allez vous intéresser aux techniques utilisées par ce groupe (Informations Groupe APT19).

L’une des techniques utilisées par APT19 est Registry Run Key/Startup Folder, qui est une variante de malware http qui établit une présence dans la cible en configurant une clé du registre (Registry Key). L’équipe sécurité prendra connaissance de cette technique et supervisera le Registre pour la présence de cette clé ou de nouvelles clés qui ne sont pas attendues.

Maintenant, trouvons le comportement de l’attaquant. Certaines IPs à partir desquelles sont réalisées les attaques sont connues mais bien évidemment elles peuvent changer. Nous nous focaliserons plutôt sur l’établissement des connections SOCKS5, car établir ce type de connexion est un comportement associé à cet attaquant. Traduisons ensuite ce comportement en tactique, il y a environ 12 tactiques à partir desquelles nous pouvons choisir (Reconnaissance, Ressource et développement, Commande et contrôle, Collecte, etc.). Pour la connexion SOCKS5 nous parlons de Commande et contrôle. Pour SOCKS5, la technique est Standard Non-Application Layer Protocol (T1095). Des attaquants peuvent utiliser Non-Application Layer Protocol pour communiquer entre un serveur hôte et un serveur C2 ou entre des hôtes infectés à l’intérieur d’un réseau.

Les équipes sécurité vont mapper les informations d’intelligence collectées et mettront en place les actions nécessaires à l’identification des menaces et leur élimination.

MITRE ATT&CK est une base de connaissances globale de tactiques et techniques basée sur des observations réelles. Cet outil aide les équipes de sécurité à identifier et gérer les TTPs rencontrés. Il définit la manière dont les équipes de sécurité peuvent superviser l’activité des systèmes IT, détecter des comportements anormaux associés à des TTPs connus et l’arrêter avant qu’il ne devienne une attaque complète.

Ce que nous avons décrit précédemment est aussi applicable aux vecteurs d’attaque (i.e. ingénierie sociale), pas très facile à changer par les attaquants sans adapter les outils employés.

Les équipes sécurité doivent concentrer leurs défenses sur les éléments qui ne sont pas facilement évolutifs, les IOCs le sont (i.e. des cartes de crédit volées, des IPs, etc.), les TTPs ne le sont pas.

Les Tactiques, Techniques et Procédures fournissent aux équipes sécurité des organisations, des informations sur la manière dont les attaquants opèrent et se déplacent dans nos infrastructures et systèmes. Elles nous donnent les moyens de perturber les maillons de la chaîne d’attaque et de l’arrêter avant qu’elle ne se matérialise.

En conclusion, l’introduction de TTPs dans la stratégie de défense des organisations, en collaboration avec des IOCs, permettra de redonner l’initiative aux défenseurs, les TTPs permettent le basculement d’une défense passive à une défense active, d’initiative forçant les attaquants soit à abandonner soit à réaliser des investissements significatifs dans la modification des techniques, tactiques et procédures d’attaque. Cette approche réduit significativement l’exposition à une attaque.

Cet article Chronique d’une attaque annoncée : IOCs vs TTPs est apparu en premier sur iDNA.

Travaillant alors au sein d’un organisme certifié ISO 27001 dont l’une des exigences était notamment la mise en place d’un PCA, j’ai été témoin de la rapidité à laquelle on peut passer d’un mode normal à un scénario de crise, mais aussi du scénario de crise au mode normal, ce qui démontre l’efficacité du PCA mis en place.

Précisément, il est souvent difficile de faire la différence entre un plan de continuité / de reprise d’activité (PCA / PRA), un plan de continuité / reprise informatique (PCI / PRI) et le fameux PCC (plan de communication de crise) souvent mis aux oubliettes …

Beaucoup de personnes ayant tendance à les confondre, nous proposons ici de détailler chacun de ces acronymes :

• PCA : Plan de continuité d’activité 

Le PCA est l’ensemble des processus visant à assurer la continuité du fonctionnement en mode dégradé d’une entreprise, en cas de sinistre majeur.

Il s’agit de maîtriser les risques opérationnels de perte provenant de processus internes inadéquats ou défaillants, de personnes et systèmes ou d’événements externes, pouvant affecter le fonctionnement ou la pérennité de l’entreprise, voire gravement y nuire. Il est donc primordial : l’objectif ici est tout simplement que l’activité des métiers ne soit pas interrompue.

• PRA : plan de reprise d’activité

Le PRA est l’ensemble des procédures et moyens matériels, technologiques et humains permettant de rétablir et de reprendre l’activité de l’entreprise après la survenue d’un incident ou un sinistre. Il peut être déployé sans l’existence d’un PCA ou être complémentaire avec celui-ci. Il est déclenché cas d’arrêt d’une activité ou d’un processus.

• PCA ou PRA, lequel choisir ?

Ces deux plans sont uniques pour chaque environnement et organisation. Pour décider de la mise en place de l’un ou l’autre, il vous faudra commencer par un bilan d’impact sur l’activité (BIA), processus qui permet de déterminer et évaluer les effets potentiels d’une interruption des opérations commerciales critiques à la suite d’une catastrophe, d’un accident ou d’une urgence.

A l’issue du BIA, un rapport destiné à la Direction est généré, comportant beaucoup de paramètres. Ce qui va déterminer votre choix, c’est le RTO (Recovery Time Objective) : la durée d’interruption maximale admissible.

Prenons un exemple : une entreprise qui peut accepter un arrêt et un redémarrage d’activité dans un laps de temps donné (RTO > 0) optera pour un PRA, si elle estime que cet arrêt mettra en péril son activité, son choix se portera sur un PCA.

Mise en place et tests

Après avoir choisi entre le PRA et le PCA, l’étape suivante est la mise en place d’une stratégie qui va définir :

• Les infrastructures informatiques à mettre en place.
• La liste des scénarios possibles et les procédures associées à chacun.
• Les ressources de la cellule de crise et celles de l’exécution opérationnelle des procédures.

Vient ensuite la phase de test, très importante car c’est elle qui déterminera l’efficacité de votre plan, ainsi que les pistes d’amélioration. Il existe beaucoup de types de tests, tels que :

• Planifié ou non planifié
• Test technique ou utilisateurs
• Test total (qui déclenche tout le PCA/PRA) ou partiel (qui en déclenche juste une partie)
• Test impactant la production ou non

Les PCA /PRA ne sont pas figés dans le temps et leur modification est très fréquente. Par exemple, après un changement d’organisation de l’entreprise ou après l’intégration d’un nouveau système informatique critique Par ailleurs, les tests doivent être planifiés périodiquement, pour s’assurer de de l’efficacité des plans mis en place.

• PCI et PRI : Plan de continuité informatique

Le PCI est plus spécifique que le PCA. Il s’agit de l’ensemble des architectures, moyens et procédures nécessaires pour assurer une continuité de fonctionnement des services informatiques. Le PCI est une sous partie du PCA.

Quant au PRI, il correspond à l’ensemble des processus qui permettront au SI de redémarrer après un sinistre ou un incident critique.

Comme le PCA et le PRA, le PCI et PRI sont complémentaires.

• PCC : Plan de communication de crise

Le Plan de communication de crise, comme son nom l’indique, est établi pour s’assurer que les collaborateurs et les sous-traitants soient informés des procédures à suivre et pour qu’ils puissent communiquer avec les autorités publiques, le cas échéant.

En conclusion, Il est évident qu’une entreprise ne pourra jamais tout anticiper. En revanche, celles qui auront le réflexe et les processus adéquats pour travailler en équipe, analyser les risques et préparer des réponses aux imprévues, notamment en mettant en place un PCA/PRA, auront les plus grandes chances de survivre à de nouvelles secousses, mais surtout d’identifier les pistes d’améliorations nécessaires à la pérennité de l’entreprise.

De son côté, iDNA offre conseil et accompagnement dans le domaine de la résilience, donc n’hésitez pas à vous rapprocher de nos experts, vous serez entre de bonnes mains !

Cet article PCA, PRA, PCI, PRI, PCC : Stop à la confusion est apparu en premier sur iDNA.

Un succès n’arrivant jamais seul, cet usage massivement répandu de la clé USB en a fait un moyen privilégié pour propager du code malveillant (virus, ver, cheval de Troie…) hors ligne (Internet).

Difficile en effet pour un profane, de résister à l’envie de vérifier le contenu d’une clé trouvée « dans la nature », rappelant au passage combien le facteur humain pèse dans la balance de la vulnérabilité numérique. Pourtant rien n’indique à ce profane, qui pèche par méconnaissance, que la clé qu’il a trouvée n’est pas un « killer USB » – dispositif capable de détruire instantanément la plupart des systèmes auquel il sera branché (en délivrant plusieurs centaines de volts pulsés – tension létale à tout semi-conducteur de la carte mère  se trouvant sur son passage – obtenus par conversion de la pacifique alimentation USB elle-même…).    

S’il a été épargné par la destruction pure et simple de son matériel, notre profane se pensera sans doute en sécurité si la solution anti-malware de son poste de travail n’a pas réagi – or certains codes malveillants s’exécutent automatiquement lorsque la clé USB est branchée (« autorun ») et passent largement sous les radars du plus à jour des anti-virus (se faisant passer par exemple pour une frappe au clavier…). Et pour cause, toute clé USB contient un microcontrôleur USB programmé par un micro logiciel (« firmware »), qui n’est pas (ou peu) protégé. Dès lors, rien de plus efficace que de modifier ce micro logiciel pour que le comportement de la clé USB soit détourné de son rôle d’origine, et obtenir le vecteur d’une épidémie numérique. C’est sur cette considération que des chercheurs en sécurité confient que « la sécurité de l’USB est fondamentalement brisée », car les attaquants exploitent la façon même dont l’USB est conçu, rendant la menace plus profonde et imperceptible qu’il n’y parait intuitivement : le risque ne réside pas seulement dans ce que la clé transporte, il est intégré au cœur même de son fonctionnement.

Ainsi, un code malveillant peut être installé sur un périphérique USB (clé, cigarette électronique…) pour prendre complètement le contrôle du poste de travail auquel il est connecté, ou même rediriger le trafic Internet de l’utilisateur.  Étant donné que ce code malveillant ne réside pas dans la mémoire flash du périphérique USB, mais dans le micro-logiciel qui contrôle ses fonctions de base, le code d’attaque peut rester caché longtemps après que le contenu de la mémoire du périphérique semble avoir été supprimé pour notre profane maintenant bien éclairé. Il a appris depuis longtemps à ne pas lancer de fichiers exécutables à partir de clés USB inconnues, pour autant cette hygiène USB « à l’ancienne » n’est d’aucun secours pour contrer une attaque par micro-logiciel piégé (aucune signature cryptographique du code pour le rendre infalsifiable).  Il sait maintenant qu’un risque de sécurité intrinsèque affecte toute clé USB, qui doit être considérée comme irrémédiablement infectée si elle a été compromise au contact d’un ordinateur non fiable – et traitée comme telle (destruction), si l’on ne dispose pas de moyens de décontamination avancés. Citons par exemple les « stations blanches » à base de matériel endurci, passant au crible la clé USB avec la combinaison de plusieurs antivirus et lui faisant subir simultanément une analyse comportementale (du code embarqué : firmware, macro VBA…) avec  une plateforme d’analyse malware. Le succès à ce test intensif engendre un certificat d’utilisation borné dans le temps, et valable uniquement si aucun bit n’a ensuite été modifié, et permet à la clé USB d’être utilisée en toute sûreté à l’intérieur du domaine informatique administré. 

Nous comprenons maintenant pourquoi la clé USB est dans le collimateur des services de sécurité informatique.  Il y a cependant encore trop peu de pédagogie autour de la fermeture des ports USB sur les flottes de PC en entreprise, qui ne se généralise que depuis quelques années. La méthodologie est d’autant moins bien comprise par l’utilisateur, qu’il croit pouvoir contourner cette restriction avec des demandes de déverrouillage « discrétionnaire », qui figurent encore parfois au catalogue de l’offre des portails kiosques informatiques, sans avoir – espérons-le – la moindre chance d’aboutir, fût-elle appuyée par le management opérationnel. Cette remarque concerne le champs IT (besoin bureautique) avec des OS dernière génération à jour et maintenu, songez à ce qu’il en est pour le champs OT (contrôle de production industrielle) avec des OS généralement obsolètes voire hors support éditeur et brèche monumentales de sécurité qui vont de pair (exécution de code à distance) … Les atteintes à une chaine de production industrielle sont potentiellement beaucoup plus graves que celles d’un système d’information mieux préparé à  faire face à une attaque, La ségrégation des périphériques mobiles (clé USB) en environnement industriel (OT) permet quant à elle de prévenir un danger immédiat. Encadrer strictement l’utilisation de la clé USB dans le cadre professionnel apparait donc être une nécessité vitale pour le système d’information. Sauf à la bannir définitivement, toute organisation devra s’équiper à cette fin d’une solution de décontamination avancée – telles les stations blanches que nous venons d’évoquer – et qui sont  déjà massivement déployées chez les Opérateurs d’Importance Vitale.

Cet article Votre clé USB peut-elle donner l’accès à votre système d’information ? est apparu en premier sur iDNA.

A cela, les managers et les équipes SOC envisagent l’automatisation des process comme solution, et l’on voit déjà les SOAR pointer le bout de leur nez pour répondre à ce besoin. Mais soyons pragmatiques, que voulons-nous automatiser ? L’ouverture de tickets et leur affectation aux équipes concernées ? Les SIEM permettent déjà de s’interfacer avec des outils de ticketing ou ITSM, et proposent généralement des interfaces API pour ceux qui ne seraient pas directement intégrés. L’automatisation d’action de remédiation ? Oui mais laquelle ? Les SIEM proposent déjà de la même façon de réaliser des actions simples de blocages de manière autonome, avec les outils qui le permettent via API. Certes, le SOAR permet d’aller beaucoup plus loin, et de mettre en œuvre des chaines de décision plus complexes, mais avez-vous déjà exploré à fond ce que votre SIEM peut déjà faire de manière native ? Avez-vous la maturité et les équipes pour mener cela à bien ?

Au-delà du traitement de ces alertes, aujourd’hui on retrouve encore et toujours les mêmes règles de détection qui encombrent les équipes. Prenons ce que l’on retrouve encore et toujours, les alertes sur les détections des anti-malwares, ou les attaques de type brutes forces. Dans le cas des premières, est-il utile de les traiter si elles sont bloquées par les outils, qu’elles ne se répètent pas à l’infini sur le même poste ou ne semblent pas atterrir sur une multitude de postes ? Et si l’on parle des attaques brutes forces, est-il utile de s’en inquiéter si le compte est désactivé, le mot de passe a expiré ou si cela ne se finit tout simplement pas par une connexion réussie ? Alors oui, certains me répondront avec les XDR, et leurs capacités de « Machine Learning », voire d’intelligence artificielle.

Pourtant une simple revue de l’efficacité de ces règles de détection, et leur optimisation, permettrait déjà de faire un premier niveau de tri. Cette année encore je me suis retrouvé face à une règle de détection sur des attaques Kerberoast qui se basait, uniquement, sur un seuil de génération de ticket par un seul et même asset, sans tenir compte d’autres marqueurs tels que le type de chiffrement demandé. Il est également possible de mettre en place des règles complexes, basées sur le nombre de détections émises par un asset ou une identité sur un temps donné, et de se servir de cela pour détecter une attaque en cours grâce aux signaux faibles.

Enfin, n’oubliez pas que ces outils se basent sur des évènements générés par d’autres. Et ce point est crucial car l’efficacité de détection des outils de corrélation vient de la qualité de vos logs, de la complétude des informations autant que de leur format.

Voilà, maintenant que tout cela est dit, comment avancer ? Déjà, en vous posant la question de ce que vous souhaitez détecter, quels sont vos risques et attaques redoutées. Avez-vous les outils et les données permettant de suivre cela, est-ce que ces informations remontent dans votre SIEM ? Ensuite, en mesurant les performances, les faux positifs générés par un scénario de détection, les règles de détection qui ne remontent jamais d’incident, etc. N’hésitez pas à tester vos scénarios de détection, et à remettre en cause leur pertinence vis-à-vis des attaques que l’on voit poindre régulièrement.

Les plus chagrins me répondront qu’ils n’ont pas les ressources humaines pour faire tout cela, qu’ils n’arrivent pas à trouver les compétences. Et si cet argument est une réalité qui se pose à l’ensemble du monde de la cybersécurité, pensez-vous réellement que vous trouverez plus de compétence sur les SOAR et les XDR ? Ne vous y trompez pas, il ne s’agit pas uniquement d’intégrer ces solutions, mais également de les faire vivre dans le temps.

Cet article Le SIEM dans tous ses états est apparu en premier sur iDNA.