Rever relatórios do Sophos Managed Risk e corrigir vulnerabilidades

O Sophos Managed Risk cria semanalmente relatórios sobre vulnerabilidades e a superfície de ataque externa. Em My Products > Managed Risk > Report History, pode transferi-los, delimitar os sistemas afetados e definir os passos seguintes. O Managed Risk recomenda medidas corretivas. No entanto, as alterações a servidores, aplicações, dispositivos de rede ou recursos cloud devem ser implementadas de forma controlada na própria organização.

Para uma orientação rápida:

1. Verifique a notificação de um novo relatório e abra Report History diretamente no tenant correto do Sophos Fusion (anteriormente Sophos Central).
2. Em External, Internal ou Account, localize o relatório semanal esperado pelo nome e contexto da análise.
3. Abra o relatório de vulnerabilidades em HTML para a triagem; utilize CSV e PDF conforme a tarefa.
4. Reveja primeiro os riscos elevados e os ativos críticos. Em seguida, verifique o ativo afetado, a base da deteção e a recomendação da Sophos.
5. Determine o responsável pelo sistema ou serviço fora do Managed Risk, planeie a alteração e valide-a tecnicamente.
6. Solicite a investigação de dúvidas ou problemas com resultados de análises e relatórios através de um caso do Managed Risk; discuta as recomendações corretivas na revisão periódica com a equipa do Managed Risk.

Escolher o tipo e o formato de relatório corretos

O Report History está dividido em três separadores. O nome do ficheiro indica a execução da qual provém o relatório:

Os elementos Account_Name e Scan_name representam, respetivamente, o nome da conta e o nome da análise. São marcadores que devem ser comparados com os nomes no próprio tenant.

Os formatos têm finalidades diferentes:

• HTML é a melhor vista de trabalho para a triagem. Mostra as vulnerabilidades ativas e resolvidas por nível de risco e ativo e disponibiliza filtros interativos.
• CSV é adequado para uma avaliação estruturada e para comparação com o registo interno do trabalho. Os relatórios ASM e Discovery estão disponíveis exclusivamente em CSV.
• PDF é uma versão estática e legível de um relatório de vulnerabilidades. Geralmente, o HTML é mais útil para limitar os resultados a ativos específicos.

Um ficheiro CSV de ASM ou Discovery não é um relatório de vulnerabilidades noutro formato. O ASM descreve a superfície de ataque externa detetada; o Discovery descreve os ativos encontrados numa análise de descoberta interna. Ambos podem clarificar o âmbito de verificações posteriores, mas não contêm a mesma análise que um relatório de vulnerabilidades.

Localizar um relatório semanal e verificar a transferência

1. Abra My Products > Managed Risk > Report History.
2. Selecione o separador adequado: External, Internal ou Account.
3. Procure o relatório semanal esperado com base no padrão de nome documentado e na análise em causa.
4. Na coluna Download report, clique na ligação correspondente ao formato necessário.
5. Abra o ficheiro transferido e, antes de o avaliar, confirme que a conta ou análise e o tipo de relatório correspondem à tarefa de revisão.

A Sophos envia uma notificação quando estão disponíveis novos relatórios. A notificação inicia a revisão, mas o Report History é a referência oficial. O relatório esperado deve estar disponível para transferência no separador correto. Se existirem várias análises internas, a comparação do nome da análise evita a avaliação acidental do relatório de outro segmento de rede.

Se faltar um relatório esperado, verifique primeiro o tenant, o separador selecionado, o padrão do nome e a análise afetada. Depois, confirme se a notificação pertence efetivamente à execução semanal atual. Se a divergência persistir, registe o nome do relatório, o separador, a análise esperada e a hora da notificação para enviar um pedido à equipa do Managed Risk. Não inclua credenciais de acesso nem outros segredos.

