Como a regra de 99,95% de disponibilidade de Singapura redefine a arquitetura da sua rede

Se você está definindo os requisitos de DDoS do MAS TRM para uma instituição financeira regulamentada em Singapura em 2026, você está operando em um ambiente regulatório diferente daquele que existia há dezoito meses.

‍

As diretrizes revisadas de Gestão de Risco Tecnológico (TRM) do MAS entraram em vigor em maio de 2024. A Lei de Cibersegurança (Emenda) de 2024 adicionou uma segunda camada em outubro de 2025. Ambas mudaram fundamentalmente as evidências que o MAS espera que você apresente quando um ataque DDoS atinge seus sistemas voltados ao cliente.

‍

A maioria dos documentos de arquitetura ainda descreve controles anteriores a 2024. A maioria das propostas de fornecedores ainda utiliza uma linguagem anterior a 2024. Este guia detalha o que realmente mudou, o que o MAS exige agora da sua postura contra DDoS e como mapear um serviço gerenciado de DDoS para cada controle específico antes da sua próxima auditoria.

‍

A Mudança Regulatória que Todo CISO em Singapura Conhece

O setor financeiro de Singapura passou por uma série de falhas de disponibilidade de grande repercussão nos últimos anos. Nenhuma teve a mesma causa. Todas compartilharam o mesmo resultado: escrutínio do MAS, divulgação pública e ações de supervisão que reformularam as expectativas de evidências que todas as instituições regulamentadas enfrentam agora.

‍

O padrão é consistente. Quando uma interrupção se torna visível o suficiente para gerar comentários públicos, o MAS responde solicitando o mesmo conjunto de controles, independentemente da causa raiz: evidências de failover, testes de BCP, revisão de resiliência de terceiros e resposta a incidentes documentada.

‍

Os controles que o MAS apontou em ações de supervisão recentes — evidências de failover, testes de BCP e revisão de resiliência de terceiros — são os mesmos que determinam os resultados das auditorias de DDoS. Se você não consegue apresentar ao MAS evidências de um failover testado sob estresse de disponibilidade simulado, sua postura contra DDoS não é a única coisa exposta.

‍

É por isso que a conformidade com o MAS TRM tornou-se importante de repente. Não porque as regras sejam novas, mas porque as consequências de não cumpri-las agora são visíveis.

‍

Incidentes de DDoS Notáveis que Moldam a Postura Regulatória de Singapura

A pausa no setor financeiro de Singapura é o incidente recente mais citado, mas não é o único evento que atrai a atenção do regulador. Três casos relevantes de DDoS são importantes para a sua análise de lacunas do MAS TRM:

‍

• DDoS na saúde (Synapxe), 1 de novembro de 2023. A rede nacional de saúde pública de Singapura sofreu um ataque DDoS sustentado que interrompeu a conectividade com a Internet em hospitais públicos e policlínicas. Serviços de e-mail e baseados na web foram afetados por várias horas. O incidente ocorreu antes das Diretrizes de TRM revisadas, mas influenciou fortemente o pensamento do regulador sobre os requisitos de evidência de disponibilidade.
• Interrupção no setor financeiro de Singapura, 14 de outubro de 2023. Uma interrupção de mais de 12 horas que desencadeou a pausa da MAS em novembro de 2023. Não foi causada por DDoS, mas a análise de causa raiz revelou as mesmas falhas de failover, testes de BCP e evidências de resiliência que as auditorias de DDoS agora exigem.
• Onda de ataques DDoS a corretoras de Singapura, 2020 (Phillip Securities, iFAST e outras). Um padrão de ataques a corretoras de varejo durante um período de alto volume de negociações expôs lacunas na disponibilidade sob estresse simultâneo de ataque e demanda. Citado nas diretrizes da MAS como o motivo pelo qual os requisitos de disponibilidade se estendem além de janelas de eventos puramente cibernéticos.
  ‍

Empresas de Singapura e provedores de serviços em nuvem que atendem clientes regulamentados devem ser capazes de citar esses casos pelo nome em qualquer revisão de arquitetura.
‍

‍

O que a TRM da MAS realmente exige para DDoS

O Aviso revisado da MAS sobre as FAQs de Gestão de Risco Tecnológico (fevereiro de 2024) e as Diretrizes de TRM revisadas (em vigor desde 10 de maio de 2024) estabelecem obrigações específicas e mensuráveis. Os principais instrumentos regulatórios a conhecer pelo nome: Aviso 644 da MAS (Gestão de Risco Tecnológico) para bancos, Aviso FSM-N30 da MAS para instituições do mercado de capitais e as Diretrizes de TRM para o universo supervisionado mais amplo.

Os números principais

