Notre vision du produit : une solution aux multiples fonctionnalités

Description

Une sonde OT est un équipement, virtuel ou physique, connecté au système d’information afin de le cartographier et de le surveiller. Elle se compose de capteurs répartis dans le réseau pour collecter les données et d’un équipement central pour corréler ces données.

Une sonde se caractérise par :

• Son mode de fonctionnement ;
• Le positionnement de ses composants ;
• Ses méthodes de détection d’attaque ;
• Son bouquet de fonctionnalités.

L’illustration ci-dessous fournit plus de détails sur chacun de ces items :

Figure 1 : Caractéristiques principales d’une sonde OT

Fonctionnalités principales

Les fonctionnalités de ces sondes OT sont essentielles pour leurs utilisateurs. L’illustration ci-dessous présente un résumé des principales fonctionnalités identifiées :

Figure 2 : Fonctionnalités principales d’une sonde OT

Des fonctionnalités plus avancées apparaissent également sur certains produits telles que le management centralisé de plusieurs sites, la fourniture de guides d’investigation, la recherche de vulnérabilité… D’après nos observations, les solutions du marché tendent vers les mêmes objectifs en termes structurels et fonctionnels. Les différences apparaissent plutôt au niveau de l’intégration globale de la sonde aux offres des fournisseurs.

Notre vision du marché : un marché en cours de consolidation

Des acteurs nombreux et variés

Nos études nous ont permis de mettre en avant un peu plus d’une vingtaine d’acteurs aux profils divers sur le marché des sondes OT. Sur les cinq dernières années, des acteurs sont apparus, d’autres ont disparu, des partenariats se sont construits et les solutions ont continué d’évoluer. Tous ces éléments indiquent un marché encore en cours de consolidation.

Figure 3 : Notre connaissance du marché

Des acteurs qui adoptent des approches différentes

Comme on peut s’y attendre d’un marché si varié, différentes approches se dégagent concernant le modèle de vente. Certains acteurs mettent plus l’accent sur leur produit en tant que tel, tandis que d’autres soulignent son intégration dans leurs catalogues de services (threat intelligence, SOC, CSIRT…) ou de produits complémentaires. Ces approches influent naturellement sur le contact entre les acteurs et leurs clients : plus l’offre mettra en avant un service plus l’acteur cherchera à avoir un contact direct avec son client.

Notre vision du terrain : un besoin de maturité

Nos retours

Au départ au moins, nous recommandons de se focaliser sur les sites et process critiques pour des raisons d’économies de temps, de finances et de compétences. De plus, afin de proposer une détection comportementale pertinente, les sondes nécessitent un temps d’apprentissage non négligeable dépendant du site sur lequel elles sont déployées (identification des faux-positifs, faux-négatifs, accumulation de données pour l’apprentissage…). A ce temps s’ajoutent d’importants besoins en ressources humaines, lors de cette phase d’apprentissage, mais aussi plus tard lors de l’utilisation quotidienne du produit (gestion des alertes essentiellement). Il sera aussi important de mettre en lien les équipes de gestion de la sonde et les équipes de réponses aux incidents afin de traiter les incidents avérés détectés par la sonde.

En amont du déploiement, le positionnement des sondes est à étudier. En effet, il sera à la fois la clef d’une cartographie complète et d’une surface de détection optimale. Ces premières réflexions doivent adresser des points importants tels que la compatibilité matérielle (des switches par exemple) avec les sondes et l’architecture du site (dont peut dépendre le nombre de sondes). En plus de fournir un inventaire en temps réel, la cartographie peut aider à implémenter ou à revoir la segmentation du réseau, étape indispensable à un projet de sécurisation. La phase de qualification doit aussi permettre de vérifier que la sonde choisie comprendra l’intégralité des protocoles industriels utilisés et de discuter du traitement des flux chiffrés, s’il y en a.

Enfin, bien sûr, ce genre de projet ne peut pas être mené sans l’intégration, dès le début, des équipes OT.

Un certain nombre de nos clients s’arrêtent à la phase de tests, mais d’autres ont commencé à déployer des sondes sur leurs sites critiques voire sur l’ensemble de leur système d’information industriel. Les raisons avancées en cas de non-déploiement sont notamment liées aux : coûts, charges et compétences nécessaires. La souveraineté d’une sonde de détection peut aussi être une question importante dans certains environnements.

Des limites identifiées

En plus des points précédents, des limites techniques peuvent elles-aussi apparaître. Des enjeux de bande passante et de surcharge réseau, induits par la collecte de logs, peuvent être anticipés. De plus, une sonde OT est par nature limitée aux échanges réseaux, ses résultats (menaces détectées, évaluation du niveau de sécurité…) sont donc à relativiser par rapport aux ressources à sa disposition.

Enfin, les sondes assurent la détection. En revanche, la réaction doit être portée par d’autres moyens, humains ou technologiques. Plus généralement, avec leurs nombreuses fonctionnalités intéressantes, les sondes sont complémentaires des bonnes pratiques de sécurité telles que : la mise en place d’antivirus et de pare-feu, l’implémentation d’un puit de logs et des configurations de collecte adéquates, la construction d’une documentation réseau, l’instauration d’équipes dédiées SOC et CSIRT… Toutes ces pratiques restent de vigueur et permettront d’exploiter pleinement les capacités des sondes.

Figure 4 : Nos principaux retours sur le déploiement d’une sonde OT

Conclusion

Les sondes offrent un panel de fonctionnalités qui répond à des besoins réels. Nos rencontres nous indiquent que les acteurs du marché continuent de prendre en considération les besoins qui leur sont remontés afin d’améliorer leur produit. Malgré un marché en cours de consolidation, les acteurs semblent techniquement converger vers des produits finaux extrêmement semblables. Les différences se joueront sur des détails d’ergonomie, sur les approches adoptées par chacun et sur les coûts.

Nos premiers retours montrent l’importance de la charge et des compétences nécessaires pour l’utilisation d’une sonde. Si elles peuvent avoir une utilité dans un contexte peu mature, afin d’aider à la connaissance du système et à la mise en place d’une bonne hygiène réseau, elles ne révèlent vraiment leur potentiel qu’une fois qu’elles s’intègrent pleinement dans l’arsenal des équipes de détection et de réponse aux incidents, ce qui correspond à un contexte fortement mature. Ainsi, il semble plus prioritaire de suivre les bonnes pratiques énoncées précédemment afin de gagner en maturité puis de songer au déploiement d’une sonde dans un second temps.

1 : Voir https://en.wikipedia.org/wiki/Purdue_Enterprise_Reference_Architecture

2 : Voir https://fr.wikipedia.org/wiki/Miroir_de_port

3 : Voir https://fr.wikipedia.org/wiki/TAP_r%C3%A9seau

Cet article Les sondes de détection en milieu industriel, notre vision du marché est apparu en premier sur RiskInsight.

Faisons un détour par une page d’histoire, avant de nous plonger dans le cœur de notre sujet :

• Au XVIII^e siècle, la machine à vapeur de James Watt et l’exploitation du charbon changent la manière de travailler. L’utilisation de machines hydrauliques fait évoluer les ateliers artisanaux en des usines bien plus performantes : la 1^re révolution industrielle bat son plein.
• Ensuite, la 2^e révolution industrielle connue pour le taylorisme et la production en série repose sur l’utilisation de l’électricité et du pétrole. Les longues chaînes d’assemblage, chères à Charlie Chaplin, viennent remplacer les machines hydrauliques et à vapeur désormais désuètes.
• Le développement des nouvelles technologies de l’information, dès 1970, épaulant les opérateurs dans les tâches les plus difficiles caractérise la 3^e révolution industrielle. Elle permet notamment une robotisation accrue et production de plus grandes séries.

Cette 4^e révolution industrielle marque l’arrivée de nouvelles technologies toujours plus connectées aboutissant à un haut niveau de dépendance à l’informatique

L’Industrie 4.0 regroupe un ensemble d’avancées technologiques et d’outils techniques permettant d’optimiser des processus industriels.

Prenons un exemple concret d’un cas d’usage :

Une entreprise a besoin d’accélérer sa cadence de production et de robotiser une partie de ses actions pour gagner du temps. Par exemple, des actions de vissage. Elle choisit d’utiliser pour cela un robot collaboratif, aussi appelé « cobot »[1] capable de réaliser des actions en simultané ou sur un même espace de travail qu’un opérateur. Celui-ci aura la charge de présenter les pièces à visser au cobot.

La mise en place de ce binôme permet, en plus de réduire le délai d’exécution, d’augmenter la qualité du produit fini.

Les cas d’usage liés à l’Industrie 4.0 augmentent le risque cyber pesant sur les processus métiers. Deux raisons à cela : la nécessité de nouvelles interconnexions des systèmes industriels avec l’extérieur et l’augmentation de l’impact potentiel en cas de compromission.

Quels sont les impacts pour la cybersécurité dans toute cette histoire ? Si nous poursuivons avec ce cobot, le vissage, initialement effectué manuellement par un opérateur, est maintenant facilité par l’utilisation du cobot. Le cobot doit être connecté pour recevoir des ordres et être mis à jour.

• L’opération manuelle est remplacée par une opération informatisée maintenant exposée à une cyberattaque

Sur un robot classique, une « cage de sécurité » est présente pour éviter une intrusion d’un opérateur pendant le fonctionnement de la machine-outil. Sur un cobot, comme il y a collaboration avec l’opérateur cette protection n’existe pas. Un impact en cas de contact entre le tournevis du cobot et la main de l’opérateur serait particulièrement grave pour celui-ci !

• L’introduction de nouvelles technologies peut augmenter la gravité d’une attaque cyber

Et cela n’est pas la seule conséquence d’une utilisation non sécurisée d’une telle technologie :

• La modification d’une valeur dans le cobot concernant le couple de vissage peut entrainer un défaut de qualité en cas de mauvais serrage ;
• L’importance plus élevée des opérations assistées implique qu’en cas de défaillance, l’impact sera plus fort sur la production… ce qui va rapidement induire un impact financier.

Résumons de manière un peu simpliste :

La question est maintenant de savoir comment traiter ces risques, sans bloquer les demandes légitimes des opérationnels. Spoiler : non, refuser le projet n’est pas la solution !

Les équipes responsables de la cybersécurité peuvent anticiper les besoins de mise en place de technologies 4.0 par l’établissement de fiches réflexes adaptées

D’un point de vue technique nous pouvons regrouper les avancées liées à l’Industrie 4.0 autour de quelques grandes thématiques : réalité augmentée, objet connecté, fabrication additive… En amont des projets et avec quelques acteurs métiers bien renseignés autour de la table, il est possible d’anticiper les demandes potentielles.

L’objectif pour l’équipe cybersécurité va être alors de dresser le portrait-robot des cas d’usage type, en déduire les risques potentiels et commencer à identifier des mesures de sécurité adaptées pour y répondre. C’est aussi l’occasion de proposer des check-lists « Industrie 4.0 » pour sensibiliser en amont des projets.

Concrètement, voici un exemple de fiche réflexe type appliquée à notre cobot vu précédemment :

