A prática, não o objeto
Attack surface management é a disciplina de manter atualizado o inventário do que uma organização expõe, atribuir dono a cada item e reduzir o conjunto de forma contínua. A superfície de ataque é o objeto. ASM é o trabalho de administrá-lo.
A distinção parece acadêmica e decide compra. Toda empresa tem superfície de ataque. Poucas têm alguém responsável por saber qual é o tamanho dela nesta semana.
O ciclo, em quatro movimentos
Descobrir. Levantar o que responde, partindo do domínio raiz em vez da planilha de ativos. A diferença entre esses dois pontos de partida é o motivo de a prática existir.
Atribuir. Cada ativo encontrado precisa de dono. Ativo sem dono não vira ticket, e achado que não vira ticket não muda nada. É aqui que a maioria dos programas trava, e não na descoberta.
Classificar. Separar o que está exposto por engano do que está exposto por decisão. Um painel administrativo aberto e um site institucional estão os dois na internet, e só um é problema.
Reduzir. Desligar o que não precisa estar no ar. É a etapa mais barata e a menos executada, porque não gera métrica bonita: o número que ela move é o de ativos que deixaram de existir.
ASM e gestão de vulnerabilidades trabalham sobre listas diferentes
Essa é a confusão mais cara do assunto.
Gestão de vulnerabilidades recebe uma lista de ativos e procura falhas neles. O escopo é dado. A qualidade do resultado depende inteiramente de a lista estar certa.
ASM produz a lista. Ele existe porque a lista oficial está errada, e está errada por construção: foi montada de dentro para fora, seguindo o organograma, enquanto os ativos aparecem seguindo as decisões de dez times ao longo de dez anos.
Rodar um scanner excelente sobre um inventário incompleto devolve um relatório limpo sobre o escopo errado. O relatório limpo é pior que nenhum, porque produz confiança sem lastro.
| | gestão de vulnerabilidades | ASM |
|---|---|---|
| ponto de partida | inventário existente | domínio raiz |
| pergunta | que falhas há nestes ativos | que ativos existem |
| erro típico | escopo incompleto | achado sem dono |
| unidade | vulnerabilidade | ativo |
O que separa ferramenta de relatório
Três perguntas resolvem uma reunião comercial melhor que qualquer lista de funcionalidade.
Quanto tempo passa entre um ativo ficar exposto e o sistema avisar. Repare se a resposta fala de frequência de varredura ou de tempo até o aviso, porque varredura diária com processamento semanal produz aviso semanal.
Quanto do que é reportado vem com dono identificado. Achado sem responsável volta para a fila e morre lá.
O que a ferramenta não faz. Permissão excessiva em conta de nuvem e credencial válida usada por quem não devia não aparecem de fora, porque não respondem em porta nenhuma. Quem promete cobertura interna e externa no mesmo produto está vendendo o nome da categoria.
Onde a prática costuma falhar
Descoberta boa com atribuição ruim é o padrão. A empresa passa a enxergar quatro vezes mais ativos do que enxergava e não consegue transformar isso em trabalho, porque ninguém sabe de quem é cada um. O resultado é uma planilha maior e a mesma paralisia.
O segundo modo de falha é tratar ASM como projeto. Um levantamento pontual descreve um estado que já mudou quando o relatório fica pronto. A superfície muda toda semana, e a prática só entrega valor quando roda na mesma cadência da mudança.
ASM dentro de um programa maior
ASM cobre a descoberta e a redução. Ele não valida se uma falha é explorável, não quantifica perda em valor financeiro e não executa a correção.
Programas maduros encaixam ASM como a primeira fase de um ciclo de gestão de exposição, onde a validação e a mobilização vêm depois. Começar pela validação, sobre um inventário incompleto, ancora o esforço na parte errada do problema.
A gestão da superfície de ataque da CSURFACE opera esse ciclo a partir do domínio raiz, com atribuição de dono e classificação de exposição, sem agente instalado.