• Meta de disponibilidade: Disponibilidade de 99,95% para sistemas críticos. Isso equivale a não mais que 4,38 horas de tempo de inatividade não programado acumulado por ano em todos os sistemas críticos combinados.
• Limite de tempo de inatividade: Não mais que 4 horas de tempo de inatividade não programado em qualquer período contínuo de 12 meses para qualquer sistema crítico individual. Esta é a restrição mais rigorosa. Uma única interrupção de 5 horas causada por DDoS viola esse limite pelos 12 meses seguintes.
• Notificação de incidente: Notificação de incidente à MAS em até 1 hora para incidentes cibernéticos relevantes. Ataques DDoS são explicitamente enumerados como reportáveis. O cronômetro começa quando a instituição toma conhecimento do incidente.
• Análise de causa raiz: Envio da análise de causa raiz em até 14 dias após o incidente. Deve identificar a causa raiz, as ações de remediação e o cronograma.

‍

O que isso significa na prática operacional: você precisa de uma detecção de DDoS que seja acionada em menos de 60 segundos. Visibilidade do SOC que sinalize o incidente dentro da janela de 1 hora. Logs forenses que permitam uma reconstrução de 14 dias. Failover que não consuma seu orçamento de 4 horas de inatividade em um período móvel de 12 meses.

‍

Um serviço de DDoS gerenciado que leva 90 segundos para detectar e 5 minutos para mitigar é aceitável para fins de SLA. 

‍

Não é aceitável para fins de notificação à MAS. É aqui que as arquiteturas híbridas superam as puramente em nuvem, já que a inspeção local (on-prem) identifica o ataque antes que os logs da borda da nuvem o façam.

‍

A Camada da Lei de Emenda à Cibersegurança de 2024

A Lei de Cibersegurança (Emenda) de 2024 de Singapura entrou em vigor em 31 de outubro de 2025. Trata-se de uma camada regulatória distinta da MAS TRM, mas que se sobrepõe a ela para qualquer instituição financeira classificada também como Infraestrutura de Informação Crítica.

‍

A Lei acrescenta:

• Notificação de 2 horas à CSA para incidentes que interrompam serviços essenciais (em comparação com a 1 hora da MAS para incidentes cibernéticos)
• Relatório de incidentes na cadeia de suprimentos; se o seu fornecedor de DDoS sofrer uma interrupção que afete o seu serviço, isso agora está no escopo
• Relatório de ataques com suspeita de APT, mesmo sem atribuição confirmada
• Uma nova categoria de Infraestrutura Digital Fundamental (FDI) que coloca provedores de nuvem, operadores de data centers e provedores de segurança gerenciada sob regulação direta da CSA pela primeira vez

‍

Este último ponto é o que a maioria dos fornecedores ainda não precificou. Um serviço de DDoS exclusivamente em nuvem que atenda a um cliente de CII em Singapura agora é uma entidade regulada pela CSA, com seu próprio cronômetro para notificação de incidentes.

‍

Por que a maioria das arquiteturas exclusivamente em nuvem enfrenta dificuldades sob o escrutínio da MAS

Três problemas estruturais tornam difícil defender o uso de DDoS puramente em nuvem em uma auditoria da MAS.

‍

1. Residência de dados

A MAS TRM tem sido cada vez mais específica sobre onde os dados dos clientes podem ser processados e armazenados. Um serviço de DDoS puramente em nuvem que redireciona o tráfego para centros de limpeza em Frankfurt, Ashburn ou até mesmo Tóquio levanta questões jurisdicionais que os auditores agora fazem explicitamente. Por onde o tráfego do cliente transita fisicamente? Onde os logs são armazenados?

‍

2. Registro de logs em ambiente multilocatário

Provedores de DDoS em nuvem operam infraestruturas multilocatárias. Produzir evidências isoladas por locatário para uma RCA da MAS, dentro de 14 dias, é mais difícil do que os materiais de marketing sugerem.

‍

3. O relógio de 1 hora vs. o relógio de chamados de suporte

Se a sua mitigação de DDoS for acionada por um controle interno do lado do fornecedor de nuvem, o momento em que você toma "ciência" do incidente é quando o portal deles sinaliza ou o SOC deles entra em contato. Alguns fornecedores possuem SLAs de notificação de 15 minutos. Outros, de 60 minutos. O relógio da MAS não leva em conta o horário comercial.

‍

A arquitetura que sobrevive ao escrutínio da MAS é a híbrida. Dispositivo local na rede, nuvem do fornecedor para capacidade de pico e portal unificado alimentando seu SOC dentro da janela de 1 hora.

‍

Os sete controles que toda arquitetura em conformidade com a MAS deve demonstrar

Estes são os controles que aparecem nas respostas de RFI da MAS, em simulações estilo iCAST e em revisões de risco em nível de diretoria.

