OBSERVE
Collecter les événements de sécurité approuvés et construire le contexte autour des actifs, identités et comportements.
CYBERSECURITY
Qavirio Sentinel
Cyberdéfense assistée par IA : détection, preuve et réponse contrôlée.
Sentinel est développé comme plateforme défensive qui observe les événements de sécurité, analyse les relations, rend le risque explicable et place la réponse sous des limites explicites de politique et d’autorité. L’objectif n’est pas plus d’alertes, mais une action mieux justifiée tout en préservant les preuves.
01 · Objectif
Pourquoi ce produit existe.
Sentinel est développé comme plateforme défensive qui observe les événements de sécurité, analyse les relations, rend le risque explicable et place la réponse sous des limites explicites de politique et d’autorité. L’objectif n’est pas plus d’alertes, mais une action mieux justifiée tout en préservant les preuves.
02 · Problème opérationnel
Un signal de sécurité n’est utile que lorsque contexte, autorité et preuve se rejoignent.
Les environnements modernes produisent beaucoup de télémétrie et d’alertes. Sentinel explore un modèle où observation, analyse assistée par IA, politique et contrôle humain restent séparés. La plateforme est explicitement défensive et n’est pas conçue comme une boîte noire autorisée à modifier sans limite la production.
Trop d’alertes isolées sans contexte opérationnelDifficile de reconstruire pourquoi une réponse a été déclenchéeAutomatisation sans limite claire de politique ou d’autoritéLes preuves peuvent être perdues pendant le containment
03 · Comment ça fonctionne01 02 03 04
OBSERVE → THINK → GUARD → ACT
THINK
Analyser corrélations, anomalies, confiance et explications alternatives.
GUARD
Évaluer la réponse possible selon politique, rôle, sévérité et autorité explicite.
ACT
Uniquement une réponse autorisée et bornée ; les actions à fort impact restent guidées par politique et autorisation.
04 · Fonctionnalités
Contexte événements & actifs
Relier les événements aux identités, endpoints, services et contexte réseau.
Analyse assistée par IA
Utiliser confiance, explications alternatives et corrélation sans donner à l’IA une autorité que la politique n’accorde pas.
Sévérité & politique
GREEN, YELLOW, ORANGE et RED structurent la sévérité ; la réponse reste séparément limitée par politique.
Preuves incident
Conserver timeline, acteur, politique, résultat et hashes/références utiles.
Containment contrôlé
Le containment est conçu borné, autorisé et réversible lorsque possible.
Orientation déploiement privé
On-premise/private cloud reste le modèle principal pour les environnements enterprise et publics sensibles.
05 · Expérience utilisateur & rôles
Opérations sécurité
Analyse alertes, contexte incident, sévérité et preuves.
RSSI / responsable sécurité
Gère limites de politique, autorité et exigences assurance.
IT / infrastructure
Évalue déploiement, intégrations, endpoints et recovery opérationnel.
Audit / gouvernance
Examine timeline, contrôles et justification sans opérer la sécurité.
06 · Cas d’usageDETECTION CONTAINMENT EVIDENCE
Comportement anormal contextualisé
Un événement n’est pas seulement marqué « suspect » ; l’analyste voit actifs concernés, événements précédents et justification de la sévérité.
Politique avant action
Une action de containment n’est autorisée que si politique, rôle et sévérité le permettent explicitement.
Reconstruction après incident
Une équipe peut revoir signaux, décisions, overrides et actions ayant conduit au résultat.
Interface réelle du produit
Interface pilote réelle : visibilité, preuve et trust restent des notions distinctes.
COMPRENDRE EN DÉTAIL
Sentinel en détail : de l’observation à la décision de sécurité contrôlée.
Sentinel est conçu à partir d’un principe simple mais essentiel : observer n’est pas savoir, et savoir n’est pas être autorisé à agir. En cybersécurité, ces trois niveaux sont souvent fusionnés trop rapidement. Un appareil répond sur le réseau, une identité change, un processus se comporte de façon inhabituelle ou un indicateur externe signale un risque ; l’information est utile, mais elle ne constitue pas encore une conclusion complète. Sentinel traite donc ces signaux comme des éléments de preuve qui nécessitent du contexte. L’interface montre explicitement ce qui a réellement été observé, la classification ajoutée par un opérateur, la corrélation effectuée et la limite d’action applicable. Une équipe de sécurité peut ainsi conserver une séparation nette entre détection, interprétation et autorité.
La preuve avant la confiance
Live LAN Discovery illustre clairement cette frontière. Un appareil peut être visible par les informations passives de voisinage ou par un contrôle de présence volontairement borné. Sentinel enregistre cette observation sans promouvoir automatiquement l’objet au statut géré, sûr ou approuvé. De même, l’absence de réponse n’est pas transformée silencieusement en affirmation « hors ligne ». Cette distinction est importante car la preuve réseau est incomplète par nature : un appareil peut dormir, se déplacer, changer d’interface ou cesser de répondre pour des raisons sans rapport avec une compromission. Le produit conserve donc séparément first seen, last observed, continuité et identité d’actif déclarée par l’opérateur au lieu de transformer un événement réseau unique en décision d’inventaire autoritative.
L’autorité de l’opérateur reste explicite
Le modèle défensif de Sentinel sépare également la logique d’advisory de l’autorité de réponse. Détection et corrélation peuvent attirer l’attention, regrouper des preuves liées et présenter une prochaine étape recommandée, mais une recommandation ne devient pas d’elle-même une action de production illimitée. Lorsqu’une capacité d’action est introduite, elle reste derrière une limite explicite de rôle, de politique et de déploiement. Cette approche est volontairement prudente : elle réduit le risque qu’un faux positif, un contexte incomplet ou une intégration compromise produise automatiquement une réponse perturbatrice. L’override humain, les décisions auditables et les limites fail-closed comptent donc autant que l’algorithme de détection.
L’ingénierie sécurité dépasse le tableau de bord
L’interface visible n’est qu’une partie du produit. Un déploiement sérieux dépend aussi de l’identité, du moindre privilège, du stockage sécurisé, de la discipline de mise à jour, des journaux, de la sauvegarde et restauration, des limites réseau et de la qualification de chaque connecteur privilégié. Sentinel publie donc son statut produit et ses gates ouvertes au lieu de présenter un pilote comme déjà certifié indépendamment. La ligne actuelle peut démontrer des capacités défensives concrètes et des preuves de release, tandis que les revendications de production plus larges restent liées aux validations externes telles que signature de code, qualification en environnement propre et revue de sécurité indépendante lorsque nécessaire. Cette distinction est volontaire : la crédibilité sécurité repose sur la connaissance exacte des contrôles prouvés et de ceux qui nécessitent encore des preuves.
07 · Architecture
Le cœur de détection et le modèle d’autorité restent séparés.
Sentinel suit une architecture en couches : connectors/events fournissent les observations ; analyse/corrélation produit hypothèses et sévérité ; la politique décide ce qui est permis ; l’audit conserve ce qui s’est produit. Une panne d’un connector externe ne doit pas faire tomber le cœur de détection.
Connectors / events→Detection & correlation→Evidence graph→Policy / RBAC→Controlled response / audit
08 · Sécurité & données
Moindre privilège et RBAC fortPreuves incident vérifiables / tamper-evident lorsque implémentéPas de monitoring de productivité salarié comme objectif produitPas d’autonomie black-box illimitéeHuman override et emergency release dans la gouvernanceMinimisation des données et rétention configurable
09 · Intégration
Les intégrations sont des frontières privilégiées, pas des cases marketing.
Un connecteur n’est annoncé intégré qu’après validation du contrat, de l’authentification, de la gestion d’erreurs, des contrôles rate/abuse et de l’acceptance fournisseur ou client pertinente. Les connecteurs étudiés ou planifiés sont étiquetés comme tels.
10 · Déploiement & hébergement
On-premise / private cloud
Orientation principale enterprise/public sector pour conserver la télémétrie brute sous contrôle client.
Hybrid
Canaux externes d’intelligence/mise à jour lorsque explicitement autorisés, sans export automatique de télémétrie par défaut.
Sovereign / restricted
Analyse locale, IA externe optionnelle/désactivée et bundles de mise à jour contrôlés pour environnements plus stricts.
11 · Exploitation & support
12 · Statut produit
PILOT RC 2.1.0
External Pilot Qualification & Deployment Assurance R1. Un release candidate pilote n’est pas une revendication de production généralisée ; pilote externe, assurance indépendante, signature et acceptance client restent des gates distinctes.
Premier pilote externe réel / qualification environnement propre lorsque requisAuthenticode / signature de code pour diffusion largeRevue sécurité indépendante / penetration testing pertinenteAcceptance client spécifique : privacy, rétention, réseau et assurance
13 · Contact / démo
Pilote / revue technique →Parler de ce produit avec Qavirio.
Un premier échange porte sur le cas d’usage, l’organisation, les systèmes existants, les exigences sécurité et le déploiement souhaité avant toute proposition.