En se préparant en amont, les équipes cybersécurité sont plus pertinentes et efficaces lorsqu’un nouveau projet est sur le point de démarrer.

Prêt à se lancer dans un projet « 4.0 » ? C’est l’occasion idéale d’accompagner le métier dans la transformation de son usine en proposant des services de cybersécurité adaptés.

L’avantage des projets « Industrie 4.0 » consiste dans leur capacité à faire évoluer en profondeur les fondations, parfois un peu poussiéreuses, des systèmes et réseaux déjà installés en usine.

Un projet de convoyeur a-t-il besoin d’échanger des informations avec l’extérieur de l’usine ? C’est l’occasion de proposer un serveur d’échange de fichiers sécurisés dans votre DMZ[2] industrielle (en absence de celle-ci, c’est également le bon moment pour y réfléchir…). Un système de réalité augmentée a-t-il besoin d’une connexion sans fil plus stable ? C’est le moment d’engager une réflexion sur le renforcement du contrôle des appareils pouvant s’y connecter…

Au risque de reprendre des évidences ici, l’idéal est d’arriver en amont des projets, par une approche constructive, plutôt qu’à travers une PSSI[3] de 100 pages et des guides de normes et règles techniques non adaptés aux cas d’usages présentés.

Pour l’analyse de risques d’un projet « Industrie 4.0 », la méthode d’analyse de risques EBIOS RM facilite les échanges par le partage de scénarios stratégiques compréhensibles par le métier

Une fois les discussions engagées autour d’un projet concret, il est utile de réaliser une analyse de risques qui servira de support aux discussions. Sa profondeur et sa méthode vont dépendre de la taille et des risques du projet.

Cette analyse va permettre d’affiner les objectifs que l’on souhaite protéger, prendre du recul sur l’écosystème en place et définir des scénarios d’attaques les plus probants.

Voici quelques exemples de scénarios fréquemment retrouvés :

• Le sabotage logique à des fins financières (version longue du scénario Ransomware) : Une attaque ciblée ou non, permettant de rendre les équipements indisponibles en vue d’un gain financier.
• L’arrêt/ralentissement de la production : Sabotage ciblé en vue d’obtenir un avantage concurrentiel, une revanche par idéologie ou juste par défi peut être opéré par un concurrent malveillant, un vengeur, un terroriste, un activiste ou voir même un amateur en quête de frissons. Attention également à ne pas oublier les erreurs de manipulation !
• L’altération de la qualité de la pièce produite: sabotage plutôt sophistiqué et ciblé impactant la qualité des produits pour décrédibiliser l’entreprise ou simplement créer des dégâts.

La conclusion de l’analyse de risques va permettre de définir précisément les mesures de cybersécurité à mettre en place et les risques résiduels associés.

Sortir du modèle tout « château fort », à savoir tout miser sur l’isolement de son SI industriel et la sécurité périmétrique, et proposer des mesures de sécurité adaptées : détection plus fine, chiffrement, MCS[4]… en quelque sorte, c’est le moment de passer aux mesures “4.0”

Nos retours d’expérience montrent que la définition d’un plan d’actions est un travail d’équilibriste dans ces projets « 4.0 ». En effet, en appliquant un modèle de sécurité trop restrictif, à base de zones et conduits type IEC 62443-3-3, nous courrons à l’incompréhension entre les parties prenantes. En effet les solutions métiers ne sont pas toutes compatibles, pas toutes matures et n’ont pas encore intégré les standards que nous aimerions voir appliquer.

Alors que faire ? Une piste pourrait être de proposer des mesures de sécurité adaptées, des mesures « 4.0 » (pour l’environnement industriel en tout cas) mais qui ont déjà fait leurs preuves dans d’autres environnements :

• Pour éviter une propagation d’une menace, renforcer les moyens de détection, surtout les flux en provenance et à destination des SI industriels. C’est le moment d’en profiter pour faire un accostage avec le SOC Groupe si ce n’est pas déjà fait.
• Afin de s’assurer de l’intégrité et la traçabilité des données transmises/reçues​, on peut mettre en place du chiffrement et de l’authentification. Vous avez déjà une PKI Groupe ? Pourquoi ne pas réfléchir à l’étendre aux périmètres industriels.
• C’est également le bon moment pour renforcer son processus de MCO / MCS. La solution est connectée avec l’extérieur ? Plus d’excuse pour ne pas installer un antivirus, le mettre à jour, installer les patchs de sécurité de son OS favori, etc. Ce point est à anticiper en amont de l’achat de la solution, plutôt qu’une fois le produit déjà installé !
• Enfin la solution est critique pour le métier ? Un volet cyber résilience doit être anticipé pour pouvoir reconstruire rapidement la solution et repartir en cas d’attaque.

Comme nous venons de le voir, les solutions ne manquent pas, mais nécessitent un accompagnement adapté de la part des équipes cybersécurité et de dépasser les modèles théoriques. Alors, profitons de ces projets « 4.0 » pour faire évoluer nos modèles de cybersécurité industrielle sans apriori !

[1] https://commons.wikimedia.org/wiki/File:Cobot.jpg licence CC : https://creativecommons.org/licenses/by-sa/4.0/deed.en

[2] Zone démilitarisée, ici la zone réseau tampon entre le SI Industriel et le SI de gestion

[3] Politique de Sécurité des Système d’Information

[4] Maintien en Conditions de Sécurité

Cet article La cybersécurité industrielle à l’ère de l’Industrie 4.0 : comment sécuriser ces nouveaux cas d’usage et accompagner les projets métiers ? est apparu en premier sur RiskInsight.

L’année dernière, j’ai eu la chance de travailler avec différentes organisations dans leur transformation du Cloud, et chacune d’elles a fourni à notre équipe de consultants Wavestone des idées et des leçons clés sur ce que les systèmes de détection basés sur le Cloud peuvent et ne peuvent pas apporter à une organisation.

Au cours de cette année, j’ai eu la chance de travailler avec différentes organisations dans leur transformation Cloud, et chacune d’entre elles a fourni à notre équipe de consultants Wavestone des retours d’expériences et des leçons clés sur ce que les systèmes de détection basés sur le Cloud peuvent et ne peuvent pas apporter à une organisation.

Pour cet article, gardez à l’esprit que nous considérerons tout changement de configuration conduisant à une dégradation du niveau de sécurité comme un incident. Bien qu’il ne corresponde peut-être pas à la définition exacte et habituelle d’un incident de sécurité, la mauvaise configuration d’un service public cloud (où les ressources et les données peuvent être directement accessibles par Internet) est un problème trop grave pour ne pas donner lieu à une alerte immédiate sur la sécurité du système d’information.

Embrassez les victoires rapides

Lorsque vous utilisez le Public Cloud des principaux fournisseurs (Amazon Web Services, Microsoft Azure et Google Cloud Platform), il est assez facile d’activer les fonctionnalités de détection natives et de d’obtenir une capacité de détection basique mais efficace. La plupart des éditeurs fournissent une plateforme de sécurité centrale qui vous permettra de détecter les erreurs de configuration  sur l’infrastructure que vous avez déployée, d’évaluer votre niveau de conformité par rapport à une norme donnée et de lever certaines alertes lorsque les incidents les plus typiques se produiront (voir plus loin). Il n’y a pratiquement aucune raison de passer sur ces fonctionnalités, qui sont parfois gratuites à activer (que ce soit pour un essai ou de manière permanente).

En outre, la journalisation est quasiment un non-problème dans votre feuille de route de sécurité. Les fournisseurs de cloud vous permettent généralement de diffuser les journaux de vos machines virtuelles (par l’intermédiaire d’agents), de vos composants PaaS (via une poignée de clics, ou de quelques paramètres dans vos modèles d’Infrastructure as Code) et du plan de gestion (management plane) de votre abonnement (souvent activé par défaut). Cela permet à votre équipe de sécurité de comprendre rapidement l’activité en cours sur la plate-forme et de commencer à construire sur la base des journaux pour obtenir quelques alertes. En outre, certains fournisseurs de cloud possèdent des systèmes SIEM (tels que Azure Sentinel) prêts à être branchés via des connecteurs pour les appliances et les sources de données externes. Ces systèmes SIEM analysent les journaux et retire  une partie du travail lourd nécessaire lors de la mise en place de la journalisation.

Saisissez l’occasion d’améliorer la sécurité dès maintenant

Une fois que vous avez appris les bases des outils natifs de détection Cloud, il est temps de construire votre propre expertise pour pouvoir compter sur vos propres outils ! Vous pouvez également vous appuyer sur des solutions tierces telles que les solutions de gestion de la posture de sécurité dans les Cloud (CSPM) et les configurer de manière à couvrir vos besoins.

Comme indiqué ci-dessus, les fonctionnalités natives des fournisseurs de services Cloud offrent quelques alertes de base qui peuvent aller loin. Avec AWS Guard Duty, vous pouvez détecter la compromission des jetons d’accès AWS EC2 ou un accès anormal aux seaux S3. Azure Security Center vous avertira lorsqu’une activité potentiellement malveillante est détectée sur une machine virtuelle, ou lorsque les comptes Azure AD sont susceptibles d’être pris en charge… Si vous devez être capable de détecter rapidement des attaques, il existe un moyen d’exploiter les alertes natives et prêtes à l’emploi disponibles (bien que certaines d’entre elles puissent nécessiter la licence premium après un essai gratuit).

L’un des principaux avantages de la détection du Cloud est que vous pouvez agir immédiatement en y remédiant automatiquement ! Par exemple, les erreurs de configuration sont une réelle source de préoccupation pour les équipes de sécurité, comme en témoignent les téraoctets de données qui ont fui par des seaux S3 accidentellement exposés. Alors pourquoi ne pas reconfigurer tout seau exposé, à moins qu’il n’ait été spécifiquement défini dans une « liste d’autorisation » ? L’automatisation vous permettra de détecter le modèle d’exposition, de lancer une fonction sans serveur qui corrigera la mauvaise configuration et pourrait même avertir le propriétaire de la ressource ou l’équipe de sécurité.

Cela peut être fait pour une mauvaise configuration, mais aussi pour une activité malveillante : si vous détectez qu’un jeton EC2 est volé dans les métadonnées d’une instance, vous pouvez temporairement lui retirer ses droits d’accès. Si vous constatez que la journalisation est désactivée, réactivez-la et verrouillez les comptes d’utilisateurs responsables. Cela vous permettra de réagir plus rapidement aux incidents de sécurité.

Bien entendu, vous devez encore travailler sur le processus global de gestion des incidents : à la fois sur la manière d’éviter la mauvaise configuration des services (par la formation des développeurs et les contrôles dans les canaux CICD s’ils existent) et sur la manière de les gérer une fois qu’ils se produisent (le modèle de fonctionnement est abordé plus loin).

Se rapprocher de l’entreprise et de l’amélioration continue

Le passage au Cloud est généralement un moment où les applications et les charges de travail devront à nouveau passer par un examen de sécurité pour s’assurer que l’architecture et la conception sont solides et sûres. Mais c’est aussi l’occasion de rendre la détection de sécurité plus pertinente pour l’application.

