Saltar al contenido
toevan
Iniciar sesiónReserve un piloto de auditoría
Abrir menúCerrar menú
Reserve un piloto de auditoría

Mapa de controles · 2022, Annex A

ISO/IEC 27001

Evidencia de código para controles del Annex A, del manejo de secretos a la criptografía, y evidencia de cambios, acceso al código y configuración desde cada fusión.

Reserve un piloto de auditoríaVer un informe de muestra
ISO/IEC 27001 · 2022, Annex A26 controles en el alcance · según el mapeo de v1.4.1
  • Código 9
  • Proceso 6
  • Planificado 11

Evidencia de código

9controles comprobados en cada pull request

Activo (proceso)

6de fusiones, aprobaciones, cambios de reglas y despliegues y releases registrados por GitHub

Planificado

11se puede evidenciar desde el código o GitHub; aún no construido

Controles de nivel organizativo

Políticas, personas, proveedores, seguridad física y similares, enumerados más abajo.Toevan aporta evidencia de apoyo para 2 de ellos.Gestionados por los procesos de su organización

Una auditoría de certificación o de seguimiento pide evidencia de que los controles del Annex A están implantados y en funcionamiento. En ingeniería, eso significa la gestión de cambios y el desarrollo seguro.

El blueprint de ISO/IEC 27001 aporta evidencia de código para controles del Annex A, desde el manejo de secretos hasta la criptografía. La evidencia de proceso de cada fusión añade aprobaciones de cambios, fases de compilación seguras, pruebas de seguridad de releases, límites de acceso al código y configuraciones aprobadas. Los controles organizativos, de personas y físicos quedan en su SGSI.

Toevan aporta evidencia para controles; nunca los certifica ni afirma que un marco esté cubierto. Si la evidencia es suficiente lo juzga su auditor. Los controles se muestran por id con los nombres cortos propios de Toevan; los títulos oficiales y el texto de los requisitos pertenecen al editor del marco.

Evidencia de código9

Sellada en cada pull request. Siempre parcial: el control también exige cosas fuera del código. Las reglas del blueprint ISO/IEC 27001 comprueban parte de cada uno en cada pull request.

  • A.5.15Reglas de accesoA.5 Temas organizativos
  • A.5.17Manejo de secretosA.5 Temas organizativos
  • A.8.2Límites de cuentas privilegiadasA.8 Temas tecnológicos
  • A.8.3Límites de lectura de datosA.8 Temas tecnológicos
  • A.8.8Corrección de fallos de softwareA.8 Temas tecnológicos
  • A.8.12Vías de fuga de datosA.8 Temas tecnológicos
  • A.8.20Salvaguardas de redA.8 Temas tecnológicos
  • A.8.22Zonas de redA.8 Temas tecnológicos
  • A.8.24Cifrado y clavesA.8 Temas tecnológicos

Activo (proceso)6

Pull requests fusionados, aprobaciones, checks obligatorios, protección de ramas, rulesets y bypasses, y despliegues y releases registrados por GitHub, cada uno sellado.

  • A.8.4Límites de acceso al códigoA.8 Temas tecnológicosEvidencia de proceso: protección de ramas, rulesets y cada bypass de una rama protegida, sellados como cambios de control.
  • A.8.9Configuraciones aprobadasA.8 Temas tecnológicosEvidencia de proceso: cambios en los rulesets del repositorio y en la protección de ramas, sellados con su estado anterior y posterior.
  • A.8.25Fases de compilación segurasA.8 Temas tecnológicosEvidencia de proceso: las revisiones y los checks obligatorios al fusionar muestran que el proceso de desarrollo se aplicó a cada cambio.
  • A.8.29Pruebas de seguridad de releasesA.8 Temas tecnológicosEvidencia de proceso: los checks de seguridad obligatorios superados al fusionar, por cambio.
  • A.8.31Separación de pruebas y producciónA.8 Temas tecnológicosEvidencia de proceso: un despliegue en producción de un commit que antes se desplegó con éxito en otro entorno. No muestra qué se probó allí ni la separación de acceso y datos entre entornos.
  • A.8.32Aprobaciones de cambiosA.8 Temas tecnológicosEvidencia de proceso: cada pull request fusionado en la rama por defecto se sella como un registro de cambio con sus aprobaciones sobre el commit final, los checks obligatorios al fusionar, quién lo fusionó, sus firmas y los veredictos de código que llevaba.

Registro de cambio rec_5b81d4e

