Histórias assustadoras para contar na rede

Com o Halloween à porta, aqui fica uma verdadeira história de terror sobre políticas de firewall. (Para maior efeito, imagine-a numa voz rouca e assustadora de advertência… ou na de Morgan Freeman, se preferir.)

Enquanto Sales Engineer, passo muitos dias a fazer demonstrações dos nossos produtos e a falar com engenheiros de segurança, responsáveis de conformidade, gestores de DevOps e CISOs sobre firewalls e segurança de rede. Por vezes, as histórias de quem está no terreno são inacreditáveis e, por vezes, francamente assustadoras. Eis um relato recente de um cliente que tirará o sono a qualquer engenheiro de firewall.

Cenário:
A empresa tinha adotado recentemente uma filosofia de “zero trust” e tinha investido um tempo considerável para se aproximar desse objetivo. Ao longo do último ano, concentraram-se em limpar as suas políticas de firewall, escrevendo regras específicas para a necessidade de negócio – nada mais – apenas os IPs e as redes específicas que precisavam de acesso. Estavam a progredir quando um dos seus engenheiros fez uma descoberta aterradora: uma temida regra “Any – Any – Any – Accept” escondida a meio da política.

Correram para perceber porque é que esta regra existia. Acabaram por descobrir que um engenheiro de rede júnior, apenas a tentar pôr algo a funcionar, tinha criado esta regra. Esta única regra contornava todo o progresso alcançado rumo ao objetivo de zero trust e expunha a rede a um risco enorme.

Era claro que a regra tinha de ser removida. Mas esta regra estava na política – sem ser detetada – há pelo menos 6 meses e permitia certamente tráfego crítico para o negócio. De facto, os registos de tráfego indicavam que era uma regra extremamente utilizada. Como é evidente, era provável que permitisse mais do que apenas tráfego crítico para o negócio: provavelmente permitia também tráfego malicioso. Era necessário remediar este problema rapidamente.

Primeiro, realizaram reuniões com as equipas de rede e tentaram adivinhar que tráfego poderia estar em causa, elencando aplicações críticas e tráfego que quem conhecia a rede sabia que poderia estar a usar essa regra. Mas, no final, decidiram que teriam simplesmente de enfrentar a situação, remover a regra e ver quem se queixava.

Assim, notificaram os gestores de todas as unidades de negócio deste erro. Com embaraço, comunicaram que seria criada uma “linha direta” com operadores de prevenção e, em última análise, tiveram de pôr pessoas a testar todas as funções críticas para o negócio, para garantir que os seus produtos, as suas aplicações, tudo aquilo a que precisavam de aceder para fazer o seu trabalho e permitir que os seus clientes/parceiros/fornecedores fizessem negócio com eles, só ficaria indisponível até conseguirem repor tudo. Sim, houve indisponibilidade e, sim, estavam preparados para tentar criar novas regras para resolver os problemas, mas que pesadelo.

—

Talvez não tenha um cenário de pesadelo como o que descrevi acima, mas a FireMon pode na mesma facilitar o seu trabalho ao ajudar a limpar as suas políticas de firewall. Eis algumas formas como a FireMon poderia evitar o cenário anterior. E, se alguma vez descobrir uma regra assustadoramente permissiva na sua política, não deixe de consultar o ponto 6 abaixo para uma solução indolor para o problema.

1) Alertas e relatórios de conformidade:
Teríamos notificado imediatamente a equipa caso entrasse em produção uma regra excessivamente permissiva como esta. Pode basicamente “regular o nível” de permissividade que aceita nas regras, como “Regras que permitem acesso a mais de 60.000 destinos” ou “Regras com origens superiores a uma rede /16”.

2) Alertas de alteração:
Esta regra apareceria na nossa vista normalizada – independentemente do fabricante da firewall – sendo evidente que tinha sido adicionada. Por isso, não poderia ser introduzida às escondidas. Alguns engenheiros e gestores recebem automaticamente por e-mail relatórios de alterações de política sempre que é feita uma alteração – ou até apenas um instantâneo de 30 dias de tudo o que mudou.

3) Com a nossa ferramenta de automatização, o FireMon Policy Planner, implementada, a regra de risco teria sido travada de imediato – antes mesmo de ser aplicada. Através da nossa “análise prévia à alteração”, a regra teria sido identificada e assinalada antes de ser colocada em produção e de permitir a passagem de um único pacote de tráfego. É por isso que as equipas de conformidade gostam do facto de não nos limitarmos a recomendar regras para criação com base na necessidade: tal como num ambiente sandbox, executamos os nossos algoritmos de conformidade antes de podermos aplicar automaticamente as regras. Alguns clientes adquirem o Policy Planner APENAS por esta funcionalidade – e utilizam as nossas APIs para lhe aceder.

4) Também com os alertas de alteração, a equipa saberia com certeza quem fez que alterações e quando. Assim, neste caso, tratando-se de um engenheiro júnior, um gestor ou responsável poderia rapidamente filtrar/ordenar as alterações que esse utilizador tinha feito na última semana, ou pelo menos no último mês, para ver que tipo de alterações este utilizador tinha efetuado. Isto é também algo que a equipa de conformidade, ou até o próprio utilizador, poderia ter consultado.

5) Do ponto de vista da documentação, a FireMon pode ser a fonte única de verdade para questões como “quem solicitou isto, quem é o proprietário da aplicação, quando foi esta regra revista pela última vez, etc.”. Assim, ao filtrar e ordenar regras com documentação associada, isto também teria sido identificado mais depressa.

6) Guardei o melhor para o fim. Se tiver efetivamente uma regra excessivamente permissiva – como acontece quando os seus antecessores tinham uma política de criação de regras diferente, de estilo mais “aberto/flexível” do que a sua – temos uma forma simples de limpar estas regras. Através da Traffic Flow Analysis, a nossa ferramenta analisa cada endereço IP que passa pela regra, decompondo um any/any/any em fluxos específicos. Pode exportar esses fluxos e criar regras específicas com base neles.