Questão de Segurança da Informação — Análise de Tráfego e Logs — INSTITUTO AOCP 2024

Análise de Vulnerabilidade: uma abordagem abrangente

Gabarito: letra C. A análise de vulnerabilidade mais eficaz combina ferramentas automatizadas, testes manuais e avaliações de código, pois cada técnica cobre uma lacuna das demais: a automação encontra vulnerabilidades conhecidas em larga escala, os testes manuais exploram falhas lógicas e de contexto que o scanner não vê, e a revisão de código identifica problemas na origem do desenvolvimento. Essa visão integrada é o que as melhores práticas de segurança da informação recomendam, em oposição a depender de uma única ferramenta ou de um único momento.

A análise de vulnerabilidade é o processo de identificar, classificar e priorizar as fraquezas de um sistema que podem ser exploradas por ameaças. Uma vulnerabilidade é uma "fraqueza de um ativo ou controle que pode ser explorada por uma ou mais ameaças" — ou seja, ela existe independentemente de já ter sido atacada. O objetivo da análise é justamente descobrir essas fraquezas antes que um atacante o faça, para que possam ser corrigidas ou mitigadas.

As melhores práticas, como as descritas na norma NBR ISO/IEC 27002 (que orienta a implementação de controles de segurança), recomendam uma abordagem multifacetada. A norma menciona, por exemplo, que a verificação de conformidade técnica deve ser feita "preferencialmente com o apoio de uma ferramenta automática, a qual gera relatórios técnicos para a interpretação dos especialistas técnicos" — mas isso não elimina a necessidade de análise humana. Na prática, um scanner automatizado (como Nessus ou OpenVAS) é excelente para varrer milhares de hosts e encontrar vulnerabilidades conhecidas (CVEs), mas ele não entende o contexto do negócio, não testa lógica de negócio, nem encontra falhas de design. Por isso, o analista precisa complementar com testes manuais (como tentativas de exploração controladas) e com a revisão do código-fonte, que revela problemas como injeção de SQL, vazamento de informações sensíveis ou falhas de autenticação.

Um exemplo concreto: imagine um sistema de gerenciamento de processos judiciais. Um scanner automatizado pode detectar que o servidor web está com uma versão desatualizada do Apache (vulnerabilidade conhecida). Mas só um teste manual pode descobrir que o formulário de busca permite injeção de SQL, e só a revisão de código pode revelar que a senha do banco de dados está hardcoded no script. Nenhuma técnica isolada cobre todos os casos — daí a necessidade de combiná-las.

A banca explora aqui a tendência de confiar cegamente em ferramentas automatizadas ou de priorizar ações reativas. A alternativa C é a única que reflete a visão holística que a segurança da informação exige: uma análise abrangente, que combina diferentes métodos para identificar tanto vulnerabilidades conhecidas (via scanners) quanto desconhecidas (via análise manual e de código).

Guarde este critério: a eficácia da análise de vulnerabilidade está na complementaridade das técnicas, não na exclusividade de uma delas. É exatamente essa fronteira que separa a alternativa correta das demais.

Alternativa A — ❌ Incorreta

Realizar apenas testes de intrusão internos é insuficiente. Embora a equipe interna conheça bem o sistema, ela pode ter vieses (achar que uma configuração é segura porque foi feita por ela) e não enxergar vulnerabilidades que um olhar externo ou uma ferramenta automatizada detectaria. Além disso, testes internos não cobrem a superfície de ataque externa, que é a mais explorada por atacantes. A análise eficaz deve incluir múltiplas perspectivas — interna, externa, automatizada e manual.

Alternativa B — ❌ Incorreta

Depender exclusivamente de ferramentas automatizadas e "corrigir vulnerabilidades em sua totalidade" é uma armadilha. Os scanners são ótimos para vulnerabilidades conhecidas, mas geram falsos positivos e falsos negativos: podem apontar problemas que não existem e deixar passar falhas lógicas ou de contexto. Além disso, o relatório da ferramenta precisa ser interpretado por um especialista — a norma ISO 27002 fala em "interpretação dos especialistas técnicos". A alternativa erra ao sugerir que o relatório é suficiente por si só e que todas as vulnerabilidades podem ser corrigidas automaticamente.

Alternativa C — ✅ Correta ⟵ GABARITO

Esta é a abordagem mais adequada e alinhada às melhores práticas. Combinar ferramentas automatizadas (para varredura em larga escala de vulnerabilidades conhecidas), testes manuais (para explorar falhas lógicas, de configuração e de contexto) e avaliações de código (para identificar problemas na origem do desenvolvimento) permite cobrir tanto vulnerabilidades conhecidas quanto desconhecidas. É exatamente essa complementaridade que torna a análise eficaz, como recomendam normas como a NBR ISO/IEC 27002 e frameworks como o NIST.

Alternativa D — ❌ Incorreta

Priorizar a correção das vulnerabilidades de baixo risco primeiro é uma inversão da lógica de gestão de riscos. O correto é priorizar as vulnerabilidades de alto risco (aquelas com maior probabilidade de exploração e maior impacto), pois são as que representam maior ameaça ao sistema. Corrigir primeiro as de baixo risco pode dar uma falsa sensação de segurança, enquanto as críticas continuam expostas. A priorização deve ser baseada na análise de risco, não na quantidade total de vulnerabilidades.

Alternativa E — ❌ Incorreta

Realizar a análise de vulnerabilidade somente após um incidente é uma postura reativa, quando a segurança da informação exige uma postura proativa. A análise deve ser feita periodicamente e continuamente, como parte do ciclo de gestão de vulnerabilidades, e não apenas como reação a um ataque. Esperar o incidente para analisar significa deixar o sistema exposto por todo o tempo anterior. A análise pós-incidente é útil para aprender com o ocorrido, mas não substitui a análise preventiva.

Gabarito: letra C