MAS Technology Risk Management Guidelines (2021)
Attestkeep vincula lo que el admission control y el escaneo de images de su cluster registraron en un periodo con 30 requisitos (fuente: Monetary Authority of Singapore, 18 de enero de 2021). De ellos, 19 se evalúan con esos registros; 11 se marcan fuera de alcance, cada uno con el motivo.
19 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.
Technology Risk Management Guidelines
Monetary Authority of Singapore, 18 de enero de 2021
Secciones 3.3 (activos de información), 6.1 y 6.3 (seguridad de aplicaciones y DevSecOps), 7.2 a 7.6 (gestión de configuración, renovación tecnológica, parches, cambios y releases de software), 11.3 y 11.4 (seguridad de sistemas y de virtualización), 12.1 y 12.2 (inteligencia de ciberamenazas y supervisión de eventos), 13.1 y 13.6 (evaluación y corrección de vulnerabilidades) y 15 (auditoría de TI)
| Referencia | Requisito | Secciones del informe |
|---|---|---|
| Paragraph 3.3.1 | Information asset management practicesPara tener una visión exacta y completa de su entorno de TI, la entidad financiera debería establecer prácticas de gestión de activos de información: identificar los activos que sustentan su negocio y la prestación de servicios financieros, clasificar cada activo según su clasificación de seguridad o criticidad, definir la propiedad de los activos y los roles y responsabilidades del personal que los gestiona, y fijar políticas, normas y procedimientos para gestionarlos según esa clasificación. | CoverageSupply chain |
| Paragraph 3.3.2 | An inventory of information assets, reviewed and kept currentLa entidad financiera debería mantener un inventario de todos sus activos de información, revisarlo periódicamente y actualizarlo cada vez que haya cambios. | CoverageSupply chain |
| Paragraph 6.1.4 | Tracking vulnerabilities in third party and open-source componentsPara corregir las vulnerabilidades a tiempo, la entidad financiera debería seguir las actualizaciones y las vulnerabilidades notificadas del código de terceros y de código abierto incorporado en su software. | Supply chainCoverage |
| Paragraph 6.1.7 | Issues tracked, and major defects remediated before deploymentTodos los problemas y defectos de software descubiertos en la revisión de código y en las pruebas de seguridad de aplicaciones deberían seguirse, y los problemas y defectos graves corregirse antes del despliegue en producción. | CoverageAdmission decisionsOutcomesControl statement |
| Paragraph 7.2.1 | Configuration management keeps accurate information about each systemLa entidad financiera debería implementar un proceso de gestión de configuración que mantenga información exacta sobre la configuración del hardware y el software de cada sistema de TI, como modelo, versión y especificaciones, para tener visibilidad y control efectivo de sus sistemas. | CoverageSupply chainControl statement |
| Paragraph 7.2.2 | Configuration information is reviewed and verified regularlyLa entidad financiera debería revisar y verificar periódicamente la información de configuración de su hardware y software para que sea exacta y esté al día. | CoverageAdmission decisionsEvidence chain |
| Paragraph 7.3.1 | Outdated and unsupported software is avoided and end-of-support watchedLa entidad financiera debería evitar hardware o software obsoleto y sin soporte, que puede aumentar su exposición a riesgos de seguridad y estabilidad, y vigilar de cerca las fechas de fin de soporte, ya que los proveedores suelen dejar entonces de publicar parches, también para vulnerabilidades descubiertas después. | Control statementCoverage |
| Paragraph 7.4.1 | Patches applied within a timeframe set by criticalityDebería establecerse un proceso de gestión de parches para que los parches funcionales y no funcionales aplicables, como correcciones de vulnerabilidades de seguridad y de errores de software, se apliquen en un plazo acorde con la criticidad de los parches y de los sistemas de la entidad. | Control statementCoverageAdmission decisionsOutcomesIssues |
| Paragraph 7.5.1 | Changes are assessed, tested, reviewed and approved before implementationLa entidad financiera debería establecer un proceso de gestión de cambios para que los cambios en los activos de información se evalúen, prueben, revisen y aprueben antes de implementarse. | Admission decisionsEvidence chain |
| Paragraph 7.5.7 | The change process is loggedComo los registros contienen información que facilita la investigación y la resolución de problemas, la entidad financiera debería asegurarse de que el registro está activado para recoger las actividades realizadas durante el proceso de cambio. | Evidence chain |
| Paragraph 7.6.2 | Traceability and integrity for code moved between environmentsDeberían implementarse controles que mantengan la trazabilidad y la integridad de todo el código de software que se mueve entre entornos de TI. | Supply chainControl statementAdmission decisionsEvidence chain |
| Paragraph 11.3.1 | Security standards outline configurations that minimise exposureLas normas de seguridad del hardware y software de la entidad, como sistemas operativos, bases de datos, dispositivos de red y dispositivos finales, deberían describir las configuraciones que reducen al mínimo su exposición a ciberamenazas, y revisarse periódicamente para comprobar su pertinencia y eficacia. | Control statementAdmission decisions |
| Paragraph 11.3.2 | Standards verified as applied uniformly, and deviations addressedLa entidad financiera debería establecer un proceso para verificar que las normas se aplican de forma uniforme en los sistemas e identificar las desviaciones; los riesgos derivados de las desviaciones deberían abordarse a tiempo. | Control statementAdmission decisionsTriage decisions |
| Paragraph 11.3.6 | Only authorised software may be installedDeberían implementarse medidas de seguridad, como una lista blanca de aplicaciones, para que solo pueda instalarse software autorizado en los sistemas de la entidad. | Control statementSupply chain |
| Paragraph 12.1.1 | Cyber-related information is collected, processed and analysedPara mantener una buena conciencia situacional en ciberseguridad, la entidad financiera debería establecer un proceso para recopilar, tratar y analizar información relacionada con la ciberseguridad (eventos, inteligencia de amenazas e información sobre vulnerabilidades de sistemas) por su pertinencia e impacto potencial en su negocio y su entorno de TI. | ClusterCoverageControl statement |
| Paragraph 12.2.2 | System logs are collected, reviewed, retained and protectedDebería establecerse un proceso para recopilar, tratar, revisar y conservar los registros del sistema que facilite las operaciones de supervisión de seguridad de la entidad, y esos registros deberían protegerse frente a accesos no autorizados. | Evidence chain |
| Paragraph 13.1.1 | Regular vulnerability assessment, with risks addressed in timeLa entidad financiera debería establecer un proceso de evaluación periódica de vulnerabilidades en sus sistemas de TI para identificar fallos de seguridad y abordar a tiempo los riesgos que generan, con una frecuencia acorde con la criticidad del sistema y el riesgo de seguridad al que está expuesto. | CoverageAdmission decisionsOutcomesControl statementIssues |
| Paragraph 13.1.2 | What a vulnerability assessment must minimally coverUna evaluación de vulnerabilidades debería incluir como mínimo el descubrimiento de vulnerabilidades, la identificación de configuraciones de seguridad débiles y de puertos de red abiertos, y las vulnerabilidades de aplicaciones; en sistemas web, también las vulnerabilidades web habituales. | CoverageControl statementAdmission decisions |
| Paragraph 13.6.1 | A remediation process that classifies, times and governs deviationsDebería establecerse un proceso completo de corrección para seguir y resolver los problemas detectados en evaluaciones o ejercicios de ciberseguridad, que incluya como mínimo la evaluación y clasificación de la gravedad, un plazo de corrección por gravedad, y la evaluación de riesgos y estrategias de mitigación para gestionar las desviaciones respecto del framework. | CoverageAdmission decisionsOutcomesControl statementTriage decisionsIssues |
11 requisitos fuera de alcance, y por qué
| Referencia | Requisito y motivo |
|---|---|
| Paragraph 6.1.3 | Third party and open-source code reviewed before integration La revisión y las pruebas ocurren antes de la integración, en un árbol de código y un build; a este control le llega el resultado como image construida, y puede decir qué contiene, no qué se le hizo antes. |
| Paragraph 6.1.6 | Application security validation and testing Las pruebas estáticas, dinámicas e interactivas leen código fuente, bytecode y una aplicación en ejecución; una decisión de admission lee los componentes de una image y los hallazgos que pesan sobre ellos: una medida distinta de un objeto distinto, que no las sustituye. |
| Paragraph 6.3.1 | DevSecOps aligned with the SDLC and IT service management La alineación entre un pipeline y un framework depende de cómo organiza el trabajo la entidad; este cluster es donde llega lo que produce el pipeline, y ve el artefacto, no el proceso que lo produjo. |
| Paragraph 6.3.2 | Segregation of duties across development, testing and release La segregación de funciones dice qué personas tienen qué permisos en un sistema de build y release, y nada de eso es visible en una decisión de admission tomada sobre el artefacto que esas personas produjeron. |
| Paragraph 7.3.3 | Management dispensation for continued use of unsupported software Una dispensa es una autorización de la dirección que acepta un riesgo y le pone fecha, y se registra en el propio gobierno de la entidad; este control puede mostrar que se admitió una image con un sistema operativo base sin soporte y que la policy lo permitía, y las aceptaciones de riesgo que sí registra son decisiones sobre hallazgos, no sobre una plataforma que ya nadie parchea. |
| Paragraph 7.4.2 | Patches are tested before production Un parche se prueba en los propios entornos de la entidad antes de aplicarse; a este control le llega después la image reconstruida, y puede decir qué ya no contiene, no qué se hizo para convencerse de que era seguro aplicarlo. |
| Paragraph 7.6.1 | Segregation of duties in the software release process Quién puede construir y quién puede promover lo deciden los permisos de un pipeline de release; este cluster es el último entorno de esa cadena y registra lo que llegó, no quién tenía derecho a enviarlo. |
| Paragraph 11.4.1 | Security standards for every component of a virtualisation solution Los componentes que nombra este párrafo son el hipervisor, el sistema operativo host y el sistema operativo invitado, todos por debajo del node en el que se ejecuta este operator; un webhook que admite un container no ve ninguno de ellos. |
| Paragraph 11.4.3 | Policies and standards governing virtual images and snapshots Los activos que regula este párrafo son images de máquinas virtuales y sus snapshots, y las directrices definen la virtualización como la simulación de hardware; una image de container comparte la palabra, no el artefacto, y los controles de este operator sobre images de container se informan en 7.6.2 y 11.3.6 en lugar de tomarse prestados para una sección sobre hipervisores. |
| Paragraph 12.1.2 | Intelligence services and threat information sharing Contratar un servicio y unirse a un acuerdo de intercambio son decisiones comerciales y de afiliación de la entidad; que este operator lea un catálogo público de vulnerabilidades explotadas se informa en 12.1.1 y no sustituye a ninguna de las dos. |
| Paragraph 15.1.1 | An independent IT audit opinion Este documento es evidencia que lee una auditoría, no la auditoría; la opinión que pide el párrafo la forma una función que debe ser independiente de los controles que examina, y un control no puede auditarse a sí mismo. |
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 escaneo9 requisitos
- Se guarda un SBOM de las images en servicio5 requisitos
- Se rechazan las images con hallazgos graves4 requisitos
- La admission rechaza los workloads que no cumplen3 requisitos
- Se registra cada decisión y cada acción administrativa3 requisitos
- Cada cambio de image se registra junto a la policy que lo regía3 requisitos
- Los workloads nombran las images por digest, no por un tag movible3 requisitos
- Hay un plazo de corrección declarado para cada severidad3 requisitos
- Los privilegios de los workloads se limitan en la admission3 requisitos
- Los riesgos aceptados tienen nombre, justificación y caducidad2 requisitos
- Solo pueden ejecutarse images de procedencia establecida2 requisitos
- Se rechazan las images cuyo sistema operativo base ya no tiene soporte1 requisito
- Los hallazgos se cotejan con un catálogo nacional de vulnerabilidades explotadas1 requisito
- Las images solo pueden entrar desde registries autorizados1 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 MAS TRM, con el número de requisitos que cita cada una.
- Organisation
- Framework mapping
- Cluster1
- Control statement12
- Coverage12
- Vulnerability findings
- Outcomes4
- Admission decisions10
- Supply chain6
- Triage decisions2
- Break-glass events
- Availability
- Evidence chain5
- Deployment context
- Issues3
- 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 Monetary Authority of Singapore's Technology Risk Management Guidelines of 18 January 2021. The Guidelines are supervisory expectations addressed to a financial institution, not a standard anybody is certified against, and nothing here is an assessment of the FI's technology risk management framework as a whole, of its IT service management processes, or of any control it operates outside this cluster. What the period's records support is the software-facing half of a few paragraphs: which images ran, what was inside them, whether their base operating system was still supported, what was known about them when they ran, what was refused, and what was admitted with an expiry on it. Section 7.3 is answered directly, because a scan records whether an image's base OS is past end of support and the policy decides what admission does about that. Hardware and network devices, endpoint protection, the hypervisor beneath the nodes, the FI's other system logs, and every paragraph whose subject is people rather than records — the change advisory board, segregation of duties in a release pipeline, the dispensation management grants for continued use of unsupported software, the independent audit function of section 15 — are named where a reader would look for them and marked outside what a cluster observes.
Sobre MAS TRM
¿Es esto una certificación según MAS TRM?
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é 11 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 MAS TRM?
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