Pour que cela compte, mon conseil serait le suivant:

• Passer par le processus de « Service Enablement » pour les nouveaux services : comme le passage au cloud permet aux équipes commerciales et informatiques d’utiliser des centaines de nouvelles fonctionnalités et de nouveaux composants, il est important de réunir les architectes et les équipes de sécurité pour évaluer les principaux risques pour chaque nouvelle technologie, trouver des contre-mesures pour limiter ces risques et commencer à réfléchir aux alertes qui devront être mises en œuvre dans le SIEM ;
• Construire un catalogue d’alerte pour chaque scénario et composant de risque typique, la logique de l’alerte étant déjà prédéfinie et seules les spécificités de l’entreprise devant être personnalisées. Le « time to market » de la supervision devrait également diminuer, car une bonne partie des composants utilisés pour les opérations dans le Cloud est commune à la plupart des applications (machines virtuelles, bases de données, applications et fonctions sans serveur, systèmes de découplage) ;
• Tenez-vous au courant des attaques liées au Cloud afin de comprendre les dernières vulnérabilités et les chemins empruntés par les attaquants, et intégrez-les dans vos systèmes de détection.

Toutes ces spécificités applicatives doivent s’ajouter aux alertes transversales couvrant les fonctions essentielles de votre Cloud (IAM, mise en réseau, zones d’atterrissage, etc.). Pour vous aider à mettre en place cette capacité de détection du noyau, vous pouvez évidemment compter sur notre équipe, mais je vous recommande également de vous renseigner sur la communauté CloudSec, qui ne cesse de s’agrandir et qui partage son expertise en permanence grâce à des outils open-source (comme cette vue consolidée ) ou sur des plateformes en direct et en ligne (comme le Forum sur la sécurité dans le Cloud et son premier Fwd:CloudSec conférence cette année).

Mais tout n’est pas facile !

D’après tout ce qui précède, il peut sembler facile d’obtenir une compétence de détection et de réaction d’un Cloud solide. Cependant, certains défis restent à relever.

Le premier qui vient à l’esprit est la tarification. Souvent proposé comme argument de vente pour les programmes Move to Cloud, il n’est pas aussi facile qu’il y paraît d’estimer avec précision le prix que votre fournisseur vous fera payer pour les détections Cloud. Au fil des ans, de nombreuses solutions de sécurité des CSP sont passées à une tarification basée sur les composants pour les IaaS et à une tarification basée sur les transactions pour les composants PaaS. Le stockage des journaux et les alertes sont parfois encore plus complexes, car certaines solutions vous factureront en fonction du transit et de l’agrégation des journaux, tandis que d’autres vous factureront le nombre d’évaluations par rapport aux alertes que vous avez lancées. Un travail important est nécessaire pour déterminer un budget réel et ne pas faire faillite.

Le deuxième point essentiel est de comprendre ce que votre fournisseur offre et ce qu’il n’offre pas en termes de détection. Si la plupart des solutions prétendront résoudre tous vos problèmes d’un seul coup, c’est malheureusement loin d’être le cas. Et pour chaque cas d’utilisation de la sécurité, il faut savoir si l’option gratuite, si elle existe, vous convient, si l’option premium est nécessaire ou si vos équipes de sécurité peuvent se débrouiller seules. De manière réaliste, vous devrez commencer par l’option native, jusqu’à ce que votre équipe de sécurité soit suffisamment mature, en termes de Cloud, pour passer à un processus fait maison.

En outre, et c’est peut-être l’aspect le plus important, vous devez concevoir un modèle d’exploitation qui vous permettra de travailler avec plusieurs abonnements, plusieurs équipes/entreprises et éventuellement plusieurs fournisseurs de Cloud. De plus en plus d’organisations parallélisent leurs opérations en choisissant différents CSP pour différents cas d’utilisation, ce qui entraîne une complexité accrue pour les équipes de sécurité – car elles doivent gérer des incidents sur différentes plateformes, les responsabilités étant réparties entre les DevOps, les SecOps et les équipes sur site. Cela sera d’autant plus difficile qu’une mauvaise configuration entraînera des risques de sécurité immédiats et qu’il faudra choisir entre les opérations et la sécurité. En l’absence d’une division solide des tâches entre tous les fournisseurs et toutes les équipes, il y a de fortes chances qu’une petite erreur de configuration se transforme en une fuite de données importante.

Enfin, n’oubliez pas que la surveillance de vos applications dans le Cloud peut également créer des risques. Outre le verrouillage des fournisseurs, vous pouvez perdre toutes les fonctions de sécurité ainsi que vos applications si tout se trouve sous le même plan de gestion. Si les droits d’administration globale du locataire SIEM sont repris par un attaquant, il aura toute liberté d’affecter les ressources sous-jacentes (c’est-à-dire d’effacer les journaux, de désactiver les alertes ou de supprimer les capacités de correction). Il vaut la peine d’y réfléchir avant d’empiler votre SIEM et vos applications critiques sous le même toit.

Pour résumer, en fin de compte :

• Attrapez les fruits qui pendent : votre fournisseur de Cloud vous aidera à collecter et à consolider les bûches facilement. Il n’y a pratiquement plus d’obstacles techniques pour ne plus utiliser les bûches. En outre, activez les fonctions de sécurité de base fournies par votre fournisseur de services dans le Cloud pour détecter les attaques les plus évidentes.
• Développez votre maturité en matière de Cloud avec des équipes de Cloud : Le mouvement Cloud a poussé les équipes commerciales et informatiques (SecDevOps) à travailler plus étroitement que jamais. Adoptez cette philosophie en comprenant mieux les besoins des entreprises en termes de sécurité, en personnalisant les alertes et en automatisant votre réponse pour permettre à votre capacité d’évoluer.

• Optimiser les coûts et les modèles de fonctionnement pour exceller : La virtualisation a facilité de nombreux aspects techniques pour les équipes, mais les processus peuvent être difficiles à adapter. Veillez à concevoir avec soin votre modèle d’exploitation de détection/réponse aux incidents pour vous assurer que toutes vos applications et tous vos fournisseurs de services dans le Cloud sont couverts. Enfin, pensez à l’optimisation des coûts lorsqu’il s’agit de la gestion des logs !

Cet article Comment améliorer votre detection cyber en migrant dans le Cloud est apparu en premier sur RiskInsight.

La couverture des risques dans la durée

Le durcissement des équipements

En complément d’une architecture et d’un outillage d’administration sécurisés, il convient d’élever le niveau de sécurité de chaque équipement en appliquant un principe de strict nécessaire. Un guide de durcissement générique peut être créé et adapté à chaque technologie identifiée lors de la cartographie du SI Industriel. Celui-ci permet de remédier à une partie des vulnérabilités présentes au niveau des configurations et des systèmes.

L’utilisation de solutions complémentaires peut également apporter un surplus de sécurité :

• Les antivirus connectés au réseau ou non (impliquant une mise à jour manuelle) vont couvrir les postes industriels contre les virus les plus communs ;
• La mise en place de règles strictes sur les pare feux locaux des machines va empêcher les communications, et donc intrusions, sur les ports inutilisés, et filtrer l’origine des flux en fonction des protocoles utilisés, permettant de mieux détecter des tentatives d’attaques ;
• Des solutions de gestion des comptes administrateurs locaux (par exemple LAPS pour Windows) peuvent enfin permettre de gérer les comptes administrateur natifs des postes de manière centralisée et individualisée.

Il arrive cependant qu’il ne soit plus possible de durcir un équipement du fait de sa vétusté, il faut alors travailler avec le Métier sur la gestion de l’obsolescence des équipements, sur leur éventuel remplacement et en dernier recours sur les capacités à les isoler du reste du SI. Des bloqueurs de configuration pourront également permettre, sur des postes vétustes, de restreindre l’installation et l’utilisation de composants à ceux uniquement nécessaire.

Il est important de rappeler que le SI Industriel souffre de certaines vulnérabilités, mais est avant tout l’outil de production du Métier. Le dialogue avec ces équipes est donc primordial à la compréhension de l’utilisation qu’ils en font afin de résoudre ces vulnérabilités en limitant les conséquences au maximum pour le métier.

Le maintien en conditions de sécurité

Lorsque les équipements atteignent le bon niveau de sécurité, il faut prévoir son maintien dans le temps. Différents scénarios de gestion des correctifs de sécurité ou « patchs » peuvent être définis pour répondre également aux besoins du Métier (disponibilité, intégrité) et synchronisés avec la maintenance industrielle :

1. Intégration dans les processus nominaux d’exploitation (par exemple : les processus de qualification / qualité d’une installation peuvent imposer que les équipements soient à jour). La mise à jour et l’administration des équipements tireront ainsi profit des arrêts industriels d’autant plus si une re-certification est nécessaire.

2. Préparation d’un processus de mise à jour « à chaud » en cas de faille de sécurité critique et d’un processus d’isolation préventive d’une ligne de production le temps que le procédé puisse être interrompu ;
3. Identification des équipements redondants ou périphériques sur lesquels une intervention avec simple information des responsables de sites est possible.

Afin de mettre en place ces process de patch, la cartographie réalisée précédemment doit faire apparaître un inventaire précis des équipements devant inclure :

• L’identification des équipements, leur type, localisation et nombre ;
• Les procédés industriels pour lesquels ils sont utilisés et la criticité associée ;
• Le système d’exploitation/lefirmware, les outils et la configuration ainsi que la mention des versions déployées ;
• Les besoins en termes de cybersécurité au regard des procédés supports ;
• La disponibilité de redondance, de mise en tampon des données et de cold spare ;
• La fréquence de patch requise et l’historique de patch.

Le maintien du niveau de sécurité ne se base pas uniquement sur l’application de correctifs de sécurité sur les équipements. Il convient également de :

• Définir le processus de mise à jour des solutions de sécurité installées sur les équipements coupés du réseau ;
• Installer des solutions de nettoyage de média amovibles qui restent très présents sur les sites industriels – certains produits ont l’avantage d’être portables et donc d’analyser le média pendant le déplacement à l’intérieur du site industriel ;
• Assurer la sauvegarde des configurations des équipements et leurs intégrations au DRP afin de garantir une remise en route post-incident qui réponde aux besoins de disponibilité ;
• Mettre en place un suivi de l’IAM[1] Industriel afin d’avoir un contrôle d’accès physique et logique robuste. Cette action permettra aussi d’automatiser de nombreuses actions fastidieuses de revue de comptes parfois encore faites à la main.

La détection des incidents de cyber sécurité

Les mesures citées précédemment permettent de réduire la probabilité d’occurrence des risques et donc d’augmenter la disponibilité des équipements pour le Métier. Il faut néanmoins se préparer au pire et avoir les outils nécessaires à la détection d’un incident pour le remédier au plus vite et garantir un temps d’interruption réduit au maximum.

La mise en place de la détection

La première étape à réaliser est l’activation des fonctions IDPS[2] sur les équipements réseaux afin d’assurer un premier stade de détection et potentiellement de blocage automatique.

