Aller au contenu principal

Pools de communautés

Un pool donne à plusieurs communautés — une par équipe — exactement le même contenu : les mêmes journaux sur les mêmes technologies, les mêmes inventaires OCSF, la même menace greffée, les mêmes scénarios lancés à la volée. Il est fait pour les sessions de Capture The Flag, où chaque équipe travaille dans son propre espace Sekoia et où aucune ne doit recevoir plus, moins ou autre chose que les autres.

/pools liste les pools ; chacun s'ouvre sur son modèle, ses équipes, leur livraison et leur alignement.

Partagé, et propre à chaque équipe​

Le pool partage ce qui est produit ; chaque équipe garde où elle le reçoit.

PartCe qu'elle couvreOù elle vit
ProductionPopulation, profil d'entreprise, fuseau, week-end, l'ensemble des technologies, menace, hôtes compromis, attributionsPartagée — réglée sur le modèle ou n'importe quelle équipe, les technologies sur l'écran du pool
LivraisonNom, description, destination, base de l'API, clés d'intake, clé d'API Sekoia, connecteurs d'assetsPropre à chaque équipe — l'écran du pool ; le modèle n'en a pas
ÉtatActivée ou arrêtée, technologies coupées, échecs d'affiléePropre à chaque équipe ; le modèle est toujours arrêté

Il n'y a pas d'écran « réglages du pool » à tenir au pas des équipes : un réglage de production enregistré sur la page du modèle ou d'une équipe est écrit sur toutes, dans une seule transaction. La page d'une équipe le dit par un bandeau, « Équipe du pool », sur chaque onglet ; celle du modèle par le sien, « Modèle du pool ».

L'ensemble des technologies fait exception : il se choisit sur l'écran du pool (ci-dessous), et l'onglet Technologies d'une équipe ne liste que les technologies du pool, chacune avec la clé d'intake de cette équipe — « Enregistrer les clés » écrit les clés et rien d'autre. Une page d'équipe restée ouverte ne peut donc pas défaire un choix fait entre-temps sur l'écran du pool.

Les corrections manuelles d'attribution sont de la production elles aussi : corriger l'archétype d'un utilisateur sur une équipe le corrige partout.

Créer un pool​

Un pool naît d'une communauté déjà réglée et vérifiée : « En faire un pool » en tête de sa page, ou « Nouveau pool » sur /pools.

ChampCe qu'il décide
Nom du poolUnique
Communauté modèleLa production que les équipes recopient ; elle devient le modèle du pool et cesse d'envoyer. Une communauté déjà dans un pool n'est pas proposée
Équipes à ajouterLe modèle n'en est pas une : il n'envoie rien — 30 équipes au plus
Motif du nom des équipes{n} est remplacé par le numéro de l'équipe, sur deux chiffres ; laissé vide, <modèle> – Équipe {n}

Le modèle devient le gabarit du pool (ci-dessous) : son identifiant devient la graine du pool entier, si bien que les équipes reçoivent au bit près la journée qu'il aurait produite. Elles recopient sa production — jamais ses clés ni ses connecteurs — et naissent arrêtées. Un nom d'équipe déjà pris refuse la création en le nommant, et rien n'est créé.

Le modèle : le gabarit du pool​

La communauté d'où le pool est né en devient le modèle — la carte Modèle, en tête de l'écran du pool, mène à sa page. Il porte la production que reçoivent les équipes et n'envoie rien : ni journaux, ni inventaires. Ce n'est pas une équipe : il n'est ni compté, ni dans la table Équipes, ni dans la grille de livraison, et l'activation du pool ne le juge pas — il n'a pas de clé à porter.

  • Il est arrêté à la création du pool, s'il tournait, et sa page ne propose plus de l'activer.
  • Sa page garde tout ce qui se produit — population, fuseau, week-end, menace, attributions — sous le bandeau « Modèle du pool » : un réglage enregistré là vaut pour toutes les équipes.
  • Rien de ce qui livre n'y figure : ni destination ni clé d'API Sekoia dans Réglages ; ni clé dans Technologies, qui liste les technologies du pool sans champ ; ni connecteur ni « Envoyer maintenant » dans Assets, où seul l'Aperçu reste — il montre ce que les équipes recevront ; ni lancement dans Menaces, qui renvoie à l'écran du pool.
  • Ses clés et ses connecteurs d'avant restent en base, masqués et inutilisés.
  • Sur /communautes, sa ligne dit « Modèle » plutôt qu'« Arrêtée ».

