Dans sa volonté d’accompagner la transformation digitale de ses clients en limitant les risques induits, la pratice Cybersécurité de Wavestone vous propose d’étudier ensemble comment il est possible de réaliser des attaques cyber sur un système d’IA et comment il est possible de s’en prémunir.

Attaquer un système d’IA interne ? (Notre RSSI nous déteste)

Démarche et objectifs

Comme le démontrent les récents travaux sur les systèmes d’IA[1] de l’ENISA[2], ou encore du NIST[3], l’IA est vulnérable à un certain nombre de menaces cyber. Ces menaces peuvent être génériques ou spécifiques et adressent globalement l’ensemble des systèmes d’IA basés sur le Machine Learning (ML).

Pour vérifier la faisabilité de telles menaces, nous avons eu le souhait d’expérimenter les menaces spécifiques de l’Evasion et de l’Oracle sur une de nos applications internes à faible impact : Artistic, un outil de classification des tickets[4] des collaborateurs à destination du support Informatique.

Pour cela, nous nous sommes mis dans la peau d’un utilisateur malveillant qui, ayant connaissance que le traitement des tickets repose sur un algorithme d’Intelligence Artificielle, chercherait à mener des attaques de type Evasion ou Oracle.

Evidemment, les impacts de telles attaques sont très faibles mais notre IA est un super terrain de jeu pour faire des expérimentations.

Présentation de l’application

Architecture de l’application

Attaque par évasion

Présentation de la démarche

Une attaque de type évasion consiste à détourner le fonctionnement de l’intelligence artificielle en lui fournissant des exemples contradictoires (également connus sous le nom de « adversarial example ») afin d’induire des prédictions erronées. Un exemple contradictoire est une instance d’un objet comportant des perturbations intentionnelles sur ses caractéristiques qui amènent un modèle d’apprentissage automatique à faire une fausse prédiction. Ces perturbations peuvent passer facilement inaperçues pour un humain, telle qu’une faute de frappe sur un mot par exemple, et modifier radicalement les données de sortie du modèle.

Dans le cadre de notre exemple, nous allons chercher à construire différents exemples contradictoires en utilisant trois techniques :

• La suppression et le changement de caractères
• Remplacements de mots en utilisant une technique dédiée (Embedding)
• Le changement de la position des mots

Concrètement, ces exemples contradictoires dans notre cas d’usage sont des demandes écrites quelques peu modifiées (cf. l’exemple 1 ci-dessous) qui vont être formulées dans l’outil de ticketing Artistic.

Pour ce faire, nous allons utiliser un outil dédié : TextAttack. TextAttack est un Framework Python permettant de réaliser des attaques par évasion (intéressant pour notre cas), d’entrainer un modèle de NLP avec des exemples contradictoires et faire de l’augmentation de données dans le domaine du NLP.

Résultats

Considérons une phrase classée correctement par notre Intelligence Artificielle avec une forte probabilité. Appliquons à présent le Framework TextAttack et utilisons le pour générer des exemples contradictoires basés sur notre phrase correctement classée.

Nous observons ainsi que des phrases, qui restent (plus ou moins) compréhensibles à un opérateur, perturbent le fonctionnement de l’Intelligence Artificielle au point de mal les classifier. De plus, nous pouvons observer qu’avec une multitude d’exemples contradictoires créés, il est possible de remonter à toutes les catégories de classification et ce avec des taux de précision plus ou moins élevés.

Par extension, sur des Intelligences Artificielles plus critiques, on relève de ces mauvaises prédictions plusieurs problèmes :

• Des atteintes à la sécurité : le modèle en question est compromis et il devient possible aux attaquants d’obtenir des prédications erronées ;
• Une confiance moindre aux systèmes d’IA : une telle attaque diminue la confiance en l’IA et le choix d’adoption de tels modèles, remettant en cause le potentiel d’une telle technologie.

Toutefois, d’après l’ENISA, quelques mesures peuvent être implémentées pour nous prémunir de ce genre d’attaques :

• Définir un modèle plus robuste aux attaques par évasion. Le système d’IA d’Artistic est particulièrement peu robuste à ces attaques et a un fonctionnement très basique (comme nous le verrons par la suite). Un modèle autre modèle aurait certainement été plus résistant aux attaques par évasion.
• Faire de l’adversarial training lors de la phase d’apprentissage du modèle. Cela consiste à ajouter des exemples d’attaques dans les données d’entraînement afin que le modèle améliore sa capacité à classifier correctement des données « étranges ».
• Mettre en place des contrôles sur les données en entrée du modèle pour assurer de la « qualité » des mots saisis par exemple.

Attaque de type Oracle

Définition

Les attaques de type Oracle consistent à étudier des modèles d’IA et tenter d’obtenir des informations sur le modèle en interagissant avec ces derniers par le biais de requête. Contrairement aux attaques par évasion, qui visent à manipuler les données d’entrée d’un modèle d’IA, les attaques par Oracle tentent d’extraire des informations sensibles sur le modèle lui-même et sur les données qu’il a manipulées (ayant servi à l’apprentissage par exemple).

Dans notre cas d’usage, nous cherchons simplement à comprendre le fonctionnement du modèle. Pour ce faire, nous avons cherché à comprendre le comportement du modèle en analysant les couples entrées-sorties fournis grâce à nos exemples contradictoires.

Résultats

