As infraestruturas críticas dependem da conectividade, mas cada ligação cria uma via potencial para um ataque. À luz dos ataques recentes, das lições retiradas da minha nova série documental «Into the Breach: Breaking the Firewall » e da evolução das tecnologias de isolamento, como os díodos de dados, precisamos de repensar a forma como os nossos sistemas mais críticos são concebidos — e explorar por que razão tanto os governos como as indústrias devem começar por uma pergunta simples: será que esta ligação tem mesmo de existir?
1. Por que criei o «Into the Breach»
Este fim de semana lançámos «Into the Breach: Breaking the Firewall », o primeiro episódio que produzi através da Cyber King Productions, apresentado por Kari Byron, do programa «MythBusters».
Porque é que decidi produzir um programa sobre cibersegurança?
Há anos que tenho tentado explicar a cibersegurança das infraestruturas críticas a clientes, responsáveis governamentais, jornalistas, parceiros, amigos e, por vezes, até à minha própria família.
Normalmente, não demora muito até começarmos a falar de firewalls, air gaps, PLCs, TI, OT, segmentação, Zero Trust, díodos de dados, malware e vulnerabilidades.
E consigo perceber quando começo a perder pessoas.
A certa altura, percebi que talvez o problema não fosse o público.
Talvez a cibersegurança tenha-se tornado péssima a contar a sua própria história.
Pense no que este setor tem de enfrentar: atacantes ligados a Estados-nação, centrais elétricas, sistemas de abastecimento de água, satélites, fábricas, IA, computadores quânticos e ataques que podem ter consequências físicas reais.
No entanto, por alguma razão, continuamos a explicar tudo isto com mais uma apresentação em PowerPoint.
Queria fazer algo diferente.
Escolha um tema que as pessoas pensem que compreendem. Crie uma experiência prática em torno desse tema. Analise-o a fundo. Teste-o. Recorra a especialistas que conheçam a tecnologia. Torne-o visual. Torne-o cativante. E, acima de tudo, questione os pressupostos que o setor da cibersegurança tem vindo a repetir há anos sem os questionar suficientemente.
Isso deu origem à série «Into the Breach». A série combina ciberataques reais, experiências práticas, entrevistas a especialistas e demonstrações para tornar a cibersegurança tangível e compreensível.
Para o episódio n.º 1, quis começar por uma das maiores suposições de todas:
«Basta colocá-lo atrás de uma firewall e fica protegido.»
Depois, quase em sincronia perfeita com o lançamento do episódio, o que se passa no Minnesota passou a dominar o noticiário.
2. Quando a cibersegurança começa a fazer a diferença
Nos dias 26 e 27 de julho, um ciberataque coordenado teve como alvo a tecnologia operacional de mais de 30 sistemas comunitários de abastecimento de água no Minnesota. O Minnesota ativou o seu mecanismo de resposta à cibersegurança a nível estadual para investigar os ataques e apoiar as comunidades afetadas.
Dois dias depois, o FBI e a EPA emitiram um alerta mais abrangente. Desde 27 de julho, as empresas de abastecimento de água e de tratamento de águas residuais em, pelo menos, sete estados tinham comunicado incidentes envolvendo controladores lógicos programáveis (PLC) ligados à Internet.
Os atacantes acederam remotamente aos dispositivos, alteraram endereços IP e palavras-passe e fizeram com que os operadores perdessem a monitorização e o controlo. O FBI relatou consequências operacionais, incluindo perda de pressão e inundações. Também identificou configurações de rede de terceiros semelhantes em várias vítimas, o que poderá ter permitido aos atacantes repetir o mesmo sucesso.
Pára um pouco e pensa nisso.
Estamos a falar de computadores que controlam a água.
Não se trata de alguém que rouba um número de cartão de crédito. Não se trata apenas de um ransomware que encripta o portátil de um colaborador.
Quando um atacante consegue interferir numa bomba, numa válvula, num disjuntor elétrico, numa conduta, numa linha de produção ou noutro processo físico, a cibersegurança assume uma dimensão muito maior.
Isso torna-se uma questão de segurança pública.
E o Minnesota não é o primeiro sinal de alerta.
3. Já vimos isto antes
O Volt Typhoon é um dos exemplos mais evidentes.
As agências de cibersegurança dos EUA e dos seus aliados documentaram que agentes chineses apoiados pelo Estado estabeleceram acesso persistente no interior de organizações de infraestruturas críticas nos setores das comunicações, da energia, dos transportes, da água e noutros setores.
Num caso confirmado de violação de segurança, os atacantes terão provavelmente obtido acesso inicial ao explorar a vulnerabilidade CVE-2022-42475 numa firewall de perímetro FortiGate 300D sem correções instaladas.
Pensa no que aconteceu ali.
O dispositivo instalado para proteger o perímetro acabou por se tornar o caminho que atravessava o perímetro.
Isso não é uma crítica à Fortinet.
Qualquer plataforma de software sofisticada pode, eventualmente, apresentar vulnerabilidades. As firewalls precisam de correções. As VPNs precisam de correções. Os sistemas operativos precisam de correções. As credenciais podem ser roubadas. As configurações podem estar erradas. Os administradores cometem erros. Ocorrem falhas de «dia zero».
Essa é a realidade do software.
A Ucrânia demonstrou as consequências físicas de forma ainda mais dramática. Em dezembro de 2015, os atacantes comprometeram três empresas de distribuição de eletricidade. Passaram dos sistemas de TI para os sistemas operacionais, acederam ao ambiente ICS através da infraestrutura VPN, acionaram disjuntores elétricos e provocaram cortes de energia que afetaram cerca de 225 000 clientes.
Há uma grande diferença entre um atacante conseguir aceder a um dos seus computadores e um atacante conseguir aceder ao computador que controla a sua eletricidade.
As consequências podem ir além do ecrã.
4. Não sou contra as firewalls
Deixem-me deixar isto bem claro.
Precisamos de firewalls.
OPSWAT utiliza-as. Os nossos clientes utilizam-nas. Quase todas as redes modernas dependem delas.
O que estou a contestar é a ideia de que uma firewall equivale a isolamento.
Penso num firewall como um segurança muito inteligente que está à porta. O segurança conhece milhares de regras. Verifica as credenciais. Analisa o tráfego. Decide o que pode entrar e sair.
Isso é extremamente valioso.
Mas ainda há uma porta.
Se alguém roubar as credenciais corretas, descobrir uma vulnerabilidade, tirar partido de um erro de configuração ou comprometer a própria tecnologia de segurança, a via de acesso continua a existir.
Então, comecei a fazer uma pergunta diferente:
E se, na verdade, ninguém precisasse de entrar pela porta?
Por que gastar tanto dinheiro a tornar a porta mais inteligente se, para começar, os requisitos da empresa nem sequer exigem uma porta?
É aí que um díodo de dados se diferencia fundamentalmente.
Um díodo de dados não é um firewall melhor.
Resolve um problema diferente.
Em vez de depender apenas de regras de software para decidir qual o tráfego que é permitido, um díodo de dados pode impor a direção da comunicação a nível de hardware.
O NIST demonstrou exatamente este tipo de arquitetura num projeto de referência para uma empresa de eletricidade. Os dados de monitorização operacional são transmitidos para o exterior através de um gateway unidirecional, e a arquitetura impede que os dados regressem através dessa mesma ligação para o ambiente industrial protegido.
Trata-se de uma propriedade de segurança fundamentalmente diferente.
5. Sem caminho de retorno desnecessário
Acho que o princípio é suficientemente simples para merecer um nome simples:
Sem caminho de retorno desnecessário
Uma empresa de abastecimento de água poderá ter de emitir alertas.
Uma central elétrica poderá ter de enviar dados de telemetria.
Uma fábrica pode precisar de exportar informações do sistema de registo histórico.
Um operador de gasoduto pode necessitar de monitorização centralizada.
Um ambiente de defesa pode ter de exportar registos.
Todas essas informações podem sair da rede protegida.
Mas se não houver qualquer motivo operacional para que a comunicação regresse através desse mesmo limite:
Por que criar o caminho de retorno?
Sei que nem todos os ambientes podem funcionar desta forma. Existem razões legítimas para a manutenção remota, o controlo remoto, as atualizações de software, as confirmações de receção e outros processos bidirecionais.
Se precisares dessa ligação, protege-a com determinação.
As orientações mais recentes do FBI para o setor da água recomendam aos operadores que retirem os PLCs da exposição direta à Internet, canalizem o acesso remoto através de gateways seguros, restrinjam o acesso, validem os ficheiros de projeto dos PLCs, protejam a conectividade móvel e mantenham a capacidade de operar manualmente após um incidente.
Concordo com tudo isso.
Mas acho que temos a configuração predefinida ao contrário.
Hoje em dia, começamos com demasiada frequência por implementar a conectividade e só depois pedimos à equipa de cibersegurança para a proteger.
No que diz respeito aos nossos sistemas mais importantes, devemos começar pelo isolamento e perguntar:
Por que é que é preciso abrir o caminho?
6. Uma via não é suficiente — e tem de ser limpa.
Há uma parte importante desta discussão que, por vezes, passa despercebida.
Um díodo de dados resolve a questão da direção.
Isso não resolve automaticamente a questão do conteúdo.
Mesmo que um ficheiro malicioso seja autorizado a circular na direção permitida, continua a ser malicioso.
Se uma atualização de software comprometida passar pelo díodo, continua a estar comprometida.
Se alguém introduzir um documento infetado num ambiente isolado, o simples facto de este estar isolado não torna o documento seguro.
É por isso que acredito que a próxima geração desta arquitetura tem de ser:
Só de ida e limpo
Utilize o díodo para controlar a direção.
Em seguida, verifique o que está autorizado a passar.
Isso significa combinar a comunicação unidirecional imposta pelo hardware com tecnologias como o « Multiscanning », a «Data Sanitization» e a tecnologia «Deep CDR™», o sandboxing, o DLP, a inspeção de conteúdos baseada em IA, a validação de ficheiros e a aplicação de políticas.
OPSWATA atual arquitetura « MetaDefender » já combina a tecnologia Deep CDR™, o Metascan™ Multiscanning, o sandboxing, Proactive DLP e a inspeção baseada em IA em fluxos de trabalho de ficheiros controlados, e os nossos produtos interdomínios combinam estas tecnologias de prevenção com arquiteturas de transferência segura. O MetaDefender™ Core pode utilizar mais de 30 motores antimalware em paralelo como parte destes fluxos de trabalho.
O objetivo não deve ser simplesmente:
Estes dados podem ser transferidos de A para B?
As perguntas devem ser:
Será que, para começar, se deve avançar nessa direção?
...ou melhor ainda...
Será que este conteúdo deveria ser permitido, de todo?
Essa é a diferença entre criar simplesmente uma barreira física e criar um processo seguro para a transferência de informação através dessa barreira.
7. O desafio de My à CISA
Quero criticar a CISA, mas também quero reconhecer o seu mérito.
A direção está a mudar.
Um novo guia de 2026 sobre o isolamento de infraestruturas críticas indica que os operadores devem ser capazes de isolar sistemas OT vitais das restantes redes, descreve o isolamento físico como a forma mais eficaz de proteção e reconhece especificamente que os díodos de dados e as soluções entre domínios proporcionam uma garantia superior à das arquiteturas padrão de gateways de rede, quando implementados corretamente.
Trata-se de um avanço importante.
My O desafio para a CISA é o seguinte:
Não devemos considerar o isolamento apenas como algo que nos preparamos para fazer durante uma crise. Devemos integrá-lo na forma como concebemos as infraestruturas críticas desde o início.
Antes de perguntar como garantimos a segurança do acesso remoto, pergunte-se se esse acesso é realmente necessário.
Se a resposta for sim, proteja-o.
Se a resposta for «não»:
Remova o caminho.
8. A regulamentação deveria colocar uma questão mais pertinente
Esta reflexão vai além das fronteiras dos Estados Unidos. O quadro europeu NIS2 estabelece agora um quadro comum de cibersegurança em 18 setores críticos, incluindo a energia, os transportes, a saúde, a água potável, as águas residuais, as infraestruturas digitais, a indústria transformadora, a administração pública e o setor espacial.
Os governos de todo o mundo estão a reforçar os requisitos em matéria de avaliação de riscos, autenticação, comunicação de incidentes, aplicação de correções, monitorização, deteção e recuperação.
Tudo isso é importante.
Mas penso que as entidades reguladoras devem acrescentar mais perguntas:
Por que é que esta ligação existe?
Como é que está a proteger a ligação?
Será que essa ligação tem mesmo de existir?
Estas questões devem ser colocadas em todos os locais onde operam infraestruturas críticas.
9. Os Estados Unidos devem assumir a liderança
Dito isto, considero que os Estados Unidos devem dar o primeiro passo.
Apelo à emissão de um decreto presidencial dos EUA com base num princípio simples:
Sem caminho de retorno desnecessário.
No que diz respeito às nossas infraestruturas mais críticas, tudo se resume a cinco conceitos:
- Nenhum controlador crítico deve ficar diretamente exposto à Internet.
- Se os dados apenas precisarem de sair, estabeleça uma ligação unidirecional e assegure que os dados estejam limpos. Recorra a uma comunicação unidirecional imposta por hardware, em conjunto com segurança de conteúdos, verificação múltipla, sanitização de dados e a tecnologia Deep CDR™, para que as informações que atravessam a fronteira sejam inspecionadas e sanitizadas.
- O controlo remoto deve ser uma exceção. Se for realmente necessário, proteja-o, restrinja-o, monitorize-o, audite-o e certifique-se de que os operadores conseguem recuperar com segurança.
- Ajudar as empresas de serviços públicos de menor dimensão a modernizarem-se. Não se deve esperar que um pequeno sistema de abastecimento de água consiga defender-se contra ciberatacantes sofisticados com os recursos de uma empresa de serviços públicos de âmbito nacional.
- São os requisitos de segurança que devem ser definidos, e não o fornecedor. Os governos devem definir o resultado pretendido e deixar que o setor concorra para apresentar a melhor solução.
O princípio é simples:
Se o tráfego não precisar de regressar, remova o caminho de retorno. E tudo o que atravessar o limite deve estar limpo.
Os Estados Unidos podem assumir a liderança, mas eu gostaria de encorajar os governos de todo o mundo a adotarem o mesmo princípio.
10. A mecânica quântica está a ensinar-nos a mesma lição
Há outra razão pela qual penso que devemos agir antes da próxima crise.
A 22 de junho de 2026, a Casa Branca emitiu o Decreto Presidencial n.º 14412, intitulado «Proteger a nação contra ataques criptográficos avançados». Este decreto reconhece a ameaça futura que os computadores quânticos de grande escala representam para a criptografia amplamente utilizada, acelera a transição federal para a criptografia pós-quântica aprovada pelo NIST e instrui as agências a ajudarem os proprietários de infraestruturas críticas a prepararem-se para a sua própria migração.
Gosto desta lógica.
Aja antes que a crise aconteça.
Isso é prevenção.
Penso que a mesma filosofia se deve aplicar à arquitetura das infraestruturas críticas.
Existe também uma ligação interessante entre os díodos de dados e a era quântica.
Para que fique claro, um díodo de dados não torna a criptografia atual resistente à computação quântica. A criptografia pós-quântica resolve esse problema matemático.
Mas as chaves de encriptação continuam a existir algures.
São gerados algures. Armazenados algures. Utilizados algures.
Os HSM, os sistemas de gestão de chaves, a infraestrutura de computação quântica e as futuras redes quânticas continuarão a envolver hardware, software, operadores e ligações de rede.
Continuarão a ter pontos vulneráveis.
Imagine um ambiente criptográfico altamente sensível que precise de enviar telemetria, informações de auditoria, eventos de segurança ou resultados computacionais aprovados para o exterior, mas que não tenha qualquer motivo para que uma rede empresarial comum inicie uma comunicação de retorno para os sistemas que protegem essas chaves.
Considero que esta é uma importante aplicação futura do isolamento implementado por hardware. Trata-se de uma inferência arquitetónica, não de um substituto para a criptografia pós-quântica. As arquiteturas unidirecionais do NIST demonstram como os percursos unidirecionais podem reduzir a acessibilidade da rede, enquanto a nova política federal em matéria de computação quântica mostra como se está a tornar importante a proteção dos futuros sistemas criptográficos.
My A perspetiva é simples:
A criptografia pós-quântica protege a matemática.
Hardware- O isolamento imposto pode proteger o caminho para as máquinas, ao proteger a matemática.
No que diz respeito aos nossos ambientes mais sensíveis, creio que vamos precisar de ambos.
11. Apostámos nesta convicção
Devo deixar claro o que é óbvio.
OPSWAT vende díodos de dados.
Mas não descobrimos esta arquitetura de repente porque o Minnesota foi atacado no mês passado, e não entramos no mercado porque eu decidi produzir um programa sobre cibersegurança.
Ao longo de anos, a OPSWAT tem vindo a integrar as nossas tecnologias com fornecedores de díodos em ambientes sensíveis dos setores governamental, da defesa, da energia e industrial. Quanto mais tempo passava com estes clientes, mais convencido ficava de que, se a nossa missão fosse realmente proteger as infraestruturas críticas do mundo, precisávamos de deter uma maior parte desta tecnologia.
Fizemos algo que não era óbvio para uma empresa historicamente conhecida pelo software.
Adquirimos duas empresas do setor do hardware.
Em 2021, a OPSWAT adquiriu os ativos da Bayshore Networks, incorporando à empresa competências nas áreas da segurança industrial, OT, ICS e transferência segura de dados.
Em 2024, adquirimos a Fend, expandindo as nossas capacidades em matéria de díodos de dados e dotando-nos de outra arquitetura particularmente adequada para infraestruturas distribuídas e remotas, como as empresas de abastecimento de água.
E a aquisição dessas empresas foi apenas o começo.
Triplicámos os recursos de I&D dedicados a esta área.
Também tomámos outra decisão.
Se vamos fabricar hardware do qual os governos e os operadores de infraestruturas críticas dependem, quero saber de onde vem esse hardware, quem o montou, que componentes foram utilizados, como foi testado e como controlamos a sua qualidade.
Por isso, aproximámos bastante a produção de nós.
Em novembro de 2025, aOPSWAT inaugurou uma unidade de produção em Tampa, na Flórida, passando a realizar internamente a produção de hardware e aumentando o nosso controlo sobre a qualidade, a conformidade, o desenvolvimento de produtos e a integridade da cadeia de abastecimento.
E Tampa não é o fim desta estratégia.
Estamos a desenvolver capacidades regionais e centros adicionais na Europa e na Ásia, porque os governos estão cada vez mais preocupados não só com o que a tecnologia de cibersegurança faz, mas também com o local onde é desenvolvida e com quem controla a cadeia de abastecimento.
Isto não é um projeto paralelo.
Trata-se de uma aposta a longo prazo naquilo que, na nossa opinião, deve ser o rumo a seguir em matéria de segurança das infraestruturas críticas.
12. A Prevenção em Primeiro Lugar
Tudo isto remete para o argumento que apresentei no meu livro, «Cybersecurity Upside Down».
O nosso setor tornou-se incrivelmente eficiente a detetar problemas, só depois de termos permitido que esses problemas chegassem ao ambiente.
Precisamos, sem dúvida, de sistemas de deteção. Precisamos de SOCs, informações sobre ameaças, monitorização e resposta a incidentes.
Mas a prevenção deve ser a prioridade.
Se for possível remover o conteúdo malicioso antes de este ser executado, remova-o.
Se puder eliminar um privilégio desnecessário, elimine-o.
Se for possível isolar o ambiente crítico, isole-o.
E se um sistema crítico não necessitar de um caminho de rede de entrada:
Remova o caminho.
É isso que se chama cibersegurança centrada na prevenção.
13. Por que criei a CyberKing Productions
E isto leva-me de volta ao ponto onde esta história começou.
«Into the Breach» não é apenas mais um vídeo de marketing do tipo « OPSWAT ».
Criei a Cyber King Productions porque acredito que a cibersegurança precisa de uma forma completamente diferente de comunicar com o mundo.
Não quero fazer anúncios publicitários para empresas.
Quero contar histórias sobre cibersegurança que as pessoas realmente queiram ver.
Escolha algo que toda a gente pensa que compreende. Descubra o pressuposto subjacente. Conceba uma experiência em torno disso. Teste-o. Questione-o. Talvez o desmonte. Talvez faça algo explodir. Depois, convide especialistas e explique o que realmente aconteceu.
Foi isso que tentámos fazer com o primeiro episódio de «Into the Breach», intitulado «Breaking the Firewall ».
Antes do lançamento oficial, o episódio começou a ser exibido na United Airlines. Depois, na Black Hat, aconteceu algo que me deixou particularmente feliz: as pessoas vieram ao stand da OPSWAT depois de terem visto o episódio durante o voo, e algumas queriam falar connosco sobre os díodos de dados.
Pensa nisso.
Alguém viu um programa sobre cibersegurança num avião, chegou ao Black Hat, passou pelo nosso stand e quis saber como proteger melhor uma rede crítica.
Era exatamente isso que eu esperava que o Cyber King conseguisse fazer.
14. As pessoas por trás do Cyber King
Ter uma ideia é fácil. Concretizá-la, já não é.
Sou o criador e produtor executivo, mas tive a sorte de contar com uma equipa incrível por trás do primeiro episódio:
- Kari Byron foi a apresentadora e produtora executiva
- Berry Blanton foi realizador e produtor
- Jason Richard foi produtor e editor
- Linda Wolkovitch foi a produtora
- Erik Weinbrecht foi escritor
- Joanna Shemesh foi produtora associada
- Scott Sorensen foi o diretor de fotografia
- Shannon Wilkerson ficou responsável pelo design 3D e pelo design de movimento
- Christopher Gore Gammon foi editor adjunto
- A equipa de produção contou ainda com Jesus «Chuy» Valadez, Mahlik Hailu, Jan Reichle, Christina Robles, Jesus Ocejo e Roman Molla.
...e, claro, o Maxx, o cão-robô, interpretou-se a si próprio.
Um agradecimento muito especial à Kari, ao Berry, ao Jason, ao Erik e a todos os que ajudaram a transformar isto de uma ideia numa realidade.
15. Isto é apenas o começo
O episódio n.º 1 foi sobre firewalls.
Não vamos ficar por aqui.
O episódio n.º 2 está neste momento em produção e já tenho enredos e ideias para muitos mais episódios.
Não faltam pressupostos em matéria de cibersegurança que vale a pena questionar. Barreiras físicas, suportes removíveis, IA, ransomware, cadeias de abastecimento, segurança na nuvem, sanitização de dados, modelo «Zero Trust», infraestruturas críticas, computação quântica e muito mais.
Mas também não quero que o Cyber King se resuma apenas a OPSWAT.
Quero que outras pessoas do setor participem.
Se é atualmente um parceiro tecnológico ou de canal da OPSWAT e tem uma tecnologia, um testemunho de cliente, uma abordagem em matéria de cibersegurança ou uma experiência que considere que mereça ser filmada, contacte-me diretamente.
Talvez experimentemos algo juntos. Talvez nos lancemos a isso. Talvez provemos que funciona. Talvez descubramos que o senso comum está errado.
No final das contas? Talvez venhamos a produzir um episódio juntos.
Envia-me uma mensagem privada no LinkedIn ou no Facebook.
Estou a falar a sério.
Já há webinars e apresentações em PowerPoint mais do que suficientes sobre cibersegurança.
Quero tornar a cibersegurança algo que as pessoas tenham realmente vontade de ver.
Veja «Into the Breach: Breaking the Firewall ». Partilhe-o. Desafie a CISA. Desafie as entidades reguladoras. Desafie OPSWAT. Desafie-me.
Mas, acima de tudo, volte à arquitetura que protege os seus próprios sistemas críticos e faça uma pergunta simples:
Será que o tráfego tem mesmo de voltar?
Se a resposta for «sim», proteja essa ligação como se as suas operações dependessem disso.
E se a resposta for «não»?
Remova o caminho.
E certifica-te de que tudo o que deixares passar está limpo.
Veja «Into the Breach: Breaking the Firewall », Episódio n.º 1:
O episódio n.º 2 está neste momento em produção. Se és um parceiro atual do « OPSWAT » e achas que devíamos fazer um episódio juntos, envia-me uma mensagem.