Les technologies : choisies une fois, pour toutes les équipes​

La carte Technologies porte une case par technologie, et rien d'autre : une clé dit où une équipe reçoit, elle n'appartient donc pas au pool. « Enregistrer les technologies » écrit l'ensemble sur toutes les équipes d'un coup.

  • Une technologie ajoutée naît sans clé chez chaque équipe : la carte Livraison en demande alors une à chacune, et la table Équipes la nomme sur chaque ligne tant qu'elle manque.
  • Une technologie retirée efface sa clé chez toutes les équipes.
  • Sans aucune technologie, chaque bloc de la carte Livraison le dit, plutôt qu'une liste de clés vide.

La livraison : un formulaire pour toutes les équipes​

La carte Livraison porte un bloc par équipe — le modèle n'en a pas : destination, base de l'API, la clé d'API Sekoia de l'équipe — sa seule clé Sekoia, qui envoie ses inventaires et crée ses intakes et ses connecteurs —, une clé d'intake par technologie du pool, et l'UUID de configuration de chaque connecteur d'assets. Un bloc s'ouvre de lui-même tant que son équipe n'a pas toutes ses clés — c'est le cas de toutes les équipes d'un pool qui vient de naître.

  • Une clé enregistrée n'est jamais réaffichée, seul son masque (••••1a2b). Laisser le champ vide conserve la clé ; l'effacer demande la case « effacer ».
  • Seul ce qui change est envoyé. Écrire une destination fait reconstruire son plan du jour à l'équipe, même quand la valeur est identique ; enregistrer la grille pour une clé ne doit pas l'imposer à vingt équipes.
  • Une équipe sans clé pour une technologie reçoit un sous-ensemble du contenu. La table Équipes nomme les technologies manquantes sur sa ligne.
  • Chaque clé d'intake porte un bouton Créer dans Sekoia : l'intake est créée dans l'espace Sekoia de l'équipe avec la clé d'API Sekoia de l'équipe, et sa clé posée, exactement comme sur une communauté. Chaque équipe est son propre espace Sekoia — sa clé et son entité ne se recopient jamais chez une autre. La clé se règle aussi sur la page de l'équipe, dans l'onglet Réglages : c'est le même champ.
  • Chaque UUID de connecteur d'assets vide porte aussi un bouton Créer dans Sekoia : le connecteur est créé dans l'espace Sekoia de l'équipe avec la clé d'API Sekoia de l'équipe, et son UUID posé, exactement comme sur une communauté. Le champ montre l'UUID sans rechargement, et enregistrer la grille ensuite le conserve.

Créer toutes les intakes d'un geste​

Deux boutons épargnent les 870 clics d'un pool de trente équipes sur vingt-neuf formats.

  • Créer les intakes de toutes les équipes, en tête de la carte, crée toutes les intakes possibles de chaque équipe.
  • Créer toutes ses intakes, à côté des clés d'intake d'une équipe, fait de même pour cette équipe seule.

Une intake est possible quand le bouton unitaire serait offert : une technologie prise en charge, sans clé. Une équipe sans base d'API ou sans clé d'API Sekoia est écartée, et nommée. Le lot s'exécute en tâche de fond, trois équipes de front, et technologie après technologie dans une équipe.

  • Le clic rend la main aussitôt. La carte Lot d’intakes montre l'avancement, puis équipe par équipe ce qui a été créé, ce qui a échoué et pourquoi, et ce qui a été écarté. Les masques apparaissent dans la grille au fil de l'eau. Sans JavaScript, rechargez la page pour suivre.
  • Un lot d'intakes à la fois par pool : les boutons sont désactivés pendant qu'il tourne, et un bouton qui n'a rien à créer dit pourquoi. Un lot de connecteurs d'assets ne le bloque pas.
  • Un refus qui se répéterait — le compte de la clé, l'entité — arrête son équipe. Une intake refusée n'arrête que sa technologie : un format absent d'un espace ne doit pas bloquer les autres.
  • Si api-asset redémarre pendant un lot, le lot est interrompu, jamais rejoué. Le relancer est sûr : seules les technologies encore sans clé sont tentées.

