Seguridad · Estados Unidos (NIST)

NIST SP 800-190 (Application Container Security)

Attestkeep vincula lo que el admission control y el escaneo de images de su cluster registraron en un periodo con 15 requisitos (fuente: NIST SP 800-190). De ellos, 11 se evalúan con esos registros; 4 se marcan fuera de alcance, cada uno con el motivo.

Crear una cuenta Cómo se construye un paquete

Qué pide el framework

11 requisitos a los que responde un cluster.

Referencias y títulos tal como los imprime el informe, es decir, en inglés. Abra un requisito para leer lo que pide, expresado de forma próxima al texto del propio instrumento.

Application Container Security Guide

NIST SP 800-190

Sección 3 (riesgos) y sección 4 (contramedidas) para images, registries, orquestadores y containers

Referencia	Requisito	Secciones del informe
3.1.1 / 4.1.1	Image vulnerabilities Las images deberían escanearse en busca de vulnerabilidades de forma continua, y las organizaciones deberían adoptar herramientas y procesos que impidan ejecutar images con vulnerabilidades por encima de un umbral definido.	CoverageAdmission decisionsOutcomesControl statement
3.1.2 / 4.1.2	Image configuration defects Las images deberían revisarse en busca de defectos de configuración, como ejecutarse como root y otros ajustes que debilitan el aislamiento del que depende un container.	Control statementAdmission decisions
3.1.3 / 4.1.3	Embedded malware Las images deberían vigilarse en busca de archivos maliciosos, con detección basada en firmas y con la procedencia de la propia image.	CoverageSupply chainControl statement
3.1.5 / 4.1.5	Use of untrusted images Las organizaciones deberían mantener un conjunto de registries e images de confianza e impedir que los workloads ejecuten images obtenidas de cualquier otro sitio.	Control statementSupply chainAdmission decisions
3.2.2 / 4.2.2	Stale images in registries Las organizaciones deberían asegurarse de que solo se despliegan images actuales, por ejemplo refiriéndose a ellas con identificadores inmutables en lugar de tags que pueden moverse a contenido más antiguo.	Control statement
3.2.3 / 4.2.3	Insufficient authentication and authorization restrictions El acceso a los registries debería estar restringido, y las images solo deberían descargarse de registries que la organización controla o ha verificado.	Control statement
3.3.1 / 4.3.1	Unbounded administrative access El acceso administrativo al orquestador debería seguir el mínimo privilegio y, cuando sea posible, estar federado al directorio de la organización en lugar de usar cuentas locales separadas.	Evidence chain
3.3.2 / 4.3.2	Unauthorized access Solo deberían admitirse en el cluster workloads autorizados, y cada decisión de admission debería poder atribuirse.	Control statementAdmission decisionsEvidence chain
3.4.4 / 4.4.4	App vulnerabilities Los containers deberían vigilarse en busca de vulnerabilidades descubiertas después de su despliegue, y estas deberían corregirse dentro de plazos definidos.	CoverageControl statementAdmission decisionsIssuesBreak-glass events
4.1.1 (policy-driven enforcement)	Deviations from the control are governed Cuando un container deba ejecutarse pese a no superar una comprobación, la desviación debería registrarse, justificarse y limitarse en el tiempo, en lugar de concederse en silencio.	Triage decisionsEvidence chain
6.4 (operations and maintenance)	The control operates continuously Las contramedidas anteriores solo son eficaces mientras funcionan; su disponibilidad forma parte del propio control.	Availability

4 requisitos fuera de alcance, y por qué

Referencia	Requisito y motivo
3.1.4 / 4.1.4	Embedded clear text secrets Un admission controller lee los metadatos y los hallazgos de una image, no el contenido de sus layers; este operator no busca secretos en el contenido de las layers y aquí no se afirma lo contrario.
3.3.4 / 4.3.4	Mixing of workload sensitivity levels La separación de namespaces y la ubicación en nodes son el diseño propio del administrador del cluster; este control decide qué images pueden ejecutarse en un namespace, no cómo se separan los namespaces entre sí.
3.3.5 / 4.3.5	Orchestrator node trust La attestation de nodes y el bastionado del host quedan fuera de la vista de un admission controller; este documento dice qué puede ejecutarse, no dónde.
3.4.1 / 4.4.1	Vulnerabilities within the runtime software El runtime forma parte de la plataforma host; este operator informa sobre las images que admite y sobre su propia disponibilidad, no sobre la versión del runtime.