Il s’agit ensuite d’assurer la collecte d’informations en déployant un concentrateur sur site. Les logs des équipement réseaux et serveurs pourront ainsi être envoyés aux SIEM[3] existants ou dédiés dans lesquels se feront corrélation et détection. Les SOC[4] et CERT[5] peuvent alors réaliser les opérations d’analyse, de détection et éventuellement de réaction sur incident en se basant sur des scénarios classiques.

L’anticipation de risques spécifiques

Cependant, la détection basée sur des scénarios classiques n’apportera que peu de valeur aux métiers. La prise en compte de l’ensemble des sources (PC, Linux, UNIX…) et la mise en place de sondes dédiées aux SI Industriels capables de s’interfacer avec des systèmes SCADA peut permettre d’améliorer le système de détection. Toutefois, ces solutions peuvent s’avérer coûteuses.

L’élément clé consistera ici à assurer une montée en maturité et en valeur incrémentale et rapide du SOC.

Se préparer à la remédiation

Pour finir, la détection d’un incident ne pourra aboutir à une remédiation efficace que si le Métier est inclus. Tout comme pour les mises à jour d’équipements, il convient donc de revoir les procédures d’arrêt d’urgence avec les utilisateurs du SI Industriel. La formalisation d’un Plan de Réponse à Incident permet de planifier les actions à mener en cas d’incident cyber-industriel.

Des exercices de gestion de crise dédiés au SI Industriel doivent également être menés pour assurer une préparation optimale des équipes et mettre en lumière les éventuels manques.

Une approche progressive et participative garantira le succès de la démarche

La mise en conditions de sécurité d’un SI Industriel est un chantier complexe qui ne peut être faite qu’avec le Métier. Il convient donc de travailler avec lui de manière progressive et participative sur chacun des chantiers suivants :

• Prendre connaissance de son SI Industriel en réalisant une cartographie en priorisant les éléments les plus critiques ;
• Mitiger les risques sur le SI Industriel en mettant en place l’état de l’art de l’architecture réseau sécurisée et définir les processus d’administration – les SI de Sûreté, par leur criticité, devront faire l’objet d’une attention particulière ;
• Atteindre un niveau de sécurité adéquat par le durcissement et le maintien en conditions de sécurité des équipements dans le temps – des discussions pourront notamment avoir lieu avec les fournisseurs et constructeurs d’équipements ;
• Mettre en place les outils nécessaires à la détection d’incident de sécurité, qui peuvent avoir une influence sur la production, et définir les processus de réaction.

Toutes ces actions ne peuvent pas toujours être menées en parallèle. La définition d’une feuille de route claire va permettre la priorisation des différentes actions pour pouvoir maitriser les coûts et maximiser l’apport pour le Métier.

Si ce vaste chantier est souvent initialisé en central, l’enjeu reste de pouvoir embarquer les sites, parfois répartis dans le monde entier, pour assurer une sécurité pérenne dans le temps. Nous observons, en général, une démarche en deux temps :

1. Un programme cybersécurité pluriannuel (souvent 3 ans) pour un budget de 10 à 15 millions d’euros visant à :

• Réaliser l’inventaire des SI Industriels ;
• Élever le niveau de sécurité du parc existant par la mise en place de protections souvent périmétriques et de filtrage ainsi que la remédiation des vulnérabilités les plus critiques – la définition de procédures est ici nécessaire ;
• Faire émerger un premier réseau de coordinateurs cybersécurité locaux ;

2. La création d’une filière cybersécurité industrielle et de la gouvernance associée réunissant :

• Le cadrage des activités clés à piloter par les acteurs locaux ;
• La construction participative d’outils pour aider ce réseau de responsable locaux à opérer les activités de cybersécurité sur le contenu ;
• La construction des moyens de pilotage de la montée en maturité et de gestion du changement (matrices de maturité, outils de modélisation budgétaire par site, définition d’indicateurs de pilotage, services centraux consommables par les sites…).

La mise en place de la gouvernance peut démarrer après le programme et tirer ainsi profit du premier réseau de correspondants sensibilisés à la cybersécurité bâti par le programme.

Une fois construite, il s’agit ensuite de l’animer et de piloter la progression des sites et des systèmes industriels à la fois en termes de niveau de sécurité et de niveau de maturité.

Cette animation réunit en général :

• Un réseau responsables cybersécurité locaux de 0,5 à 2 ETP[6] par site en charge de réaliser les projets, d’implémenter les activités récurrentes de cybersécurité, d’améliorer continuellement la sécurité et de reporter ;
• Une équipe centrale de 3 à 10 ETP pilotant globalement et appuyant les responsables locaux notamment en termes d’expertise.

[1] IAM i.e. Identity and Access Management.

[2] IDPS i.e. Introduction Detection and Prevention Systems.

[3] SIEM i.e. Security Incident and Event Management.

[4] SOC i.e. Security Operation Center.

[5] CERT i.e. Computer Emergency Response Team.

[6] Ces chiffres peuvent varier significativement en fonction de la taille de l’entreprise et du nombre de sites locaux, il s’agit d’une moyenne observée dans de grandes organisations internationales que Wavestone accompagne.

Cet article Saga (3/3) – Retours d’expérience et bonnes pratiques pour protéger et maintenir en condition de sécurité des SI Industriels est apparu en premier sur RiskInsight.

Introduction

Components of Electron 

https://www.wildnettechnologies.com/build-cross-platform-desktop-apps-with-electron/

Principe de l’attaque

• Le dossier « app » qui contient l’application ;
• Le fichier « electron.asar » qui prépare l’environnement Chronium au lancement de l’application.

app.on(‘browser-window-focus‘, function (event, bWindow) { bWindow.webContents.executeJavaScript(« alert(Hello Github !!’);« ) })

Démonstration

Conclusion

Cet article BEEMKA – Electron Post-Exploitation When The Land Is Dry est apparu en premier sur RiskInsight.

Des méthodes de détection statiques à de l’analyse comportementale

Les attaques évoluant de plus en plus rapidement et de manière toujours plus élaborée, le SOC (Security Operations Center) est forcé de revoir son approche concernant les outils en place car les mécanismes de détection statiques deviennent trop rapidement obsolètes :

• L’approche historique repose sur la reconnaissance de comportements et d’empreintes connues (ex : signatures de malwares). Cette méthode, appelée misuse-based, remonte des alertes explicites et simples à analyser pour les opérationnels, mais seules les attaques déjà subies et détectées pourront être reconnues.
• La nouvelle approche vise à analyser les actions déviant du comportement normalement observé sans avoir à définir explicitement et exhaustivement un acte malveillant (ex : comportement d’un individu s’éloignant de celui de ses collègues). Cette approche anomaly-based permet de détecter des attaques non renseignées directement dans les outils mais nécessite d’exploiter de plus larges volumes de données.

L’approche anomaly-based exploite les capacités de corrélation des algorithmes d’apprentissage non supervisé mettant en avant des liens dans des données non labellisées (non catégorisées comme normales ou anormales).

Recette de l’été : détection d’anomalies sur lit de Machine Learning

Pour savoir si le Machine Learning convient à son contexte, la meilleure solution reste de réaliser un PoC (Proof of Concept). Comment l’implémenter ? Quels sont les points d’attention ? Voici les étapes clés de notre développement.

Entrée, plat ou dessert : définir le cas d’usage

Faire du Machine Learning, c’est bien. Savoir pourquoi, c’est mieux. Définir un cas d’usage revient à répondre à la question « Que voulez-vous observer ? » et déterminer les moyens disponibles pour y répondre.

Dans notre contexte, un cas d’usage est un scénario de menace portant sur un ou des groupes de comptes (administrateurs malveillants, exfiltration de données sensibles…). Pour les évaluer, plusieurs critères sont à prendre en considération :

• Utilité: quel serait l’impact si le scénario se réalisait ?
• Disponibilité des données: quelles sont les sources de données utiles disponibles ?
• Complexité des données: les données disponibles sont-elles structurées (nombres, tableaux) ou non structurées (images, texte) ?

Nous avons choisi de travailler sur la compromission de comptes de services : certains peuvent avoir des droits importants, et leurs actions automatisées génèrent des données relativement structurées. Dans le cadre d’un PoC, un périmètre restreint et des sources de données homogènes et facilement accessibles sont à privilégier pour obtenir des résultats concrets et exploitables, avant d’envisager des cas d’usages plus ambitieux.

Pesée des ingrédients : déterminer le modèle de données

Afin d’exploiter au mieux les données, il est nécessaire de définir une représentation permettant de modéliser un comportement à partir des informations disponibles. Ici intervient notamment l’expertise métier : une action isolée peut-elle être signe de compromission ou faut-il plutôt prendre en compte une série d’actions pour détecter un comportement malveillant ?

Dans un premier temps, nous avons défini un modèle basé sur l’analyse de logs unitaires et de même famille (ex : connexions, accès aux ressources…) pour évaluer le fonctionnement global. Cependant, un modèle trop simple ignorera des signaux faibles cachés dans des corrélations d’actions, tandis qu’une représentation trop complexe ajoutera du temps de traitement et sera plus sensible aux biais de modélisation.

Sélection des ustensiles : choisir l’algorithme

Plusieurs types d’algorithmes peuvent être employés pour la détection d’anomalies :

• Certains tentent d’isoler chaque point : si un point est facile à isoler, il est éloigné des autres et donc plus anormal.
• Les algorithmes de clustering créent des groupes de points qui se ressemblent et calculent le barycentre de chacun correspondant au comportement moyen : si un point est trop éloigné du barycentre, il est considéré comme anormal.
• Moins fréquents, les auto-encodeurs sont des réseaux de neurones artificiels qui apprennent à recréer le comportement normal avec moins de paramètres : les erreurs de reproduction du comportement pourront être considérées comme un score d’anomalie.

D’autres approches existent encore, jusqu’aux plus exotiques systèmes immunitaires artificiels qui imitent les mécanismes biologiques pour créer un outil de détection évolutif. Il faut cependant ne pas oublier qu’un outil simple et bien optimisé est souvent plus efficace qu’un outil trop complexe.

L’algorithme de clustering des k-moyennes a été sélectionné dans notre cas : utilisé notamment dans la détection de fraude bancaire, il simplifie le réentrainement qui permet à l’outil de rester adapté malgré les évolutions des comportements.

Tous ces algorithmes peuvent également être enrichis, selon le modèle de comportements choisi, pour prendre en compte une suite d’actions. Ainsi, des réseaux de neurones convolutifs ou récurrents peuvent être ajoutés en amont pour prendre en compte des séries temporelles.

Préparation des ingrédients : transformer les données

Une fois que l’algorithme a été sélectionné, il faut traiter les données brutes afin de les rendre exploitables. Ce traitement s’effectue en plusieurs étapes :