Créer tous les connecteurs d'assets d'un geste​

Le pool n'a pas d'ensemble de formats de connecteur à lui — chaque équipe règle ses connecteurs dans la grille —, si bien que le lot crée les formats cochés au lancement. Six cases figurent en tête de la carte, toutes décochées : créer dans Sekoia se coche délibérément.

  • Créer les connecteurs de toutes les équipes crée, pour chaque équipe, chaque format coché dont elle n'a pas encore de connecteur.
  • Créer ses connecteurs cochés, à côté des UUID de connecteur d'une équipe, fait de même pour cette équipe seule.
  • Rien de coché : refusé, et dit, avant que rien ne parte.

Chaque connecteur est créé exactement comme le bouton unitaire le ferait — configuration de module, connecteur, UUID posé, collecte arrêtée — avec la clé d'API Sekoia de l'équipe. Une équipe sans base d'API ou sans cette clé est écartée, et nommée. Le lot s'exécute en tâche de fond, comme le lot d'intakes :

  • la carte Lot de connecteurs d’assets montre l'avancement, puis équipe par équipe ce qui a été créé — avec son UUID —, ce qui a échoué et pourquoi, et ce qui a été écarté ; les UUID apparaissent dans la grille au fil de l'eau, et enregistrer la grille ensuite les conserve ;
  • un lot de connecteurs à la fois par pool — un lot d'intakes qui tourne en même temps ne le bloque pas : chaque nature a sa clé ;
  • un compte refusé arrête son équipe, la clé valant pour tous ses formats ; un connecteur refusé n'arrête que son format ;
  • un connecteur posé entre-temps — à la main, ou par le bouton unitaire — est écarté, jamais remplacé ;
  • si api-asset redémarre, le lot est interrompu, jamais rejoué : le relancer ne tente que les formats encore sans connecteur.

Activer toutes les équipes d'un geste​

« Activer le pool » active toutes les équipes — jamais le modèle — et planifie leur journée sur un seul instant : elles émettent depuis la même minute, et la matinée écartée est la même pour toutes. Si une équipe ne peut pas partir — aucune de ses technologies ne porte de clé, ou aucun utilisateur ne joue d'archétype —, le pool entier est refusé, en nommant chaque équipe et son motif : un pool à moitié parti n'est pas une session équitable. « Arrêter le pool » les arrête toutes.

Les inventaires du jour partent avec les journaux : activer le pool met en file l'exécution du jour de chaque équipe, elle aussi sous un seul instant, sans attendre le passage suivant de l'ordonnanceur ni 8 h.

Une équipe réactivée plus tard — après la coupure à cent échecs, ou depuis sa propre page — reprend à la minute courante : une matinée n'est jamais rejouée. La carte Alignement nomme une telle équipe, quelle qu'en soit la cause :

  • pas de journée aujourd'hui, ou une journée en échec ;
  • partie en retard, et de combien de minutes ;
  • des minutes sautées qui diffèrent de celles des autres ;
  • des technologies coupées chez elle seule.

Suivre les émissions du jour​

La carte Émissions du jour dit ce que chaque équipe a reçu aujourd'hui, dans le fuseau de la population. Quatre tuiles totalisent les équipes qui ont une journée — Messages prévus (et combien ont été écartés, déjà passés quand le pool est parti), Envoyés, En échec et Reste à envoyer aujourd’hui —, puis une ligne par équipe :

ColonneCe qu'elle montre
ÉquipeMène à la fiche de l'équipe, qui détaille chaque technologie.
JournéeLe statut de la journée, et la minute jusqu’à laquelle elle est à jour — Aucune journée si elle ne tourne pas.
EnvoyésCe qui est réellement parti, sur ce qui pouvait encore partir au moment du plan, avec une barre.
En échecLes messages dont le lot a été définitivement refusé ou perdu.
ResteCe qu'il reste à envoyer aujourd'hui.

Les chiffres sont comptés sur les lots réellement envoyés, jamais sur un compteur tenu à côté. La page les suit en direct : chaque lot posté par une équipe la rafraîchit — la carte, la carte Alignement et l'état des équipes —, ceux des autres communautés et des bancs d'essai non. Sans JavaScript, la page montre les chiffres tels qu'au chargement ; la recharger les fait avancer.

