Bien démarrer avec la sécurité
Status200 détecte les menaces dans les données dont vous disposez déjà - vos journaux, les outils de sécurité que vous utilisez et tout ce que vous lui envoyez -, regroupe ce qu'il trouve en dossiers et y répond avec des playbooks. Deux clics suffisent pour tout mettre en place, et il n'y a rien à installer.
Avant de commencer
Mettre en place la sécurité demande le rôle Project Owner, Project Admin ou Security Admin. Les rôles Security Member et Security Viewer consultent ce qui est trouvé ; voir Rôles.
Mettre en place
Activer ce dont la plupart des équipes ont besoin
Ouvrez Produits → Événements de sécurité. Sur Vue d'ensemble, cliquez sur Activer les recommandations. Trois choses s'activent d'un coup : Trouver des événements de sécurité dans vos journaux, les règles de détection recommandées et Enrich New Cases, un playbook qui confronte chaque nouveau dossier au renseignement sur les menaces et y laisse une liste de contrôle pour le tri.
Envoyer une attaque de test
Cliquez sur Envoyer une attaque de test. Une douzaine de connexions échouées depuis une adresse de documentation passent par le vrai traitement : elles sont stockées, la règle de force brute les détecte et un dossier s'ouvre. Personne n'est alerté et aucun SIEM ne les reçoit.
Ouvrir le dossier
Cliquez sur Ouvrir le dossier. Voici à quoi ressemble une vraie découverte : les événements qui la justifient, l'adresse concernée et ce qu'a trouvé Enrich New Cases. Fermez-le comme test une fois terminé.
Dès lors, Vue d'ensemble s'ouvre sur ce qui attend quelqu'un, sous Attention requise : vos dossiers ouverts, ceux que personne n'a pris en charge et les étapes de playbook en attente d'approbation. S'il n'y en a aucun, elle affiche Tout est calme.
Fonctionnement
De vos données à un dossier
| Partie | Où | Ce qu'elle fait |
|---|---|---|
| Sources | Connexions | Vos journaux, les produits de sécurité qu'interroge Status200 et tout ce que vous envoyez |
| Détections | Détections | Des règles Sigma et des flux de renseignement sur les menaces qui cherchent des menaces dans chaque événement |
| Dossiers de sécurité | Dossiers de sécurité | Ce qui a été trouvé, regroupé par l'utilisateur, l'hôte ou l'adresse concernés |
| Playbooks | Playbooks | Des étapes qui s'exécutent sur les nouveaux dossiers : les enrichir, prévenir, ouvrir un incident ou contenir |
En haut de Vue d'ensemble, sous ce qui attend quelqu'un, chaque partie montre ses chiffres : les sources et leurs événements des dernières 24 heures, les règles actives, les dossiers ouverts et les playbooks qui répondent. Une partie non configurée le dit et ouvre la page où la configurer.
Trouver des événements de sécurité dans vos journaux
La carte Vos journaux, en haut de Connexions, ne demande aucune installation. Avec Trouver des événements de sécurité dans vos journaux activé, Status200 lit chaque minute les nouveaux journaux du projet et transforme les lignes qu'il reconnaît en événements de sécurité :
| Journaux | Ce qui devient un événement de sécurité |
|---|---|
| Connexions SSH | Les connexions SSH échouées et réussies, tirées du journal d'authentification, du journal système ou du syslog d'un serveur |
| sudo | Les commandes exécutées en tant qu'un autre utilisateur, les mauvais mots de passe sudo et les personnes qui n'ont pas le droit d'utiliser sudo |
| Journaux d'audit Kubernetes | Les modifications du cluster, les shells ouverts dans des pods, les secrets lus et les requêtes refusées |
| AWS CloudTrail | Les connexions à la console, les modifications faites dans vos comptes AWS et les appels refusés par AWS |
| Attaques web | Les requêtes du journal d'accès d'un serveur web qui tentent une injection SQL, une traversée de répertoires ou Log4Shell |
Vos journaux restent tels quels. Seules les lignes qui comptent pour la sécurité deviennent des événements : jamais chaque page servie par un serveur web, ni chaque lecture d'une API.
Envoyer ce que trouve Status200 à votre SIEM
Si votre équipe travaille déjà dans un SIEM, Status200 y envoie aussi ce qu'il trouve. Sous Connexions → Envoyer vers votre SIEM, cliquez sur Ajouter une destination, renseignez la région, l'instance et la clé de compte de service de votre Google SecOps, puis cliquez sur Envoyer un événement de test avant d'enregistrer. Voir Envoyer des événements de sécurité à Google SecOps.
Dépannage
Turn on recommended est grisé
Votre rôle ne peut pas ajouter de règles de détection, de playbooks ni la source de journaux. Adressez-vous à un Project Owner, un Project Admin ou un Security Admin, ou demandez-lui de vous donner le rôle Security Admin.
Turn on recommended n'a pas pu tout activer
La carte indique chaque élément qu'elle n'a pas pu activer, et pourquoi : votre rôle, votre forfait, ou une erreur du côté de Status200. Tout le reste est activé. Corrigez ce qu'elle indique, puis cliquez sur Réessayer : seul ce qui manque encore est activé, et rien n'est ajouté deux fois.
L'attaque de test n'a ouvert aucun dossier
Le dossier s'ouvre en général avant que le bouton ne réponde ; quand la règle rattrape encore son retard, il le dit et le dossier s'ouvre dans la minute. Regardez de nouveau Dossiers de sécurité, et vérifiez sous Détections que la règle de force brute est active.
Aucun événement de sécurité ne vient de mes journaux
Vérifiez que Trouver des événements de sécurité dans vos journaux est activé et que la carte Vos journaux indique quand la dernière vérification a eu lieu. Seuls les types de lignes du tableau ci-dessus deviennent des événements : un serveur qui n'envoie ni journaux SSH, sudo, d'audit, CloudTrail ou d'accès n'a rien à trouver.
Vue d'ensemble indique que le dernier événement de sécurité date de plusieurs jours
Rien n'a atteint Security depuis. Ouvrez Connexions et vérifiez que Vos journaux et chaque connexion sont toujours activés, et quand chacun a vérifié pour la dernière fois.
La carte qui active Security a disparu
Quelqu'un l'a fermée avec Masquer. Tant que rien n'est encore surveillé pour détecter des menaces, Vue d'ensemble propose Configurer Security, qui la fait revenir.