Réduction du bruit et hiérarchisation : la taille unique ne convient pas à tous

réduction du bruit et priorisation

Le malheur des uns fait le bonheur des autres, ce que l'on considère comme indésirable est probablement spécifique à l'auditeur. Ou, du moins, c'est la règle non écrite dans plusieurs situations, dont l'une semble avoir été jusqu'ici la outils de surveillance du paysage des menaces .

La guerre sans fin contre la fatigue d'alerte

Dans la communauté infosec, parler de réduction de bruit est devenu aussi omniprésent que la petite discussion obligatoire sur les mises à jour de COVID-19 au début des réunions Zoom. Avec des professionnels de la cybersécurité submergés d'alertes jour après jour, trouvant de mieux en mieux façons de prioriser est la clé de tout produit de cybersécurité.

L'attractivité de l'approche unique pour réduire le bruit a échappé à peu de ces fournisseurs de produits, qui espèrent réussir à prioriser les informations pertinentes pour tous leurs clients, quels que soient leur secteur d'activité et leurs défis. Bien que cette approche puisse avoir du sens pour les menaces standard, telles que la détection de logiciels malveillants ou les vulnérabilités des serveurs, il est extrêmement difficile de trouver une approche généralisée pour détection de fuite technique.

Les cas d'utilisation des alertes et des événements varient

À un haut niveau, outre les grandes institutions financières, pour qui presque toutes les activités sur les plateformes du dark web ont une valeur relativement élevée, surveillance du dark web n'est pas nécessaire pour certaines organisations. Creuser plus profondément pour trouver fuites techniques sur les sites de partage de code tels que GitHub est d'une grande valeur pour les organisations travaillant avec des référentiels privés et essayant de trouver où (pas si) les employés ont poussé du code avec leur adresse e-mail privée par erreur.

Cependant, les établissements d'enseignement supérieur avec lesquels nous travaillons ont mentionné que les engagements de code des étudiants ont beaucoup moins de valeur pour eux. Ils veulent toujours les suivre, mais les garder à un niveau de priorité inférieur aux activités et infrastructures liées aux employés.

Pour surveillance des anomalies de l'infrastructure, les entreprises possédant des plages d'adresses IP, avec des parties exécutées sur site, ont une approche de surveillance très différente de celles qui exécutent leur infrastructure derrière des équilibreurs de charge cloud ou des services tiers tels que Cloudflare. Sur ces services, les ports potentiellement sensibles tels que 8080 ou 9200 peuvent généralement se voir attribuer une priorité inférieure.

Tirer parti des commentaires des utilisateurs pour améliorer le moteur de notation des risques

Avec ces préoccupations à l'esprit, nous nous sommes orientés vers une approche intelligente, méthode adaptative de notation des risques qui s'ajuste en permanence. Les utilisateurs ont désormais la possibilité de donner un retour direct à notre moteur de notation des risques, ce qui aura un impact au fil du temps sur la façon dont notre système hiérarchise les activités et les alertes pour celles-ci. Le résultat sera un système d'alerte continuellement amélioré, personnalisé pour chaque organisation ou utilisateur.

Contactez-nous si vous en avez marre de voir votre flux d'alertes pollué par ce que les plus grands acteurs considèrent comme important. Nous vous aiderons à surveiller le Web clair et sombre à la recherche de fuites techniques avant que des acteurs malveillants n'en profitent.

Partager cet article

Équipe produit

Flare’s product team explores new technologies and processes that will help Flare stay ahead of the competition and guides the engineering team in the development of the product.

Contenu similaire