En passant par plusieurs essais, l’attaquant peut être capable de déceler la sensibilité du modèle aux changements sur les données d’entrée. Grace à l’exemple ci-dessus, nous observons que l’algorithme utilisé par l’application prédit la classe d’un message en attribuant un score à chaque mot puis détermine la catégorie. En analysant ces résultats divers, l’attaquant peut être en mesure de déduire les vulnérabilités du modèle aux attaques par évasion.

Par extension, sur des Intelligences Artificielles plus critiques, les attaques de type Oracle posent plusieurs problèmes :

• Atteinte à la propriété intellectuelle : comme mentionné, l’attaque de type Oracle peut permettre le vol de l’architecture du modèle, les hyperparamètres, etc. De telles informations peuvent servir pour créer une réplique du modèle.
• Atteintes à la confidentialité des données d’entraînement : cette attaque peut permettre de révéler des informations sensibles sur les données d’entrainement utilisées pour former le modèle, et qui peuvent être confidentielles.

Quelques mesures auraient pu être implémentées pour nous prémunir de ce genre d’attaques :

• Définir un modèle plus robuste aux attaques de type Oracle. Le système d’IA d’Artistic est très basique et est très facile à comprendre.
• [Pour les IA de manière plus large] S’assurer que le modèle respecte la confidentialité différentielle. La confidentialité différentielle est une définition extrêmement forte de la confidentialité qui garantit une limite à ce qu’un attaquant ayant accès aux résultats de l’algorithme peut apprendre sur chaque enregistrement individuel de l’ensemble de données.

S’emparer du sujet aujourd’hui dans votre organisation

Nous observons que même sans connaître précisément les paramètres d’un modèle d’Intelligence Artificielle, il est relativement aisé de mener des attaques de type Evasion ou Oracle.

Dans notre cas d’usage, les impacts sont limités. Toutefois, les conséquences d’une attaque par évasion sur un véhicule autonome ou encore d’une attaque de type Oracle sur un modèle utilisé avec des données de santé sont largement plus graves pour les individus : dégâts physiques dans un cas et atteinte à la vie privée dans l’autre.

Plusieurs de nos clients commencent d’ores et déjà à déployer des premières mesures pour faire face aux risques cyber induits par l’utilisation de système d’IA. Ils font notamment évoluer leur méthodologie d’analyse de risques afin de prendre en compte les menaces montrées ci-dessus et surtout ils mettent en place des contres mesures, lorsque celles-ci sont pertinentes au regard des risques, venant des guides de sécurisation tels que ceux proposés par l’ENISA ou le NIST.

[1] Un système d’intelligence artificielle, dans la proposition législative de l’AI Act, est défini de la façon suivante : « un logiciel développé à l’aide d’une ou plusieurs des techniques et approches énumérées à l’annexe I de la proposition et capable, pour un ensemble donné d’objectifs définis par l’homme, de générer des résultats tels que des contenus, des prédictions, des recommandations ou des décisions influençant les environnements avec lesquels ils interagissent. » Dans notre article, nous considérons que les systèmes d’IA ont été entraînés via le Machine Learning, comme cela est généralement le cas sur les cas d’usage modernes tels que ChatGPT.

[2] https://www.enisa.europa.eu/publications/securing-machine-learning-algorithms

[3] https://csrc.nist.gov/publications/detail/white-paper/2023/03/08/adversarial-machine-learning-taxonomy-and-terminology/draft

[4] Un ticket représente une suite de mots (autrement dit, une phrase) dans laquelle le collaborateur exprime son besoin.

Cet article Attaquer une IA ? Un exemple concret ! est apparu en premier sur RiskInsight.

Mais comment renforcer la détection d’une intrusion dans son entreprise ? Les tests d’intrusion permettent d’évaluer le niveau de protection/durcissement sur un périmètre précis et encadré, qui ne représentent pas forcement la réalité vécue lors de nos réponses à incidents. Les exercices de gestion de crise permettent quant à eux d’améliorer la réaction… L’opération Red Team peut être un bon élément de réponse, permettant ainsi d’évaluer (et donc d’améliorer) de bout en bout le système d’informations ainsi que les capacités de détection.

Qu’est-ce qu’une opération Red Team ? C’est tout simplement une attaque réaliste mais sans les effets négatifs. L’objectif est de déterminer, aujourd’hui, quelles sont les actions malveillantes qu’un groupe d’attaquants peut réaliser sur mon entreprise et à quel moment suis-je capable de les détecter ?

Dans cet article, nous verrons quelles sont les étapes clefs d’une telle opération et comment s’assurer d’en récolter les fruits.

 

ETAPE 1 : DEFINIR L’EQUIPE CŒUR ET IDENTIFIER LE TROPHEE

Définir une équipe de contrôle restreinte est primordiale pour limiter la fuite d’informations vers la Blue Team (équipe de détection, i.e. SOC), fluidifier les communications et faciliter la prise de décision par le client. L’équipe de contrôle devra donc être séparée clairement de la Blue Team. Souvent le choix se porte vers le CISO ou un représentant du COMEX, avec qui il faudra fixer les limites du périmètre et du mode opératoire (les plus larges possibles), pour éviter tout incident malencontreux !

« That’s out of scope » – Said no attacker ever

