Poste
Sécurité informatique
À quelle vitesse apprenez-vous l'existence d'une vulnérabilité critique dans un système que vous exploitez ? Ce chiffre décide si la fenêtre entre la publication et le correctif est un risque ou simplement une tâche.
Entretien préalable
Quatre questions par lesquelles nous commencerions
À quelle vitesse apprenez-vous une nouvelle vulnérabilité dans un composant que vous utilisez ?
Si c'est par une lettre d'information hebdomadaire, la fenêtre de réaction est d'une semaine quelle que soit la gravité.
Combien de fois par jour une alerte se révèle-t-elle fausse ?
Si l'équipe a cessé de lire les alertes, la surveillance fonctionne sur le papier et non en fait.
Quand décide-t-on de couper un service vulnérable ?
Si la réponse est jamais, parce que le métier ne le permettra pas, mieux vaut le savoir avant un incident que pendant.
Qu'est-ce que vous repoussez en premier quand il y a plus de tickets que de personnes ?
En général : les vulnérabilités moyennes et les revues, c'est-à-dire d'où viendront les incidents dans six mois.
Nous prenons la collecte et la priorisation, vous gardez le jugement et les décisions
Réunir l'information sur les vulnérabilités, filtrer le bruit des alertes, recueillir le contexte pendant un incident et tenir la documentation peuvent être retirés du bureau. Juger la menace et décider de la réponse restent au spécialiste.
- Une vulnérabilité est rattachée à votre environnement. - Toute vulnérabilité critique ne vous concerne pas, et la priorité dépend de l'endroit où le composant est utilisé et de son exposition.
- Une alerte arrive avec son contexte. - Ce qui se passait d'autre sur cette fenêtre, quels événements sont liés, si le motif s'est déjà produit.
- Un incident a sa chronologie consignée. - Pendant et non après, parce que la reconstituer une semaine plus tard est toujours moins bon et toujours plus cher.
Périmètre
Ce qui peut être retiré de la sécurité informatique
Dix-neuf tâches à titre d'exemple. Chacune a un point de validation humaine. Ci-dessous une sélection ; le périmètre, nous l'ajustons à votre surface d'attaque.
Vulnérabilités et priorité
- Rattacher une vulnérabilité publiée aux composants que vous utilisez
- Signalement des systèmes où le composant est exposé
- Une priorité proposée par exposition et criticité (décision : le spécialiste)
- Le statut de remédiation par système
- Un signal quand une vulnérabilité critique est ouverte depuis plus longtemps que convenu
Surveillance et alertes
- Une alerte avec le contexte des événements de la même fenêtre
- Regroupement des alertes qui partagent une cause
- Signalement des règles à plus forte part de faux positifs, hors règles de gravité élevée
- Un signal quand un système n'a aucune couverture de surveillance
Incidents
- Réunir les données nécessaires à l'appréciation d'un événement
- La chronologie de l'incident consignée pendant qu'il se déroule
- Alerter les personnes convenues selon la gravité (décision : le spécialiste)
- Un projet de rapport post-incident (contenu : le spécialiste)
Sensibilisation des salariés
- Un calendrier de formations et de simulations d'hameçonnage
- Des résultats récapitulés par service, sans nommer de personnes
- De la matière de rappel pour les domaines aux résultats les plus faibles
Conformité et audits
- Un récapitulatif des preuves exigées par la norme
- Le statut des actions correctives après un audit
- Un registre des dérogations de sécurité avec une date de réexamen
Une journée de travail
Aujourd'hui
- Vous apprenez les vulnérabilités par des listes et des lettres d'information
- Déduire si l'une vous concerne prend des heures par système
- Les alertes arrivent en quantités que personne ne parcourt en entier
- Pendant un incident, vous commencez par collecter des journaux à plusieurs endroits
- Vous reconstituez la chronologie de l'incident après coup
- Vous réunissez les preuves pour un audit pendant deux semaines
Avec l'assistance de l'IA
- Une vulnérabilité est rattachée aux composants que vous avez réellement
- Vous voyez où le composant est exposé, et la priorité a un fondement
- Les alertes sont regroupées et les règles qui génèrent du bruit sont signalées
- Un incident commence avec le contexte déjà réuni
- La chronologie se consigne pendant que l'événement se déroule
- Les preuves pour l'audit se réunissent au fil de l'eau
- Délai de correction d'une vulnérabilité critique
une fenêtre plus courte entre la publication et le correctif
la vulnérabilité est rattachée à l'environnement tout de suite
- Bruit dans les alertes de sécurité
l'équipe lit les alertes, parce qu'il y en a moins
les règles qui génèrent du bruit sont signalées
- Délai de réaction à un incident
moins de temps à collecter, plus à décider
le contexte accompagne l'avis
- Résistance à l'hameçonnage
on voit quels domaines ont besoin d'un rappel
les résultats des tests sont récapitulés par service
Nous commençons par rattacher les vulnérabilités à votre environnement, parce que c'est ce qui raccourcit le plus vite le délai de réaction.
- Étape 1
Les vulnérabilités face aux composants que vous utilisez
Ce que vous avez réellement, où c'est exposé, quelle priorité cela représente pour vous.
- Étape 2
De l'ordre dans les alertes
Regroupement, contexte et signalement des règles qui génèrent du bruit.
- Étape 3
Traitement des incidents
Contexte avec l'avis et chronologie consignée pendant le déroulement.
- Étape 4
Conformité et sensibilisation
Preuves d'audit et récapitulatifs des simulations d'hameçonnage. En dernier, parce que cela repose sur des vulnérabilités et des alertes en ordre.
Questions fréquentes
Les questions qui reviennent à la première réunion
En quoi est-ce différent de la maintenance des systèmes et de la gestion des accès ?
L'administrateur maintient les systèmes en marche, la gestion des accès décide qui voit quoi. Ici, il s'agit de vulnérabilités, de menaces et d'incidents. Les domaines se croisent sur les mises à jour et sur les droits excessifs, mais les questions quotidiennes sont complètement différentes.
Cela veut-il dire moins de monde en sécurité ?
Les équipes de sécurité sont presque partout trop petites pour le nombre d'alertes, et c'est pour cela que les alertes cessent d'être lues. Retirer le bruit ne réduit pas l'équipe, cela lui rend sa capacité à remarquer l'inhabituel. Dans une file saturée, une attaque ciblée se perd d'autant plus sûrement, et c'est de cela que parle toute cette conversation.
Cela relève-t-il du règlement sur l'IA ?
La sécurité informatique n'est pas un usage à haut risque. La limite se situe aux données sur le comportement des salariés : les résultats des simulations d'hameçonnage et l'analyse d'événements peuvent renvoyer à des personnes précises, donc nous tenons les récapitulatifs par service et par système et non par nom ; sinon ce serait de la surveillance des salariés.
Une question qui ne figure pas ici ? Réservez un appel
Étape suivante
Combien de vos vulnérabilités critiques sont ouvertes depuis plus d'un mois ?
Nous vous montrerons à quoi ressemble le travail d'une équipe sécurité quand une vulnérabilité est rattachée à l'environnement et qu'un incident commence avec du contexte.