O que o score mede e o que não mede
O Security Score avalia a superfície de ataque dos seus domínios visível de fora. Trata-se de tudo o que uma pessoa externa consegue ver sem credenciais: seu site, seus servidores de e-mail, seus registros DNS e a reputação dos seus endereços. Daí resultam as categorias segurança de rede, segurança de aplicações, DNS, reputação de IP, segurança de e-mail e vazamentos de dados, cada uma com um valor próprio de 0 a 100.
É propositalmente uma visão de fora. É ali que os atacantes começam, e muitos incidentes têm origem em configurações erradas simples: cabeçalhos de segurança ausentes, autenticação de e-mail fraca, software desatualizado em um servidor esquecido. Esses achados muitas vezes são corrigidos rapidamente, desde que sejam conhecidos.
O que o score não mede é igualmente importante. Ele não vê o que está por trás do login, como seus funcionários estão treinados ou se seus backups funcionam. Ele não substitui um teste de invasão nem um sistema de gestão. Uma boa nota significa uma visão de fora limpa, não uma empresa segura. Por isso, no Sightadel, o score aparece ao lado do progresso de compliance por framework, e não no lugar dele.
Como tratar os problemas
Comece pelos problemas de maior impacto. A lista pode ser filtrada por gravidade e cada problema mostra seu impacto no score. Os achados críticos e altos vêm primeiro, depois os médios. Os avisos baixos e informativos podem ser tratados quando houver tempo, ou você pode decidir conscientemente ignorá-los.
Abra cada problema na tela de detalhes. Lá você encontra a descrição, os detalhes do achado, os ativos afetados e uma proposta de correção. Verifique primeiro se o ativo afetado ainda é seu e se ainda é necessário. Às vezes, a melhor correção é desativar um serviço antigo.
Defina o status “Em andamento” assim que alguém começar a tratar o problema. Para mudanças maiores, crie um plano de ação com responsável e prazo e vincule-o ao controle correspondente. Quando o problema estiver corrigido, marque-o como tal. Uma nova varredura confirma a correção antes de o problema ser fechado.
Se, no seu caso, um achado for intencional, defina-o como “Ignorado” e justifique a decisão. Assim, o score continua honesto e a decisão, rastreável.
Comunicar o score da forma certa
Um valor de 0 a 100 e uma nota de A a F são mais fáceis de entender para a alta direção do que uma lista de nomes de cabeçalhos. Aproveite isso, mas explique o valor. Mais importante do que o número em si é a evolução dele. O histórico de 7, 30, 60 e 90 dias ou de um ano mostra se a situação está melhorando.
Apresente o score junto com as categorias. Um bom valor geral pode esconder uma segurança de e-mail forte e uma segurança de aplicações fraca. As categorias mostram onde está o problema e quem é responsável: desenvolvimento web, operação de e-mail ou rede.
Não transforme o score em um objetivo em si. Quem só olha para o número fica tentado a ignorar achados incômodos. Faz mais sentido um objetivo como este: problemas críticos e altos não ficam em aberto por mais do que um período definido, que você estabelece na sua política.
Para o público externo, mostre a situação pelo Trust Center. O selo Sightadel exibido lá tem link para o seu scorecard. Assim, os clientes veem que suas informações vêm de um sistema bem mantido.
O que os auditores tiram disso
Na gestão de vulnerabilidades, o auditor não verifica se você não tem vulnerabilidades. Ninguém está nessa situação. Ele verifica se você tem um processo para identificá-las, avaliá-las e tratá-las, e se esse processo é praticado.
O Security Score fornece provas para isso. A lista de problemas mostra quando um achado foi detectado pela primeira e pela última vez, qual é o status dele e qual o impacto no score. Um plano de ação vinculado ao controle mostra como o achado técnico virou uma medida gerenciada. O histórico do score mostra o efeito ao longo do tempo.
Preste atenção à coerência com os seus documentos. Se a sua política estabelece que vulnerabilidades críticas são corrigidas em um determinado prazo, o auditor quer ver exemplos disso. Achados ignorados sem justificativa também chamam atenção.
Aqui também a delimitação é importante. A visão de fora cobre apenas uma parte da gestão de vulnerabilidades. Sistemas internos, estações de trabalho e aplicações por trás do login precisam de verificações próprias. Os resultados delas são armazenados como evidência na biblioteca.
