Regulatorio · Unión Europea

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.

Qué pide el framework

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)

ReferenciaRequisitoSecciones del informe
Article 8(1)
Identify, classify and document ICT assets

Las 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 inventories

Las 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 providers

Las 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 data

Las 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 flaws

Las 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 require

Las 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 mechanisms

Las 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 management

Las 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 updates

Las 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 failure

Las 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 response

Los 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 anomalies

Las 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 policy

Las 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 arrangement

Antes 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 standards

Las 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é
ReferenciaRequisito y motivo
Article 5Governance 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 6ICT 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 12Backup, 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 13Learning 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 – 23ICT-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 – 27Digital 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ó.

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.

  • 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
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 DORA, con el número de requisitos que cita cada una.

Más sobre el paquete

  1. Organisation
  2. Framework mapping
  3. Cluster
  4. Control statement8
  5. Coverage7
  6. Vulnerability findings
  7. Outcomes4
  8. Admission decisions7
  9. Supply chain4
  10. Triage decisions
  11. Break-glass events2
  12. Availability2
  13. Evidence chain3
  14. Deployment context
  15. Issues1
  16. Ledger
  17. Population
  18. Runtime events
  19. 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 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.

Preguntas

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