Sistemas legados são softwares ou hardware que, apesar de antigos, ainda desempenham funções críticas em muitas organizações. Eles podem ser encontrados em setores como bancos, governo, saúde e indústria, frequentemente operando por décadas. A segurança desses sistemas é um desafio particular porque eles foram projetados em uma época em que as ameaças cibernéticas eram menos sofisticadas, e muitas vezes não recebem mais suporte dos fornecedores. Nesta aula, vamos explorar os principais aspectos da segurança de sistemas legados, desde a avaliação de riscos até estratégias de migração, fornecendo um guia prático para proteger esses ativos valiosos.

O objetivo é que você compreenda não apenas os riscos, mas também as técnicas para mitigá-los, mesmo quando o sistema não pode ser atualizado ou substituído imediatamente. Abordaremos como isolar sistemas críticos, como aplicar patches quando possível, e como planejar uma migração segura para tecnologias mais modernas.

Risk

O primeiro passo para proteger sistemas legados é entender os riscos específicos que eles apresentam. Esses riscos podem ser categorizados em técnicos, operacionais e estratégicos. Tecnicamente, sistemas legados frequentemente usam protocolos e formatos de dados obsoletos, têm vulnerabilidades conhecidas e não recebem atualizações de segurança. Operacionalmente, pode haver falta de documentação, conhecimento concentrado em poucos especialistas e dificuldade de integração com sistemas modernos. Estrategicamente, a dependência de fornecedores que não oferecem mais suporte pode levar a impasses.

Para avaliar riscos, é essencial realizar uma análise detalhada. Uma abordagem comum é criar um inventário de todos os sistemas legados, identificando sua função, dados que manipulam, conectividade de rede, e dependências. Em seguida, pode-se usar uma matriz de risco, classificando cada sistema pela probabilidade de exploração e pelo impacto potencial. Por exemplo, um sistema de folha de pagamento em COBOL que roda em um mainframe pode ter alto impacto se comprometido, mas a probabilidade pode ser moderada se estiver isolado. Já um sistema de controle industrial com interface exposta à internet teria alta probabilidade e alto impacto.

Uma ferramenta útil é a análise de impacto nos negócios (BIA), que ajuda a priorizar quais sistemas precisam de atenção imediata. Além disso, é importante considerar riscos de conformidade, como LGPD ou PCI DSS, que podem exigir proteções específicas. Abaixo, um exemplo de como documentar riscos em uma tabela simples:

Sistema | Função | Vulnerabilidade | Probabilidade | Impacto | Risco Total
Sistema A | Folha de pagamento | Sem patches há 5 anos | Alta | Alto | Crítico
Sistema B | Controle de acesso | Protocolo Telnet | Média | Alto | Alto
Sistema C | Relatórios | Dados não criptografados | Baixa | Baixo | Médio

Com base nessa análise, a equipe de segurança pode decidir quais medidas tomar, como isolamento, compensações ou planejamento de migração.

Isolation

O isolamento é uma das estratégias mais eficazes para proteger sistemas legados. Consiste em limitar o acesso a esses sistemas, reduzindo a superfície de ataque. Isso pode ser feito em vários níveis: de rede, de aplicação e de dados. No nível de rede, o sistema legado pode ser colocado em uma VLAN separada, com regras de firewall estritas que permitem apenas o tráfego necessário. Por exemplo, se um sistema legado precisa se comunicar apenas com um servidor de banco de dados, podemos criar uma regra que permita somente essa comunicação.

No nível de aplicação, podemos usar proxies reversos ou gateways que aceitam solicitações modernas e as traduzem para o protocolo legado, sem expor o sistema diretamente. Isso é comum em sistemas que usam interfaces de terminal (como telnet) ou protocolos proprietários. No nível de dados, podemos criptografar dados sensíveis em repouso e em trânsito, mesmo que o sistema legado não suporte criptografia nativamente, usando soluções externas.

Um exemplo prático de isolamento é usar um jump host (bastion host) para acesso administrativo. O administrador se conecta ao jump host via SSH (porta 22) e, a partir dele, acessa o sistema legado via protocolo antigo (ex.: telnet) somente dentro da rede interna. Isso evita expor o telnet na internet. Veja um exemplo de configuração de firewall (iptables) para permitir apenas SSH ao jump host:

