Vue d’ensemble
SentinelOps est une plateforme infonuagique d’opérations de sécurité qui centralise la surveillance des événements de sécurité et la gestion des incidents. Elle transforme les événements entrants en enregistrements structurés, ce qui permet aux analystes d’examiner les alertes, d’enquêter sur les activités suspectes, de prioriser les menaces potentielles et de suivre les incidents depuis un tableau de bord centralisé.
Le problème
Les événements de sécurité proviennent de différents systèmes, chacun produisant des journaux aux structures et aux niveaux de détail différents. Sans méthode cohérente pour traiter ces informations, il devient difficile d’identifier les menaces significatives.
Le défi était de concevoir un système capable de standardiser les données de sécurité entrantes, de préserver les détails importants pour les enquêtes et de relier les événements à un workflow structuré de réponse aux incidents.
Implémentation
J’ai conçu une architecture full stack reliant le traitement infonuagique des événements à un backend ASP.NET Core, une base de données PostgreSQL et un tableau de bord React.
La plateforme valide et normalise les événements de sécurité entrants avant de les stocker dans un format cohérent. Les événements peuvent ensuite être associés à des incidents, ce qui permet aux analystes d’enquêter sur l’activité, de gérer les priorités et de suivre l’état des incidents.
Ma contribution
J’ai conçu l’architecture globale du système, le schéma des événements de sécurité, la structure des API backend, le modèle de base de données et l’expérience frontend.
Je me suis concentré sur la séparation de l’ingestion, de la validation, de la normalisation, du stockage et de la gestion des incidents en responsabilités distinctes.
J’ai aussi travaillé sur l’authentification, la cohérence des réponses API, la journalisation, la gestion des erreurs et la structure nécessaire aux futures intégrations infonuagiques.
Décisions techniques
L’une de mes principales décisions architecturales a été d’introduire un modèle standardisé d’événement de sécurité plutôt que de laisser chaque source de données imposer sa propre structure dans toute l’application.
Cela facilite le traitement d’événements de différentes sources sans devoir constamment modifier le backend ou le tableau de bord.
J’ai aussi séparé les informations brutes des événements des données de gestion des incidents afin de préserver le contexte des enquêtes tout en permettant aux incidents d’évoluer indépendamment.
Une autre décision importante a été d’utiliser une base de données relationnelle pour maintenir des relations claires entre les événements de sécurité, les alertes et les incidents.
Défis
L’un des principaux défis était de concevoir un schéma d’événement flexible capable de représenter différents types d’activités de sécurité sans perdre de détails importants.
Un autre défi était de maintenir la traçabilité entre un incident et les événements d’origine qui l’ont déclenché.
J’ai aussi dû réfléchir à la façon dont la plateforme devait gérer les données d’événements invalides, les échecs de traitement et les informations incohérentes sans compromettre la fiabilité du workflow de gestion des incidents.
Ce que j’ai appris
Construire SentinelOps m’a appris que les systèmes de sécurité exigent une approche différente de l’intégrité des données et de la gestion des erreurs. J’ai appris à quel point il est important de préserver les informations d’origine des événements tout en transformant les données dans un format standardisé.
J’ai aussi approfondi ma compréhension de la conception de systèmes backend autour de responsabilités claires, particulièrement pour séparer le traitement des événements de la gestion des incidents.
L’une des leçons les plus importantes est qu’une alerte n’est utile que si l’analyste peut comprendre son origine, ce qui l’a déclenchée et ses liens avec d’autres activités de sécurité.
État actuel
SentinelOps est un projet de portfolio en évolution, axé sur l’architecture des opérations de sécurité et le développement full stack.
Les fondations actuelles couvrent le traitement structuré des événements de sécurité, la gestion des incidents, les API backend, le stockage persistant et un tableau de bord destiné aux analystes.
Les prochaines étapes porteront sur l’élargissement des intégrations AWS, l’enrichissement automatisé des événements, l’amélioration des capacités de détection et le renforcement de l’automatisation de l’infrastructure.
Ce que j’améliorerais
J’élargirais le système d’ingestion des événements pour prendre en charge davantage de services de sécurité AWS et j’introduirais un enrichissement automatisé pour fournir plus de contexte sur les activités suspectes.
J’explorerais aussi la corrélation d’événements pour repérer les relations entre des alertes qui pourraient autrement sembler sans lien.
Les autres améliorations comprendraient des notifications en temps réel, l’infrastructure comme code, une journalisation d’audit plus détaillée et des tests automatisés des workflows sensibles sur le plan de la sécurité.