Cómo la regla de disponibilidad del 99,95 % de Singapur transforma la arquitectura de su red

Si está definiendo los requisitos de DDoS bajo las directrices TRM de la MAS para una institución financiera regulada en Singapur en 2026, se encuentra en un entorno normativo distinto al que existía hace dieciocho meses.

‍

Las directrices revisadas de Gestión de Riesgos Tecnológicos (TRM) de la MAS entraron en vigor en mayo de 2024. La Ley de Ciberseguridad (Enmienda) de 2024 añadió una segunda capa en octubre de 2025. Ambas cambiaron fundamentalmente las pruebas que la MAS espera que usted presente cuando un ataque DDoS afecta a sus sistemas orientados al cliente.

‍

La mayoría de los documentos de arquitectura aún describen controles anteriores a 2024. La mayoría de las propuestas de proveedores siguen utilizando un lenguaje previo a 2024. Esta guía detalla qué ha cambiado realmente, qué exige ahora la MAS de su postura frente a DDoS y cómo asignar un servicio gestionado de DDoS a cada control específico antes de su próxima auditoría.

‍

El cambio normativo que todo CISO en Singapur conoce

El sector financiero de Singapur ha experimentado una serie de fallos de disponibilidad de alto perfil en los últimos años. Ninguno tuvo la misma causa, pero todos compartieron el mismo resultado: el escrutinio de la MAS, la divulgación pública y medidas de supervisión que transformaron las expectativas de evidencia a las que se enfrenta ahora toda institución regulada.

‍

El patrón es constante. Cuando una interrupción es lo suficientemente visible como para generar comentarios públicos, la MAS responde solicitando el mismo conjunto de controles independientemente de la causa raíz: pruebas de conmutación por error (failover), pruebas de continuidad del negocio (BCP), revisión de resiliencia de terceros y respuesta a incidentes documentada.

‍

Los controles que la MAS ha cuestionado en recientes acciones de supervisión —pruebas de failover, pruebas de BCP y revisión de resiliencia de terceros— son los mismos que determinan los resultados de las auditorías de DDoS. Si no puede mostrar a la MAS pruebas de un failover probado bajo estrés de disponibilidad simulado, su postura frente a DDoS no es lo único que queda expuesto.

‍

Por eso el cumplimiento de las TRM de la MAS es importante ahora. No porque las reglas sean nuevas, sino porque las consecuencias de incumplirlas son ahora visibles.

‍

Incidentes DDoS destacados que definen la postura normativa de Singapur

La pausa en el sector financiero de Singapur es el incidente reciente más citado, pero no es el único evento que impulsa la atención del regulador. Tres casos relevantes de DDoS son importantes para su análisis de brechas de las TRM de la MAS:

‍

• Ataque DDoS a Synapxe, 1 de noviembre de 2023. La red nacional de salud pública de Singapur sufrió un ataque DDoS sostenido que interrumpió la conectividad a Internet en hospitales públicos y policlínicos. Los servicios de correo electrónico y basados en la web se vieron afectados durante varias horas. El incidente fue anterior a las directrices TRM revisadas, pero influyó profundamente en la visión del regulador sobre los requisitos de evidencia de disponibilidad.
• Interrupción del sector financiero en Singapur, 14 de octubre de 2023. Una interrupción de más de 12 horas que provocó la pausa de la MAS en noviembre de 2023. No fue causada por un ataque DDoS, pero el análisis de causa raíz reveló las mismas deficiencias en la conmutación por error, las pruebas de continuidad del negocio (BCP) y la evidencia de resiliencia que ahora exigen las auditorías de DDoS.
• Ola de ataques DDoS a casas de bolsa en Singapur, 2020 (Phillip Securities, iFAST y otras). Un patrón de ataques a casas de bolsa minoristas durante un periodo de alto volumen de operaciones dejó al descubierto deficiencias en la disponibilidad bajo la presión simultánea de ataques y demanda. Citado en la guía de la MAS como la razón por la que los requisitos de disponibilidad se extienden más allá de los periodos de ciberincidentes puros.
  ‍