• Le nettoyage: correction des erreurs de parsing, suppression des informations inutiles et ajout des informations manquantes
• L’enrichissement: ajout des données venant d’autres sources et retraitement des champs pour mettre en avant une information (ex : indiquer si une date est un jour férié…)
• La transformation: création de colonnes binaires pour les données qualitatives (ex : nom de compte, type d’événement…) ne pouvant pas être directement transformées en nombres (une colonne pour chaque valeur unique, indiquant si la valeur est présente ou non)
• La normalisation : retraitement des valeurs afin qu’elles soient toutes comprises entre 0 et 1 (pour éviter qu’un champ ne prenne l’ascendant sur un autre)

En raison de la variété d’événements possibles et de la complexité des logs, nous avons fait le choix d’automatiser ce processus : pour chaque champ, l’algorithme détecte le type de données et sélectionne la transformation adaptée dans une bibliothèque prédéfinie. L’opérateur peut ensuite interagir avec l’outil pour modifier ce choix avant de continuer le processus.

Assaisonnement : tester et optimiser l’outil

Une fois le modèle défini, l’algorithme choisi et les données transformées, l’outil développé devrait être en capacité de lever des alertes sur des anomalies. Ces alertes ont-elles du sens ou sont-elles des faux positifs ?

Afin d’évaluer la performance de l’outil, nous avons effectué deux types de tests :

• La simulation d’intrusion en effectuant des actions malveillantes pour vérifier si elles sont bien détectées comme anormales (cette approche peut être également traitée en ajoutant directement de « faux » logs dans les sets de données)
• L’analyse des anomalies en vérifiant si les alertes levées correspondent effectivement à des comportements malveillants

De nombreux paramètres peuvent être ajustés dans les algorithmes permettant d’affiner la détection. L’optimisation des performances se fait par itérations, en modifiant les paramètres et en observant l’effet sur un set de données de validation. Chronophage manuellement, elle peut être améliorée par l’approche AutoML qui cherche à automatiser certaines étapes par l’utilisation d’algorithmes d’optimisation.

Cependant, l’optimisation des paramètres ne suffit pas : les résultats de notre PoC nous ont permis de constater que la qualité d’une détection basée sur de l’analyse comportementale repose en grande partie sur la pertinence des comportements définis en amont du développement de l’algorithme.

ML or not ML: that may not be the question

Malgré ses atouts indéniables, le Machine Learning est un outil à utiliser de manière raisonnée : les frameworks deviennent de plus en plus accessibles et simples d’utilisation, mais les étapes cruciales restent la définition du use-case et du modèle de comportement. Ces choix, où l’expertise métier est indispensable, influenceront de manière irréversible le choix des données, la sélection de l’algorithme de détection et les tests à effectuer.

La question n’est donc plus « Où puis-je mettre du Machine Learning dans mon SOC ? », mais « Parmi toutes les approches disponibles, quelle est la plus efficace pour répondre à mon problème ? ».

Pour le savoir, une seule solution : allumez les fourneaux !

Cet article Détecter des incidents cyber par Machine Learning : notre maquette en 5 étapes clefs ! est apparu en premier sur RiskInsight.

Le dilemme de l’évolution des dispositifs antifraude : quels leviers pour intégrer ces technologies ?

Faisant écho à ces problématiques, l’écosystème des éditeurs s’est organisé pour proposer des solutions antifraude s’appuyant sur ces technologies. Ainsi éditeurs et start-ups se sont très largement développés, partout dans le monde (plus de 150 fournisseurs ont été recensés au sein du radar « Antifraude » Wavestone). Le besoin de lutte antifraude a en effet par nature une dimension internationale, notamment dans la protection des flux monétaires qui sont rarement limités à un seul pays.

Figure 2 :Exemple du radar des éditeurs antifraude Wavestone (extrait non exhaustif)

Même si la lutte contre la fraude apparait comme un use case de choix pour démontrer le ROI du Machine Learning (réduction du nombre de fraudes, automatisation de la détection…) et au-delà du choix de la stratégie d’outillage de lutte contre la fraude au regard de la maturité du marché, les questions à se poser doivent rester celles d’une solution SI « standard » (exploitation, maintenance, évolutivité…).

Si les coûts d’infrastructures nécessaires à la mise en place d’outils basés sur le Machine Learning et le big data ne sont pas négligeables, ils permettent de créer un environnement favorable à l’exploitation de la richesse des données pour divers usages (maintenance prédictive des serveurs, connaissance client, etc.) en gardant à l’esprit les garde-fous mis en place par le RGPD.

Figure 3 : Où peut-on agir avec le Machine Learning : exemple d’une banque

Une nouvelle cible à atteindre : une approche « sans couture » technologique et métier

Face aux nouveaux enjeux et l’apport des technologies émergentes, une nouvelle stratégie antifraude doit être désormais définie.

La mise en place d’un dispositif de détection globale de confiance qui devra respecter 5 grands principes.

• L’efficience et l’automatisation : il bénéficiera d’une détection à plusieurs critères (moteur de règles et Machine Learning) et d’une efficacité opérationnelle optimisée par l’automatisation de mesures allant de l’augmentation du niveau d’authentification demandé au gel d’un virement.
• L’évolutivité et l’omnicanal : il intègrera plusieurs périmètres dans la détection avec une logique « sans couture » entre le monde cyber et le monde « hors cyber » et sera conçu pour permettre l’intégration de nouvelles données disponibles (ex : données de biométrie comportementale).
• La visibilité et l’exploitabilité : il fournira la visibilité (reporting) et l’explication des résultats de détection, aux équipes antifraude, aux clients et également aux régulateurs.
• La conformité et la sécurisation : il respectera les obligations en matière de détection ainsi que les réglementations (RGPD), et traitera les risques inhérents au Machine Learning (tentatives de poisoning, compréhension par l’attaquant du modèle…).
• La gouvernance transverse cybersécurité et métier : une collaboration étroite des équipes de détection de menaces cyber et métier antifraude, dépassant les silos encore trop présents, permettra une réponse globale avec une vision 360 des menaces et fera le meilleur usage des données disponibles.

Pour bénéficier de tous les atouts apportés par cette nouvelle stratégie de détection, il conviendra également de ne pas négliger les systèmes d’investigation et de réaction.

Une décentralisation partielle de la lutte contre la fraude, impliquant les conseiller bancaires, permettra une plus grande capacité d’investigation. Ayant la connaissance la plus fine de leurs clients, ces derniers représentent un atout dans le processus d’investigation.

De plus, la biométrie comportementale et le machine learning permettent de fournir une meilleure visibilité sur le niveau de confiance qu’on peut accorder à l’utilisateur. Une fois le niveau de confiance défini, il est donc possible d’adapter les niveaux d’authentification demandés en conséquence. Une contribution adaptée et graduée de l’utilisateur permettra ainsi de réduire le nombre d’alertes émises.

La mise en place d’une nouvelle cible antifraude n’est pas seulement pour assurer une réponse adaptée à un changement de contexte mais aussi pour anticiper une vague de fond qui s’amorce aujourd’hui. La détection de fraudes deviendra à l’avenir de plus en plus complexe compte tenu d’une digitalisation qui va continuer à s’accélérer, en particulier sur les moyens de paiement. L’émergence de nouveaux acteurs, comme les Fintechs, et la désintermédiation grandissante des banques vont notamment entraîner un appauvrissement de la donnée disponible. Les dispositifs antifraude sont donc voués à évoluer en profondeur afin de garder et développer leur efficacité.

Cet article Revolution technologique : quelle perspective pour la lutte contre la fraude ? (2/2) est apparu en premier sur RiskInsight.

Les expériences et expérimentations du secteur bancaire, en avance sur ces problématiques, permettent d’envisager les perspectives à venir et fournit donc un prisme d’analyse utile aussi pour les autres secteurs.

Menaces, usages, réglementations : trois évolutions majeures qui impliquent des adaptations des dispositifs antifraude

Les transformations business et technologiques dans l’ensemble des secteurs d’activité font apparaitre des évolutions impactant directement les dispositifs antifraude historiques.

Les menaces évoluent, les pratiques de fraude se sont professionnalisées avec de nouveaux outils et de nouvelles pratiques. Prenons l’exemple du phishing : même sans connaissances informatiques, une cellule de fraudeurs entrainée peut désormais acheter un kit de phishing prêt à l’emploi et met en moyenne seulement trois minutes entre une connexion frauduleuse et une sortie d’argent. Les tentatives de fraude se sont donc démultipliées ces dernières années.

En parallèle, les usages évoluent vers une plus forte digitalisation, parfois dictés directement par des évolutions réglementaires, à la fois à destination des clients ou à destination des collaborateurs. Par exemple la mise en place de l’Instant Payment en France ou de la directive européenne sur les services de paiement 2ème version (DSP2) prévoient des virements instantanés. Ces nouveaux usages accélèrent les transactions financières entre les acteurs entrainant par la même occasion des besoins d’évaluation instantanée des risques de fraude. De plus, cette multiplication des canaux de paiement entraîne une augmentation de la surface d’attaque avec notamment une diversification des malwares bancaires aux applications mobiles ainsi que l’apparition de pratiques d’ingénierie sociale complexes multicanales et appuyées sur une compréhension des processus métier.

La diversification des fraudes, la volumétrie associée et l’augmentation des besoins de traitement instantané rend le traitement manuel presque impossible. La création de règles d’alertes plus restrictives pour minimiser les volumes ferait cependant courir le risque de manquer un grand nombre de fraudes.

Dans ce nouveau paysage, où la fraude devient de plus en plus technologique et peut avoir de multiples origines (clients, donneurs d’ordres, sous-traitants, fournisseurs, administrateurs…), les stratégies de détection doivent évoluer et passer d’une détection réactive des fraudes connues à une détection proactive des menaces encore inconnues.

Les nouvelles technologies, l’avenir de l’antifraude pour faire face à ce nouveau paradigme

L’approche historique de la détection de fraude est fondée principalement sur la définition de règles unitaires générant une alerte en cas de non-respect d’un des critères et sur la corrélation d’événements, consistant à mettre en œuvre des règles métiers plus avancées prenant en compte plusieurs types de données, afin de générer une alerte lorsque apparaissent des indices du déroulement d’un scénario de fraude connu.

Cette approche tout en demeurant efficace pour la détection de fraudes connues, par exemple dans la lutte contre le phishing, n’est plus suffisante pour faire face aux évolutions en cours. Une approche hybride doit être enrichie sur la base des nouvelles technologies présentes sur le marché (intelligence artificielle / Machine Learning, biométrie comportementale…) qui offrent deux grandes perspectives d’enrichissement des dispositifs actuels.

1.  Passer d’une détection de masse à une détection individualisée beaucoup plus fine qui va se concentrer sur les changements de comportement.

Le Machine Learning a la possibilité de créer des profils individuels à chaque client. Ces profils, composés de variables construites à l’aide des données collectées, vont permettre de modéliser le comportement. Ainsi, les algorithmes utilisés vont comparer le profil du client (et donc son habitude) avec un événement donné et, de fait, remonter une anomalie lorsqu’une divergence apparait. A noter que le nombre de variables manipulées peut facilement dépasser plusieurs dizaines, là où des règles statiques n’intègreront que quelques paramètres, permettant ainsi de démultiplier le potentiel de détection ou de réduire le nombre de faux positif.