Qué produce Attestkeep

Evidencia a partir de registros que el cluster ya guarda.

Nada se rellena a mano. La respuesta de cada requisito lleva un estado (cumplido, parcial, carencia o fuera de alcance), una nota con las cifras del propio periodo y las secciones del informe de donde salen esas cifras.

En qué se apoya el mapeo

Cada requisito evaluado se responde con una o varias de estas afirmaciones sobre los registros del periodo. La misma afirmación responde a la misma pregunta en todos los frameworks, así que dos informes de un mismo periodo no pueden discrepar.

La admission rechaza los workloads que no cumplen3 requisitos
Se registra cada decisión y cada acción administrativa3 requisitos
Cada image del inventario tiene un registro de escaneo3 requisitos
Solo pueden ejecutarse images de procedencia establecida2 requisitos
Las images solo pueden entrar desde registries autorizados2 requisitos
El acceso administrativo está federado con un directorio1 requisito
El propio control estuvo operativo durante todo el periodo1 requisito
Los workloads nombran las images por digest, no por un tag movible1 requisito
Los riesgos aceptados tienen nombre, justificación y caducidad1 requisito
Un rechazo o un hallazgo crítico llega a una persona1 requisito
Hay un plazo de corrección declarado para cada severidad1 requisito
Se rechazan las images con hallazgos graves1 requisito
Los privilegios de los workloads se limitan en la admission1 requisito

El paquete

Qué contiene el informe.

Todos los paquetes llevan las mismas secciones, sea cual sea el framework. Las marcadas son las que citan las respuestas para NIST SP 800-190, con el número de requisitos que cita cada una.

Más sobre el paquete

Organisation
Framework mapping
Cluster
Control statement8
Coverage3
Vulnerability findings
Outcomes1
Admission decisions5
Supply chain2
Triage decisions1
Break-glass events1
Availability1
Evidence chain3
Deployment context
Issues1
Ledger
Population
Runtime events
Producer statements (VEX)

Alcance

El párrafo de alcance, tal como lo formula el informe.

This document reports what one Kubernetes cluster's admission control and image scanning recorded during the period, mapped onto NIST SP 800-190. The guide covers images, registries, orchestrators, containers and host operating systems; this operator observes the first three at the point a workload is admitted. Runtime behaviour inside a running container, and the hardening of the hosts themselves, are outside what an admission controller can see and are marked as such rather than claimed.

Preguntas

Sobre NIST SP 800-190

¿Es esto una certificación según NIST SP 800-190?

No. El paquete es evidencia generada a partir de los propios registros de su cluster. No es una certificación, y ningún auditor está obligado a aceptarlo. El párrafo de alcance de esta página es el mismo que lleva el informe.

¿Por qué 4 de los requisitos están fuera de alcance?

Preguntan por cosas que los registros de admission y escaneo de un cluster no pueden mostrar. Se incluyen con el motivo en lugar de omitirse, para que quien lea el informe vea que la exclusión es deliberada.

¿Qué plan incluye NIST SP 800-190?

Todos los planes pueden generar informes para este framework. Community y Team incluyen 1 framework a elegir; Business, 3; Enterprise, todos. Los precios están en la página de precios.

¿Cómo comprueba un auditor el paquete?

En un navegador, en attestkeep.com/verify.html, donde no se sube nada, o con el breve script del sitio de documentación. Ninguno de los dos nos necesita. La página Para auditores tiene los detalles.

Instálelo usted mismo.

Cree una cuenta, confirme su correo con el código que le enviamos, obtenga la clave Community gratuita en la página Licences e instale con Helm.

Crear una cuenta