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

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

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

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

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

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

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

Gestion des mises à jour: EternalBlue (MS17 – 010) est un exploit utilisant une faille de sécurité présente dans la première version du Protocole SMB.

Il existe bien des réponses, mais dans cet article je vais me focaliser sur trois sources majeures :

Le cas des postes de travail

Pour le cas des postes de travail, si les mises à jour systèmes sont généralement appliquées de manière régulière, les applications tierces mises en œuvre dessus le sont beaucoup moins.

A cela, deux raisons, la première étant encore trop souvent liée à la liberté laissée aux utilisateurs de déployer les applications qu’ils souhaitent.

La seconde, est généralement liée à une absence, ou une mise en œuvre défaillante des outils de mise à jour.

Bien entendu, à la base, il y a toujours une absence, ou une non-application, de politique et procédures de sécurité. Enfin nous sommes toujours confrontés à la gestion de l’obsolescence.

Si les postes sous Windows 7 sont, sans surprise, encore légion, il ne faut pas oublier les générations plus anciennes, et notamment Windows XP. Cela est d’autant plus vrai dans le monde industriel.

Le cas des serveurs

Dans le cas des serveurs, la situation se complique quelque peu. En effet, la raison majeure de non mise à jour de composants reste l’obsolescence. Et cela concerne toutes les couches, Systèmes d’exploitations, middlewares et applications. En cause ?

Tout simplement que de nombreux projets de mise en œuvre de solutions ne posent pas les bases de suivi de version.

Pourtant, les contrats sont bien présents, tout le monde s’assure que l’éditeur proposera bien les mises à jour pour la durée de vie initiale de la solution.

Hélas, il n’est que trop peu souvent prévu les cycles de mise à jour, et on ne compte plus les outils business que l’on ne peut surtout pas toucher, plantés au milieu des SI, et identifiés comme composants critiques.

Et puis au milieu de tout cela, des outils intégrés aux masters, ou utilisés par un admin, laissés à l’abandon.

Il est quand même rageant de se voir fournir une machine dédiée à la mise en œuvre d’une solution de sécurité, équipée d’un célèbre lecteur de fichiers PDF vieux de cinq ans.

Affligeant de constater que deux ans après une campagne de patch urgente et massive, ayant mobilisée de nombreuses ressources, on nous livre une machine vulnérable à EternalBlue.

Oui la mise à niveau des masters, et des composants installés par défaut, sont également trop souvent négligés.

La gestion des mises à jour: par où commencer ?

Alors que faire, surtout quand on se retrouve au pied du mur de l’existant.

Avant tout, il est nécessaire d’établir une politique de sécurité qui posera le cadre de l’attendu, et qu’il faudra ensuite décliner au niveau des procédures. Ensuite, traiter la nouveauté.

Introduire dans les cycles de vie produit, les cycles de mises à jour, se poser la question de la mise en œuvre de celles-ci.

Enfin le point primordial : identifier celui, ou celle, qui sera propriétaire de cette application, et donc garant de son maintien en condition opérationnelle et de sécurité.

Une fois que le nouveau est traité, l’existant pourra concentrer votre attention. Il faudra identifier les éléments obsolètes, qui devront faire l’objet d’un projet de remplacement. Appliquer les mises à jour de sécurité qui peuvent l’être sans montée de version logicielle. Enfin, planifier les montées de version des applications et de leurs middlewares. Pour vous aider dans tout cela, iDNA peut vous proposer du conseil et des outils adaptés.

Cet article La gestion des mises à jour : Une ligne de défense négligée est apparu en premier sur iDNA.

Comment ces ransomwares sont-ils introduits dans les SI, et comment se propagent ils ?

Ici, rien d’extraordinaire, dans la majorité des cas, le malware est introduit via un mail contenant une pièce jointe malveillante et dans une faible proportion via des machines directement exposées sur internet. Bien sûr, il peut s’agir directement de la charge virale, mais également d’une première charge permettant de prendre la main sur le poste de la victime. Dans le premier cas, il est nécessaire que le malware embarque un exploit lui permettant de se répandre par lui-même. Dans le second scénario, les attaquants prennent la main sur un premier terminal avant de s’en servir comme rebond pour propager manuellement le malware.

Que faire pour contrer cela ?

