Registrar lo que ocurrió en sus sistemas

Cómo lo verifica StandardOS

Conectado en solo lectura, según un calendario. Una comprobación superada mantiene fresca una entrada de evidencia; una fallida la deja caducar, para que una regresión salga a la luz en lugar de esperar a la auditoría. Cada integración, y qué puede ver cada credencial.

• Google Cloud · StandardOS lee si los registros de auditoría de acceso a datos están activados para todos los servicios en cada proyecto, ya que la actividad administrativa se registra por defecto y quién leyó qué no.
• Microsoft Azure · StandardOS lee si cada suscripción envía su registro de actividad administrativa a un área de trabajo de Log Analytics, una cuenta de almacenamiento o un event hub, porque el portal guarda 90 días y después desaparece.
• AWS · StandardOS lee si CloudTrail cubre todas las regiones, porque la actividad en una región que ningún trail vigila queda sin registrar.
• Okta · StandardOS lee las cuentas bloqueadas, donde un bloqueo repetido en una misma cuenta es el patrón que merece atención, más que el bloqueo en sí.
• AWS · StandardOS lee si cada VPC de la región tiene un flow log activo.
• Microsoft Azure · StandardOS lee si cada servidor SQL escribe un registro de auditoría, y si cada grupo de seguridad de red tiene un flow log.
• Google Cloud · StandardOS lee si cada subred registra flow logs.

Qué preguntan los clientes sobre este control

Los cuestionarios de seguridad no usan números de control. Estas son las preguntas, tal como las plantean los clientes, que desembocan en A.8.15. Cada una se responde a partir de los mismos cuatro registros: el estado en la DdA, la política aprobada, evidencia fechada y una comprobación en vivo. El mapa completo de los treinta temas.

• ¿Se recogen los registros de seguridad de forma centralizada y se vigilan en busca de actividad sospechosa?

  Registro, monitorización, SIEM, alertas · también A.8.16