Em resumo: a gestão de vulnerabilidades numa PME é um ciclo enxuto e recorrente: conhecer os sistemas, acompanhar os alertas de forma direcionada, avaliar segundo o risco, decidir, executar e comprovar. O que conta não são ferramentas caras, mas responsabilidades claras e uma priorização que tenha em conta a acessibilidade, os dados e a situação de ataque. O PHP2Shell é um bom exemplo para praticar, porque todos os passos nele aparecem.
Centenas de alertas, pouco pessoal
Todas as semanas são publicadas novas falhas de segurança, em sistemas operativos, linguagens de programação, aplicações e plugins. Um grande grupo empresarial tem uma equipa para isso. Uma PME tem muitas vezes um responsável de TI, um ou dois administradores e vários prestadores de serviços externos. Ninguém consegue ler todos os alertas, e ninguém precisa de o fazer.
O que é preciso é um filtro: que alertas dizem respeito aos nossos sistemas, quais deles são urgentes e quem trata do assunto? Sem este filtro, acontece uma de duas coisas. Ou se ignora tudo até algo acontecer, ou cada alerta provoca agitação e o realmente crítico perde-se no ruído.
O ciclo da gestão de vulnerabilidades
Um procedimento sustentável para PME pode descrever-se em seis passos:
- Registar o que está em funcionamento. Sem inventário, não há comparação possível. Que sites, servidores, versões do PHP e aplicações opera, e onde? Como o conseguir, mostra-o Saber o que está a correr: inventário de todos os sites e servidores.
- Acompanhar os alertas. Subscreva poucas fontes fiáveis: os avisos do BSI (Gabinete Federal Alemão para a Segurança da Informação), os alertas dos fabricantes do seu software, as páginas de segurança da sua distribuição Linux e, no caso do PHP, a página inicial do php.net.
- Avaliar. O alerta diz-nos respeito? Se sim, com que urgência? Mais sobre isto adiante.
- Decidir. Corrigir, proteger temporariamente, isolar o sistema ou assumir o risco conscientemente. Quem pode decidir o quê?
- Executar. Instalar a atualização, aplicar uma medida provisória, contratar um prestador de serviços.
- Comprovar e acompanhar. A vulnerabilidade está mesmo fechada? Quando é que uma solução provisória será substituída?
Depois, o ciclo recomeça. Entram sistemas novos, saem sistemas antigos e surgem novos alertas.
No passo 2, ajuda uma regra simples: é melhor ler com regularidade poucas fontes do que muitas de vez em quando. Para um ambiente web típico de uma PME, bastam em regra os avisos do CERT-Bund (a equipa de resposta a incidentes do governo alemão) no BSI, os alertas de segurança da distribuição Linux em uso, as páginas dos fabricantes do CMS e da loja e a página inicial do php.net. Defina quem lê estas fontes e crie para isso uma caixa de correio ou um canal partilhado que não dependa de uma única pessoa.
Vale também a pena um olhar de fora. Uma análise regular de vulnerabilidades aos sistemas acessíveis ao público mostra se há software desatualizado ou serviços desnecessariamente abertos à vista. Não substitui nem o inventário nem as atualizações, mas revela sistemas que não constam de nenhuma lista.
Avaliar: o que vem primeiro
A pontuação CVSS, uma classificação normalizada da gravidade, é um bom ponto de partida. Para a ordem de trabalho dentro da casa, porém, não basta. Há três perguntas adicionais que decidem:
| Pergunta | Aumenta a urgência | Reduz a urgência |
|---|---|---|
| O sistema está acessível a partir da Internet? | site público, loja, portal | apenas interno, atrás de VPN |
| É preciso iniciar sessão para explorar a vulnerabilidade? | não, sem autenticação | sim, só para administradores |
| Que dados trata o sistema? | dados de clientes, pagamentos, acessos | conteúdos públicos sem contas |
| Há relatos de ataques? | tentativas de ataque comunicadas | nenhuma tentativa conhecida |
| Existe uma medida provisória? | não | sim, com eficácia comprovada |
O PHP2Shell mostra como tudo se conjuga. Ambas as vulnerabilidades têm um valor CVSS v4.0 de 9,2, permitem a execução de código sem autenticação e afetam servidores web acessíveis ao público. A Cloudflare e a Patchstack reportaram, segundo os media, tentativas de ataque; o BSI classificou a situação com o nível de alerta 3. As medidas provisórias do php.net não oferecem, expressamente, proteção completa. Todas as perguntas apontam na mesma direção: agir de imediato. O que o BSI recomendou em concreto está em O que o BSI recomenda sobre o PHP2Shell.
Decidir e documentar
Nem todas as vulnerabilidades se podem fechar de imediato. Um sistema antigo corre no PHP 8.1, para o qual já não existem atualizações oficiais (veja PHP 8.1 e anteriores: o que se aplica agora); uma aplicação especializada ainda não suporta a atualização. Nesse caso é preciso uma decisão, e essa decisão não pertence apenas à área técnica.
Uma boa nota de decisão contém o sistema afetado, a vulnerabilidade, a avaliação, a opção escolhida, as medidas provisórias, a pessoa responsável e uma data para nova avaliação. Quando um risco é assumido conscientemente, decide a direção, e não o administrador sozinho. O OWASP Cheat Sheet sobre o tratamento de dependências vulneráveis recomenda igualmente que a aceitação do risco fique expressamente ancorada ao nível da direção.
Mantenha uma única lista de vulnerabilidades em aberto, com estado, responsável e prazo. Uma tabela chega. O importante é que seja revista com regularidade, por exemplo na reunião mensal com a gerência.
O que a NIS2 e os prestadores de serviços têm a ver com isto
Para as empresas abrangidas pela NIS2, o tratamento de vulnerabilidades faz parte das obrigações de gestão de risco. Os pormenores são descritos em NIS2 e segurança de servidores web. Mas, mesmo sem obrigação legal, um procedimento documentado é uma vantagem, por exemplo perante clientes, seguradoras e a própria gerência.
Muitos passos podem ser externalizados, como o acompanhamento de alertas ou a instalação de atualizações. A decisão sobre riscos e a visão de conjunto devem, no entanto, permanecer dentro da casa. Quem entrega o ciclo por inteiro a um prestador de serviços acaba por não saber, numa emergência, que sistemas tem sequer. Como organizar a execução como rotina, descreve-o Gestão de patches como processo e não como combate a incêndios.
Como ajuda concretamente a PHP SOS?
- Elaboramos consigo o inventário dos seus sites e servidores como base para qualquer comparação.
- Acompanhamos os alertas relevantes para os seus sistemas e entregamos uma avaliação em linguagem clara, com recomendação.
- Preparamos notas de decisão para os casos em que uma atualização não é possível de imediato.
- Através da monitorização de segurança, verificamos continuamente se os sistemas se tornam suspeitos enquanto uma vulnerabilidade continua aberta.
Conclusão: a gestão de vulnerabilidades numa PME não tem de ser grande, mas tem de ser vinculativa. Quem conhece os seus sistemas, lê poucas fontes boas e regista as decisões reage com rapidez e acerto ao próximo alerta crítico.
Perguntas frequentes
O que é a gestão de vulnerabilidades?
Um procedimento recorrente com o qual uma empresa toma conhecimento das falhas de segurança nos seus sistemas, as avalia, as corrige ou as aceita conscientemente e regista o resultado. Não se trata de uma ferramenta, mas de responsabilidades e decisões.
A pontuação CVSS basta para definir prioridades?
É um bom ponto de partida, mas não chega. É decisivo saber também se o sistema afetado está acessível a partir da Internet, que dados trata e se já foram observados ataques. Uma vulnerabilidade com pontuação elevada num sistema de teste interno pode esperar; no caso da loja online, não.
Uma pequena empresa precisa de uma ferramenta própria para isto?
No início, não. Basta uma lista atualizada dos sistemas, avisos de segurança subscritos e uma tabela com os pontos em aberto. Os analisadores de vulnerabilidades compensam quando o número de sistemas cresce ou quando é preciso comprovar verificações com regularidade.
É permitido não corrigir uma vulnerabilidade de propósito?
Sim, desde que o risco seja avaliado, a decisão seja tomada pela direção responsável e fique registada por escrito, de preferência com medidas provisórias e uma data para nova avaliação.