2. Diversifier les périmètres à couvrir en bénéficiant des économies d’échelle apportées par ces technologies (mutualisation des infrastructures big data, massification des données, automatisation permettant un gain de temps pour les analystes…)

Ces technologies ont la capacité d’intégrer et corréler, grâce à des Data Lake sur lesquels elles s’appuient, des volumétries importantes de données brutes, techniques ou métiers (logs applicatifs, connaissances clients, opérations financières…) et d’apporter un potentiel d’enrichissement par des données extérieures (liste de surveillance, transformation d’adresses IP en localisations physiques…). Pour tirer le maximum de bénéfices des systèmes antifraudes, le Data Lake doit disposer d’un historique de données pertinentes et conformes, à savoir 13 mois pour des personnes physiques et 6 mois pour des personnes morales.

Pour autant ces technologies ne sont pas « magiques », elles nécessitent d’avoir à disposition des données en qualité et en quantité afin de réaliser un important travail préparatoire sur la construction des variables qui portent les capacités de détection des algorithmes. Cette phase de construction nécessite un apport d’expertise à la fois métier mais aussi technologique (datascience, développeurs, etc.).

Figure 1 – les principales méthodes de détection

Le choix des algorithmes n’est également pas à négliger, notamment d’un point de vue de la transparence. En effet, certains outils sont basés sur des algorithmes où les résultats sont difficilement justifiables. Le manque de visibilité sur les critères d’établissement des résultats entraine une remontée d’alertes en « boîte noire » et ne permet pas toujours de justifier les blocages aux clients. Une trop grande opacité peut également avoir des conséquences juridiques, voir être illégale, lorsque ces alertes ont des conséquences directes sur des clients.

Si ce premier article présente quelles sont les technologies d’avenir dans la lutte contre la fraude, un deuxième article viendra détailler comment les intégrer au mieux.

Cet article Revolution technologique : quelle perspective pour la lutte contre la fraude ? (1/2) est apparu en premier sur RiskInsight.

Comment l’idée vous est-elle venue ?

GitGuardian souligne l’importance de l’expérience de ses cofondateurs ingénieurs, spécialisés en intelligence artificielle dans la conception de leur solution : « Nous utilisons au quotidien les outils de l’open source, et en particulier la plateforme GitHub », qui reste génératrice de risques pour ses utilisateurs. Certains codes source publiés peuvent contenir une clé privée, suffisante pour « s’introduire dans des systèmes d’information d’entreprise, de la petite start-up aux grands groupes du CAC40 », la solution GitGardian a été créée pour « analyser en temps réel l’ensemble du code open source pour détecter les informations sensibles ».

Quel est le plus grand risque de sécurité pour les banques et pour ses clients selon vous ? Comment répondez-vous à la menace qui pèse sur les banques ?

Eric Fourier souligne l’interconnexion croissante entre les systèmes bancaires : « cette augmentation de la surface de vulnérabilité attire les hackers et le nombre de cyberattaques augmente tous les ans. Les failles de sécurité que nous détectons exposent régulièrement des données personnelles, pouvant appartenir aux employés de la banque, à ses clients, ou à des tiers. Ces fuites détériorent leurs images et leur font courir un risque légal et stratégique. Ainsi, GitGuardian permet de diminuer ces risques en détectant certaines vulnérabilités au niveau des interfaces entre les systèmes » bancaires.

L’enjeu pour les RSSI aujourd’hui est de parvenir à concilier la facilité d’implémentation, la simplicité d’utilisation des solutions de sécurité avec une technologie sécurisée. Comment convaincre un RSSI de la pertinence de votre solution et de la sécurité du produit ? Quels sont les différenciateurs qui vous démarquent sur le marché ?

GitGuardian met en avant la nature exogène de sa solution face « à l’infrastructure IT dans la mesure où nous analysons des données disponibles publiquement. Il suffit donc de quelques minutes pour l’installer. Nos algorithmes basés sur du Machine Learning nous permettent d’alerter le RSSI et son équipe sécurité d’une vulnérabilité moins de quatre secondes après l’événement, lorsqu’il est encore temps de limiter fortement les dégâts possibles ». Grâce à ce temps de réaction très faible, la solution est la seule sur le marché à fournir un service aussi précis et rapide car « les acteurs traditionnels s’appuient sur l’analyse humaine, qui peut prendre quelques semaines ».

Quelles sont les synergies entre votre innovation et les solutions de sécurité bancaires existantes à l’heure actuelle ?

GitGuardian note l’effort croissant des banques pour protéger leurs clients : « elles luttent contre la fraude bancaire avec des solutions de sécurisation des achats sur Internet, de protection contre les faux sites bancaires ou les tentatives d’hameçonnage. Les banques possèdent aussi des solutions standardisées pour la protection de leurs systèmes d’information, telles que les pare-feus ou le chiffrement des données. Cependant, les banques se protègent péniblement contre les erreurs humaines de leurs milliers d’employés et prestataires répartis sur le territoire français et dans le monde entier. GitGuardian colmate ces brèches en temps réel, avant que des dommages soient causés par des acteurs malveillants ».

Comment voyez-vous la banque de demain ? Quelles opportunités pour la cybersécurité dans la banque de demain ?

La principale tendance qui émerge est celle du numérique et de la transparence. GitGuardian l’explique ainsi : « La banque de demain sera une banque entièrement digitalisée et connectée. Les applications liées au secteur bancaire se multiplient, les exigences des clients s’intensifient et les fraudes bancaires s’amplifient. La banque de demain se doit d’être plus ouverte et transparente, comme en témoigne l’engouement qui s’anime autour de la technologie blockchain. Tout cela se traduit nécessairement par la mise en place de programmes de cybersécurité encore plus élaborés pour protéger la transition et assurer la sécurité de millions de personnes ».

Pour en savoir plus : https://www.gitguardian.com/

Cet article L’interview de GITGUARDIAN – Sécuriser les clés privées est apparu en premier sur RiskInsight.

Dans un contexte où l’on assiste à une véritable pénurie de compétences cybersécurités, ces problématiques ne peuvent être adressées uniquement par le renforcement des effectifs du SOC. L’utilisation de nouveaux outils, basée sur 4 axes stratégiques, est indispensable pour permettre au SOC d’avoir de l’avance sur les nouvelles menaces.

Ainsi, l’extension de la détection à de nouveaux périmètres permet de protéger de nouvelles parties du SI, aujourd’hui insuffisamment sécurisées (Cloud) ; et des ressources de plus en plus prises pour cibles (attaques ransomware sur les terminaux, attaques ciblées utilisant les AD…).

Dans le même temps, l’adoption de nouvelles approches devient une nécessité pour détecter les attaques ciblées (0days, « low signal » …), dont la subtilité croissante met à mal les dispositifs de sécurité existants.

En complément de nouveaux outils de détection, une connaissance avancée des menaces et des attaquants peut venir améliorer les capacités de détection existantes, aider à la priorisation des incidents à traiter et faire gagner en efficacité lors de la réaction.

Mais les équipes SOC éprouvent déjà des difficultés à traiter les évènements générés par les outils existants. Il est donc primordial d’industrialiser et d’automatiser les interactions entre équipes et systèmes, et, lorsque c’est possible, les étapes d’analyse et de réaction !

Pendant l’été, suivez les épisodes de notre saga pour découvrir les moyens d’outiller ces 4 axes stratégiques !

Étendre la détection à de nouveaux périmètres

Une solution unique pour sécuriser tous les Cloud : CASB

Les CASB (pour Cloud Access Security Broker) adressent un périmètre du SI aujourd’hui mal desservi par les mesures de sécurité classiques : le Cloud. Par sa nature, sa protection nécessite en effet des adaptations par rapport aux SI classiques : pas ou peu de maîtrise des ressources (infrastructures, OS ou applications, selon le type d’offre), localisation à l’extérieur du SI…

Les CASB visent à centraliser et à faire appliquer les politiques de sécurité aux services situés dans le Cloud. Certains fournisseurs Cloud proposent leurs propres services de sécurisation CASB (par exemple Microsoft avec Microsoft Cloud App Security) ; mais, selon les besoins, il est parfois préférable d’utiliser des solutions tierces, même si l’ajout d’un acteur supplémentaire a un coût. En effet, le CASB visant à s’assurer du niveau de sécurité du Cloud, confier ce rôle aux fournisseurs du service à surveiller peut être contre-productif, et l’utilisation d’un « tiers de confiance » est à privilégier.

Dans tous les cas, les CASB sont des solutions variées, pouvant regrouper de très nombreux services, leurs maturités variant selon les éditeurs de solution, les fournisseurs Cloud et le type d’hébergement (IaaS, PaaS, SaaS…).

D’une part, les solutions CASB permettent d’adresser les enjeux spécifiques aux Cloud, en palliant le manque de visibilité sur ces environnements (détection du Shadow IT, statistiques d’utilisation…), et en s’assurant de leur conformité (vérification des configurations…).

D’autre part, elles participent au déploiement des mesures de sécurités classiques sur ce périmètre. En particulier, les enjeux de sécurité de la donnée (DLP et mesures de chiffrement, particulièrement appréciées par les régulateurs) et de détection des menaces (centralisation des logs Cloud pour transmission au SIEM, détection de comportements anormaux -UEBA !, voir partie dédiée-…) font parties des capacités classiques proposées par les éditeurs. En complément, certaines problématiques d’IAM peuvent aussi être adressées par ces solutions (SSO, contextualisation des accès…).

Il existe deux principaux modes de déploiement pour la mise en place de ces fonctionnalités, chacun possédant ses avantages (et inconvénients). Les solutions types proxy sont placées en coupure entre les utilisateurs et le service Cloud.

A l’opposé, dans le cas des solutions de type API, parfois appelées out-of-band, les consommateurs du service Cloud communiquent directement avec celui-ci. Pour chaque accès, le service interroge les API du CASB afin de d’évaluer les risques, et d’autoriser ou non la consommation du service. Les solutions API s’appuient cependant sur les interfaces proposées par le fournisseur Cloud pour fonctionner, ce qui peut limiter certaines possibilités.

Aujourd’hui jeunes et peu matures, les CASB restent peu déployés. Au vu de la démocratisation (déjà bien avancée) des services Cloud, les CASB ont cependant un bel avenir devant eux, et permettront aux équipes SOC d’étendre leur surveillance sur ce périmètre, voué à représenter une partie importante du SI.

Exemples d’éditeurs CASB :

Détection et réaction, le nouveau couteau suisse pour sécuriser les terminaux : EDR (Endpoint Detection and Response)

Les solutions EDR (pour Endpoint Detection and Response) viennent compléter les capacités de détection et de réaction des SOC sur les terminaux (PC, serveurs…).

Comme leur nom l’indique, les EDR participent à la détection d’attaques. Ceux-ci viennent en effet combler les faiblesses des anti-virus (et autres HIPS) s’appuyant sur des signatures d’attaques précises, et donc inadaptées pour détecter certains types d’attaques, notamment les attaques avancées (APT). Les EDR se basent donc sur d’autres méthodes de détection, les éditeurs proposant généralement une combinaison de techniques habituellement utilisées sur d’autres périmètres.