Las empresas de Singapur y los proveedores de servicios en la nube (CSP) que atienden a clientes regulados deberían poder hacer referencia a estos casos por su nombre en cualquier revisión de arquitectura.
‍

‍

Lo que la TRM de la MAS exige realmente para los ataques DDoS

El Aviso revisado de la MAS sobre las preguntas frecuentes de Gestión de Riesgos Tecnológicos (febrero de 2024) y las Directrices de TRM revisadas (en vigor desde el 10 de mayo de 2024) establecen obligaciones específicas y cuantificables. Los instrumentos normativos fundamentales que deben conocerse por su nombre son: el Aviso 644 de la MAS (Gestión de Riesgos Tecnológicos) para bancos, el Aviso FSM-N30 de la MAS para instituciones del mercado de capitales y las Directrices de TRM para el universo supervisado en general.

Las cifras principales

• Objetivo de disponibilidad: 99,95 % de disponibilidad para sistemas críticos. Esto equivale a no más de 4,38 horas de tiempo de inactividad no programado acumulado al año en todos los sistemas críticos combinados.
• Límite de tiempo de inactividad: No más de 4 horas de tiempo de inactividad no programado en cualquier periodo móvil de 12 meses para cualquier sistema crítico individual. Esta es la restricción más estricta. Una sola interrupción de 5 horas causada por un ataque DDoS supone un incumplimiento durante los siguientes 12 meses.
• Notificación de incidentes: Notificación de incidentes a la MAS en un plazo de 1 hora para los ciberincidentes pertinentes. Los ataques DDoS se enumeran explícitamente como notificables. El cronómetro comienza cuando la institución tiene conocimiento del incidente.
• Análisis de causa raíz: Presentación del análisis de causa raíz en un plazo de 14 días tras el incidente. Debe identificar la causa raíz, las acciones de remediación y el cronograma.

‍

Lo que esto significa realmente en la operativa: necesitas una detección de DDoS que se active en menos de 60 segundos. Visibilidad del SOC que señale el incidente dentro de la ventana de 1 hora. Registro forense que permita una reconstrucción de 14 días. Y una conmutación por error que no consuma tu presupuesto de 4 horas de tiempo de inactividad en un periodo móvil de 12 meses.

‍

Un servicio de DDoS gestionado que tarda 90 segundos en detectar y 5 minutos en mitigar es aceptable a efectos de los SLA. 

‍

No lo es a efectos de las notificaciones de la MAS. Aquí es donde las arquitecturas híbridas superan a las puramente en la nube, ya que la inspección local detecta el ataque antes que los registros del borde de la nube.

‍

La capa de la Ley de Enmienda de Ciberseguridad de 2024

La Ley de Ciberseguridad (Enmienda) de 2024 de Singapur entró en vigor el 31 de octubre de 2025. Es una capa regulatoria independiente de la TRM de la MAS, pero se suma a ella para cualquier institución financiera clasificada también como Infraestructura de Información Crítica.

‍

La Ley añade:

• Notificación en 2 horas a la CSA para incidentes que interrumpan servicios esenciales (frente a la hora de la MAS para incidentes cibernéticos)
• Informes de incidentes en la cadena de suministro: si tu proveedor de DDoS sufre una interrupción que afecta a tu servicio, ahora está dentro del alcance
• Informes de ataques sospechosos de ser APT, incluso sin una atribución confirmada
• Una nueva categoría de Infraestructura Digital Fundamental (FDI) que, por primera vez, somete a los proveedores de nube, operadores de centros de datos y proveedores de seguridad gestionada a la regulación directa de la CSA

‍

Ese último punto es el que la mayoría de los proveedores aún no ha tenido en cuenta en sus precios. Un servicio de DDoS exclusivamente en la nube que preste servicio a un cliente de CII en Singapur es ahora una entidad regulada por la CSA, con su propio plazo para la notificación de incidentes.

