O que o score mede e o que não mede
O Security Score avalia a superfície de ataque visível de fora dos seus domínios. Trata-se de tudo o que uma pessoa externa consegue ver sem credenciais: o seu site, os seus servidores de correio, os seus registos 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 do e-mail e fugas de dados, cada uma com um valor próprio de 0 a 100.
É deliberadamente uma visão de fora. É aí que os atacantes começam, e muitos incidentes têm origem em configurações erradas simples: cabeçalhos de segurança em falta, autenticação de e-mail fraca, software desatualizado num servidor esquecido. Estas deteções são muitas vezes corrigidas depressa, desde que se conheçam.
O que o score não mede é igualmente importante. Não vê o que está por trás do início de sessão, como os seus colaboradores estão formados ou se as suas cópias de segurança funcionam. Não substitui um teste de intrusã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 em vez dele.
Como tratar os problemas
Comece pelos problemas com maior impacto. A lista pode ser filtrada por gravidade e cada problema mostra o seu impacto no score. As deteções críticas e elevadas vêm primeiro, depois as médias. Os avisos baixos e informativos podem ser tratados quando houver tempo, ou pode decidir conscientemente ignorá-los.
Abra cada problema na vista de detalhe. Aí encontra a descrição, os detalhes da deteção, os ativos afetados e uma proposta de correção. Verifique primeiro se o ativo afetado ainda lhe pertence e se ainda é necessário. Por vezes, a melhor correção é desligar um serviço antigo.
Defina o estado «Em curso» assim que alguém começar a tratar o problema. Para alterações maiores, crie um plano de ação com responsável e prazo e associe-o ao controlo correspondente. Quando o problema estiver corrigido, marque-o como tal. Uma nova análise confirma a correção antes de o problema ser fechado.
Se, no seu caso, uma deteção for intencional, defina-a como «Ignorado» e justifique a decisão. Assim, o score continua honesto e a decisão rastreável.
Comunicar corretamente o score
Um valor de 0 a 100 e uma nota de A a F são mais fáceis de compreender para a gestão de topo 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 sua evolução. O histórico de 7, 30, 60 e 90 dias ou de um ano mostra se a situação está a melhorar.
Apresente o score juntamente com as categorias. Um bom valor global pode esconder uma segurança do 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 do correio ou rede.
Não defina o score como objetivo em si. Quem só olha para o número sente a tentação de ignorar deteções incómodas. Faz mais sentido um objetivo como este: os problemas críticos e elevados não ficam em aberto mais do que um período definido, que estabelece na sua política.
Para o exterior, mostre o ponto da situação através do Trust Center. O selo Sightadel aí apresentado tem ligação para o seu scorecard. Os clientes veem assim que as suas informações provêm de um sistema bem mantido.
O que os auditores daí retiram
Na gestão de vulnerabilidades, o auditor não verifica se não tem vulnerabilidades. Ninguém está nessa situação. Verifica se tem um processo para as identificar, avaliar e tratar, e se esse processo é praticado.
O Security Score fornece provas para isso. A lista de problemas mostra quando uma deteção foi identificada pela primeira e pela última vez, que estado tem e qual o seu impacto no score. Um plano de ação associado ao controlo mostra como a deteção técnica se tornou uma medida gerida. O histórico do score mostra o efeito ao longo do tempo.
Tenha atenção à coerência com os seus documentos. Se a sua política estabelece que as vulnerabilidades críticas são corrigidas num determinado prazo, o auditor quer ver exemplos disso. As deteções ignoradas sem justificação também se destacam.
Também aqui a delimitação é importante. A visão de fora cobre apenas uma parte da gestão de vulnerabilidades. Os sistemas internos, os postos de trabalho e as aplicações por trás do início de sessão precisam de verificações próprias. Os resultados destas são guardados como evidência na biblioteca.
