Evidencia automatizada · 12 sistemas
Integraciones
StandardOS se conecta en solo lectura a los sistemas que ya utiliza, lee ajustes concretos según un calendario y convierte cada lectura en una entrada de evidencia asociada al control del Anexo A que respalda. Una comprobación superada mantiene fresca esa entrada. Una fallida la deja caducar, de modo que la regresión aparece en sus notificaciones y no en la auditoría.
APIs de solo lectura. Ningún agente en el portátil de nadie.
Cada credencial de abajo recibe los permisos indicados bajo ella y nada más, y todos ellos son permisos de lectura. Nada de lo que StandardOS guarda puede cambiar un ajuste, enviar un comando o inscribir un dispositivo. El estado de los dispositivos se lee del MDM que ya utiliza. El software en los equipos de los empleados es la queja más sonora contra los proveedores establecidos y, en un comité de empresa europeo, una conversación sobre vigilancia antes que un control. Nosotros no tenemos esa conversación porque no instalamos nada.
Entre todas, las 12 conexiones producen evidencia para 52 de los 93 controles del Anexo A. Cada página de control nombra la lectura que hay detrás, y cada tarjeta de abajo enlaza con los controles que cubre.
Identidad y directorio
Microsoft Entra ID
Cuántas personas tienen el rol de administrador global, si existen cuentas de invitado y si la autenticación multifactor se exige realmente para iniciar sesión.
Qué comprueba
- Los administradores globales son pocos e identificados
- Las cuentas de invitado externas son conocidas
- La autenticación multifactor se exige para iniciar sesión, mediante los valores predeterminados de seguridad o una directiva de acceso condicional activada
- Administrador global se activa cuando hace falta, no se mantiene de forma permanente
- La autenticación heredada está bloqueada
- Los roles de directorio están cubiertos por una política MFA
- Una política exige un dispositivo conforme o unido
- Ninguna cuenta habilitada lleva 90 días sin iniciar sesión
- Los secretos y certificados de aplicación duran como mucho dos años
- Las invitaciones de invitados están restringidas y los invitados ven poco
- Cada administrador tiene un segundo factor registrado
Qué puede ver la credencial
- Directory.Read.All
- Policy.Read.All
- RoleManagement.Read.Directory
Un registro de aplicación con permisos de aplicación, consentido una vez por un administrador. Todos los permisos son de lectura, así que la credencial no puede cambiar nada en el inquilino.
Evidencia para
Okta
Sus personas, para mantener actualizado el registro de empleados, y los estados de cuenta que significan que alguien nunca se incorporó del todo o nunca se dio de baja del todo.
Qué comprueba
- Los usuarios del directorio se sincronizan con el registro de empleados, y se nombra a quien está activo aquí pero ha desaparecido de Okta
- Ninguna cuenta se ha quedado a medias en la incorporación
- Las cuentas suspendidas están identificadas
- Las cuentas bloqueadas son visibles
- Super Administrator lo tienen pocas personas, con nombre
- Ninguna cuenta activa lleva 90 días sin iniciar sesión
- Cada superadministrador tiene un factor activo registrado
- Los roles de administrador los tienen pocas cuentas
Qué puede ver la credencial
- okta.users.read
- okta.roles.read
Un token de API de solo lectura. Hereda los permisos del administrador que lo crea, por lo que se crea como administrador de solo lectura.
Evidencia para
Google Workspace
Sus personas, para mantener actualizado el registro de empleados, y después la verificación en dos pasos en todo el dominio y quién es superadministrador.
Qué comprueba
- Los usuarios del directorio se sincronizan con el registro de empleados, y se nombra a quien está activo aquí pero ha desaparecido de Workspace
- La verificación en dos pasos está activada en todo el dominio
- Los superadministradores son pocos, y todos usan la verificación en dos pasos
- Las cuentas suspendidas están identificadas
- Ninguna cuenta activa lleva 90 días sin iniciar sesión
- La verificación en dos pasos se impone, no solo se activa
- Los roles de administrador los tienen pocas cuentas
Qué puede ver la credencial
- https://www.googleapis.com/auth/admin.directory.user.readonly
Una cuenta de servicio con delegación en todo el dominio para el único ámbito de directorio de solo lectura, que actúa en nombre de un administrador que usted designa. Una cuenta de servicio no tiene identidad propia en su directorio, y por eso Google lo exige.
Evidencia para
Sistema de RR. HH.
Personio
Sus personas desde el sistema de RR. HH., para mantener actualizado el registro de empleados: quién está activo, de permiso o incorporándose, y quién se ha ido.
Qué comprueba
- Los usuarios del directorio se sincronizan con el registro de empleados, y se nombra a toda baja en Personio que siga activa aquí
- El sistema de RR. HH. es la fuente del registro de empleados
- Cada baja lleva una fecha de salida
- Ningún empleo activo ha superado su fecha de fin de contrato
- Cada empleo activo nombra un supervisor
Qué puede ver la credencial
Una integración personalizada en Marketplace, Integraciones conectadas, con el único ámbito de lectura de personas. La API de Personio no admite subdominio; la credencial identifica a la empresa, y nada aquí escribe en un expediente de RR. HH.
Evidencia para
Infraestructura en la nube
Amazon Web Services
MFA y claves de acceso de la cuenta raíz, usuarios de consola sin MFA, antigüedad de las claves de acceso, la política de contraseñas de la cuenta, el bloqueo de acceso público a S3 a nivel de cuenta, la cobertura de CloudTrail, el cifrado de RDS, la retención de copias de seguridad y Multi-AZ, si hay un grabador de AWS Config en marcha, si alguna instancia EC2 se ejecuta en la VPC predeterminada y si GuardDuty está activado.
Qué comprueba
- La cuenta raíz tiene autenticación multifactor
- La cuenta raíz no tiene claves de acceso
- Todo el que tiene acceso a la consola usa autenticación multifactor
- Las claves de acceso se han rotado en los últimos 90 días
- Hay una política de contraseñas establecida en la cuenta
- El acceso público a S3 está bloqueado para toda la cuenta
- La actividad de la API se registra en todas las regiones
- Las bases de datos están cifradas en reposo en la región que usted indica
- Las bases de datos conservan copias de seguridad automáticas al menos una semana
- Las bases de datos sobreviven a la pérdida de una zona de disponibilidad
- La configuración de los recursos se registra de forma continua
- Ninguna carga de trabajo se ejecuta en la VPC predeterminada
- La detección de amenazas está activada
- El acceso administrativo completo se ejerce mediante roles, no usuarios permanentes
- Las instancias gestionadas ejecutan un servicio de sincronización horaria
- Ninguna contraseña de consola ni clave de acceso queda sin uso 90 días
- La cuenta raíz no se usa para el trabajo diario
- Los volúmenes EBS nuevos se cifran por defecto
- Ningún grupo de seguridad abre SSH, RDP o un puerto de base de datos a Internet
- Cada VPC registra flow logs
- Las claves KMS gestionadas por el cliente rotan automáticamente
- IAM Access Analyzer vigila los recursos compartidos fuera de la cuenta
- Hay un plan de copias de seguridad programado
- Las alarmas de CloudWatch llevan una acción que llega a alguien
- Las imágenes de contenedor se analizan al subirlas en busca de vulnerabilidades conocidas
- AWS tiene un contacto de seguridad al que escribir
- La capacidad está vigilada
- Un plan de copia de seguridad copia a otra región o bóveda
Qué puede ver la credencial
- arn:aws:iam::aws:policy/SecurityAudit
Un usuario de IAM con una única política gestionada por AWS, SecurityAudit, que es de solo lectura por construcción. Nombrar la política en vez de enumerar acciones significa que nadie arma a ojo una política demasiado amplia, y usted puede verificar que es la que AWS publica.
Evidencia para
Microsoft Azure
Cuentas de almacenamiento que permiten acceso público a blobs o HTTP sin cifrar, bases de datos SQL sin cifrado de datos transparente, su retención de copias de seguridad y redundancia de zona, suscripciones cuyo registro de actividad no se envía a ningún sitio duradero, grupos de seguridad de red que abren SSH o RDP a internet, políticas de ciclo de vida del almacenamiento y qué planes de Defender for Cloud están activos.
Qué comprueba
- Las cuentas de almacenamiento no permiten acceso público a blobs
- Las cuentas de almacenamiento exigen HTTPS y TLS 1.2 o posterior
- Las bases de datos SQL están cifradas en reposo
- Las bases de datos SQL conservan copias de seguridad a un momento dado al menos una semana
- Las bases de datos SQL sobreviven a la pérdida de una zona de disponibilidad
- La actividad de la suscripción se registra en algún sitio duradero
- Ningún grupo de seguridad de red abre SSH o RDP a internet
- Las cuentas de almacenamiento tienen una política de ciclo de vida para datos que envejecen
- Defender for Cloud vigila al menos un tipo de recurso
- Los Key Vaults tienen eliminación temporal y protección contra purga
- Las cuentas de almacenamiento conservan un tiempo los blobs eliminados
- Los servidores SQL auditan los accesos
- Ninguna regla de firewall de SQL admite todo Internet
- Los grupos de seguridad de red registran flow logs
- Defender for Cloud tiene un contacto de seguridad al que avisar
- Azure Policy está asignado en cada suscripción
- Un almacén de Recovery Services respalda algo
Qué puede ver la credencial
- Reader (Azure role, on each subscription in scope)
El registro de aplicación de Entra ID, con el rol integrado Lector en cada suscripción que quiera leer. Lector es de solo lectura por construcción, se asigna por suscripción, y el mismo registro ya conecta Entra ID e Intune.
Evidencia para
Google Cloud
Buckets legibles por el público, instancias de Cloud SQL sin TLS o abiertas a internet, claves de cuenta de servicio pendientes de rotación, registro de auditoría de acceso a datos por proyecto y reglas de cortafuegos que abren SSH o RDP a todo el mundo, además de si cada instancia de Cloud SQL hace copias de seguridad automáticas y se ejecuta en varias zonas y si cada bucket tiene una regla de ciclo de vida.
Qué comprueba
- Ningún bucket de Cloud Storage es legible por el público
- Las instancias de Cloud SQL exigen TLS y no están abiertas a internet
- Las instancias de Cloud SQL hacen copias de seguridad automáticas
- Las instancias de Cloud SQL sobreviven a la pérdida de una zona
- Los buckets de Cloud Storage tienen una regla de ciclo de vida para datos que envejecen
- Las claves de cuenta de servicio se han rotado en los últimos 90 días
- Los registros de auditoría de acceso a datos están activados en todos los servicios
- Ninguna regla de cortafuegos abre SSH o RDP a internet
- Los buckets de Cloud Storage conservan versiones de los objetos
- Los buckets de Cloud Storage usan acceso uniforme a nivel de bucket
- Las instancias de Cloud SQL están protegidas contra la eliminación
- Ninguna persona tiene el rol básico Owner o Editor
- Ninguna máquina virtual tiene una dirección pública
- Las subredes registran flow logs
- Ningún proyecto conserva la red predeterminada en modo automático
- Las claves de Cloud KMS rotan según un calendario
- Google tiene un contacto de seguridad para cada proyecto
Qué puede ver la credencial
- roles/iam.securityReviewer (project role)
Una clave de cuenta de servicio con el rol integrado Security Reviewer en cada proyecto del alcance. El rol es de solo lectura por construcción, y se lee cada proyecto activo que la cuenta puede ver; nada aquí escribe.
Evidencia para
Código fuente
GitHub
Si se exige la autenticación de dos factores, qué repositorios son públicos, si las ramas predeterminadas exigen revisión, cuánto tiempo permanecen abiertos los hallazgos de Dependabot, si las fusiones exigen comprobaciones de estado superadas y si los despliegues pasan por un entorno protegido.
Qué comprueba
- La autenticación de dos factores se exige en toda la organización, o está activada en la cuenta
- Los repositorios de código fuente son privados
- Las ramas predeterminadas exigen revisión antes de fusionar
- Los hallazgos de Dependabot se corrigen dentro del plazo de remediación: 14 días para crítico, 30 para alto, 90 para medio, 180 para bajo
- Las ramas predeterminadas exigen pruebas superadas antes de fusionar
- Los despliegues a producción pasan por un entorno protegido
- Cada repositorio nombra a sus propietarios de código y ejecuta un flujo de trabajo en cada cambio
- Nadie ajeno a la organización puede hacer push sin un acuerdo
Qué puede ver la credencial
- read:org
- repo (read-only)
- security_events (read-only)
- read:user
Un token de acceso personal, clásico o de grano fino, con los ámbitos de solo lectura indicados. Todo ámbito salvo repo es opcional: una comprobación que necesita uno que no se le dio dice cuál falta en lugar de informar de un fallo.
Evidencia para
Gestión de vulnerabilidades
Snyk
Problemas abiertos medidos frente a sus plazos de remediación, si cada proyecto se está analizando realmente y si la última prueba de algún proyecto es demasiado antigua para significar algo.
Qué comprueba
- Los hallazgos abiertos se corrigen dentro del plazo de remediación: 14 días para crítico, 30 para alto, 90 para medio, 180 para bajo
- Todos los proyectos se han probado, de modo que un proyecto sin hallazgos es uno que se analizó y no uno que se omitió
- Todos los proyectos se han probado en los últimos 30 días
- Ningún secreto está confirmado en un repositorio analizado
- Los problemas altos y críticos ignorados están decididos, no olvidados
- Las pull requests se prueban antes de fusionarse
Qué puede ver la credencial
Un token de API de una cuenta con el rol Viewer en la organización. Nada aquí escribe.
Evidencia para
Dispositivos gestionados
Kandji
Cifrado de disco y bloqueo de pantalla en toda su flota Apple, y qué dispositivos han dejado de reportarse. Leído del MDM que ya utiliza, sin ningún agente nuestro en ningún sitio.
Qué comprueba
- Los dispositivos gestionados están cifrados en reposo
- Los dispositivos gestionados se bloquean cuando están desatendidos
- Los dispositivos gestionados se han reportado en los últimos 30 días
- Los Mac gestionados tienen bloqueo de recuperación o contraseña de firmware
- Los dispositivos gestionados están supervisados, así que la gestión no puede eliminarse
- Los Mac gestionados no tienen más de un administrador local
Qué puede ver la credencial
- Device List (read)
- Device Details (read)
Un token de API limitado, en la propia configuración de Kandji, a los dos permisos de lectura de dispositivos. Nada aquí escribe.
Evidencia para
Jamf Pro
FileVault, bloqueo de pantalla y Gatekeeper en toda su flota Mac, y qué dispositivos han dejado de reportarse. Leído del MDM que ya utiliza, sin ningún agente nuestro en ningún sitio.
Qué comprueba
- Los dispositivos gestionados están cifrados en reposo, contando un Mac como cifrado solo cuando lo están todas las cuentas que contiene
- Los dispositivos gestionados se bloquean cuando están desatendidos
- Los dispositivos gestionados ejecutan protección de endpoints, leída de Gatekeeper
- Los dispositivos gestionados se han reportado en los últimos 30 días
- Los Mac gestionados ejecutan el cortafuegos de aplicaciones
- Ningún Mac gestionado inicia sesión automáticamente al arrancar
- La protección de integridad del sistema y el arranque seguro completo están activos
Qué puede ver la credencial
- Read Computers
- Read Computer Inventory Collection
Un cliente de API con un rol de API que tiene exactamente dos privilegios de lectura, canjeado por un token de corta duración. No el usuario y la contraseña de la API clásica, que serían una credencial capaz también de borrar un portátil.
Evidencia para
Microsoft Intune
Cifrado de disco en sus dispositivos gestionados y cuáles han dejado de sincronizarse. El mismo registro de aplicación que Entra ID, con un permiso de lectura más.
Qué comprueba
- Los dispositivos gestionados están cifrados en reposo
- Los dispositivos gestionados se han reportado en los últimos 30 días
- Los dispositivos gestionados cumplen sus directivas de cumplimiento
- Ningún dispositivo gestionado tiene jailbreak ni root
- Un socio de defensa contra amenazas informa de cada dispositivo gestionado como seguro
Qué puede ver la credencial
- DeviceManagementManagedDevices.Read.All
El registro de aplicación de Entra ID con un permiso de aplicación adicional, consentido una vez. Un cliente que ha conectado Entra añade el permiso y conecta esto con el mismo ID de cliente y el mismo secreto.
Evidencia para
Cómo una lectura se convierte en evidencia
1. Usted conecta, y la credencial se comprueba antes de guardarse
La credencial se prueba primero contra el proveedor. Si funciona, se guarda donde ninguna sesión de navegador puede leerla, y la primera ejecución ocurre de inmediato para que vea resultados antes de salir de la página.
2. Cada comprobación se ejecuta a diario y mantiene una entrada de evidencia
Una comprobación superada prolonga la validez de la entrada. Una fallida la devuelve a hoy, de modo que caduca como un certificado vencido y aparece en el mismo lugar. Una comprobación que no pudo leer lo que necesitaba lo dice, y dice qué permiso conceder, en lugar de informar de un fallo que no observó.
3. Un superado que pasa a fallido envía un correo a sus administradores
Una vez, cuando cambia. Un ajuste que estaba bien anoche y está mal esta mañana es el único evento que merece un correo; un ajuste que lleva un mes mal ya está en sus notificaciones.
Qué no está integrado
La pregunta que de verdad hace una comparación por número de funciones. Aquí está la respuesta, para que no tenga que descubrirla después de registrarse.
Un agente en el portátil de cualquiera
Deliberadamente, y para siempre. Todo lo relativo a un dispositivo se lee del MDM que ya utiliza. Los agentes en los equipos son la queja más sonora contra los proveedores establecidos, y en un comité de empresa europeo son una conversación sobre software de vigilancia antes que un control.
Otros sistemas de RR. HH.
Personio se lee; BambooHR, HiBob, Workday y el resto no. Para una empresa cuyas personas viven primero en Okta o Google Workspace, son esos los que mantienen el registro actualizado.
Plataformas de tickets, chat y registro
Los registros de incidentes y cambios se guardan en el propio StandardOS, en su propia cadena de hashes. No se lee nada de Jira, Slack ni un SIEM.
Conectado en minutos, leído cada noche
Cada conexión es un formulario con los campos de arriba y nada más. La exportación que recibe su auditor está organizada por referencia del Anexo A, y cada entrada automatizada nombra el sistema del que se leyó y el día en que se leyó.
Los nombres de los permisos se citan tal como los escribe cada proveedor, para que pueda cotejarlos con la propia consola del proveedor al concederlos.