Ensuite, une particularité d’une opération Red Team est de définir un « trophée », c’est la cible de l’opération. En effet, un attaquant est souvent motivé par un objectif (gain, destruction, espionnage, …) et il convient de calquer les objectifs de la Red Team dessus. La Red Team a en général déjà quelques bonnes idées mais les meilleurs trophées (i.e l’impact le plus fort lors de la restitution) sont étroitement liées aux enjeux business de l’entreprise ainsi que son actualité.

La cible doit être les scénarios qui font le plus froid dans le dos des dirigeants : une prise de contrôle à distance de l’infrastructure SWIFT ? Une compromission des terminaux de paiement ? La fuite de la liste des clients VIP ? Les positions prises ces derniers mois à l’étranger ? Les idées peuvent être nombreuses, mais il est nécessaire de se restreindre à une cible ou deux pour garder en visibilité ce qui est le plus critique. Il sera toujours possible d’identifier un autre trophée pour la prochaine opération : il est même conseillé de modifier les trophées d’une année sur l’autre afin de tester des pans de système d’information différents.

Lors de nos dernières interventions, des COMEX portent leur choix sur des scénarios ayant déjà eu lieu lors de réelles cyberattaques qu’ils avaient subies. Cela leur permet aussi d’évaluer l’efficacité des nouveaux moyens de sécurité mis en œuvre.

 

ETAPE 2 : PREPARER ET LANCER L’ASSAUT EN MELANT EFFICACITE ET FURTIVITE

La crédibilité de l’attaque est un des facteurs clef du succès de l’opération, notamment pour la phase de restitution. Une fois le trophée arrêté : nous construisons une démarche basée sur les techniques utilisées par les groupes d’attaquants.

C’est à ce moment que les retours terrains sont particulièrement utiles ! Chez Wavestone, nous nous appuyons fortement sur notre équipe de réponse à incident (CERT-W) et sa capacité de Threat Intelligence pour identifier les dernières tendances, sur le savoir-faire technique de notre équipe d’audit ainsi que la créativité de notre équipe CTF (Capture The Flag).

Ainsi, la Red Team utilisera l’ensemble des moyens possibles et nécessaires afin de pénétrer sur le SI (campagne de phishing, phishing téléphonique, intrusion physique, compromission de composants exposés sur internet…) et ensuite rebondir vers le trophée. Cette phase est la plus créative et passionnante pour les auditeurs (comme pour les attaquants), et peut potentiellement durer plusieurs semaines, à l’image des cyberattaques les plus médiatisées.

Toutefois, le maître-mot doit rester : « furtivité » ! En effet, la moindre détection par la Blue Team peut totalement faire échouer ou reculer l’opération. Une attention particulière doit être portée sur des outils et infrastructures d’attaque sur mesure pour ne pas affoler les systèmes de détection. Pour le premier point, nous avons développé en interne l’outil Abaddon, désormais open-source, et permettant de construire et déployer en quelques clics les infrastructures nécessaires.

 

Deux questions reviennent systématiquement concernant le déroulement d’une opération Red Team.

La première « Que faire en cas de détection ? ». Qu’une action se fasse détecter peut arriver au cours d’une opération Red Team : une bonne règle de corrélation du SIEM, un utilisateur averti qui partage un comportement anormal, etc.. Tout d’abord, dans l’organisation de base l’équipe de contrôle doit superviser les incidents au sein du SOC afin d’éviter une « sur-escalade » en crise d’un incident en relation avec le Red Team. La cellule de contrôle pourra ainsi demander un rapport à la Blue Team (résumé, comportement détecté, timeline des actions, actions de remédiation, …) et définir ensuite le scénario de reprise avec la Red Team : ne pas tenir compte de la détection car elle est trop ancienne, repartir de l’avant dernier asset compromis qui n’a pas été détecté, etc. De plus, le travail deviendra plus compliqué pour la Red Team qui devra par exemple changer totalement son infrastructure C2 et dorénavant réussir à tromper une Blue Team en alerte.

La seconde « Si les le(s) trophée(s) sont obtenues très rapidement, que faire ?». Imaginons le pire des scénarios : l’administrateur applicatif du trophée se fait piégé par un mail de phishing et nous permet de prendre le contrôle complet de l’application dès le début de l’opération (Tout le monde peut faire une erreur). Le point sera partagé avec l’équipe de contrôle et la marche à suivre sera définie conjointement : ajouter des trophées pour tester la robustesse d’un autre périmètre, repartir de zéro et identifier un autre chemin de compromission, … Cet exemple un peu caricatural est là pour rappeler que l’objectif d’une opération Red Team est d’améliorer durablement le niveau de sécurité via l’entrainement de la Blue Team et non juste l’obtention d’un trophée.

 

ETAPE 3 : RESTITUER UNE REPONSE CLAIRE SUR UN RISQUE METIER CRITIQUE

L’objectif reste d’apporter aux commanditaires une vision claire sur l’état de sécurité réel de leur SI, sur les scénarios d’attaque permettant d’accéder à leurs ressources critiques (identifiées comme « trophées » de l’opération), ainsi que sur leurs capacités de détection. Tout simplement, l’opération Red Team doit permettre de répondre à la question « Le trophée est-il accessible et avec quel niveau d’expertise ? ». Il faut cependant retenir que l’opération Red Team va mettre en valeur un chemin exploitable qui ne sera peut-être pas le seul, ni le plus simple.

Dès lors, nous restituons aux parties prenantes (CISO, SOC, COMEX…) avec une synthèse haut-niveau afin de présenter les conclusions de l’opération Red Team, le scénario d’attaque suivi et les chantiers les plus prioritaires. Les résultats sont généralement comparés à des profils type d’attaquants (Maze, REvil/Sodinoki…) sur le référentiel MITRE ATT&CK pour être plus parlants.

 