Parmi ces techniques, la détection d’exploitation de vulnérabilités connues ou de patterns d’attaque (ouverture de port suspects vers des adresses douteuses…), l’analyse de fichiers par une sandbox (émulation locale, soumission dans le Cloud…), et des approches comportementales basées sur du Machine Learning (en particulier les solutions UEBA, cf. partie dédiée) sont utilisées par bon nombre de solutions. Selon les besoins du SOC, les alertes remontées peuvent être intégrées comme sources du SIEM, ou disponibles directement depuis la console de management de la solution.

En plus de ces capacités de détection avancées, les solutions EDR apportent aussi un important gain en visibilité sur les terminaux : liste des processus et services lancés, liste de fichiers dans certains répertoires systèmes… et toute autre information permettant de faciliter l’investigation en cas d’alerte. Certaines solutions ne se limitent pas à récupérer l’état du terminal au moment de la demande, mais permettent aussi de récupérer son historique : génération de logs, récupération de fichiers supprimés…

Mais les fonctionnalités des EDR ne s’arrêtent pas aux étapes de détection et d’analyse. En effet, ces solutions permettent d’effectuer des actions de remédiation à distance, dont la complexité dépend des éditeurs : suppression ou mise en quarantaine de fichiers, arrêt de processus, mise en quarantaine réseau de postes, modification de clés de registre…

Les EDR sont donc des solutions très complètes intervenant à toutes les étapes du processus : de la détection, à l’analyse, jusqu’à la réaction. Elles n’ont cependant pas vocation à remplacer les solutions anti-virus, toujours plus efficaces pour bloquer les attaques connues ; même si l’on observe de plus en plus d’éditeurs proposant des solutions unissant les deux types de fonctionnalités.

Pour plus de détails sur les solutions EDR, vous pouvez consulter notre article dédié au sujet ici !

Exemples d’éditeurs EDR :

Protection des clés du royaume : supervision Active Directory

Les annuaires comptent parmi les composants les plus critiques du SI. En effet, ceux-ci fournissent les fonctionnalités d’authentification et d’habilitation pour la quasi-totalité des ressources du SI, aussi bien techniques que métiers, y compris les plus critiques. Il n’est donc pas étonnant que la compromission d’AD figure parmi les méthodes d’attaque les plus utilisées, car ouvrant de nombreuses portes aux attaquants.

Malgré cette criticité, et bien que les architectures AD soient bien connues et aient peu évolué depuis plusieurs années, leur sécurisation reste perfectible. Cela est en particulier dû à leur mode de fonctionnement spécifique (OU, domaines, arbres, forêts, utilisateurs…), rendant les moyens de protection et de surveillance classiques peu efficaces, en particulier lorsque toute vulnérabilité peut représenter un risque majeur pour le reste du SI.

Les solutions de surveillance AD visent à pallier ce problème en supervisant (en temps réel, ou lors d’audit) les spécificités des annuaires (configuration, état des comptes…), et en y détectant des vulnérabilités susceptibles de causer leur compromission. Pour cela, les solutions de supervision AD possèdent une connaissance très pointue du fonctionnement des AD, et tout particulièrement des enjeux de sécurité liés.

Lorsqu’une vulnérabilité est détectée, une alerte est remontée (par le biais du SIEM, ou directement dans la solution) et des conseils de remédiation peuvent être fournis afin de faciliter le travail des équipes en charge de la correction.

Les outils de supervision AD permettent par ailleurs au SOC de détecter toute modification de configuration (légitime, accidentelle ou malveillante) et de s’assurer en continu du niveau de sécurité de ces composants critiques, compliquant d’autant la tâche de nombreux attaquants.

En complément du renforcement direct du niveau de sécurité de l’AD, ces solutions peuvent aussi être utilisés pour s’assurer de la compliance vis-à-vis de normes ou de contraintes réglementaires (LPM, PCI DSS…).

Ces solutions restent assez peu répandues aujourd’hui, et leur utilisation généralement limitée à des audits ponctuels. Cependant, au vu des importants gains de sécurité associés (détection et conseils de remédiation) et de leur simplicité d’utilisation, ces solutions sont prometteuses et devraient réussir à se faire une place parmi les outils du SOC.

Exemples d’éditeurs de supervision AD :

Pour retrouver notre second article de la saga, c’est par ici.

Cet article SOAR, UEBA, CASB, EDR et autres acronymes… suivez la saga de l’été pour comprendre et choisir parmi les nouveaux outils du SOC (1/3) est apparu en premier sur RiskInsight.

Face à cela, les outils historiques ne semblent pourtant que trop peu adaptés aux nouvelles menaces, de plus en plus volatiles (40% des attaques ne s’appuient sur aucun fichier déposé sur un poste compromis, d’après une étude de l’institut Ponemon pour Barkly). En conséquence, un nouveau type de solution de sécurité est apparu, mêlant efficacité de détection et remédiation adaptative, les Endpoint Detection & Response (EDR).

AUX ORIGINES : LES ANTIVIRUS

A l’heure du trentième anniversaire de la première annonce de neutralisation d’un virus, les antivirus figurent aujourd’hui parmi les solutions les plus utilisées dans la protection des équipements terminaux que sont les serveurs et les postes de travail. Seulement, de nouvelles stratégies de défense viennent aujourd’hui consolider les fortifications de nos systèmes d’information, afin de faire face à un spectre plus large d’attaques et de menaces.

Une réponse toujours nécessaire face aux attaques connues

Que ce soit pour nettoyer un support de stockage USB ou un serveur critique, les antivirus bénéficient d’une réputation d’outils indispensables grâce à leur stratégie, allant de la détection de fichiers à signatures virales connues à la remédiation, ainsi qu’à leur faible taux de faux-positif.

Aujourd’hui largement employés par l’ensemble des acteurs numériques, certains antivirus efficaces permettent un investissement minime face à des conséquences majeures. Pour exemple, les coûts de l’attaque massive Wannacry sont estimés à près d’un milliard de dollars – mais la somme aurait pu être beaucoup plus élevée. En effet, comme l’a démontré le groupe de recherche MRG Effitas, certains antivirus peuvent bloquer les attaques les plus notables émanant de la faille EternalBlue, par détection de signatures au travers du réseau.

Partant de ce constat, certaines solutions antivirales semblent répondre à la majorité des attentes d’une entreprise « connectée », à savoir détecter les menaces les plus massives. Cependant, la recrudescence des attaques ciblées et sur-mesure laisse envisager une banalisation du contournement de ces défenses traditionnelles. Ces attaques peuvent conduire à une intrusion dans les  systèmes d’information les plus critiques, dans un environnement où le nombre d’infrastructures augmente et devient par conséquent plus complexe à maitriser. De plus, l’efficacité des antivirus reste dépendante de la multiplicité des attaques, et par conséquent d’une récolte efficace et complète des signatures virales.

Des mécanismes insuffisants face à l’évolutivité des cyber attaquants

Deux limites sont aujourd’hui mises en cause pour juger de la légitimité des antivirus à l’avenir. Elles sont majoritairement liées à la collecte et au stockage des bases antivirales perpétuellement alimentées.

1. Le délai de mise à jour des bases virales
   Dans un environnement constamment modelé par les cyber-attaquants, une première limite est la durée de mise à jour des banques de signatures virales. Comme rappelé par F-Secure à Gartner, « il y aura toujours un délai entre l’acquisition d’un échantillon, son analyse, et la création de la détection ». Il en découle un délai conséquent d’alimentation et d’adaptation des bases de signatures, pouvant conduire à la détection d’un virus plusieurs jours après infection.

2. Une détection principalement basée sur la recherche d’attaques connues
   Les attaques de type zero-day se caractérisent par l’absence de publication et de réponse connue à leur encontre, souvent due à leur récente réalisation. Pouvant pourtant partager des comportements avec des attaques connues, elles ne figurent pas dans le périmètre de détection des antivirus. Et bien que des mécanismes IDS (Intrusion Detection System) et de machine learning se soient greffés afin d’élargir les comportements détectés, ceux-ci ne représentent que peu de challenge pour un attaquant et sont potentiellement sources de faux-positifs.

En définitive, aucun attaquant censé ne s’est jamais entendu dire :

“D*mn there is an antivirus… Oh well too bad…”

Mais comment se prémunir face a ces attaques ?

Annoncée en préambule, la technologie EDR fait son apparition en 2013 et fonde sa stratégie sur la prévention d’attaques avancées, via l’utilisation de schémas de compromission connus. Pour cela, la clé de l’efficacité d’un EDR se trouve dans la collecte d’un maximum d’informations en continu.

A travers ses fonctions principales, un outil de Endpoint Detection and Response répond à trois besoins majeurs des équipes de sécurité des entreprises :

1.Détection    2.Investigation   3. Remédiation

Voici ci-dessous une vue globale des fonctionnalités possibles :

• Une détection intelligente en temps-réel :

• Une investigation intuitive et complète :
  • Recherche exhaustive d’indicateurs de compromission (IOC) sur l’ensemble des équipements terminaux distants (hash, nom de fichiers, date de création, taille, autres attributs) ;
  • Timeline (ou Kill-Chain) des évènements déroulés lors d’une attaque. Elle peut contenir des informations relatives aux augmentations de privilèges, aux escalades horizontales (exécution sur des machines tierces), etc.

Le détail d’un fichier peut être représenté comme suit :

• Une remédiation automatique ou sur demande :

Dans l’objectif de prioriser les interventions des équipes de sécurité, des mécanismes de scoring de la criticité des alertes permettent aux opérateurs de hiérarchiser les actions. Et, même si la suppression automatique de processus malveillants permet une première remédiation facile, d’autres remédiations « on-demand » et réalisables à distance sont envisageables :

A noter que les mécanismes présentés ci-dessus ne sont pas forcément présents dans toutes les solutions se présentant comme EDR. La présence d’un antivirus intégré n’est par exemple pas une garantie, tant l’efficacité des autres mécanismes de détection s’accélère et permet des performances de détection équivalentes.

Suivant le niveau de maturité de chaque solution, il est par conséquent nécessaire d’adopter une stratégie réalisée sur-mesure en regard des ressources matérielles/logicielles, des données métier à protéger et des ressources financières mobilisables.

Contextualisation pour une strategie sur-mesure

Une combinaison entre solutions historiques et innovantes

Puisque les EDR permettent la coexistence d’autres solutions de prévention, il n’est pas nécessaire de se séparer de son actuel antivirus afin de compléter ses défenses. Pour autant, l’aspect financier du maintien de deux solutions distinctes sur le même périmètre peut être un handicap.

De plus, certains EDR peuvent aussi intégrer des antivirus raisonnables, qui deviennent d’autant plus efficaces dans l’investigation des évènements lorsqu’ils sont liés à la même console de supervision. A l’inverse, plusieurs acteurs de solutions antivirales essayent de faire migrer leur solution vers les technologies EDR, ceci afin d’alimenter leur offre de protection Endpoint.