‍

Por qué la mayoría de las arquitecturas exclusivamente en la nube tienen dificultades ante el escrutinio de la MAS

Tres problemas estructurales hacen que sea difícil defender el uso de DDoS puramente en la nube durante una auditoría de la MAS.

‍

1. Residencia de datos

Las directrices TRM de la MAS son cada vez más específicas sobre dónde se pueden procesar y almacenar los datos de los clientes. Un servicio DDoS exclusivamente en la nube que redirige el tráfico a centros de limpieza en Fráncfort, Ashburn o incluso Tokio plantea cuestiones jurisdiccionales que los auditores ahora plantean explícitamente. ¿Por dónde transita físicamente el tráfico del cliente? ¿Dónde se almacenan los registros?

‍

2. Registro de inquilinos compartidos

Los proveedores de DDoS en la nube utilizan infraestructuras multiinquilino. Generar pruebas aisladas por inquilino para un análisis de causa raíz (RCA) de la MAS en un plazo de 14 días es más difícil de lo que sugieren los materiales de marketing.

‍

3. El reloj de 1 hora frente al reloj de los tickets de soporte

Si su mitigación de DDoS se activa mediante un control interno del proveedor de la nube, el momento en que usted se vuelve "consciente" del incidente es cuando su portal lo marca o su SOC le llama. Algunos proveedores tienen acuerdos de nivel de servicio (SLA) de notificación de 15 minutos. Otros, de 60 minutos. Al reloj de la MAS no le importan los horarios comerciales.

‍

La arquitectura que supera el escrutinio de la MAS es híbrida. Un dispositivo local en la red, la nube del proveedor para la capacidad de ráfaga y un portal unificado que alimente a su SOC dentro del plazo de 1 hora.

‍

Los siete controles que toda arquitectura conforme a la MAS debe demostrar

Estos son los controles que aparecen en las respuestas a las solicitudes de información (RFI) de la MAS, en las simulaciones de tipo iCAST y en las revisiones de riesgos a nivel de junta directiva.

‍

1. Protección siempre activa, no bajo demanda. La MAS espera que la detección ocurra de forma continua. La limpieza bajo demanda crea un intervalo en el que el reloj del incidente ya ha comenzado antes de que usted haya empezado a mitigar.
2. Protección multicapa. Capa de red (volumétrica L3/4), capa de aplicación (L7 / inundaciones HTTPS) y capa de DNS. Los auditores de la MAS preguntan cada vez más sobre el DNS específicamente.
3. Limpieza en la región. Tráfico del cliente procesado en Singapur o en una jurisdicción aprobada explícitamente. El acuerdo con el proveedor especifica la ubicación de limpieza según la clase de tráfico.
4. Manuales de procedimientos documentados. Procedimientos de mitigación paso a paso para los 15 tipos de ataques principales. Revisados anualmente y puestos a prueba en ejercicios de simulación.
5. Pruebas de conmutación por error (failover) con evidencia. La MAS exige pruebas de que su sistema de conmutación realmente funciona, no solo políticas que indiquen que debería hacerlo. Se requieren ejercicios anuales de ingeniería del caos o simulacros de continuidad del negocio (BCP) con documentación de resultados.
6. Visibilidad del SOC para el plazo de 1 hora. Los registros del servicio DDoS se integran en su SIEM/SOAR casi en tiempo real. Su SOC detecta el incidente antes que el cliente.
7. Acuerdos de nivel de servicio (SLA) de proveedores alineados con el tiempo de actividad del TRM. El SLA publicado por el proveedor iguala o supera el 99,95 %. Su tiempo de inactividad se suma a su presupuesto de tiempo de inactividad. Existen recursos contractuales en caso de incumplimiento.

‍

Si su servicio DDoS actual no puede presentar pruebas de estos siete puntos, tiene una brecha de arquitectura, no solo una brecha de adquisición.

‍

Cómo se asigna la arquitectura híbrida al TRM de la MAS