Dans un second temps, il faudra évidemment restituer en détails à la Blue Team les étapes techniques de l’opération, en vue de définir des axes de progrès sur la détection.

“If we win, we lose » Said a good red teamer

Cet article Comment tirer parti d’une opération Red Team ? est apparu en premier sur RiskInsight.

Wavestone possède depuis plusieurs années des démonstrateurs sur la sécurité des systèmes industriels. En particulier, vous avez peut-être déjà rencontré notre maquette de train et bras robotiques avec un capture the Flag physique !

Cette maquette de train est principalement utilisée pour des workshops dans des conférences de sécurité (Black Hat Europe 2014, BruCON 2015 & 2017, DEF CON 2016 & 2018, Bsides LV, etc.), ou des cours en école d’ingénieurs (EPITA, Mines, ESIEA, Télécom Sud Paris, etc.).

En plus des conférences et des cours en école, nous avons tourné cet été une vidéo de la maquette afin de présenter les principales attaques sur les systèmes industriels, et en particulier l’insécurité des protocoles industriels.

La première partie de la vidéo rappelle ce que sont les systèmes industriels et présente les principales familles de risques et vulnérabilités sur ces systèmes :

• Des défauts d’organisation et de sensibilisation des acteurs
• L’absence de supervision de sécurité
• L’absence de mécanismes de sécurité dans les équipements et les protocoles
• La non-maitrise des sous-traitants et de la maintenance
• La ségrégation inexistante des réseaux
• L’absence de patch management

La seconde partie de la vidéo rentre plus dans la pratique, avec tout d’abord la présentation de la maquette : les automates, la supervision ainsi que le fonctionnement général.
L’objectif est d’attaquer les automates : il faut arrêter le train et attraper son drapeau à l’aide des bras robotiques.
Différents outils de lecture et écriture de registres sont alors présentés :

• S7getDB pour les automates Siemens
• Mbtget pour les automates Schneider

Enfin, nous concluons sur le fait qu’il est relativement
facile de piloter les automates de manière illégitime avec des outils
implémentant les protocoles de communication industriel. Par ailleurs, bien que
de nouvelles gammes d’automates, plus robustes, existent chez certains
constructeurs, la première étape de sécurisation consiste à cloisonner et
filtrer ses réseaux industriels

• Outils pour la lecture et l’écriture de registres (Modbus ou S7)
  • Mbtget – outil perl pour les requêtes de lecture/écriture Modbus https://github.com/sourceperl/mbtget
  • S7get et S7getDB – outil python pour les requêtes de lecture/écriture sur les automates Siemens développé par Wavestone : https://github.com/wavestone-cdt/s7-get