datos de ejemplo
Pull request  payments-api #1921 · Add tenant check to refund handlerInformado + sellado
Aprobaciones  9d07…e3a4, c58f…71d0 · ambas sobre el commit final e81b2d0Informado + sellado
Independiente del autor  Sí, por id de cuenta de GitHubRecalculado
Checks obligatorios  ci/test ✓ · ci/lint ✓ · toevan/gate ✓Informado + sellado
Reglas vigentes  main-protection: 2 aprobaciones, checks obligatorios, commits firmadosInformado + sellado

De apoyo2

Toevan registra evidencia relacionada, pero la obligación es organizativa, así que nunca cuenta como cubierta.

  • A.5.3Separación de funcionesA.5 Temas organizativosSeparación de funciones por cambio: el autor frente a los aprobadores, calculado a partir de los ids de cuenta de GitHub. La obligación más amplia sigue siendo organizativa.
  • A.5.32Registros de derechos de softwareA.5 Temas organizativosEvidencia de apoyo: una regla registra evidencia relacionada con esta obligación. La obligación en sí es un trámite regulatorio.

Planificado11

Se puede evidenciar desde el código o GitHub. Todavía ninguna regla los comprueba; cada uno está planificado y ninguno cuenta hoy como evidencia.

  • A.5.16Ciclo de vida de identidadesA.5 Temas organizativos
  • A.5.18Revisión de permisosA.5 Temas organizativos
  • A.8.5Robustez del inicio de sesiónA.8 Temas tecnológicos
  • A.8.10Eliminación de datosA.8 Temas tecnológicos
  • A.8.11Enmascaramiento de datos sensiblesA.8 Temas tecnológicos
  • A.8.13Copias de seguridadA.8 Temas tecnológicos
  • A.8.15Registro de actividadA.8 Temas tecnológicos
  • A.8.26Exigencias de seguridad de aplicacionesA.8 Temas tecnológicos
  • A.8.27Hábitos de diseño seguroA.8 Temas tecnológicos
  • A.8.28Hábitos de codificación seguraA.8 Temas tecnológicos
  • A.8.33Cuidado de datos de pruebaA.8 Temas tecnológicos

Controles de nivel organizativo

Los controles de nivel organizativo (políticas, personas, proveedores, seguridad física y similares) siguen en manos del propio proceso de su organización; Toevan no se ocupa de ellos.

Mostrar la lista

A.5 Temas organizativos

A.5.1Conjunto de políticas escritasuna política de la organización
A.5.2Responsables de roles de seguridaduna política de la organización
A.5.4Respaldo de la direcciónuna política de la organización
A.5.5Contactos con autoridadesuna política de la organización
A.5.6Contactos con grupos de expertosuna política de la organización
A.5.7Seguimiento de noticias de atacantesun proceso operativo
A.5.8Pasos de seguridad en proyectosuna política de la organización
A.5.9Lista de activos con responsableuna política de la organización
A.5.10Reglas de uso de activosuna política de la organización
A.5.11Devolución de activosuna política de la organización
A.5.12Clasificación por sensibilidaduna política de la organización
A.5.13Marcado por sensibilidaduna política de la organización
A.5.14Reglas de transferencia de datosuna política de la organización
A.5.19Exigencias de seguridad a proveedorescontratos y proveedores
A.5.20Cláusulas de acuerdos con proveedorescontratos y proveedores
A.5.21Controles de la cadena de suministrocontratos y proveedores
A.5.22Revisión del servicio de proveedorescontratos y proveedores
A.5.23Reglas de uso de la nubeuna política de la organización
A.5.24Preparación ante incidentesun proceso operativo
A.5.25Clasificación de eventos por gravedadun proceso operativo
A.5.26Pasos de respuesta a incidentesun proceso operativo
A.5.27Aprendizaje de incidentesun proceso operativo
A.5.28Recogida de evidencia de incidentesun proceso operativo
A.5.29Planes de seguridad ante interrupcionesun proceso operativo
A.5.30Preparación para la recuperaciónun proceso operativo
A.5.31Seguimiento de obligaciones legalesun trámite regulatorio
A.5.33Custodia de registrosun trámite regulatorio
A.5.34Obligaciones de privacidadun trámite regulatorio
A.5.35Revisión independienteuna evaluación externa
A.5.36Revisión del cumplimiento de políticasuna evaluación externa
A.5.37Pasos operativos escritosuna política de la organización

A.6 Temas de personas

A.6.1Antecedentes al contratarun asunto de personas y RR. HH.
A.6.2Deberes de seguridad por escritoun asunto de personas y RR. HH.
A.6.3Formación en concienciación de seguridadun asunto de personas y RR. HH.
A.6.4Consecuencias de incumplir las reglasun asunto de personas y RR. HH.
A.6.5Deberes tras la salidaun asunto de personas y RR. HH.
A.6.6Compromisos de confidencialidadun asunto de personas y RR. HH.
A.6.7Salvaguardas del trabajo remotouna política de la organización
A.6.8Avisos de problemas del personalun proceso operativo