‍

Esta es la asignación específica que permite cerrar acuerdos en los ciclos de adquisición del sector bancario y financiero (BFSI) de Singapur.

‍

‍

Plantilla de lenguaje para RFP: qué exigir a cualquier proveedor de DDoS

Estos son los términos contractuales específicos que una institución financiera regulada por la MAS debe exigir en cualquier RFP de DDoS.

• SLA de detección: "El proveedor debe detectar ataques DDoS volumétricos en un plazo de 60 segundos tras el inicio del ataque".
• SLA de mitigación: "El proveedor debe iniciar la mitigación en un plazo de 90 segundos tras la detección."
• SLA de notificación: "El proveedor debe notificar al SOC del cliente en un plazo de 15 minutos ante cualquier evento de DDoS, independientemente de su magnitud."
• Ubicación de filtrado: "El tráfico del cliente debe filtrarse en Singapur o en una jurisdicción aprobada. El proveedor debe proporcionar una certificación del flujo de red si se solicita."
• Aislamiento de inquilinos: "El proveedor debe generar registros forenses por cliente que sean suficientes para respaldar un RCA de la MAS en un plazo de 14 días."
• Disponibilidad: "La disponibilidad del servicio del proveedor debe ser igual o superior al 99,95 %. Por debajo de este umbral, se aplicarán créditos de servicio."
• Alineación con los informes de la CSA: "El proveedor debe notificar al cliente en un plazo de 30 minutos sobre cualquier incidente que afecte a los sistemas regulados del cliente, de modo que este pueda cumplir con la notificación de 2 horas a la CSA conforme a la Ley de Ciberseguridad de 2024."
• Derecho de auditoría: "El cliente se reserva el derecho de auditar las operaciones de filtrado del proveedor una vez al año con un preaviso razonable."

‍

Si un proveedor se resiste a cualquiera de estos puntos, esa resistencia es la respuesta. No pueden cumplir con las obligaciones de la MAS.

‍

Donde fallan Cloudflare, AWS Shield Advanced y Akamai Prolexic

Los tres productos de DDoS de nivel hiperescalar que se despliegan con mayor frecuencia en las instituciones financieras de Singapur presentan carencias específicas frente a los requisitos revisados de la MAS:

‍

• Cloudflare Magic Transit: Dirige el tráfico del cliente a la red global Anycast de Cloudflare. El tráfico de Singapur suele llegar al PoP de SIN, pero el contrato no garantiza el procesamiento en una única jurisdicción bajo condiciones de ataque. Los SLA de notificación se basan por defecto en alertas del portal; el contacto manual entre SOC requiere el nivel Enterprise.
• AWS Shield Advanced: Protege únicamente los recursos de AWS. Para una institución financiera que opera en un entorno híbrido, Shield es solo una pieza de una infraestructura de múltiples proveedores, y la cadena de evidencia para la MAS debe cubrir las brechas existentes. La escalada al equipo de respuesta de Shield en 15 minutos requiere soporte Business o Enterprise, lo que añade un mínimo de unos 15 000 USD al mes.
• Akamai Prolexic: Cuenta con la mayor presencia de PoP en Singapur y un SLA de mitigación explícito de 3 segundos. La brecha se encuentra en el aislamiento forense por inquilino para el análisis de causa raíz (RCA) de 14 días; los informes de Prolexic son detallados, pero la profundidad del aislamiento del inquilino varía según el nivel de servicio. Confirme el SKU que incluye su contrato.

‍

Ninguna de estas opciones es incorrecta para la institución adecuada. Todas son más fáciles de defender en una auditoría de la MAS cuando se combinan con un dispositivo local dentro de la red del CSP que respalde la estrategia de residencia de datos.

‍

Preguntas frecuentes

¿Se aplican las directrices TRM de la MAS a las instituciones financieras no bancarias?

