Gestão de Patches

Gestão de patches começa antes do patch: é necessário saber quais ativos existem, quem é responsável, qual versão executam e até quando recebem suporte. O inventário inclui roteador, access points, switches, hubs, servidores, containers, aplicativos, câmeras, NVR, fechaduras, sensores, gateways, firmwares de rádio, smartphones e serviços cloud administrados. Para cada item, registra fabricante, modelo, número de série, hardware revision, firmware, sistema, pacotes, endereço, VLAN, criticidade, data de compra, EOL/EOS e canal de atualização. SBOM ajuda fabricantes e software próprio a mapear bibliotecas. CVEs, avisos do fornecedor, CISA KEV, CERTs e feeds indicam correções. A ausência de CVE não significa ausência de risco; fabricantes podem publicar nota própria. O processo distingue patch de segurança, correção funcional, upgrade de versão e atualização de assinatura. NIST SP 800‑40 Rev. 4 enquadra patching como manutenção preventiva. Um inventário automatizado por MDM, Ansible, controlador de rede, agente ou API reduz lacunas. IoT barato pode não expor versão. O integrador registra manualmente e monitora app do fabricante. Dispositivos que atualizam automaticamente precisam de log e política. A consequência para o morador é evitar que um roteador esquecido fique anos com vulnerabilidade conhecida enquanto o aplicativo aparenta normalidade. O inventário também identifica produtos sem suporte, que precisam de isolamento ou substituição, não apenas de “procurar atualização”.

Nem todo patch recebe a mesma urgência. A prioridade combina exposição, exploração ativa, facilidade, privilégio, impacto, criticidade, compensações e disponibilidade. Uma vulnerabilidade RCE sem autenticação em roteador exposto e listada no CISA KEV é emergencial. Uma falha local que exige acesso físico a um sensor isolado pode aguardar. CVSS oferece características técnicas, mas não conhece o ambiente. EPSS estima probabilidade de exploração e pode ajudar. O fornecedor classifica. A equipe define SLAs, por exemplo 24–72 horas para exploração ativa crítica em borda, 7 dias para alta exposição, 30 dias para moderada e ciclo normal para baixa; números são políticas, não universais. Antes da correção, mitigação temporária pode fechar porta, desabilitar serviço, bloquear origem, retirar Internet, aplicar WAF ou segmentar. A mitigação precisa de prazo. A criticidade funcional também. Atualizar um controlador de acesso sem teste pode impedir entrada. A decisão planeja janela e fallback. Em casa, roteador, VPN, reverse proxy, hub e smartphone têm prioridade. Uma lâmpada isolada tem menor impacto, mas pode ser pivô se VLAN permite. O patch deve ser autêntico e vir de canal oficial. Não instalar firmware de fórum sem verificação. A prioridade também considera idade do ativo. Se não há patch, o risco residual é documentado e o dispositivo substituído. A gestão não deve esperar “próxima manutenção” para KEV ativo.

Uma atualização segura possui pré-check, backup, energia estável, janela, método oficial, verificação e rollback. Em ambientes maiores, um grupo piloto recebe primeiro. Em residência, um dispositivo não crítico pode testar antes de toda frota. Leia release notes, dependências, migrações e requisitos. Faça backup de configuração, não apenas dados. Confirme que o backup restaura na versão nova. UPS protege roteador, hub e NVR contra queda durante firmware. Não desligar. Atualizações assinadas devem ser verificadas pelo equipamento. Após instalar, confirme versão, serviço, regras, automações, rádio, certificado, armazenamento e logs. Um scanner verifica que vulnerabilidade não permanece. “Atualização concluída” no app não prova. Rollback pode ser suportado por partições A/B, snapshot, imagem anterior ou restore; alguns fabricantes bloqueiam downgrade por segurança. Planeje. Não forçar downgrade vulnerável. Em clusters, atualize nó a nó. Em dispositivos Matter/Thread/Zigbee, o hub pode distribuir OTA; compatibilidade e bateria importam. Sensores a bateria atualizam lentamente. O dispositivo precisa estar acordado. A implantação deve ter backoff e limite para não saturar Wi‑Fi. Atualização automática é útil para consumidor, mas exige confiança no fornecedor. Para componentes críticos, use janela e notificação. A verificação inclui que o controle local continua sem cloud e que configurações de segurança não foram resetadas.

Gestão de patches é contínua e mede cobertura, tempo de correção, falhas, ativos sem suporte e conformidade. Métricas úteis: percentual inventariado, tempo mediano entre publicação e implantação, número de ativos críticos atrasados, taxa de sucesso, rollback e EOL. Uma planilha pode servir em uma casa; organização usa plataforma. O processo define responsáveis: proprietário, integrador, condomínio, fornecedor e TI. Contratos especificam janela de suporte, notificações e acesso. Contas do fabricante não podem pertencer apenas ao instalador. O proprietário mantém. Backups de configuração ficam acessíveis. Atualizações podem alterar privacidade, cloud e recursos; revisão. O fim de suporte é uma decisão de segurança. Um dispositivo que funciona eletricamente pode estar inseguro. Opções: substituir, isolar, retirar Internet, colocar atrás de gateway, reduzir privilégio ou aceitar risco. Não existe patch caseiro para firmware fechado. Open source pode receber comunidade, mas depende. A gestão também inclui dependências de software próprio: sistema operacional, containers, Python packages, Node modules, banco e imagens. Pinning eterno bloqueia correções; atualização sem teste quebra. Use automação com staging. Uma limitação real é que patch pode introduzir regressão ou vulnerabilidade. Assinatura garante origem, não qualidade. Por isso há teste, rollback e monitoramento. O objetivo é reduzir janela de exposição sem sacrificar disponibilidade crítica.