Cada relatório de análise permanece acessível no Sophos Fusion por um período máximo de dois anos a contar da data de conclusão dessa análise. Destina-se exclusivamente ao uso interno do cliente ou MSP e não pode ser redistribuído, revendido nem transmitido de qualquer outra forma para fora da respetiva organização.

Filtrar e priorizar o relatório HTML

Transfira um relatório de vulnerabilidades em HTML e abra-o localmente. Nesta vista, pode filtrar os resultados por Risk level, Device type e IP address.

O relatório Account acrescenta filtros para tipos de análise e análises individuais. Resume os dados da análise de vulnerabilidades externa e de todas as análises internas. Por isso, é adequado para uma priorização global, mas não substitui a análise do relatório individual apropriado quando são necessários detalhes.

Na primeira triagem, comece pelos níveis de risco mais elevados e restrinja depois os resultados por ativo, tipo de dispositivo ou análise. Contudo, o nível de risco não determina sozinho a ordem. Dentro do mesmo nível, um sistema exposto à Internet ou um ativo crítico para o negócio pode ser mais urgente do que um sistema de testes isolado. Verifique também se várias entradas estão relacionadas com a mesma causa técnica no mesmo ativo.

Identificar ativos críticos

No relatório HTML, a lista Assets encontra-se à esquerda. Ao colocar o ponteiro do rato sobre o nome de um sistema marcado, uma janela mostra a etiqueta Critical Asset e, mais abaixo, a Critical Asset Description. A opção Show critical assets only limita a vista às vulnerabilidades que afetam ativos críticos. Os widgets no topo mostram então o número de vulnerabilidades associadas e de ativos afetados.

Esta marcação fornece contexto empresarial, mas não determina automaticamente a correção concreta. A descrição, a função real e o atual responsável pelo sistema devem continuar a ser comparados com a documentação interna dos ativos.

As análises podem produzir falsos positivos e falsos negativos. Além disso, a Sophos não garante que forneçam uma imagem completa e exata das falhas de segurança. Por isso, uma constatação requer verificação técnica; inversamente, a ausência de uma constatação não prova que não exista uma vulnerabilidade. Não confie apenas nas análises.

Da constatação à correção segura

Uma entrada no relatório é o ponto de partida de uma revisão técnica, não uma alteração já autorizada. Qualquer ação baseada nas sugestões da Sophos relativas à aplicação de patches e à correção de vulnerabilidades está fora do âmbito do serviço; o cliente ou MSP é o único responsável pela sua execução e pelas consequências. Para cada constatação prioritária, siga este ciclo:

1. Confirmar o ativo: compare o endereço IP, nome do anfitrião, tipo de dispositivo, tipo de análise e, quando aplicável, a descrição do ativo crítico com a documentação atual. Se não for possível identificar o ativo, não faça alterações com base numa suposição.
2. Compreender a constatação: leia o nível de risco, o componente afetado e as informações ou provas do relatório. Verifique se provém de uma análise externa, interna, autenticada ou não autenticada; tipos diferentes podem fornecer níveis de detalhe distintos.
3. Avaliar a recomendação: compare a correção recomendada pela Sophos com as instruções do fabricante, a versão utilizada, as dependências e o estado real do sistema. Uma recomendação geral, como uma atualização ou alteração de configuração, deve adequar-se ao produto e ao ambiente.
4. Determinar o responsável técnico: identifique o responsável pelo sistema, aplicação, rede ou cloud através do seu processo operacional. O Report History não documenta uma função de atribuição; o registo do trabalho e a aprovação da alteração devem, portanto, ficar no sistema interno destinado a esse fim.
5. Proteger a alteração: defina o impacto, a janela de manutenção, uma cópia de segurança ou opção de reversão e um teste funcional adequado antes da implementação. Sobretudo em ativos de produção ou críticos, o nível de risco não justifica ignorar dependências.
6. Corrigir e validar: depois da alteração autorizada, verifique a versão ou configuração no sistema de destino e teste a função afetada. A entrada do relatório, por si só, não prova que o sistema funciona corretamente.
7. Verificar o relatório seguinte: no próximo relatório disponível, volte a examinar a mesma análise e o mesmo ativo. Um relatório alterado é uma prova adicional, mas não substitui a verificação técnica do sistema nem uma função garantida de nova análise ou encerramento.

