Preuves automatisées · 12 systèmes
Intégrations
StandardOS se connecte en lecture seule aux systèmes que vous exploitez déjà, lit des paramètres précis selon un calendrier et transforme chaque lecture en une entrée de preuve rattachée à la mesure de l'annexe A qu'elle soutient. Une vérification réussie garde cette entrée fraîche. Une vérification en échec la laisse expirer, de sorte que la régression apparaît dans vos notifications plutôt qu'à l'audit.
Des API en lecture seule. Aucun agent sur l'ordinateur de quiconque.
Chaque identifiant ci-dessous reçoit les autorisations listées sous lui et rien d'autre, et chacune d'elles est une autorisation de lecture. Rien de ce que détient StandardOS ne peut changer un paramètre, envoyer une commande ou inscrire un appareil. L'état des appareils est lu depuis le MDM que vous exploitez déjà. Le logiciel sur les machines des salariés est la plainte la plus bruyante contre les acteurs établis et, dans un comité d'entreprise européen, une conversation sur la surveillance avant d'être une mesure. Nous n'avons pas cette conversation parce que nous n'installons rien.
À elles toutes, les 12 connexions produisent des preuves pour 52 des 93 mesures de l'annexe A. Chaque page de mesure nomme la lecture qui la sous-tend, et chaque carte ci-dessous renvoie aux mesures qu'elle couvre.
Identité et annuaire
Microsoft Entra ID
Combien de personnes détiennent le rôle d'administrateur général, si des comptes invités existent, et si l'authentification multifacteur est réellement exigée pour se connecter.
Ce qui est vérifié
- Les administrateurs généraux sont peu nombreux et identifiés
- Les comptes invités externes sont connus
- L'authentification multifacteur est exigée pour se connecter, par les paramètres de sécurité par défaut ou une stratégie d'accès conditionnel activée
- Administrateur général est activé au besoin, pas détenu en permanence
- L'authentification héritée est bloquée
- Les rôles d'annuaire sont couverts par une politique MFA
- Une politique exige un appareil conforme ou joint
- Aucun compte activé n'est resté 90 jours sans connexion
- Les secrets et certificats d'application durent deux ans au plus
- Les invitations d'invités sont restreintes et les invités voient peu
- Chaque administrateur a un second facteur enregistré
Ce que l'identifiant peut voir
- Directory.Read.All
- Policy.Read.All
- RoleManagement.Read.Directory
Une inscription d'application avec des autorisations d'application, consentie une fois par un administrateur. Chaque autorisation est une autorisation de lecture, donc l'identifiant ne peut rien changer dans le locataire.
Preuve pour
Okta
Vos personnes, pour tenir le registre du personnel à jour, et les états de compte qui signifient que quelqu'un n'a jamais été complètement intégré ou complètement retiré.
Ce qui est vérifié
- Les utilisateurs de l'annuaire sont synchronisés dans le registre du personnel, et quiconque est actif ici mais a disparu d'Okta est nommé
- Aucun compte n'est bloqué à mi-chemin de son intégration
- Les comptes suspendus sont identifiés
- Les comptes verrouillés sont visibles
- Super Administrator est détenu par quelques personnes nommées
- Aucun compte actif n'est resté 90 jours sans connexion
- Chaque super administrateur a un facteur actif enregistré
- Les rôles d'administrateur sont détenus par peu de comptes
Ce que l'identifiant peut voir
- okta.users.read
- okta.roles.read
Un jeton d'API en lecture seule. Il hérite des droits de l'administrateur qui le crée, il est donc créé en tant qu'administrateur en lecture seule.
Preuve pour
Google Workspace
Vos personnes, pour tenir le registre du personnel à jour, puis la validation en deux étapes sur tout le domaine et qui détient le rôle de super-administrateur.
Ce qui est vérifié
- Les utilisateurs de l'annuaire sont synchronisés dans le registre du personnel, et quiconque est actif ici mais a disparu de Workspace est nommé
- La validation en deux étapes est activée sur tout le domaine
- Les super-administrateurs sont peu nombreux et utilisent tous la validation en deux étapes
- Les comptes suspendus sont identifiés
- Aucun compte actif n'est resté 90 jours sans connexion
- La validation en deux étapes est imposée, pas seulement activée
- Les rôles d'administrateur sont détenus par peu de comptes
Ce que l'identifiant peut voir
- https://www.googleapis.com/auth/admin.directory.user.readonly
Un compte de service avec délégation au niveau du domaine pour l'unique portée d'annuaire en lecture seule, agissant au nom d'un administrateur que vous nommez. Un compte de service n'a pas d'identité propre dans votre annuaire, c'est pourquoi Google l'exige.
Preuve pour
Système RH
Personio
Vos personnes depuis le système RH, pour tenir le registre du personnel à jour : qui est actif, en congé ou en intégration, et qui est parti.
Ce qui est vérifié
- Les utilisateurs de l'annuaire sont synchronisés dans le registre du personnel, et tout partant dans Personio encore actif ici est nommé
- Le système RH est la source du registre du personnel
- Chaque départ porte une date de fin
- Aucun emploi actif n'a dépassé sa date de fin de contrat
- Chaque emploi actif nomme un responsable
Ce que l'identifiant peut voir
Une intégration personnalisée sous Marketplace, Intégrations connectées, avec l'unique portée de lecture des personnes. L'API de Personio ne prend pas de sous-domaine ; l'identifiant désigne l'entreprise, et rien ici n'écrit dans un dossier RH.
Preuve pour
Infrastructure cloud
Amazon Web Services
MFA et clés d'accès du compte racine, utilisateurs de la console sans MFA, âge des clés d'accès, stratégie de mots de passe du compte, blocage de l'accès public S3 au niveau du compte, couverture CloudTrail, chiffrement RDS, rétention des sauvegardes et Multi-AZ, si un enregistreur AWS Config tourne, si une instance EC2 tourne dans le VPC par défaut, et si GuardDuty est activé.
Ce qui est vérifié
- Le compte racine a l'authentification multifacteur
- Le compte racine n'a aucune clé d'accès
- Toute personne ayant accès à la console utilise l'authentification multifacteur
- Les clés d'accès ont été renouvelées dans les 90 jours
- Une stratégie de mots de passe est définie sur le compte
- L'accès public S3 est bloqué pour tout le compte
- L'activité de l'API est journalisée dans toutes les régions
- Les bases de données sont chiffrées au repos dans la région que vous nommez
- Les bases de données conservent des sauvegardes automatiques au moins une semaine
- Les bases de données survivent à la perte d'une zone de disponibilité
- La configuration des ressources est enregistrée en continu
- Aucune charge de travail ne tourne dans le VPC par défaut
- La détection des menaces est activée
- L'accès administratif complet passe par des rôles, pas par des utilisateurs permanents
- Les instances gérées exécutent un service de synchronisation horaire
- Aucun mot de passe de console ni clé d'accès ne reste inutilisé 90 jours
- Le compte root n'est pas utilisé pour le travail quotidien
- Les nouveaux volumes EBS sont chiffrés par défaut
- Aucun groupe de sécurité n'ouvre SSH, RDP ou un port de base de données à Internet
- Chaque VPC enregistre des journaux de flux
- Les clés KMS gérées par le client tournent automatiquement
- IAM Access Analyzer surveille les ressources partagées hors du compte
- Un plan de sauvegarde est planifié
- Les alarmes CloudWatch portent une action qui atteint quelqu'un
- Les images de conteneurs sont analysées à l'envoi pour les vulnérabilités connues
- AWS dispose d'un contact sécurité à qui écrire
- La capacité est surveillée
- Un plan de sauvegarde copie vers une autre région ou un autre coffre
Ce que l'identifiant peut voir
- arn:aws:iam::aws:policy/SecurityAudit
Un utilisateur IAM détenant une seule stratégie gérée par AWS, SecurityAudit, en lecture seule par construction. Nommer la stratégie plutôt que lister des actions signifie que personne n'assemble une stratégie trop large en devinant, et vous pouvez vérifier que c'est celle qu'AWS publie.
Preuve pour
Microsoft Azure
Comptes de stockage autorisant l'accès public aux blobs ou le HTTP en clair, bases SQL sans chiffrement transparent des données, leur rétention de sauvegarde et leur redondance de zone, abonnements dont le journal d'activité n'est expédié nulle part de durable, groupes de sécurité réseau ouvrant SSH ou RDP à Internet, stratégies de cycle de vie du stockage, et quels plans Defender pour le cloud sont actifs.
Ce qui est vérifié
- Les comptes de stockage n'autorisent pas l'accès public aux blobs
- Les comptes de stockage exigent HTTPS et TLS 1.2 ou ultérieur
- Les bases SQL sont chiffrées au repos
- Les bases SQL conservent des sauvegardes à un instant donné au moins une semaine
- Les bases SQL survivent à la perte d'une zone de disponibilité
- L'activité de l'abonnement est journalisée quelque part de durable
- Aucun groupe de sécurité réseau n'ouvre SSH ou RDP à Internet
- Les comptes de stockage ont une stratégie de cycle de vie pour les données vieillissantes
- Defender pour le cloud surveille au moins un type de ressource
- Les Key Vaults ont la suppression réversible et la protection contre la purge
- Les comptes de stockage conservent un temps les blobs supprimés
- Les serveurs SQL auditent les accès
- Aucune règle de pare-feu SQL n'admet tout Internet
- Les groupes de sécurité réseau enregistrent des journaux de flux
- Defender for Cloud a un contact sécurité à notifier
- Azure Policy est affecté sur chaque abonnement
- Un coffre Recovery Services sauvegarde quelque chose
Ce que l'identifiant peut voir
- Reader (Azure role, on each subscription in scope)
L'inscription d'application Entra ID, dotée du rôle intégré Lecteur sur chaque abonnement à lire. Lecteur est en lecture seule par construction, attribué par abonnement, et la même inscription connecte déjà Entra ID et Intune.
Preuve pour
Google Cloud
Buckets lisibles par le public, instances Cloud SQL sans TLS ou ouvertes à Internet, clés de compte de service à renouveler, journalisation d'audit des accès aux données par projet, et règles de pare-feu ouvrant SSH ou RDP au monde entier, ainsi que si chaque instance Cloud SQL effectue des sauvegardes automatiques et s'étend sur plusieurs zones, et si chaque bucket a une règle de cycle de vie.
Ce qui est vérifié
- Aucun bucket Cloud Storage n'est lisible par le public
- Les instances Cloud SQL exigent TLS et ne sont pas ouvertes à Internet
- Les instances Cloud SQL effectuent des sauvegardes automatiques
- Les instances Cloud SQL survivent à la perte d'une zone
- Les buckets Cloud Storage ont une règle de cycle de vie pour les données vieillissantes
- Les clés de compte de service ont été renouvelées dans les 90 jours
- Les journaux d'audit des accès aux données sont activés pour tous les services
- Aucune règle de pare-feu n'ouvre SSH ou RDP à Internet
- Les buckets Cloud Storage conservent les versions des objets
- Les buckets Cloud Storage utilisent l'accès uniforme au niveau du bucket
- Les instances Cloud SQL sont protégées contre la suppression
- Aucune personne ne détient le rôle de base Owner ou Editor
- Aucune machine virtuelle n'a d'adresse publique
- Les sous-réseaux enregistrent des journaux de flux
- Aucun projet ne conserve le réseau par défaut en mode automatique
- Les clés Cloud KMS tournent selon un calendrier
- Google a un contact sécurité pour chaque projet
Ce que l'identifiant peut voir
- roles/iam.securityReviewer (project role)
Une clé de compte de service avec le rôle intégré Security Reviewer sur chaque projet du périmètre. Le rôle est en lecture seule par construction, et chaque projet actif que le compte peut voir est lu ; rien ici n'écrit.
Preuve pour
Code source
GitHub
Si l'authentification à deux facteurs est exigée, quels dépôts sont publics, si les branches par défaut exigent une revue, combien de temps les alertes Dependabot restent ouvertes, si les fusions exigent des vérifications de statut réussies, et si les déploiements passent par un environnement protégé.
Ce qui est vérifié
- L'authentification à deux facteurs est exigée dans toute l'organisation, ou activée sur le compte
- Les dépôts de code source sont privés
- Les branches par défaut exigent une revue avant fusion
- Les alertes Dependabot sont corrigées dans le délai de remédiation : 14 jours pour critique, 30 pour élevé, 90 pour moyen, 180 pour faible
- Les branches par défaut exigent des tests réussis avant fusion
- Les déploiements en production passent par un environnement protégé
- Chaque dépôt nomme ses propriétaires de code et exécute un workflow à chaque changement
- Personne hors de l'organisation ne peut pousser sans accord
Ce que l'identifiant peut voir
- read:org
- repo (read-only)
- security_events (read-only)
- read:user
Un jeton d'accès personnel, classique ou à granularité fine, avec les portées en lecture seule listées. Toute portée sauf repo est facultative : une vérification qui en a besoin d'une qu'on ne lui a pas donnée dit laquelle manque au lieu de signaler un échec.
Preuve pour
Gestion des vulnérabilités
Snyk
Les problèmes ouverts mesurés contre vos délais de remédiation, si chaque projet est réellement analysé, et si le dernier test d'un projet est trop ancien pour signifier quoi que ce soit.
Ce qui est vérifié
- Les résultats ouverts sont corrigés dans le délai de remédiation : 14 jours pour critique, 30 pour élevé, 90 pour moyen, 180 pour faible
- Chaque projet a été testé, de sorte qu'un projet sans résultat est un projet analysé et non un projet sauté
- Chaque projet a été testé dans les 30 derniers jours
- Aucun secret n'est commité dans un dépôt analysé
- Les problèmes élevés et critiques ignorés sont décidés, pas oubliés
- Les pull requests sont testées avant la fusion
Ce que l'identifiant peut voir
Un jeton d'API d'un compte détenant le rôle Viewer sur l'organisation. Rien ici n'écrit.
Preuve pour
Appareils gérés
Kandji
Chiffrement du disque et verrouillage de l'écran sur votre parc Apple, et quels appareils ont cessé de se signaler. Lu depuis le MDM que vous exploitez déjà, sans aucun agent de notre part.
Ce qui est vérifié
- Les appareils gérés sont chiffrés au repos
- Les appareils gérés se verrouillent sans surveillance
- Les appareils gérés se sont signalés dans les 30 jours
- Les Mac gérés ont un verrou de récupération ou un mot de passe de firmware
- Les appareils gérés sont supervisés, la gestion ne peut donc pas être retirée
- Les Mac gérés ne portent pas plus d'un administrateur local
Ce que l'identifiant peut voir
- Device List (read)
- Device Details (read)
Un jeton d'API limité, dans les propres paramètres de Kandji, aux deux autorisations de lecture des appareils. Rien ici n'écrit.
Preuve pour
Jamf Pro
FileVault, verrouillage de l'écran et Gatekeeper sur votre parc Mac, et quels appareils ont cessé de se signaler. Lu depuis le MDM que vous exploitez déjà, sans aucun agent de notre part.
Ce qui est vérifié
- Les appareils gérés sont chiffrés au repos, un Mac ne comptant comme chiffré que lorsque chaque compte qu'il héberge l'est
- Les appareils gérés se verrouillent sans surveillance
- Les appareils gérés exécutent une protection des terminaux, lue depuis Gatekeeper
- Les appareils gérés se sont signalés dans les 30 jours
- Les Mac gérés exécutent le pare-feu applicatif
- Aucun Mac géré n'ouvre une session automatiquement au démarrage
- La protection de l'intégrité du système et le démarrage sécurisé complet sont actifs
Ce que l'identifiant peut voir
- Read Computers
- Read Computer Inventory Collection
Un client d'API avec un rôle d'API détenant exactement deux privilèges de lecture, échangé contre un jeton de courte durée. Pas le nom d'utilisateur et le mot de passe de l'API classique, qui seraient un identifiant capable aussi d'effacer un ordinateur portable.
Preuve pour
Microsoft Intune
Chiffrement du disque sur vos appareils gérés et lesquels ont cessé de se synchroniser. La même inscription d'application qu'Entra ID, avec une autorisation de lecture supplémentaire.
Ce qui est vérifié
- Les appareils gérés sont chiffrés au repos
- Les appareils gérés se sont signalés dans les 30 jours
- Les appareils gérés respectent leurs stratégies de conformité
- Aucun appareil géré n'est jailbreaké ni rooté
- Un partenaire de défense contre les menaces signale chaque appareil géré comme sûr
Ce que l'identifiant peut voir
- DeviceManagementManagedDevices.Read.All
L'inscription d'application Entra ID avec une autorisation d'application supplémentaire, consentie une fois. Un client qui a connecté Entra ajoute l'autorisation et connecte ceci avec le même ID client et le même secret.
Preuve pour
Comment une lecture devient une preuve
1. Vous connectez, et l'identifiant est vérifié avant d'être conservé
L'identifiant est d'abord essayé auprès du fournisseur. S'il fonctionne, il est stocké là où aucune session de navigateur ne peut le lire, et la première exécution a lieu immédiatement, pour que vous voyiez des résultats avant de quitter la page.
2. Chaque vérification tourne chaque jour et tient une entrée de preuve
Une vérification réussie prolonge la validité de l'entrée. Une vérification en échec la ramène à aujourd'hui, de sorte qu'elle expire comme un certificat périmé et apparaît au même endroit. Une vérification qui n'a pas pu lire ce dont elle avait besoin le dit, et dit quelle autorisation accorder, au lieu de signaler un échec qu'elle n'a pas observé.
3. Une réussite qui devient un échec envoie un e-mail à vos administrateurs
Une fois, au basculement. Un paramètre qui était correct hier soir et faux ce matin est le seul événement qui vaille un e-mail ; un paramètre faux depuis un mois est déjà dans vos notifications.
Ce qui n'est pas intégré
La question qu'une comparaison du nombre de fonctionnalités pose vraiment. Voici la réponse, pour que vous n'ayez pas à la découvrir après l'inscription.
Un agent sur l'ordinateur de quiconque
Délibérément, et définitivement. Tout ce qui concerne un appareil est lu depuis le MDM que vous exploitez déjà. Les agents sur les terminaux sont la plainte la plus bruyante contre les acteurs établis, et dans un comité d'entreprise européen ils sont une conversation sur le logiciel de surveillance avant d'être une mesure.
D'autres systèmes RH
Personio est lu ; BambooHR, HiBob, Workday et les autres ne le sont pas. Pour une entreprise dont les personnes vivent d'abord dans Okta ou Google Workspace, ce sont eux qui tiennent le registre à jour.
Plateformes de tickets, de chat et de journalisation
Les enregistrements d'incidents et de changements sont tenus dans StandardOS lui-même, sur sa propre chaîne d'empreintes. Rien n'est lu depuis Jira, Slack ou un SIEM.
Connecté en quelques minutes, lu chaque nuit
Chaque connexion est un formulaire avec les champs ci-dessus et rien d'autre. L'export que reçoit votre auditeur est organisé par référence de l'annexe A, et chaque entrée automatisée y nomme le système d'où elle a été lue et le jour de la lecture.
Les noms d'autorisation sont cités tels que chaque fournisseur les écrit, pour que vous puissiez les rapprocher de la console du fournisseur au moment de les accorder.