‍

1. Proteção sempre ativa, não sob demanda. A MAS espera que a detecção ocorra continuamente. A limpeza sob demanda cria uma janela onde o relógio do incidente já começou antes mesmo de você iniciar a mitigação.
2. Proteção em múltiplas camadas. Camada de rede (volumétrica L3/4), camada de aplicação (L7 / inundações HTTPS) e camada de DNS. Os auditores da MAS perguntam cada vez mais sobre DNS especificamente.
3. Limpeza na região. Tráfego do cliente processado em Singapura ou em uma jurisdição explicitamente aprovada. O contrato com o fornecedor especifica o local de limpeza por classe de tráfego.
4. Runbooks documentados. Procedimentos de mitigação passo a passo para os 15 principais tipos de ataque. Revisados anualmente. Testados em exercícios de simulação.
5. Failover testado com evidências. A MAS espera evidências de que seu failover realmente funciona, não apenas uma política que diga que deveria funcionar. Exercícios anuais de engenharia de caos ou simulações de BCP com documentação dos resultados.
6. Visibilidade do SOC para o prazo de 1 hora. Os logs do serviço de DDoS fluem para seu SIEM/SOAR quase em tempo real. Seu SOC identifica o incidente antes do cliente.
7. SLAs de fornecedores alinhados ao uptime do TRM. O SLA publicado pelo fornecedor corresponde ou supera 99,95%. O tempo de inatividade deles é somado ao seu orçamento de inatividade. Existem recursos contratuais para violações.

‍

Se o seu serviço de DDoS atual não consegue apresentar evidências para todos os sete pontos, você tem uma lacuna de arquitetura, não apenas uma lacuna de aquisição.

‍

Como a arquitetura híbrida se mapeia para o TRM da MAS

‍

Este é o mapeamento específico que fecha negócios nos ciclos de aquisição de BFSI em Singapura.

‍

‍

Modelo de linguagem para RFP: O que exigir de qualquer fornecedor de DDoS

Estes são os termos contratuais específicos que uma instituição financeira regulada pela MAS deve exigir em qualquer RFP de DDoS.

• SLA de detecção: "O fornecedor deve detectar ataques volumétricos de DDoS em até 60 segundos após o início do ataque."
• SLA de mitigação: "O fornecedor deve iniciar a mitigação em até 90 segundos após a detecção."
• SLA de notificação: "O fornecedor deve notificar o SOC do cliente em até 15 minutos após qualquer evento de DDoS, independentemente do tamanho."
• Local de filtragem: "O tráfego do cliente deve ser filtrado em Singapura ou em jurisdição aprovada. O fornecedor deve fornecer atestado de fluxo de rede mediante solicitação."
• Isolamento de locatário: "O fornecedor deve produzir logs forenses por cliente suficientes para suportar uma RCA da MAS em até 14 dias."
• Disponibilidade: "A disponibilidade do serviço do fornecedor deve ser igual ou superior a 99,95%. Créditos de serviço se aplicam abaixo deste limite."
• Alinhamento com relatórios da CSA: "O fornecedor deve notificar o cliente em até 30 minutos sobre qualquer incidente que afete os sistemas regulamentados do cliente, de forma suficiente para que o cliente cumpra a notificação de 2 horas à CSA sob a Lei de Cibersegurança de 2024."
• Direito de auditoria: "O cliente reserva-se o direito de auditar as operações de filtragem do fornecedor uma vez por ano, mediante aviso prévio razoável."

‍

Se um fornecedor contestar qualquer um desses pontos, a contestação é a resposta. Eles não conseguem cumprir as obrigações da MAS.

‍

Onde Cloudflare, AWS Shield Advanced e Akamai Prolexic falham

Os três produtos de DDoS de classe hiperescala mais comumente implantados em instituições financeiras de Singapura apresentam lacunas específicas em relação aos requisitos revisados da MAS:

‍

• Cloudflare Magic Transit: Encaminha o tráfego do cliente para a rede global Anycast da Cloudflare. O tráfego de Singapura geralmente chega ao PoP de SIN, mas o contrato não garante o processamento em uma única jurisdição sob condições de ataque. Os SLAs de notificação são baseados em alertas no portal por padrão; o contato manual entre SOCs exige o plano Enterprise.
• AWS Shield Advanced: Protege apenas recursos da AWS. Para uma instituição financeira que opera em ambiente híbrido, o Shield é apenas uma parte de uma pilha multivendedor, e a cadeia de evidências para o MAS precisa cobrir essas lacunas. A escalada de 15 minutos para a equipe de resposta do Shield exige suporte Business ou Enterprise, o que adiciona um custo mínimo de aproximadamente US$ 15 mil/mês.
• Akamai Prolexic: Possui a presença de PoP mais robusta em Singapura e um SLA explícito de mitigação de 3 segundos. A lacuna reside no isolamento forense por locatário para a análise de causa raiz (RCA) de 14 dias; os relatórios do Prolexic são detalhados, mas a profundidade do isolamento de locatários varia conforme o nível do serviço. Confirme qual SKU está incluído no seu contrato.

