DORA (Digital Operational Resilience Act)
Attestkeep vincula lo que el admission control y el escaneo de images de su cluster registraron en un periodo con 22 requisitos (fuente: Reglamento (UE) 2022/2554). De ellos, 15 se evalúan con esos registros; 7 se marcan fuera de alcance, cada uno con el motivo.
15 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.
Digital Operational Resilience Act
Reglamento (UE) 2022/2554
Capítulo II, artículos 8 a 11 (gestión del riesgo relacionado con las TIC: identificación, protección y prevención, detección, respuesta) y capítulo V, artículo 28 (riesgo de terceros proveedores de TIC)
| Referencia | Requisito | Secciones del informe |
|---|---|---|
| Article 8(1) | Identify, classify and document ICT assetsLas entidades financieras identificarán, clasificarán y documentarán adecuadamente todas las funciones de negocio, funciones y responsabilidades apoyadas en las TIC, así como los activos de información y de TIC que las sustentan, y revisarán cada año la idoneidad de esa clasificación. | CoverageControl statement |
| Article 8(6) | Maintain and update inventoriesLas entidades financieras mantendrán los inventarios pertinentes y los actualizarán periódicamente y cada vez que se produzca un cambio importante. | Coverage |
| Article 8(5) | Identify processes dependent on third-party providersLas entidades financieras identificarán y documentarán todos los procesos que dependan de terceros proveedores de servicios TIC. | Control statementSupply chain |
| Article 9(2) | Availability, authenticity, integrity and confidentiality of dataLas entidades financieras diseñarán, adquirirán e implementarán políticas, procedimientos, protocolos y herramientas de seguridad de las TIC destinados a garantizar la resiliencia, la continuidad y la disponibilidad de los sistemas de TIC y a mantener altos niveles de disponibilidad, autenticidad, integridad y confidencialidad de los datos, en reposo, en uso o en tránsito. | Supply chainControl statement |
| Article 9(3)(b) | Minimise the risk of technical flawsLas entidades financieras reducirán al mínimo el riesgo de alteración o pérdida de datos, de acceso no autorizado y de fallos técnicos que puedan obstaculizar la actividad. | CoverageAdmission decisionsOutcomes |
| Article 9(4)(c) | Limit logical access to what legitimate functions requireLas entidades financieras aplicarán políticas que limiten el acceso físico o lógico a los activos de información y de TIC a lo que exijan únicamente las funciones y actividades legítimas y aprobadas. | Control statementAdmission decisions |
| Article 9(4)(d) | Strong authentication mechanismsLas entidades financieras aplicarán políticas y protocolos de mecanismos de autenticación reforzada, basados en normas pertinentes y en sistemas de control específicos. | Evidence chain |
| Article 9(4)(e) | ICT change managementLas entidades financieras contarán con políticas, procedimientos y controles documentados de gestión de cambios en las TIC, que garanticen que todos los cambios se registran, prueban, evalúan, aprueban, implementan y verifican de forma controlada. | Control statementAdmission decisionsEvidence chain |
| Article 9(4)(f) | Patches and updatesLas entidades financieras contarán con políticas documentadas adecuadas y completas sobre parches y actualizaciones. | Control statementCoverageAdmission decisionsOutcomesIssues |
| Article 10(1) | Promptly detect anomalous activities and single points of failureLas entidades financieras dispondrán de mecanismos para detectar con rapidez actividades anómalas, incluidos los problemas de rendimiento de la red TIC y los incidentes relacionados con las TIC, y para identificar posibles puntos únicos de fallo significativos. Todos los mecanismos de detección se someterán a pruebas periódicas. | CoverageAvailability |
| Article 10(2) | Alert thresholds and criteria to trigger responseLos mecanismos de detección permitirán varias capas de control y definirán umbrales de alerta y criterios para activar los procesos de respuesta a incidentes relacionados con las TIC, incluidas alertas automáticas al personal pertinente. | Admission decisionsCoverageOutcomesBreak-glass events |
| Article 10(3) | Resources to monitor activity and anomaliesLas entidades financieras dedicarán recursos y capacidades suficientes a supervisar la actividad de los usuarios, la aparición de anomalías en las TIC y los incidentes relacionados con las TIC, en especial los ciberataques. | Evidence chainAdmission decisionsBreak-glass events |
| Article 11(1) | ICT business continuity policyLas entidades financieras establecerán una política integral de continuidad de las actividades de TIC, como parte integrante de su política de continuidad operativa, para garantizar la continuidad de las funciones esenciales o importantes. | Availability |
| Article 28(4) | Due diligence before entering a third-party arrangementAntes de celebrar un acuerdo contractual sobre el uso de servicios TIC, las entidades financieras identificarán y evaluarán todos los riesgos pertinentes y aplicarán toda la diligencia debida a los posibles terceros proveedores de servicios TIC. | Supply chainControl statement |
| Article 28(5) | Providers shall meet appropriate information security standardsLas entidades financieras solo podrán celebrar acuerdos contractuales con terceros proveedores de servicios TIC que cumplan normas adecuadas de seguridad de la información; cuando esos servicios apoyen funciones esenciales o importantes, se aplicarán las normas más actualizadas y de mayor calidad. | Supply chainControl statementCoverageAdmission decisionsOutcomes |
7 requisitos fuera de alcance, y por qué
| Referencia | Requisito y motivo |
|---|---|
| Article 5 | Governance and organisation La aprobación, la supervisión y la rendición de cuentas del órgano de dirección son registros de la entidad, no de un cluster. Los parámetros de aplicación que reproduce la declaración de control son un resultado de ese gobierno, no una evidencia de él. |
| Article 6 | ICT risk management framework El marco es un documento que la entidad mantiene y revisa. Este control funciona dentro de él y produce evidencia para algunas de sus partes; no es el marco. |
| Article 12 | Backup, restoration and recovery La copia de seguridad y la restauración de los sistemas y datos de la entidad quedan fuera de lo que registra un admission controller. La copia de seguridad de la propia base de datos del operator corresponde al cliente. |
| Article 13 | Learning and evolving La revisión posterior a un incidente es una práctica que llevan a cabo personas. Los rechazos, excepciones y periodos de interrupción de este documento son aportaciones a esa revisión, no la revisión. |
| Articles 17 – 23 | ICT-related incident management, classification and reporting La clasificación según los umbrales de DORA y la notificación a una autoridad competente son decisiones y comunicaciones de la entidad. Este control genera y registra eventos; no los clasifica ni los notifica. |
| Articles 24 – 27 | Digital operational resilience testing El programa de pruebas de la entidad, incluidas las pruebas de penetración basadas en amenazas, lo realizan evaluadores sobre sus sistemas. Nada de lo que registra un cluster prueba que se haya hecho. |
| Article 28(3) | Register of information on contractual arrangements El registro de información es un registro contractual que mantiene la entidad. El inventario de images de este documento registra lo que se ejecuta, no lo que se contrató. |
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.
- Cada image del inventario tiene un registro de escaneo4 requisitos
- Se rechazan las images con hallazgos graves4 requisitos
- Solo pueden ejecutarse images de procedencia establecida3 requisitos
- Las images solo pueden entrar desde registries autorizados3 requisitos
- Se registra cada decisión y cada acción administrativa2 requisitos
- El propio control estuvo operativo durante todo el periodo2 requisitos
- Los workloads nombran las images por digest, no por un tag movible2 requisitos
- Un rechazo o un hallazgo crítico llega a una persona2 requisitos
- Se guarda un SBOM de las images en servicio2 requisitos
- El acceso administrativo está federado con un directorio1 requisito
- La admission rechaza los workloads que no cumplen1 requisito
- Hay un plazo de corrección declarado para cada severidad1 requisito
- Los privilegios de los workloads se limitan en la admission1 requisito
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 DORA, con el número de requisitos que cita cada una.
- Organisation
- Framework mapping
- Cluster
- Control statement8
- Coverage7
- Vulnerability findings
- Outcomes4
- Admission decisions7
- Supply chain4
- Triage decisions
- Break-glass events2
- Availability2
- Evidence chain3
- Deployment context
- Issues1
- Ledger
- Population
- Runtime events
- Producer statements (VEX)
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 the Digital Operational Resilience Act. DORA governs a financial entity's entire ICT risk management framework, of which a container image control is one instrument: it speaks to identification of ICT assets, to protection, prevention and detection under Articles 8 to 11, and to the point in Article 28 where third-party code enters the estate. Governance, testing, backup and the incident reporting owed to competent authorities are the entity's own and are marked outside the scope of this document rather than claimed.
Sobre DORA
¿Es esto una certificación según DORA?
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é 7 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 DORA?
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