Requisitos da SAMA para testes de intrusão
Se o Banco Central Saudita o supervisiona, o teste de intrusão é uma obrigação anual recorrente e não um projeto. O referencial é específico em dois pontos que decidem se as suas evidências sobrevivem à revisão: os testes têm de ser independentes e o âmbito tem de alcançar os sistemas que os seus clientes podem tocar.
O requisito, dito com clareza
Espera-se que as instituições supervisionadas pelo Banco Central Saudita realizem testes de intrusão externos independentes no mínimo anuais, com âmbito a cobrir os sistemas expostos ao exterior, as aplicações web e a infraestrutura de rede.
Três palavras nessa frase carregam todo o peso, e cada uma é um ponto onde as evidências falham habitualmente na revisão:
- Independentes — não realizados pela equipa que constrói ou opera os sistemas sob teste.
- Anuais, no mínimo — o ciclo anual é um piso, e uma alteração material aos sistemas expostos à internet é um gatilho separado.
- Teste de intrusão — não uma análise de vulnerabilidades com outra capa. Os avaliadores tornaram-se bons a distingui-los.
Onde as evidências da SAMA falham realmente
Quatro modos de falha explicam a maior parte do que é contestado, e os quatro custam menos a evitar do que a remediar.
Uma análise apresentada como teste de intrusão
O sinal é estrutural: cada achado é um CVE com uma descrição fornecida pelo fabricante, nada está encadeado e não há narrativa que explique o que um atacante poderia conseguir. Um teste de intrusão demonstra impacto: este serviço exposto entrega uma credencial, essa credencial alcança este sistema interno, que contém estes dados. Se o seu relatório é uma lista ordenada de versões, é uma análise. A distinção por inteiro.
Uma independência que não se aguenta
Testes realizados pela equipa de engenharia, pelo prestador de serviços geridos que também opera a infraestrutura, ou por um fabricante a avaliar o seu próprio produto. Cada um destes casos falha o requisito de independência por mais competentes que tenham sido os testes.
Um âmbito que falha a camada voltada ao cliente
Backends de banca móvel, APIs de parceiros, a nova integração fintech lançada depois de assinado o âmbito. Os sistemas expostos à internet e as aplicações web estão explicitamente nomeados no referencial, pelo que uma lacuna aqui é uma falha direta e não uma questão de critério.
Sem reteste
Um relatório com doze achados de severidade alta e nenhuma evidência de que algum tenha sido fechado é, da perspetiva de um revisor, a documentação de um problema por resolver. O ciclo de remediação e reteste é o que converte um teste em evidência de conformidade.
O que o trabalho cobre
A linha de base regulatória, todos os anos:
- Testes de rede externa — todo o parque exposto à internet: banca online, interfaces de pagamento, VPN e acesso remoto, infraestrutura de correio, e os hosts publicados para um projeto e nunca retirados.
- Testes de aplicações web e APIs — autenticação e gestão de sessões, autorização e controlo de acessos entre clientes, lógica de negócio nos fluxos de transação, injeção, e as APIs por detrás das aplicações móveis. Numa instituição financeira, os achados de lógica de negócio são normalmente os que mais importam e os que a automação nunca encontra.
Recomendado a par disso, e incluído pela maioria das instituições num ciclo anual ou alternado:
- Testes de rede interna — até onde chega realmente um ponto de apoio, e se a segmentação entre o ambiente corporativo e o de pagamentos aguenta.
- Active Directory — abuso de ADCS, Kerberoasting, delegação e caminhos de ACL até Domain Admin. É assim que um modesto ponto de apoio se torna um comprometimento de todo o banco, e é invisível aos testes externos.
- Nuvem — escalada no Entra ID e no Azure RBAC, armazenamento exposto e configuração incorreta de identidades, onde as cargas de trabalho migraram.
- Violação assumida — partir de um ponto de apoio em vez do perímetro, o que responde à pergunta que um conselho realmente faz: até onde poderia alguém chegar?
Onde também lida com dados de cartão, o requisito 11.4 do PCI DSS aplica-se em paralelo e sobrepõe-se substancialmente — dimensionados em conjunto são um só trabalho, não dois.
O entregável
Um relatório construído para a forma como as instituições financeiras o consomem realmente: um sumário executivo que o vosso conselho e o vosso regulador possam ler sem tradução, um corpo técnico com passos de reprodução, evidências e classificações CVSS para os vossos engenheiros, e um mapeamento explícito de cada achado ao controlo do referencial que lhe diz respeito, para que a vossa equipa de conformidade não tenha de construir esse mapeamento sozinha.
Depois, as partes que transformam um relatório em evidência: apoio à remediação enquanto corrigem, um reteste dos achados fechados e uma carta de atestação declarando que o teste foi realizado, por quem, contra que âmbito e em que datas. Tudo incluído. Um relatório de exemplo mostra o formato.
Quem o realiza
Lida diretamente com quem testa — sem gestor de conta, sem um júnior a executar ferramentas sob o nome de um sénior na fatura, sem três semanas de espera entre os testes e o relatório. Para um prazo regulatório, essa imediatez é normalmente o que permite cumprir a data.
Certificações, já que isto é sempre perguntado nas compras do setor financeiro: OSCP+, eCPPT, eWPT, eCIR, mais AZ-500, SC-200 e SC-300 para a parte Microsoft e Azure — todas verificáveis através da credential wallet da OffSec. Antes de me dedicar a tempo inteiro ao trabalho ofensivo fui engenheiro de deteção e analista de CTI, uma bagagem útil precisamente neste setor: o relatório diz-lhe não só como funciona um caminho de ataque, mas que aspeto teria tido no seu SIEM e se a sua monitorização o teria apanhado.
Trabalho remotamente a partir de Amã em GMT+3, o mesmo horário e a mesma semana de trabalho que Riade, em árabe ou inglês.
Como começar
Diga-me o seu tipo de licença, o que está no âmbito e até quando o teste tem de estar concluído. Receberá um orçamento fechado e uma data de início. Se o seu ciclo anual se aproxima e quer ver primeiro a sua exposição externa atual, a análise de perímetro gratuita leva uns minutos.
Relacionado: testes de intrusão na Arábia Saudita para ver como a SAMA convive com a NCA ECC, o controlo 2-11 do ECC se também carrega uma obrigação governamental, e a visão geral de conformidade para tudo o resto. Entre em contacto — o árabe é bem-vindo.
Perguntas sobre a SAMA
As organizações membro supervisionadas pelo Banco Central Saudita: bancos, companhias de seguros e resseguros, sociedades financeiras, centrais de risco de crédito e prestadores de serviços de pagamento, incluindo fintechs que operam sob licença da SAMA ou no seu sandbox regulatório. Se a sua licença vem da SAMA, o referencial aplica-se-lhe. As fintechs são frequentemente apanhadas de surpresa: a obrigação chega com a licença, numa fase em que o programa de segurança está muitas vezes ainda a formar-se.
Testes de intrusão externos independentes, no mínimo anuais. O «no mínimo» faz trabalho real nessa frase: espera-se geralmente que uma alteração material aos sistemas expostos à internet despolete testes independentemente do ponto do ciclo anual, e uma instituição que lançou uma nova plataforma voltada ao cliente seis meses após o teste anual e não a testou terá uma conversa difícil. Trate o teste anual como o piso e a alteração significativa como um gatilho separado.
Que os testes não podem ser realizados pelas pessoas que constroem ou operam os sistemas sob teste. Uma função de segurança interna que reporta separadamente da engenharia aproxima-se mais, mas a resposta mais limpa e habitualmente aceite é uma parte externa sem qualquer papel na construção ou operação do ambiente. É o requisito que as instituições falham com mais frequência, e descobrem-no na revisão e não no dimensionamento — que é a ordem cara.
O âmbito explicitamente nomeado são os sistemas expostos à internet, as aplicações web e a infraestrutura de rede. A maioria das instituições vai mais longe, e com razão: um teste que prova que um atacante consegue alcançar o perímetro mas nunca pergunta o que acontece a seguir responde a metade da pergunta. O padrão que funciona bem é uma avaliação externa e de aplicações web completa todos os anos como linha de base regulatória, integrando testes de rede interna e Active Directory pelo menos em anos alternados ou sempre que o parque mude materialmente.
Sim, e é o caso habitual. Normalmente já dispõem do mapeamento do referencial, de uma função GRC e de uma relação com a auditoria interna; o que precisam são os testes e as evidências que encaixam nisso tudo. Dimensiono face ao controlo que têm de satisfazer, mapeio os achados a esse controlo no relatório e entrego o reteste e a atestação que a vossa equipa de conformidade precisa de arquivar. Não sou uma consultora GRC e não tentarei vender-vos um programa de referencial: os testes são a parte que eu faço.
Teste anual da SAMA a vencer?
Independente, com o âmbito do referencial, e com o reteste e a atestação que a vossa equipa de conformidade arquiva.