A.7 Temas físicos

A.7.1Perímetros seguros de instalacionesseguridad física
A.7.2Controles de entrada a instalacionesseguridad física
A.7.3Salas con llaveseguridad física
A.7.4Vigilancia de instalacionesseguridad física
A.7.5Protección contra incendio e inundaciónseguridad física
A.7.6Reglas de zonas segurasseguridad física
A.7.7Escritorios despejadosseguridad física
A.7.8Ubicación de equiposseguridad física
A.7.9Salvaguardas de activos fuera de sedeseguridad física
A.7.10Cuidado de unidades de discoseguridad física
A.7.11Respaldo ante cortes de energíaseguridad física
A.7.12Protección del cableadoseguridad física
A.7.13Mantenimiento de equiposseguridad física
A.7.14Borrado seguro de equiposseguridad física

A.8 Temas tecnológicos

A.8.1Protección de dispositivos de usuarioun proceso operativo
A.8.6Planificación de capacidadun proceso operativo
A.8.7Defensa frente a malwareun proceso operativo
A.8.14Capacidad de reservaun proceso operativo
A.8.16Vigilancia de comportamiento inusualun proceso operativo
A.8.17Sincronización de relojesun proceso operativo
A.8.18Límites a programas de utilidadun proceso operativo
A.8.19Aprobación de software en producciónun proceso operativo
A.8.21Reglas de servicios de redun proceso operativo
A.8.23Filtrado de tráfico webun proceso operativo
A.8.30Supervisión de desarrolladores externoscontratos y proveedores
A.8.34Salvaguardas de auditoríauna evaluación externa

Cómo usarlo en una auditoría

  1. Tome la población de los registros de cambio

    Cada pull request fusionado en la rama por defecto y cada push a una rama protegida que ningún pull request fusionado explique, en el periodo, capturados de GitHub en el momento, es un registro sellado que puede exportar para el muestreo. Puede repetir la población de la rama por defecto a partir del historial de git; las ramas de producción designadas están planificadas.

  2. Lea la evidencia de código del periodo

    Cada pull request lleva resultados de código sellados frente a las reglas del blueprint, fijados al commit y a la versión del conjunto de reglas vigente.

  3. Pruebe una muestra

    Para cada registro muestreado, compruebe sus resultados y luego verifíquelo sin conexión con la clave publicada, con openssl y la shell: obtenga la evidencia, confirme la clave, compruebe el registro. Para repetir toda la cadena, Toevan facilita el comando toevan a petición; aún no es público.

    Los tres pasos, con los comandos exactos

Cómo se obtuvo cada hecho6 etiquetas
Recalculado
Toevan lo calculó a partir del propio código o del historial de git.
Informado + sellado
GitHub lo informó; Toevan lo capturó en el evento y lo firmó.
Declarado + sellado
La organización lo declaró, como un cambio en lo que se comprueba; Toevan firmó la declaración y su historial.
Registro de Toevan, sin sellar
Guardado en la base de datos de Toevan pero no sellado en el libro, como una exención hoy. Ninguna firma lo protege.
Consumido
Tomado de los registros de despliegue y de release de GitHub y enlazado por commit o digest.
No capturado
No había una fuente fiable. Toevan no lo infiere.
A.8.4Aprobaciones de cambiosHoja de pruebas · datos de ejemplo
Población148 cambios: 146 pull requests fusionados y 2 pushes directos
Recalculado listado desde el historial de git y cotejado con los registros sellados
Muestra25 extraídos por el auditor, cada uno un registro sellado
AprobacionesInformado + sellado de GitHub en la fusión, independientes del autor
ExcepcionesSin PR 2 pushes directos el 19 sepHueco requisito de revisión desactivado durante 29 minutosAmbos constan en el registro.
Firmas25 / 25 ✓ Verified OK
El informe de muestra de evidencia de cambios muestra la evidencia tal como la recibe su auditor, con cada hecho etiquetado.Abrir el informe de muestra

Pruebe el mapeo en una auditoría real.

Traiga un repositorio y una auditoría próxima. Configuraremos el blueprint y guiaremos a su auditor en la verificación.

Reserve un piloto de auditoríaVer un informe de muestra
  • Un repositorio, un marco
  • Evidencia desde el primer pull request
  • Verificable sin una cuenta de Toevan