Menaces et inventaires, sur tout le pool​

Lancer un scénario sur toutes les équipes​

La carte Lancer un scénario de l'écran du pool joue un scénario maintenant sur toutes les équipes — jamais sur le modèle —, sous une même graine, une même minute de départ et les mêmes cibles, pour une durée bornée. Ses champs sont ceux de l'onglet Menaces d'une communauté (cf. Bruit de fond pirate) :

  • Aperçu montre la première équipe, et la nomme au-dessus de ses messages : le contenu est identique chez toutes, seules leurs clés diffèrent. Le téléchargement rejoue cette équipe.
  • Lancer maintenant écrit un relevé par équipe, et le résultat liste ce que chacune reçoit. Une équipe qui ne peut pas recevoir — une destination sans URL, par exemple — refuse le lancement entier, en la nommant : rien ne part pour aucune.
  • Un pool sans équipe montre une note à la place du formulaire.

Lancer depuis l'onglet Menaces de n'importe quelle équipe fait de même : l'onglet le dit avant le clic, et mène à l'écran du pool. L'onglet du modèle ne lance rien, et y mène aussi.

Suivre les lancements​

La carte Lancements du pool liste les derniers lancements, une ligne par lancement, qu'il soit parti de cet écran ou de l'onglet d'une équipe :

ColonneCe qu'elle montre
ScénarioMène au scénario dans la bibliothèque.
DébutLa première minute jouée — la même chez toutes les équipes.
DuréeCe que dure le lancement.
CiblesLes hôtes sur lesquels le scénario joue — les mêmes chez toutes les équipes.
Envoyés / prévusAdditionnés sur les équipes ; les messages en échec sont nommés à côté.
ÉtatEn cours tant qu'une seule équipe a encore des messages en attente.
Équipes« 2 équipes », qui se déplie sur chacune : son avancement, son état, un lien vers ses menaces.

L'avancement est lu sur les lots envoyés, jamais stocké, et les suit en direct, comme les émissions plus haut. Une équipe détachée quitte cette liste ; ses relevés restent sur sa propre page.

Inventaires​

  • « Envoyer maintenant » sur un connecteur d'assets envoie l'inventaire de chaque équipe qui a un connecteur de ce format, toutes décrivant le même instant ; celles qui n'en ont pas sont nommées, et le modèle n'en est pas. L'inventaire quotidien fait de même : les équipes partagent un fuseau, elles sont donc dues au même passage — ou partent ensemble quand on active le pool.

Divergences​

La carte Divergences n'apparaît que lorsque des équipes ne partagent plus la même production. Le chemin d'écriture unique du pool ne peut pas en créer ; seule une écriture à côté — directement en base — le peut. La carte nomme le champ et les équipes qui s'écartent du modèle : tant qu'elle n'est pas corrigée, la session n'est pas équitable.

Détacher, supprimer​

  • « Détacher » rend une équipe à l'état de communauté ordinaire. Elle garde sa configuration et sa graine, donc continue de produire le contenu du pool — sans conséquence, mais bon à savoir.
  • Le modèle ne se détache pas : il porte la production des équipes.
  • Supprimer un pool détache ses équipes et son modèle, qui redevient une communauté ordinaire, arrêtée, avec ses clés et ses connecteurs d'avant. Cocher « Supprimer aussi ses équipes, leurs clés et leur historique (après le CTF) » les supprime avec lui — le nettoyage d'après session.

Ce que cela coûte​

  • Le volume × N. Cent utilisateurs font quelque 130 000 messages par jour et par équipe ; les charges utiles en file et les messages conservés 24 h montent d'autant. Les équipes reçoivent le même contenu à quelques secondes d'écart : l'envoyeur poste cinq lots à la fois.
  • Les inventaires. L'inventaire logiciel d'un pool prend environ ⌈N / 3⌉ × 2 minutes — trois exécutions de front, espacées par connecteur. Un rafraîchissement des CVE peut tomber entre deux équipes : l'instant partagé fige le moment décrit, pas le catalogue des vulnérabilités.
  • Un seul processus. Le verrou du planificateur et le cache des plans vivent dans la mémoire d'api-activity : des répliques demanderaient un verrou en base.