‍

Nenhuma dessas opções está incorreta para a instituição certa. Todas são mais fáceis de justificar em uma auditoria do MAS quando combinadas com um dispositivo local dentro da rede do CSP, o que reforça a estratégia de residência de dados.

‍

Perguntas frequentes

As diretrizes de TRM do MAS se aplicam a instituições financeiras não bancárias?

Sim. As diretrizes de TRM do MAS aplicam-se a todas as instituições financeiras reguladas pelo MAS, incluindo bancos, seguradoras, intermediários do mercado de capitais, provedores de serviços de pagamento, sistemas de pagamento designados e emissores de moeda eletrônica. Os requisitos de disponibilidade e notificação de incidentes variam de acordo com o tamanho e a criticidade da instituição, mas a estrutura aplica-se de forma abrangente.

‍

E quanto aos fornecedores de proteção DDoS em nuvem com PoP em Singapura, eles estão em conformidade com o MAS?

Ter um PoP de limpeza (scrubbing) em Singapura é necessário, mas não suficiente. O fornecedor também precisa demonstrar que o tráfego do cliente é realmente roteado por esse PoP, que os logs são armazenados em Singapura, que o isolamento de locatários permite RCAs individuais por cliente e que os SLAs de notificação atendem ao prazo de 1 hora. Um PoP é infraestrutura. Conformidade é processo.

‍

Como funciona o prazo de 1 hora se o ataque começar às 3 da manhã?

O cronômetro começa no momento em que a instituição regulada toma conhecimento do incidente. As instituições financeiras reguladas precisam de operações de SOC 24/7 capazes de confirmar e reportar um incidente de DDoS independentemente do horário. A terceirização do SOC para o fornecedor é aceitável, desde que o SLA de notificação do fornecedor seja rápido o suficiente.

‍

Somos obrigados a usar um fornecedor de DDoS constituído em Singapura?

Não. As diretrizes MAS TRM não exigem constituição jurídica em Singapura. Elas exigem uma gestão de risco demonstrável, incluindo due diligence de fornecedores, obrigações contratuais, direitos de auditoria e evidências de resposta a incidentes.

‍

O que acontece se ultrapassarmos o limite de 4 horas de inatividade?

Uma violação desencadeia uma resposta de supervisão da MAS. A resposta inicial é, normalmente, um pedido de esclarecimento e um plano de remediação. Violações recorrentes podem escalar para ações formais de supervisão, incluindo revisões independentes obrigatórias (como o setor financeiro de Singapura vivenciou em 2023).

‍

Qual é a diferença entre as diretrizes MAS TRM e a Lei de Emenda à Cibersegurança de 2024?

As diretrizes MAS TRM são específicas para o setor de serviços financeiros. A Lei de Cibersegurança é intersetorial e aplica-se a Infraestruturas de Informação Crítica em diversos setores. Muitas instituições financeiras reguladas pela MAS também são designadas como CII, caso em que ambas as estruturas se aplicam.

‍

Como isso afeta meu contrato atual com a Cloudflare ou AWS Shield?

A maioria dos contratos de DDoS exclusivamente em nuvem é anterior à revisão das diretrizes MAS TRM e à Lei de Cibersegurança de 2024. A maioria das instituições precisará de uma emenda contratual, ou de um arranjo híbrido paralelo para cargas de trabalho reguladas pela MAS, para adequar a arquitetura à conformidade.

‍

O que fazer esta semana

Se você é uma instituição financeira regulada em Singapura avaliando a conformidade de DDoS, o próximo passo concreto é uma análise de lacunas entre os SLAs publicados pelo seu fornecedor atual e os 7 controles acima. Em metade dos casos, a lacuna pode ser resolvida por meio de uma emenda contratual. Na outra metade, é necessária uma mudança na arquitetura.

‍

Se você é um provedor de serviços em nuvem vendendo proteção contra DDoS para o mercado de serviços bancários e financeiros de Singapura, crie o documento de mapeamento de arquitetura mencionado acima e apresente-o a todos os clientes potenciais do setor em seu pipeline.

‍

Para uma conversa sobre como a arquitetura híbrida da Nexusguard se alinha aos controles MAS TRM, agende uma revisão de 30 minutos com nossa equipe na região da Ásia-Pacífico: https://www.nexusguard.com/pt/contact-us

‍