Mapa de controles · Rev 5, NIST SP 800-53B
NIST 800-53 Moderate
Evidencia de código para controles desde la aplicación del acceso hasta la protección en reposo, y control de cambios de configuración desde cada fusión.
Evidencia de código
12controles comprobados en cada pull requestActivo (proceso)
2de fusiones, aprobaciones, cambios de reglas y despliegues y releases registrados por GitHubPlanificado
23se puede evidenciar desde el código o GitHub; aún no construidoControles de nivel organizativo
Políticas, personas, proveedores, seguridad física y similares, enumerados más abajo.Toevan aporta evidencia de apoyo para 4 de ellos.Gestionados por los procesos de su organizaciónNIST SP 800-53 Moderate es la línea base sobre la que se construye FedRAMP; Toevan mapea la línea base sin las adiciones de FedRAMP. El control de cambios de configuración exige que los cambios se revisen, aprueben y documenten, y que solo personas autorizadas puedan hacerlos.
El blueprint de NIST 800-53 Moderate aporta evidencia de código para controles desde la aplicación del acceso hasta la protección en reposo. Los registros de cambio aportan evidencia para CM-3 Configuration Change Control y SA-10 Developer Configuration Management, con evidencia de apoyo para la separación de funciones, las restricciones de acceso para el cambio y la integridad.
Toevan aporta evidencia para controles; nunca los certifica ni afirma que un marco esté cubierto. Si la evidencia es suficiente lo juzga su auditor.
Evidencia de código12
Sellada en cada pull request. Siempre parcial: el control también exige cosas fuera del código. Las reglas del blueprint NIST 800-53 Moderate comprueban parte de cada uno en cada pull request.
AC-2Gestión de cuentasAC Control de accesoAC-3Aplicación del accesoAC Control de accesoAC-4Aplicación del flujo de informaciónAC Control de accesoAC-6Mínimo privilegioAC Control de accesoCM-2Configuración baseCM Gestión de configuraciónCM-6Ajustes de configuraciónCM Gestión de configuraciónIA-5Gestión de autenticadoresIA Identificación y autenticaciónSA-11Pruebas y evaluación del desarrolladorSA Adquisición de sistemas y serviciosSC-7Protección del perímetroSC Protección de sistemas y comunicacionesSC-8Confidencialidad e integridad de la transmisiónSC Protección de sistemas y comunicacionesSC-28Protección de la información en reposoSC Protección de sistemas y comunicacionesSI-2Corrección de fallosSI Integridad de sistemas e información
Activo (proceso)2
Pull requests fusionados, aprobaciones, checks obligatorios, protección de ramas, rulesets y bypasses, y despliegues y releases registrados por GitHub, cada uno sellado.
CM-3Control de cambios de configuraciónCM Gestión de configuraciónEvidencia 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.SA-10Gestión de configuración del desarrolladorSA Adquisición de sistemas y serviciosEvidencia de proceso: registros de cambio y cambios de control del repositorio de código fuente.
Registro de cambio rec_5b81d4e
datos de ejemploDe apoyo4
Toevan registra evidencia relacionada, pero la obligación es organizativa, así que nunca cuenta como cubierta.
AC-5Separación de funcionesAC Control de accesoSeparació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.CM-5Restricciones de acceso para cambiosCM Gestión de configuraciónQuién puede modificar ramas protegidas, y cada bypass, sellados como cambios de control. La gestión de accesos en sí sigue siendo organizativa.SI-7Integridad de software, firmware e informaciónSI Integridad de sistemas e informaciónDatos de firma de commits en cada cambio fusionado.SR-11Autenticidad de componentesSR Gestión del riesgo de la cadena de suministroEvidencia de apoyo: una atestación de GitHub que nombra el commit. Toevan no verifica la firma de la atestación. No se muestra la autenticidad de los componentes de terceros.
Planificado23
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.
AC-7Intentos fallidos de inicio de sesiónAC Control de accesoAC-11Bloqueo de dispositivoAC Control de accesoAC-12Cierre de sesiónAC Control de accesoAC-17Acceso remotoAC Control de accesoAU-2Registro de eventosAU Auditoría y responsabilidadAU-3Contenido de los registros de auditoríaAU Auditoría y responsabilidadAU-8Marcas de tiempoAU Auditoría y responsabilidadAU-9Protección de la información de auditoríaAU Auditoría y responsabilidadAU-11Conservación de registros de auditoríaAU Auditoría y responsabilidadAU-12Generación de registros de auditoríaAU Auditoría y responsabilidadCM-7Funcionalidad mínimaCM Gestión de configuraciónCP-9Copia de seguridad del sistemaCP Planificación de contingenciasIA-2Identificación y autenticación (usuarios de la organización)IA Identificación y autenticaciónIA-4Gestión de identificadoresIA Identificación y autenticaciónIA-6Retroalimentación de autenticaciónIA Identificación y autenticaciónIA-8Identificación y autenticación (usuarios externos a la organización)IA Identificación y autenticaciónRA-5Monitorización y análisis de vulnerabilidadesRA Evaluación de riesgosSC-12Establecimiento y gestión de claves criptográficasSC Protección de sistemas y comunicacionesSC-13Protección criptográficaSC Protección de sistemas y comunicacionesSC-23Autenticidad de la sesiónSC Protección de sistemas y comunicacionesSI-10Validación de entradas de informaciónSI Integridad de sistemas e informaciónSI-11Gestión de erroresSI Integridad de sistemas e informaciónSI-12Gestión y conservación de la informaciónSI Integridad de sistemas e información
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
AC Control de acceso
AT Concienciación y formación
AU Auditoría y responsabilidad
CA Evaluación, autorización y monitorización
CM Gestión de configuración
CP Planificación de contingencias
IA Identificación y autenticación
IR Respuesta a incidentes
MA Mantenimiento
MP Protección de soportes
PE Protección física y ambiental
PL Planificación
PS Seguridad del personal
RA Evaluación de riesgos
SA Adquisición de sistemas y servicios
SC Protección de sistemas y comunicaciones
SI Integridad de sistemas e información
SR Gestión del riesgo de la cadena de suministro
Cómo usarlo en una auditoría
- 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.
- 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.
- 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.
- 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.
Recalculado listado desde el historial de git y cotejado con los registros sellados
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.
- Un repositorio, un marco
- Evidencia desde el primer pull request
- Verificable sin una cuenta de Toevan