Pour contrer cela, on pense immédiatement aux solutions anti-spam, aux anti-malware voire aux solutions de Sandboxing. Certes ces solutions permettent de réduire fortement le risque, même si elles restent faillibles. En complément, il est important de ne pas oublier la première des actions à réaliser : sensibiliser les utilisateurs. Bien sûr, certains vous diront que les utilisateurs ne comprennent rien, que c’est une perte de temps et d’argent. Mais d’expérience, une communication régulière de sensibilisation, qui ne se limite pas à une communication par mails et quelques posters, permet d’obtenir des améliorations significatives sur les comportements des utilisateurs.

Ensuite, avant de vous jeter sur la dernière technologie de sécurité qu’il vous manque, demandez-vous si les outils que vous avez déjà sont pleinement configurés et à jour.
Mais au-delà du premier poste contaminé, se pose la question de la propagation.

Généralement, elle est due à la présence de vulnérabilités sur les postes, que ce soit au niveau des systèmes d’exploitation, ou au niveau des logiciels présents sur les machines. Et c’est précisément là que se trouve le principal point de vulnérabilité, souvent mal maîtrisé.

En effet, aujourd’hui encore, la gestion des vulnérabilités n’est pas une priorité dans de nombreuses entreprises, et même si une politique est en œuvre, le suivi est souvent défaillant. Enfin, si les OS sont globalement bien mis à jour, les composants présents sur les machines ne le sont généralement pas, parce que non couverts par les outils en place. En plus de cela, certains éléments sont maintenus pour des problèmes de compatibilité. Bref, beaucoup de points peuvent être discutés au sujet des mises à jour, mais nous aborderons cela dans un prochain article. Le point à retenir, c’est que dans la majorité des cas, les mises à jour de certains composants auraient rendu inopérantes ces attaques.

Bien sûr, il n’y a pas de solutions parfaites, mais en utilisant un panaché de mesures, cela permet de complexifier la tâche des attaquants.

Très bien, mais cela ne garantit pas que je ne serai pas touché(e), comment s’y préparer ?

Mon premier conseil, préparez-vous à la gestion de crise. La meilleure solution dans le cas d’un ransomware est d’isoler, d’éteindre,  de contrôler et le cas échéant de restaurer ce qui a été compromis : cela se prépare et nécessite de parfaitement maitriser votre SI. Et pour cela, l’une des solutions serait que votre PRA prenne en compte ce scénario, cela vous permettra d’identifier les actions à réaliser, les chaines de décisions ainsi que toute la logistique associée, mais également de pouvoir conduire des exercices de simulation basés sur ces scénarios.

Ensuite, la sauvegarde vous permettra de récupérer tout ou partie de vos données. Bien entendu, il sera nécessaire de s’assurer que celles-ci sont fonctionnelles, et qu’elles permettent de retourner sur plusieurs versions antérieures, afin d’éviter de récupérer des données corrompues.

Enfin, et en dernier recours, la souscription d’une assurance pourra vous permettre de couvrir une partie des coûts de perte d’exploitation, ainsi que de la remédiation.

Et payer la rançon, est-ce une solution ?

Mon caractère tend vers la réponse suivante : Non, jamais. Maintenant, si vous êtes compromis sans espoir de récupérer des données vitales pour votre entreprise, la question peut se poser et les grands principes ne sont plus une option. Dans ce cas, surtout, ne vous précipitez pas. Prenez contact avec eux, essayez de comprendre leurs motivations et assurez-vous de réellement pouvoir récupérer vos données.

Au final, une bonne préparation vous permettra de limiter le risque, voire de le rendre tellement complexe à réaliser que les attaquants n’y verront plus aucun intérêt. Et si malgré tout vous êtes touché(e), vous saurez comment réagir, et ainsi réduire l’impact de cette attaque.

Cet article Ransomware, sont ils inéluctables? est apparu en premier sur iDNA.

Certains penseront que je suis parfois un peu négatif, ceux qui me connaissent savent que ce n’est pas totalement faux, mais le raccourci réseau = sécurité perdure encore et ce pour le meilleur, mais surtout pour le pire.[/vc_column_text][/vc_column][/vc_row]

Cet article Réseau et Sécurité, amalgame pour un échec est apparu en premier sur iDNA.

Cet article Mais quel(le) ******, pourquoi il(elle) a cliqué dessus… est apparu en premier sur iDNA.

Cet article Cyber sécurité, et si on arrêtait d’acheter et que l’on prenait le temps de configurer nos solutions est apparu en premier sur iDNA.