# Permitir SSH na interface pública
-A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT
# Bloquear todo o resto na interface pública
-A INPUT -i eth0 -j DROP
# Permitir tráfego interno livremente
-A INPUT -i eth1 -j ACCEPT

Além disso, o isolamento pode envolver a segmentação física, como manter o sistema em uma máquina sem acesso à internet, ou lógica, usando microsegmentação em redes definidas por software (SDN). É crucial monitorar o tráfego para detectar tentativas de acesso não autorizado. Ferramentas como IDS/IPS podem ser configuradas para alertar sobre qualquer tráfego anômalo destinado ao sistema legado.

Patching

Patching é o processo de aplicar correções de software para resolver vulnerabilidades. Em sistemas legados, isso pode ser complicado, pois o fornecedor pode não oferecer mais patches, ou o sistema pode ser tão antigo que a aplicação de patches quebra funcionalidades. No entanto, existem estratégias para lidar com isso. Primeiro, é importante estabelecer um processo de gerenciamento de vulnerabilidades que inclua a avaliação contínua da exposição do sistema. Mesmo sem patches oficiais, é possível aplicar mitigações, como desabilitar serviços não utilizados, fechar portas desnecessárias e aplicar hardening no sistema operacional.

Em alguns casos, é possível obter patches de terceiros ou contratar suporte estendido do fornecedor original. Por exemplo, algumas empresas oferecem suporte para sistemas antigos por um custo adicional. Se o código-fonte estiver disponível, a equipe interna pode desenvolver patches, mas isso requer testes rigorosos. Uma prática comum é usar um sistema de controle de versão e um ambiente de homologação para testar patches antes de aplicá-los em produção.

Um exemplo de mitigação sem patch é desabilitar SMBv1 em um Windows legado, já que o SMBv1 tem vulnerabilidades conhecidas (ex.: EternalBlue). Mesmo que o sistema não receba patches, essa ação reduz o risco. Veja como fazer isso via PowerShell:

# Desabilitar SMBv1
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" -Name "SMB1" -Type DWORD -Value 0
# Reiniciar o serviço
Restart-Service lanmanserver

Outra abordagem é usar virtualização para isolar o sistema legado e aplicar patches no host, enquanto a VM permanece intacta. Isso permite que o sistema continue operando sem ser afetado por atualizações do host, mas ainda se beneficia de melhorias de segurança no hypervisor. Além disso, é essencial manter um inventário de patches aplicados e monitorar novos anúncios de vulnerabilidades relevantes, usando feeds de segurança como CVE.

Migration

Eventualmente, a migração para um sistema moderno é a solução mais segura a longo prazo. Migrar sistemas legados, no entanto, é um projeto complexo que envolve planejamento cuidadoso, análise de custo-benefício e minimização de riscos. O primeiro passo é decidir se a migração é viável: às vezes, o custo pode ser proibitivo, ou o sistema é tão específico que não há substituto direto. Nesses casos, o isolamento e as compensações podem ser a estratégia permanente.

Quando a migração é decidida, é importante usar uma abordagem incremental, como o padrão strangler fig, onde o sistema legado é gradualmente substituído por um novo, funcionalidade por funcionalidade. Isso reduz o risco e permite que a equipe se adapte. Por exemplo, uma aplicação monolítica legada pode ser dividida em microsserviços, com cada serviço sendo substituído individualmente. Durante a transição, ambos os sistemas coexistem, e a integração é feita via APIs.

Um plano de migração deve incluir: levantamento de requisitos, análise de dados (incluindo migração de dados), testes de compatibilidade, treinamento de usuários e um plano de rollback. Um exemplo de cronograma simplificado:

Fase 1: Análise e preparação (2 meses)
- Inventário de funcionalidades
- Definição de arquitetura alvo
- Seleção de ferramentas

Fase 2: Desenvolvimento e testes (6 meses)
- Desenvolvimento de novos serviços
- Testes unitários e de integração
- Migração de dados em ambiente de teste

Fase 3: Implementação gradual (3 meses)
- Migração por módulos
- Validação com usuários
- Ajustes e otimização