Para o seu próprio registo de trabalho, anote os factos verificáveis: relatório e semana, análise, ativo, vulnerabilidade, recomendação verificada, área técnica responsável, alteração autorizada e resultado da validação técnica. Não deduza campos ou estados do Managed Risk que não estejam documentados na interface.

Limite da função de relatórios: não estão documentadas para a vista de relatórios do Managed Risk funções de atribuição, aceitação do risco, nova verificação iniciada manualmente, encerramento ou controlo de SLA. Estes processos podem ser necessários internamente, mas não são controlos garantidos nem estados do produto Managed Risk. As designações “active” e “resolved” no relatório HTML também não equivalem a um estado de pedido controlável pelo administrador.

Utilizar recomendações e revisões periódicas

A equipa do Managed Risk revê os relatórios, faz recomendações e discute as constatações atuais, os novos riscos e as medidas recomendadas em reuniões periódicas. Para se preparar, reúna as constatações de risco elevado ainda por resolver, os ativos afetados, os factos técnicos já verificados e as perguntas concretas. Assim, fica claro se é necessário explicar a deteção, clarificar o contexto da análise ou avaliar uma medida alternativa.

Um caso do Managed Risk é o meio documentado quando a própria equipa não consegue esclarecer dúvidas ou problemas relativos a resultados de análises de vulnerabilidades ou relatórios. Aplica-se, por exemplo, se:

• um resultado de análise de risco elevado não for claro ou plausível,
• o relatório e o estado atual do sistema forem diferentes,
• o contexto da análise, a deteção ou o conteúdo do relatório suscitarem dúvidas.

As perguntas sobre a correção recomendada também podem ser preparadas para a revisão periódica com a equipa do Managed Risk. Um caso não substitui a aprovação interna da alteração nem constitui uma aceitação ou encerramento garantido da correção.

O pedido deve incluir o nome exato do relatório, o separador e a semana, a análise afetada, o ativo, a vulnerabilidade em causa, a divergência observada e as verificações seguras já efetuadas. Não transmita palavras-passe, chaves privadas ou outros segredos.

Separar a correção de vulnerabilidades da resposta ativa a incidentes

O Managed Risk é um serviço de gestão de vulnerabilidades e requer uma licença MDR ou MDR Plus existente. O processo normal deste artigo avalia vulnerabilidades, planeia medidas de reforço ou atualizações e verifica o respetivo efeito técnico. Não é o mesmo que responder a uma intrusão ativa.

Se a investigação revelar indícios de abuso em curso, uma ameaça ativa ou sistemas já comprometidos, não aguarde pelo relatório da semana seguinte. Aplique o processo acordado de resposta a incidentes ou escalamento MDR. O relatório de vulnerabilidades pode fornecer contexto, mas não substitui a investigação, contenção e recuperação do incidente.

Verificação final de cada ciclo de revisão

No final de cada ciclo, confirme que:

• todos os relatórios semanais esperados em External, Internal e Account foram revistos,
• o tipo, nome, análise e formato do relatório correspondem à respetiva avaliação,
• os riscos elevados e as vulnerabilidades em ativos críticos foram avaliados tecnicamente em primeiro lugar,
• o ativo e a base da deteção são rastreáveis,
• cada correção implementada foi validada no sistema de destino e com um teste funcional adequado,
• as constatações de risco elevado abertas ou pouco claras estão preparadas para a equipa do Managed Risk com perguntas concretas,
• os indícios de uma ameaça ativa não foram confundidos com a correção normal de vulnerabilidades.

Esta verificação documenta a sua própria revisão. Não estabelece um estado final no Managed Risk nem garante um prazo para que uma alteração apareça num relatório posterior.