• Modbusclient – module Metasploit pour les requêtes de lecture/écriture Modbus (contribution Wavestone) : https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/scanner/scada/modbusclient.rb
• Outils utilisant la fonction 90 de Modbus pour l’administration (un article détaillé est par ailleurs disponible ici : https://www.securityinsider-wavestone.com/2018/02/fun-with-modbus-0x5a.html
• Modicon_command_CTv2 – module Metasploit pour arrêter/démarrer une CPU (contribution Wavestone) : https://github.com/wavestone-cdt/fun-with-modbus-0x5a/blob/master/modicon_command_CTv2.rb
• Modicon_stux_transfer_ASO – module Metasploit pour télécharger le programme d’un automate (contribution Wavestone) : https://github.com/wavestone-cdt/fun-with-modbus-0x5a/blob/master/modicon_stux_transfer_ASO.rb
• Schneider – module pour forcer les entrées / sorties d’un automate développé par Wavestone : https://github.com/wavestone-cdt/fun-with-modbus-0x5a/blob/master/schneider.rb

Cet article Pentesting ICS 101 est apparu en premier sur RiskInsight.

Adresser le besoin de savoir et le besoin de rassurance

Soutenue par l’augmentation du nombre d’incidents et d’attaques sur les systèmes d’information, la crise cyber s’est installée dans l’espace public. La démocratisation de son champ lexical est ainsi un indicateur marquant de la place médiatique qu’a pris ce sujet. Fuite de données, ransomware, hacktiviste, DDoS, phishing, lanceur d’alerte, ces mots ont quitté les salles serveurs et les blogs spécialisés pour se faire une place dans les colonnes des journaux nationaux et dans le vocabulaire de la plupart des français. La crise cyber n’est plus un simple incident qualité silencieusement traité en interne et est devenue un événement qui suscite l’intérêt de tous les publics entraînant mécaniquement dans son sillage une crise de nature communicationnelle. Cependant, si la popularité nouvelle de cette thématique se décline logiquement dans l’accroissement de la couverture de ces crises, d’autres éléments justifient l’augmentation significative des sollicitations, qu’elles soient internes ou externes à l’organisation en crise.

Lorsque la crise cyber a pour conséquence la fuite d’une donnée par exemple, ce n’est plus seulement le sujet de la crise qui est médiatique, mais son objet même. De fait, lorsque la donnée fuite ou est volée, sa nature intrigue et suscite la curiosité, qu’il s’agisse d’une donnée personnelle, d’un secret d’état ou simplement d’une conversation privée. Cette mécanique engendre logiquement pour de nombreux publics tant le besoin de connaître l’inconnu, que de s’assurer de ne pas en être la victime. Ces deux besoins primaires de curiosité et de réassurance constituent les moteurs essentiels de la couverture médiatique et plus généralement incite le consommateur d’information, le partenaire, le client à combler ce besoin et à chercher à obtenir cette information. La même logique suppose que la source de cette information, en l’occurrence, le détenteur légitime de cette donnée adresse ces requêtes et communique sur l’incident.

Que ce soient des évènements stratégiques tels que des élections présidentielles ou des conversations privées du quotidiens via des médias digitaux qui sont compromis, l’effet médiatique de la crise se voit amplifié par le caractère extraordinaire de l’événement. Cela résulte tant de sa supposée impossibilité que de la confiance que le public lui confère. La rupture soudaine de la confiance placée en ces « institutions » d’importances majeures, érigées en bonne place dans une version 2.0 de la pyramide de Maslow, génère alors elle aussi l’intérêt et le besoin de savoir, traduits dans une explosion du nombre des requêtes et des demandes d’information à l’organisation en crise.

figure 1. Exemple de pyramide de Maslow

Guerre de communication entre l’attaquant et le communicant

La communication de crise cyber est ainsi un exercice particulier de par le sujet qu’elle traite, mais aussi de par la nature des acteurs en présence. De fait, quand des sommes incommensurables d’argent sont dérobées sans coup férir ou que des institutions tombent sous les attaques d’hacktivistes « citoyens », l’opinion voue une sympathie relative à l’encontre du héros moderne qu’est le pirate romanesque, le hacker hors la loi, le justicier anonyme.

Ce personnage public, conscient de son image et des codes du monde communicationnel, saura bien entendu se jouer de cet environnement. Ainsi, les méthodes mêmes des attaquants renforcent la place centrale de la communication dans la gestion des crises cyber. Les attaques aux motifs politiques, idéologiques et militants ne se limitent plus à la compromission d’un système mais envoient un message dont la publicité doit être maximale.

Cette appropriation manifeste des méthodes propres aux activistes s’illustre de plusieurs manières : Annonce d’un DDoS en amont, défacement d’un site internet, publication au fur et à mesure de preuves d’un vol sur les réseaux sociaux, diffusion d’informations telles que des échanges de conversations mails privés compromettants… Si les attaquants ont appris à maximiser l’impact réputationnel des attaques, ils utilisent aussi ce levier afin de perturber la gestion de crise de leur cible et générer un bruit qui leur fera gagner du temps une fois leur attaque découverte. Alors qu’un des facteurs clefs du succès d’une gestion de crise est la reprise en main du rythme de celle-ci et de la publication de nouveaux éléments, la crise cyber laisse inéluctablement ce pouvoir à un tiers malveillant.

Ce tiers peut aussi, si la compromission est profonde, altérer les moyens de communication de l’entreprise. Alors qu’elle tente de répondre à la nécessité de s’exprimer urgemment et largement, cette entrave peut lourdement affecter la fluidité de sa communication. Sans messagerie mail, comment diffuser un message à ses employés ? Sans réseaux sociaux, comment être au plus proche de sa communauté et répondre à ses questions ?

Restaurer le rapport de confiance par la communication

Fasciné par les attaquants et l’ampleur des attaques, le grand public n’en demeure pas moins intransigeant à une heure où la confiance et la donnée constituent la valeur même d’une entreprise. Intrinsèquement, la préservation de la première suppose la protection de la seconde. Lorsque l’organisation faillit à cet objectif, la communication de crise est seule en mesure de restaurer ce rapport de confiance duquel dépend l’avenir de la relation avec clients et partenaires qui continueront ou non à confier la garde de leurs données ou la gestion de leurs outils, ainsi que leurs services à une organisation.

Cette exigence de confiance entraine par ailleurs, lorsqu’elle est brisée, la recherche et la désignation rapide d’un responsable. Bien que la réalité des faits soit bien plus complexe, le grand public aura aisément tendance à supposer que les attaques informatiques sont rendues possibles par l’exploitation d’une vulnérabilité et donc d’une faute.

Une fuite de données, n’est ainsi pas uniquement perçue comme une attaque perpétuée par un tiers malintentionné, mais aussi comme une négligence dans la défense de l’entreprise victime du vol. Cette dernière se voit automatiquement désignée comme responsable et sa réputation en est logiquement impactée. Alors même que les attaquants se professionnalisent, que les attaques se complexifient et que l’absence de vulnérabilité est un mythe, la cyberattaque est aujourd’hui un sujet de gestion et de communication de crise à part entière. Du fait de son impact potentiel sur le quotidien du grand public et donc sa nature médiatique, elle force la victime, considérée comme co-responsable de sa perte, à s’exprimer.

Réaliser l’effort de simplicité pour mieux communiquer face à la crise

Au-delà de la définition d’une stratégie claire, partagée et opportune, la gestion de crise cyber avec son rythme particulier et les entraves causées par les attaquants doit être accompagnée d’une communication particulière qui suppose enfin un dernier travail : l’effort de simplicité.

Face à la crise cyber et comme pour tout type de crise, communiquer suppose d’être en mesure de traduire les évènements subis et les actions correctives menées en impacts clairs et de porter ce discours de façon cohérente. Bien entendu, la complexité des termes et des rouages d’une crise cyber rend cet exercice délicat et constitue une autre spécificité à prendre en considération.

Dans ce cadre, par sa capacité à traduire la cause technique en conséquence métier et plus généralement par son pouvoir vulgarisateur, le rôle du RSSI et de ses équipes est central. En situation nominale comme en temps de crise, la mission du RSSI est de porter cet effort de traduction des faits et des composantes techniques non seulement en impacts métiers mais en impacts compréhensibles et convaincants pour des publics diversifiés et non experts. Il ou elle peut ainsi être amené à concevoir, voire à porter les éléments de langage de communication de crise de la même manière qu’un représentant des ressources humaines sera exposé lors d’une crise sociale.

Sans présupposer de son exposition au journal télévisé d’une grande chaine de télévision, la parole des experts SI sera attendue sur les réseaux sociaux, sur les réseaux professionnels, dans la presse spécialisée ou en interne. En communication de crise, chacun est responsable de tous et tout un chacun doit s’y préparer.

Ainsi, le sujet cyber porte une puissance médiatique qui lui est propre ; dont la conséquence immédiate est l’augmentation considérable des attentes et des demandes d’informer émanant des différentes directions d’une organisation ainsi que du public externe. Si l’imminence de l’occurrence d’un incident SI implique une défense spécifique et une planification de la continuité des opérations, elle exige aussi l’anticipation de ces requêtes et une préparation active à cet effort global de communication.

Cet article La crise cyber, un sujet médiatique à part entière est apparu en premier sur RiskInsight.

Des attaques dont les objectifs sont souvent difficiles à cerner

L’actualité le montre trop régulièrement, les actes cybercriminels se multiplient et visent tous types d’organisation. Certains sont revendiqués et leurs objectifs sont rapidement connus. C’est le cas pas exemple de l’attaque visant le site Ashley Madison où les motivations sont explicites.

Mais dans la plupart des cas, les objectifs de l’attaquant sont beaucoup plus difficiles à identifier ! Il est pourtant crucial de le faire pour pouvoir réagir au mieux et protéger rapidement ce qui n’a pas encore été touché par l’attaque.

Une des clés pour mieux comprendre une attaque consiste à exploiter les erreurs des attaquants. En effet, malgré leur niveau de compétences potentiellement élevé, les pirates restent des humains et commettent souvent des erreurs. Des fautes qu’il est possible d’exploiter pour mieux comprendre l’attaque et la contrer, mais aussi pour identifier ceux à son origine.

Utiliser les erreurs des attaquants pour mieux les comprendre

Le cas récent d’Ashley Madison semble être un bon exemple, même s’il faudra attendre les investigations complètes pour confirmer tous les éléments. Les attaquants auraient diffusé les données volées via BitTorrent en utilisant un serveur loué chez un hébergeur aux Pays Bas. Ils auraient cependant oublié de sécuriser ce serveur, en particulier ils n’ont pas mis de mot de passe sur les interfaces d’administration web. Même si cela ne permet pas de les identifier directement, il s’agit d’une piste de premier choix pour les forces de l’ordre en charge des investigations. Il faut cependant rester prudent car cela peut aussi être une forme de diversion réalisée par les attaquants. Affaire à suivre !

Autre exemple, le cas « Red October ». C’est l’affaire d’une vaste opération de cyber espionnage qui a commencé en mai 2007 et qui a été découverte par le cabinet Kaspersky quelques années plus tard. Le cabinet a réussi à identifier, bloquer et neutraliser le logiciel malveillant en utilisant une faille de l’attaque. En effet, les noms de domaines pour les serveurs d’exfiltration qui étaient utilisés dans le code malveillant n’avaient pas été réservés par les attaquants. Cela a permis à Kaspersky de simuler un de ces serveurs et de voir qui était infecté et quelles données étaient capturées.

Parfois, ces erreurs permettent même d’identifier les auteurs de l’attaque, comme ce fut le cas avec la traque de la personne derrière le malware PlugX.

Nos consultants ont d’ailleurs eux aussi rencontré ce genre de situation dans le cadre d’une attaque ciblée chez un de nos clients. Les pirates avaient en effet « oublié » la présence d’un keylogger sur les serveurs internes utilisés pour l’exfiltration des données, ce qui a permis à nos experts d’identifier quelles données étaient ciblées et où elles étaient envoyées. Nous avons même pu récupérer le login et le mot de passe utilisés par les attaquants. Le concept de « l’arroseur arrosé » remis au goût du jour.

Savoir tirer parti de ces informations pour mieux gérer la crise

Les informations obtenues grâce à ces erreurs sont très précieuses, elles permettent ensuite d’adapter la réponse à l’incident. D’autant plus que les attaquants utilisent parfois des mécanismes de diversion « bruyants » (redémarrage de machines, effacement de fichiers, forte activité CPU, voir déni de service…) afin de détourner l’attention des vrais données qu’ils visent. Une compréhension « métier » des objectifs de l’attaque permet d’éviter de se focaliser sur ces pièges.
Il est même souvent intéressant de laisser l’attaque se dérouler pour mieux la comprendre.

Les réflexes face aux incidents de sécurité « classiques » (déployer des signatures antivirales, réinstaller des serveurs…) sont donc aujourd’hui largement révolus. Il faut adopter une approche dynamique de la crise, s’intéresser à son objectif métier et utiliser les erreurs des attaquants pour être plus pertinent, en pouvant même envisager des réponses « actives » à l’attaque. Un challenge pour les équipes de réponses à incidents, qui doivent adapter leurs méthodologies et leurs réflexes, mais un objectif crucial pour lutter contre ces attaques

Cet article Cybercriminalité : savoir profiter des erreurs des attaquants est apparu en premier sur RiskInsight.

La demande explosant, le besoin d’industrialisation se fait ressentir. Cette situation aboutit « naturellement » à la création d’offres de « Hack As A Service ». Conçu sur le modèle des services cloud, elle consiste à disposer des services de hacking, simple d’accès, forfaitaire et dont les coûts sont maîtrisés. Balbutiant depuis plusieurs années, ce marché  se développe et se structure de plus en plus.Voici un florilège des évolutions récentes qui montrent indubitablement cette tendance de fond.

Remarque : afin d’éviter toute mise en avant de sites offrant ce type de biens ou de prestations, aucun nom ne sera cité directement.

La fourniture de logiciels d’attaques performantes

Pour des tarifs « raisonnables », tournant généralement entre 500$ et 4000$, il est facile de se procurer des kits de logiciels, comme Poison Ivy ou encore Zeus / Spyeye, permettant de mener soi-même des attaques. En plus de fournir des outils permettant de trouver des mots de passe, rebondir sur le réseau et faciliter l’exfiltration de données, ces kits fournissent tout le nécessaire pour assurer la discrétion et l’anonymisation des attaquants. Grâce à ces outils, plus besoin d’être un professionnel du domaine pour échapper aux protections classiques tels que l’antivirus, ces kits sont souvent vendus avec des mises à jour régulière pour conserver leur avance.

La réalisation d’actions malicieuses « au forfait »

De plus en plus fréquentes et de moins en moins chères, ces offres sont parmi les plus simples à utiliser. En effet, aucune connaissance n’est requise. Les prestations sont variées et peuvent aller d’un simple déni de service à un vol de données sensibles en passant par du défacement de sites web. Par exemple, hacker un compte Gmail se chiffre autour de 400$ . Le paiement peut lui aussi être anonyme en passant par le principe de monnaies virtuelles encore peu encadré aujourd’hui.

Le recel d‘informations personnelles ou bancaires

Pourquoi attaquer quand les informations convoitées sont d’ores et déjà exfiltrées ? C’est le principe des plates-formes de recel de données personnelles et bancaires. Le prix des cartes de crédit, suivant la qualité des données et le type de carte y évolue de quelques dollars à plusieurs centaines dans certains cas. Des mécanismes de type « try & buy » permettent d’ailleurs de vérifier aisément la qualité des données. Tout comme LeBoncoin ou eBay, ces places de marché permettent la vente de ces informations. D’autres données peuvent y être vendues, comme par exemple celles à caractère personnel (adresses numéros de téléphone, etc.) qui peuvent s’y échanger pour pas moins de 25 centimes . Ces trafics seraient à l’origine d’un rendement financier supérieur à celui du trafic de drogue en Russie.

La vente d’exploit zero-day

Ce marché est encore limité car les prix et la capacité à exploiter les données d’un exploit nécessitent des compétences et des moyens particuliers. Cependant, il s’agit d’une arme imparable pour pénétrer les réseaux et bien utiliser ces exploits devient vite très rentable. Les prix oscillent entre 5 000 $ pour des exploits simples, visant par exemple Adobe Reader et 250 000 $ pour des attaques visant les plateformes mobiles, l’iOS en particulier.

Que retenir de la démocratisation de ce marché ?

La création de ces nouveaux services montre explicitement qu’il ne faut plus être un attaquant chevronné, disposer de contacts dans le milieu ou encore avoir d’importants moyens financiers pour lancer une attaque. La probabilité d’être visé augmente donc aussi rapidement que les services se démocratisent et que les prix baissent.

Ces exemples peuvent être d’intéressantes pistes pour sensibiliser des équipes trop réticentes ou encore trop naïve sur les moyens nécessaires pour attaquer une entreprise, ses collaborateurs et ses clients !

[Article rédigé en collaboration avec Xavier Paquin]

Cet article Le Hack As A Service (HaaS), un marché florissant ! est apparu en premier sur RiskInsight.

Ce nouveau cas est en ligne avec ce que nous observons actuellement de manière plus globale et confirme deux grandes tendances : l’attaque a lieu en période de faiblesse du système d’information et la compromission des systèmes centraux est quasi systématique.

 Attaquer pendant une période de faiblesse

Le cas de l’Élysée montre que les attaquants savent tirer profit de l’actualité de leur cible. L’attaque de l’Élysée a eu lieu entre les deux tours, pendant une période de changement pour cette structure et par conséquent moment privilégié pour s’installer et se « cacher » dans le SI avant l’arrivée du nouvel occupant.

Il est courant pour les attaquants de viser les périodes de faiblesse des organisations. Une majorité d’attaque se déroule le week-end ou pendant les heures non ouvrées. Aujourd’hui la plupart des organisations ne disposent ni des moyens ni des équipes pour assurer un tel niveau de  protection et de surveillance. Et les attaquants le savent !

 Compromettre les systèmes centraux

On estime souvent qu’il faut protéger en priorité les serveurs métiers les plus critiques. Les attaques récentes montrent cependant que ce sont bien souvent les systèmes centraux de gestion du SI les cibles initiales des attaquants. Nous avons observé une majorité d’attaques sur l’Active Directory mais également sur d’autres éléments  tels que la télédistribution. Ces systèmes sont utilisés pour prendre le contrôle de l’ensemble du SI puis par rebond d’accéder aux serveurs métiers et aux précieuses informations qu’ils contiennent. Prendre pied à ce niveau autorise également une installation dans la durée et une capacité d’action sur l’ensemble des postes de travail de l’entreprise.

 Rester sur ses gardes et renforcer les processus d’administration

L’évolution des menaces nécessite de reposer certains fondamentaux de la protection. Les équipes sécurité doivent aujourd’hui se doter de moyens pour surveiller le SI et agir 24h sur 24. Si ce n’est possible pour les équipes internes, le recours à un service tiers couplé à une organisation d’astreinte permet de répondre au besoin. Cette surveillance, qui lorsqu’elle existe est souvent centrée sur la périphérie du réseau, doit se réorganiser pour ajouter les systèmes métiers sensibles et les services centraux.

Mais attention : la surveillance ne fait pas tout. Il est nécessaire d’éviter la compromission initiale et sur le volet des systèmes centraux, il reste beaucoup à faire ! En effet, les pratiques d’administration sont souvent génératrices de risques : multiplication des comptes administrateurs et des serveurs, utilisation de poste d’administration pour des usages personnels (messagerie, surf internet…), authentification simple et mot de passe partagé… Un audit sur ce périmètre révèle souvent bien des mauvaises surprises et nécessite d’ajouter une rigueur nécessaire vue la criticité des systèmes manipulés pour l’organisation.

Les attaques se suivent et bien souvent se ressemblent. Il est maintenant grand temps d’agir sur les zones les plus à risque et les retours d’expériences montre clairement où elles se trouvent !

Cet article Attaque du SI de l’Elysée : la confirmation de nouvelles tendances en matière de cybercriminalité ? est apparu en premier sur RiskInsight.

Tout d’abord, les attaques ne visent plus uniquement les entités gouvernementales ou leurs sous-traitants et leurs fameux « secret défense ». Les entreprises sont aujourd’hui la cible, soit pour les données de leurs clients, soit pour leurs propres données (stratégie, R&D, accords commerciaux…). Le phénomène est mondial et la France est concernée, même si cela est moins visible. Tous les secteurs d’activités sont touchés sans distinction.

Mais au-delà de ce buzz médiatique, que retenir de l’évolution de la sécurité de l’information sur ces 12 derniers mois ? Et que doit répondre le RSSI à sa direction générale qui l’interroge de plus en plus fréquemment sur ces affaires ?

Diffuses, opportunistes ou ciblées : savoir reconnaître les attaques

L’analyse des évènements récents fait ressortir trois différents types d’attaques. La première catégorie, « historique », correspond aux habituelles infections virales ou encore au spam. Il s’agit d’attaques diffuses. Ne visant pas une organisation en particulier, ces attaques vont avoir un effet néfaste sur le SI : déni de service, perte de données utilisateurs…

Ces attaques sont souvent simples à éviter et simples à juguler. Elles ont marqué les entreprises dès les années 2000 pour connaître leur dernière itération majeure avec Conficker en 2008. Celles-ci ne seront pas abordées dans la suite de l’article.

La deuxième catégorie, l’attaque opportuniste, est à but lucratif ou idéologique. Elle vise soit à capturer de l’information facilement monnayable (données des clients, données de cartes bancaires, etc.), soit à avoir un effet médiatique important (déni de service distribué ou defacement de sites web publics, vols de données lambda ensuite publiées sur internet, etc.). Elle ne relève souvent pas d’un haut niveau de technicité et ses auteurs ne cherchent pas à nuire à tout prix à une organisation donnée. Aussi, si l’une est plus sécurisée qu’une autre, ils passeront leur chemin pour se jeter sur la proie la plus facile. Ce scénario est également majoritairement vrai pour les attaques « idéologiques ». Il s’agit pour des groupes comme Lulzsec ou Anonymous de capturer, là où c’est facile, des données perçues comme sensibles et de les rendre publiques. La quasi-totalité de leurs attaques ont été rendues possibles par des manques criants de sécurité et des failles extrêmement simples dans les systèmes des organisations visées.

La troisième catégorie correspond à l’attaque ciblée. Celle-ci vise des informations sensibles et précises dans l’organisation. Ses auteurs sont mandatés pour viser une entité en particulier avec un objectif clair. Ils disposent de temps pour comprendre et analyser l’organisation, préparent des scénarios d’attaques et utilisent tous les moyens à leur disposition, techniques comme humains, internes comme externes, simples comme complexes, afin d’atteindre leur but. Le niveau de technicité et les moyens disponibles s’élèvent drastiquement, tout comme les enjeux. La communauté sécurité évoque ainsi le terme APT ou Advanced Persistent Threat pour décrire ces menaces avancées et persistantes. Google ou RSA en ont été victimes. De nombreux autres cas ont été recensés, y compris en France. Les attaques les plus courantes reposent sur des emails piégés émis à destination de personnes clés (spear-phishing), ou encore des attaques sur des plate-formes externes (site web) permettant ensuite des rebonds multiples sur le réseau interne pour atteindre les données de l’organisation visée.

Après cette entrée en matière, deux autres tribunes vont venir compléter l’analyse.

Tribune n°2

Tribune n°3

Cet article Nouvelles menaces externes et attaques ciblées : quelle stratégie pour le RSSI ? est apparu en premier sur RiskInsight.