Sí. Las directrices TRM de la MAS se aplican a todas las instituciones financieras reguladas por la MAS, incluidos bancos, aseguradoras, intermediarios del mercado de capitales, proveedores de servicios de pago, sistemas de pago designados y emisores de dinero electrónico. Los requisitos de disponibilidad y notificación de incidentes varían según el tamaño y la importancia de la institución, pero el marco se aplica de forma generalizada.

‍

¿Qué ocurre con los proveedores de DDoS en la nube que tienen un PoP en Singapur? ¿Cumplen con la normativa de la MAS?

Tener un PoP de limpieza en Singapur es necesario, pero no suficiente. El proveedor también debe demostrar que el tráfico del cliente se dirige realmente a través de ese PoP, que los registros se almacenan en Singapur, que el aislamiento del inquilino permite realizar análisis de causa raíz (RCA) por cliente y que los SLA de notificación cumplen con el plazo de 1 hora. Un PoP es infraestructura. El cumplimiento es un proceso.

‍

¿Cómo funciona el plazo de 1 hora si el ataque comienza a las 3 de la mañana?

El cronómetro comienza en el momento en que la institución regulada tiene conocimiento del incidente. Las instituciones financieras reguladas deben contar con operaciones de SOC 24/7 capaces de confirmar y reportar un incidente de DDoS independientemente de la hora. Es aceptable externalizar el SOC al proveedor, siempre que el SLA de notificación del proveedor sea lo suficientemente rápido.

‍

¿Estamos obligados a utilizar un proveedor de DDoS constituido en Singapur?

No. Las directrices MAS TRM no exigen la constitución de una empresa en Singapur. Requieren una gestión de riesgos demostrable, que incluya la diligencia debida de proveedores, obligaciones contractuales, derechos de auditoría y pruebas de respuesta ante incidentes.

‍

¿Qué sucede si superamos el límite de 4 horas de inactividad?

Un incumplimiento activa una respuesta de supervisión por parte de la MAS. La respuesta inicial suele ser una solicitud de explicaciones y un plan de remediación. Los incumplimientos reiterados pueden derivar en medidas de supervisión formales, incluidas revisiones independientes obligatorias (como las que experimentó el sector financiero de Singapur en 2023).

‍

¿Cuál es la diferencia entre las directrices MAS TRM y la Ley de Enmienda de Ciberseguridad de 2024?

Las MAS TRM son específicas para el sector de servicios financieros. La Ley de Ciberseguridad es intersectorial y se aplica a la Infraestructura de Información Crítica en múltiples industrias. Muchas instituciones financieras reguladas por la MAS también son designadas como CII, en cuyo caso se aplican ambos marcos.

‍

¿Cómo afecta esto a mi contrato actual con Cloudflare o AWS Shield?

La mayoría de los contratos de protección DDoS exclusivamente en la nube son anteriores a la revisión de las MAS TRM y a la Ley de Ciberseguridad de 2024. La mayoría de las instituciones necesitarán una enmienda contractual, o un acuerdo híbrido paralelo para las cargas de trabajo reguladas por la MAS, para que la arquitectura cumpla con la normativa.

‍

Qué hacer esta semana

Si es una institución financiera regulada en Singapur y está evaluando el cumplimiento de la protección DDoS, el siguiente paso concreto es realizar un análisis de brechas entre los SLA publicados por su proveedor actual y los 7 controles mencionados anteriormente. En la mitad de los casos, la brecha puede cerrarse mediante una enmienda contractual; en la otra mitad, se requiere un cambio de arquitectura.

‍

Si es un proveedor de servicios en la nube (CSP) que vende protección DDoS en el mercado bancario y financiero de Singapur, elabore el documento de mapeo de arquitectura mencionado anteriormente y preséntelo a todos los clientes potenciales del sector financiero en su cartera.

‍

Para conversar sobre cómo la arquitectura híbrida de Nexusguard se alinea con los controles MAS TRM, programe una revisión de 30 minutos con nuestro equipo en APAC: https://www.nexusguard.com/es/contact-us

‍