KOR IT LAB / 02
Security Lab
Le Security Lab est l'endroit où l'architecture de sécurité des agents est éprouvée plutôt que schématisée. Il existe pour tester si les contrôles que nous concevons — provenance sur la mémoire, politique au rappel, médiation à la frontière des outils — tiennent lorsqu'un système réel s'y confronte.
- Sécurité des agents
- Sécurité de la mémoire
- Politique d'exécution
- Sécurité des outils
- Détection des menaces
- Automatisation SOC
Provenance à l'écriture contre reconstitution au rappel
Question
L'origine et le niveau de confiance d'un enregistrement mémoire peuvent-ils être retrouvés après coup, ou doivent-ils être attachés au moment de sa création ?
Méthode
Les enregistrements mémoire du laboratoire sont écrits via un chemin d'ingestion qui leur assigne une classe de provenance — origine, contexte d'écriture, niveau de confiance. Nous avons ensuite tenté de reconstituer cette classe pour des enregistrements où elle avait été omise, à partir du contexte de session environnant et du contenu de l'enregistrement lui-même.
Constats
- Attacher la provenance au moment de l'écriture, plutôt que tenter de la reconstituer au rappel, est ce qui rend la classe utilisable. Une fois qu'un enregistrement mémoire existe sans son origine, cette origine est en pratique irrécupérable.
- Les classes de provenance ne valent que le chemin d'ingestion qui les assigne. Là où ce chemin se trompe, la classe est fausse, et le runtime agira avec assurance sur un enregistrement mal étiqueté.
- La politique au rappel n'a aucun sens sans provenance à l'écriture : il n'y a rien à évaluer.
Limites
Observabilité SOC de l'activité des agents
Question
Que verrait réellement un SOC si un agent de cet environnement était influencé par du contenu non fiable, et le contenu de détection existant joindrait-il les événements ?
Méthode
La pile de supervision du laboratoire a été construite spécifiquement pour observer le comportement des agents : récupération, invocation d'outils, décisions de politique et approbations sont émises comme événements, aux côtés de la télémétrie d'infrastructure classique.
- Règles d'alerte
- 55
- Groupes d'alertes
- 18
- Tableaux de bord
- 6
Mesure relevée sur une configuration testée dans un environnement expérimental. Ce n'est pas un benchmark, et elle n'est transposable ni à un autre matériel, ni à un autre modèle, ni à une autre charge de travail.
Constats
Les chiffres ci-dessus décrivent la quantité d'instrumentation présente dans la configuration de supervision propre au laboratoire. Ils ne disent rien de la qualité de fonctionnement de quoi que ce soit, et il ne s'agit pas d'un déploiement client.
- Les écritures en mémoire sont rarement des événements pertinents pour la sécurité dans la télémétrie classique, si bien que l'action à l'origine est souvent absente des données dont dispose un SOC.
- Le rappel est implicite tant qu'il n'est pas délibérément émis : sans cela, personne ne peut voir quels enregistrements ont façonné une décision donnée.
- L'identité de l'agent écrase la provenance — chaque action en aval partage un seul principal, quelle que soit la personne ayant influencé le raisonnement.
- Le contenu de détection existant suppose des sessions bornées, ce que la mémoire des agents dépasse délibérément.
Limites
Prochaines expériences
Écrites avant d'être menées, pour que les résultats soient jugés à l'aune de ce que nous cherchions et non de ce que nous avons remarqué en chemin.
Mener des tentatives contrôlées d'empoisonnement de mémoire contre le modèle de provenance : écrire du contenu non fiable, puis mesurer si et quand il est rappelé et suivi d'effet lors de sessions ultérieures.
Tester si des enregistrements mis en quarantaine peuvent être réintroduits dans le rappel par des chemins indirects tels que la synthèse ou la mémoire dérivée.
Quantifier le coût des portes d'approbation humaine — combien d'actions à risque sont réellement arrêtées, et quelle latence la porte ajoute par session.