En se concentrant sur des scénarios adressables par la technologie EDR, nous pouvons noter la présence de solutions permettant :

1. L’utilisation d’une console d’investigation et de remédiation centralisée et permettant la protection de sites distants
2. L’interfaçage avec un SIEM ou des outils d’authentification (type Active Directory)
3. La restauration d’un OS infecté par un ransomware vers un état sain
4. L’adaptation de la remédiation opérée, afin qu’elle soit automatique ou manuelle

Des points de vigilance à adresser

Pour autant, un EDR n’est pas à considérer comme une solution miracle car :

• Il peut devenir destructeur entre de mauvaises mains, ce qui nécessite notamment un durcissement de configuration, une revue de la gestion des accès ou encore une procédure de patch management ;
• Certains mécanismes de contournement sont possibles, Wannacry en est un exemple via son utilisation d’un mécanisme de détection d’un environnement sandbox. Si une sandbox était utilisée pour l’exécuter, le virus retardait le lancement de son attaque (le temps que se déroulent les analyses de protection) afin de contourner la défense ;
• Il représente une potentielle surface d’attaque supplémentaire, avec ses propres vulnérabilités logicielles, en raison par exemple du besoin de privilèges élevés des agents déployés sur les postes.

« En 2019, les fonctionnalités des antivirus et des EDR auront fusionné dans une seule et même offre » (Gartner)

L’intérêt que représentent les EDR n’est pas anodin, comme partagé dans une étude Gartner prédisant la fusion de leurs mécanismes de détection, d’investigation et de remédiation avec un socle plus mature, celui des antivirus (source : Gartner, « Magic Quadrant for Endpoint Protection Platforms 2017 », 2017), à partir de 2019.

Le chiffre d’affaires généré par le marché des EDR a doublé entre 2015 et 2016. L’intérêt grandissant de ce domaine d’innovation laisse prédire, selon Gartner, une croissance annuelle de près de 50% du chiffre d’affaires global lié aux EDR jusqu’en 2020.

Actuellement présent sur près de 5% de l’ensemble des équipements compatibles, ce nouvel outil à la mode semble prédisposé à davantage de résonnance dans les stratégies de protection de nos postes de travail, de serveurs mais aussi de nos smartphones.

Les éditeurs

Une liste -non exhaustive- d’acteurs du monde des EDR est renseignée à titre indicatif ci-dessous.

Cet article EDR : Nouveau challenger dans la protection des endpoints est apparu en premier sur RiskInsight.

Aux origines : les Honeypots

Le principe de Deceptive Security est basé sur l’utilisation de Security Decoys (ou « leurres » en français), inspirés des Honeypots (pots de miel). Le principe est simple : des leurres sont répartis aux points stratégiques du SI et toute activité y est tracée. Ces leurres n’ayant d’autres utilités que d’appâter de potentiels attaquants, toute communication avec l’un d’entre eux est nécessairement suspecte. Leur analyse permet donc de détecter et d’étudier de potentielles menaces.

Aujourd’hui, les Honeypots demeurent peu répandus, les principaux cas d’usage restant cantonnés à des cas de recherche ou de récupération d’informations (notamment de Threat Intel). Ainsi, des « pots de miel » sont exposés publiquement afin d’observer le trafic reçu sur Internet, et d’en extraire des informations : observation de nouvelles menaces (ransomware, chevaux de Troie…), identification d’IP suspectes ou compromises (SPAM, botnet…) … On peut cependant noter le regain d’intérêt pour les honeypots suite à l’attaque WannaCry, pendant laquelle nombre d’entre eux ont été utilisés pour récupérer et analyser le ransomware.

Dans les SI des entreprises, leur utilisation est encore plus marginale, et – en plus des cas cités précédemment – majoritairement limitée à des besoins bien spécifiques de gestion de crise ou de réponse à incident. Dans ces cas, les Honeypots sont utilisés pour contenir la menace dans un périmètre défini (afin de protéger les ressources critiques), étudier son comportement et en déduire son objectif.

Ainsi, aujourd’hui, les Honeypots sont principalement utilisés dans des buts d’observation et de compréhension de la menace.

Les difficultés que les Honeypots rencontrent pour se démocratiser reposent principalement sur deux limites : ceux-ci sont généralement trop facilement détectés par les attaquants, et le passage à l’échelle d’un SI relève de l’impossible, notamment par manque d’industrialisation des solutions.

Suivre le rythme : wider, faster, stealthier

Le principe de Deceptive Security vise justement à adresser ces deux problématiques, et repose sur la capacité à déployer des leurres de manière industrielle et sur des périmètres étendus. Le déploiement de ces honeypots peut être réalisé de deux façons : par le déploiement d’environnements leurres dédiés, ou par l’ajout de leurres (agents…) installés sur des environnements existants (serveurs de production, de transfert de fichier…). La stratégie de certaines solutions de Deceptive Security repose sur le déploiement de leurres à une échelle telle que ceux-ci créent un « second SI » dans le SI (ou une partie de celui-ci), similaire à une toile d’araignée dans laquelle l’attaquant vient s’emmêler.

Même si cette industrialisation représente un progrès majeur en soi, ce qui justifie la création d’une nouvelle catégorie d’outils (plutôt que de parler de simple évolution), c’est surtout la capacité à mieux dissimuler les leurres. Terminés les serveurs vulnérables avec des mots de passe par défaut : le piège est évident, l’attaquant n’y croit plus. Aujourd’hui, les solutions de Deceptive Security les plus avancées racontent une histoire à l’attaquant afin de le guider peu à peu vers leurs pièges.

La recette : remonter les miettes jusqu’au pot de miel

Pour cela, des informations (généralement appelées « miettes ») sont disséminées sur les environnements existants : serveurs de productions, AD… Bien entendu, l’industrialisation du déploiement de ces miettes est lui aussi un des enjeux principaux mis en avant par les solutions les plus avancées. Une miette représente un brin d’information : la mention d’un serveur hébergeant un middleware obsolète, des identifiants de connexion à un serveur, l’existence d’un compte possédant des droits d’administration…

Selon les solutions, ces miettes peuvent poursuivre deux buts distincts. Elles peuvent être utilisées comme un mécanisme de protection, en guidant les attaquants vers de fausses pistes, ralentissant leur progression et les encourageant à jeter l’éponge et à changer de cible.

Mais surtout, elles peuvent aussi permettre la détection des attaquants. Dans ce cas, chacune des miettes représente un indice, que les attaquants peuvent récolter en explorant les différentes ressources du réseau. Une fois récoltés, interprétés et corrélés, ces indices guident petit à petit les attaquants vers des leurres. Et c’est ici qu’est le réel enjeu, et la rupture par rapport au positionnement classique, de la Deceptive Security : comment créer des scénarios plausibles -et variés- pour piéger les attaquants ?

Ainsi, là où les Honeypots se contentent de circonscrire l’attaquant dans un périmètre défini afin de comprendre le fonctionnement et l’objectif de l’attaque, les Security Decoys visent à être déployés sur un maximum de ressources, afin d’augmenter les chances de détection, et doivent donc savoir rester discrets.

Une fois le contact avec le leurre établi, l’attaquant est repéré. Son comportement peut être alors étudié ou son accès bloqué. Dans les cas les plus poussés, de fausses informations peuvent aussi être mises à disposition pour exfiltration, permettant de faire croire à l’attaquant que sa tentative est réussie, ou de le déstabiliser lui ou son employeur : faux secrets de fabrication ou projets de brevets, fausses stratégies de rachat…

Une nouvelle approche aux nombreux avantages

Au vu de son fonctionnement, la Deceptive Security présente certains avantages par rapport aux solutions existantes.

• La transparence pour les utilisateurs et les applications : la mise en place de leurres n’ajoute aucune contrainte aux équipes IT et utilisateurs finaux : pas d’ouverture de flux, de blocage de communication ou de fichiers légitimes… ;
• Un faible taux de fausses alertes: un leurre n’étant pas supposé être utilisé de manière légitime, tout contact a de forte chance d’être lié à une menace ;
• L’absence de connaissance des attaques pour être efficace : la protection apportée par la Deceptive Security n’est pas basée sur une connaissance préalable de la menace à détecter ou bloquer (pas de signatures…). Elle est donc à même de détecter certaines menaces inconnues (0-days sur des dispositifs de sécurité ou des middlewares…) et ne nécessite pas de mise à jour continue pour être efficace. Cependant, pour détecter de cas spécifiques – sur un type d’attaque ou une ressource ciblée par exemple -, une bonne connaissance des vecteurs d’attaques reste une nécessité pour la création de miettes convaincantes et pertinentes pour le scénario souhaité ;
• L’absence de phase d’apprentissage : la détection ou le blocage d’une menace ne repose pas non plus sur l’apprentissage du réseau (seuils, patterns…), même si une connaissance de celui-ci reste nécessaire. L’outil est donc opérationnel dès son déploiement, et n’est pas vulnérable pendant cette phase de définition de la « normalité » du réseau. Ainsi, la Deceptive Security évite les principaux inconvénients des approches par signature et par apprentissage ;
• L’absence de besoin de corrélation avec d’autres ressources: même si la corrélation avec d’autres ressources reste un plus, une simple connexion sur un leurre suffit à lever une alerte nécessitant d’étudier le cas plus en détail ;
• La possibilité de couvrir des périmètres généralement difficiles à protéger: des leurres peuvent être déployés sur de nombreux périmètres (IoT, legacy…) avec une complexité limitée, et donc apporter une nouvelle protection à ces ressources souvent non-couvertes par les dispositifs classiques.

Des cas d’usage bien spécifiques

Si la Deceptive Security permet de détecter certaines attaques classiques (malwares, scans…), le réel intérêt de ce type de solution n’est pas là, ces menaces pouvant être adressées plus efficacement par les dispositifs existants (antivirus…).

Le meilleur cas d’usage de la Deceptive Security est la détection des tentatives d’explorations fines et d’installation au sein du réseau, permettant ainsi -quand le niveau de sophistication des miettes est suffisamment important- de détecter certaines APT. Plus généralement, ce type de solution permet de détecter les mouvements latéraux au sein du réseau, et ce même avec un niveau limité de personnalisation des miettes.

Ce type de dispositif n’est donc pas destiné à remplacer les mesures existantes, mais peut agir comme complément, dans le but de détecter ces types de menaces échappant communément aux dispositifs classiques.

Et pour la suite ?

Concernant l’évolution de ces solutions, certains travaux cherchent à appliquer ce principe (déguiser les leurres en environnements de production) … mais dans l’autre sens ! En faisant passer les environnements de production pour des leurres, cette démarche à contrepied permettrait d’éviter à ces ressources d’être ciblées par les attaquants !

Les éditeurs

Une liste -non exhaustive- d’éditeurs de solution de Deceptive Security est renseignée à titre indicatif ci-dessous.

Cet article Deceptive Security : comment arroser l’arroseur ? est apparu en premier sur RiskInsight.