Fase 4: Descomissionamento (1 mês)
- Desligamento do sistema legado
- Arquivamento de dados históricos

Durante a migração, a segurança deve ser considerada desde o início. O novo sistema deve seguir as melhores práticas de segurança, como autenticação multifator, criptografia e monitoramento. Além disso, é importante garantir que os dados legados sejam migrados com integridade e que as permissões de acesso sejam reavaliadas.

Boas Práticas e Observações Finais

Além das estratégias específicas, algumas boas práticas podem ajudar a gerenciar a segurança de sistemas legados de forma contínua. Primeiro, mantenha uma documentação detalhada de cada sistema, incluindo arquitetura, configurações, dependências e contatos de suporte. Isso facilita a análise de riscos e o planejamento de migração. Segundo, estabeleça um comitê de revisão periódica para reavaliar os riscos e as medidas de mitigação, pois o cenário de ameaças muda constantemente.

Outra prática é treinar a equipe de TI e os usuários sobre os riscos específicos dos sistemas legados e as políticas de segurança. Muitas vezes, o fator humano é o elo mais fraco. Por fim, considere a possibilidade de adquirir seguros cibernéticos que cubram incidentes envolvendo sistemas legados, como uma camada adicional de proteção financeira.

Lembre-se de que a segurança de sistemas legados é um processo contínuo, não um projeto com fim. Mesmo com isolamento e patches, o risco nunca é zero. Portanto, a migração, quando possível, é o caminho mais sustentável. No entanto, enquanto a migração não ocorre, as medidas apresentadas aqui podem reduzir significativamente a exposição.

Referências

Exercícios

  1. Explique por que sistemas legados são considerados de alto risco e cite três exemplos de vulnerabilidades comuns em sistemas legados.

    2. ✓ Resposta: Sistemas legados são de alto risco porque frequentemente possuem vulnerabilidades conhecidas sem correção, usam protocolos e tecnologias obsoletas, e não recebem mais suporte ou atualizações de segurança. Exemplos de vulnerabilidades comuns incluem: uso de protocolos não criptografados como Telnet, falta de autenticação robusta (senhas fracas ou em texto claro), e sistemas operacionais sem patches de segurança (ex.: Windows XP).
  2. Descreva duas estratégias de isolamento para um sistema legado que não pode ser atualizado.

    3. ✓ Resposta: Duas estratégias: 1) Segmentação de rede: colocar o sistema em uma VLAN separada com firewall que bloqueia todo o tráfego não autorizado, permitindo apenas comunicações essenciais. 2) Uso de um bastion host (jump host) para acesso administrativo, onde o administrador se conecta via SSH ao bastion e, a partir dele, acessa o sistema legado via protocolo antigo, sem expor o sistema diretamente à rede externa.
  3. Qual é a diferença entre aplicar um patch e aplicar uma mitigação? Dê um exemplo de mitigação sem patch para um sistema legado.

    4. ✓ Resposta: Patch é uma atualização oficial do fornecedor que corrige a vulnerabilidade no código. Mitigação é uma medida alternativa que reduz o risco sem corrigir o código. Exemplo: desabilitar SMBv1 em um Windows legado (via registro) para evitar exploits como EternalBlue, mesmo sem patch oficial.
  4. Explique o padrão Strangler Fig e como ele pode ser aplicado na migração de um sistema legado.

    5. ✓ Resposta: O padrão Strangler Fig consiste em substituir gradualmente partes do sistema legado por novos componentes, funcionalidade por funcionalidade, até que o sistema legado seja completamente substituído. Aplicado na prática: divide-se o sistema legado em módulos, cria-se novos microsserviços para cada módulo, e integra-se ambos durante a transição, usando APIs. Isso reduz riscos e permite rollback.
  5. Por que é importante considerar a segurança durante o planejamento de migração? Cite dois aspectos de segurança a serem incluídos.

    6. ✓ Resposta: Porque a migração é uma oportunidade para eliminar vulnerabilidades antigas e implementar melhores práticas. Aspectos a incluir: 1) Autenticação multifator (MFA) para todos os usuários do novo sistema. 2) Criptografia de dados em trânsito e em repouso, garantindo que dados sensíveis sejam protegidos desde o início.