Les projets, en détail

• Un noyau partagé contient les outils communs ; chaque organisation reçoit sa propre instance.
• Le travail arrive branche par branche, jamais sur place.
• Chaque branche passe par une relecture indépendante, une analyse automatique qui bloque les données d'organisation, et une fusion approuvée par le responsable.

• Des relecteurs indépendants sont liés au commit exact : ce qui a été relu est ce qui est livré.
• Une analyse de marqueurs bloque les données d'organisation.
• Les tâches lourdes s'exécutent une à la fois, pour que les ressources partagées restent prévisibles.

• Il rapporte des faits sur l'hôte : charge, mémoire, disques, services, mises à jour en attente et ports à l'écoute. Des faits uniquement, ni secrets ni contenu de fichiers.
• Il n'exécute que les commandes d'une liste d'autorisation fixe, définie dans sa propre configuration locale, et plafonne la sortie qu'une commande renvoie. Tout le reste est refusé et signalé.
• Les commandes sont signées et portent une date d'expiration ; une commande expirée, ou déjà vue, est ignorée.
• Une clé par hôte, limitée aux chemins propres à cet hôte. Un dépôt de gestion de versions sert de transport et il n'y a aucun port entrant : l'hôte va vers l'extérieur, et rien n'entre.
• Déploiement dans l'ordre : d'abord les faits seuls et la lecture seule sur un hôte réel, les commandes en dernier.

La conception est celle décrite ci-dessus. Ce contre quoi elle ne protège pas :

• Un hôte compromis. La clé propre à l'hôte permet à un attaquant d'envoyer de faux faits pour cet hôte ; les dégâts se limitent aux chemins de cet hôte.
• La compromission de la clé de signature côté émetteur. Elle permettrait n'importe quelle commande autorisée sur tous les hôtes qui lui font confiance. La façon dont la clé est conservée et dont les commandes sont signées reste un point de conception ouvert.
• Une mauvaise liste d'autorisation. Les commandes ne sont sûres que dans la mesure de la configuration locale que rédige le propriétaire de l'hôte.

• Des zones regroupent les agents, les hôtes et les plateformes.
• Un filtre de légende affiche ou masque des types d'éléments.
• Une vue textuelle donne les mêmes informations sans l'image.

• Un contrôle est lié aux référentiels qu'il satisfait, aux risques qu'il atténue, aux preuves qui l'étayent et aux audits qui l'ont testé.
• Les référentiels, les exigences et les contrôles sont des enregistrements liés, pas des listes à plat ; les enregistrements d'audit et de test rattachent les constats aux contrôles testés.
• Politiques, problèmes, incidents, risque fournisseur, protection de la vie privée, continuité d'activité, obligations réglementaires et formation vivent dans le même graphe.
• Les flux de travail et les tableaux de bord sont construits à partir d'étapes, de déclencheurs et de vues réutilisables.
• Le rôle de chaque utilisateur détermine les écrans qui existent pour lui. Les locataires sont séparés, avec un contrôle d'accès qui refuse par défaut.
• Les changements sont enregistrés sous forme d'événements structurés (qui a changé quoi, de quelle valeur à quelle valeur) et les enregistrements conservent des versions datées, de sorte que « à quoi cela ressemblait-il alors » trouve une réponse.

• Un référentiel GRC hiérarchique et souple, fondé sur la CSA Cloud Controls Matrix, déployé dans toute l'entreprise.
• Correspondance automatisée des contrôles et flux de tâches pour les audits SMSI.
• Évaluations de sécurité internes menées sur le même socle.

• La méthodologie conçue de zéro et pilotée.
• Audits informatiques internes et externes coordonnés autour d'elle.
• Un référentiel de gestion documentaire conçu sur trois processus ITIL essentiels.

• Un système de contrôle interne et une matrice des risques et contrôles établis.
• Processus de gestion des comptes à privilèges développés.
• Audits informatiques coordonnés.