 |
| Bellacosa Mainframe e o ataque as geladeiras de armazenamento de alimentos e bancos de sangue |
☕ UM CAFÉ NO BELLACOSA MAINFRAME
🔥 FULLMETAL HACKER: O DIA EM QUE OS CIBERCRIMINOSOS TRANSFORMARAM GELADEIRAS EM FORNALHAS NA EUROPA!
Edward Elric e a Lei da Troca Equivalente: como invasores atacaram supermercados, destruíram alimentos e revelaram o lado perigoso da Internet das Coisas
Bellacosa Mainframe — Arqueologia da Computação, COBOL, Mainframes, Cibersegurança e os Fantasmas do Código Legado
Uma investigação sobre os ataques à cadeia de frio europeia em 2026, acompanhada de curiosidades históricas, engenharia de segurança e um laboratório didático em COBOL.
⚗️ Prólogo — A Lei da Troca Equivalente chegou ao supermercado
"Para obter alguma coisa, é preciso sacrificar outra de valor equivalente."
Quem conhece Fullmetal Alchemist reconhece imediatamente a ideia que governa a alquimia praticada pelos irmãos Edward e Alphonse Elric.
No universo criado por Hiromu Arakawa, a alquimia permite transformar a matéria, mas exige respeito a determinadas regras.
E o que acontece quando alguém tenta ignorá-las?
Desastres.
A história começa justamente com uma tentativa de transmutação humana que termina em tragédia. Edward perde partes do corpo, enquanto Alphonse perde o corpo inteiro e tem sua alma vinculada a uma armadura.
Agora imagine nosso alquimista de aço diante de uma notícia bastante real.
Europa, madrugada de 2 de novembro de 2026.
Em supermercados espalhados por diferentes países, equipamentos de refrigeração começam a apresentar temperaturas anormais.
Alguns sistemas indicam valores próximos de 50 graus Celsius.
Funcionários chegam ao trabalho e encontram câmaras frigoríficas comprometidas, congeladores fora das condições adequadas de conservação e produtos que precisam ser descartados.
Milhares de euros em alimentos podem desaparecer economicamente em poucas horas.
Mas não houve necessariamente uma pane elétrica.
Também não foi preciso um criminoso entrar fisicamente em cada estabelecimento.
Os sistemas haviam sido alcançados por meio de conexões digitais.
Edward Elric observa os números e protesta:
— Esperem! Quem foi o idiota que resolveu transmutar um congelador em uma fornalha?
Alphonse, sempre mais ponderado, examina o painel:
— Irmão, parece que alguém alterou os parâmetros de funcionamento remotamente.
Edward fecha o punho metálico.
— Então a Lei da Troca Equivalente continua funcionando. Alguém alterou alguns números, e os supermercados perderam toneladas de mercadorias!
Bem-vindos a uma nova fronteira da cibersegurança.
Uma fronteira onde bits modificam átomos.
Onde comandos digitais afetam equipamentos reais.
E onde o verdadeiro prejuízo não precisa aparecer primeiro numa base de dados, mas pode surgir diretamente dentro de uma câmara frigorífica.
Pegue seu café.
Hoje nossa investigação começa nos supermercados europeus, passa pela tecnologia operacional e termina num laboratório COBOL, sob a supervisão do nosso pequeno — não digam isso perto dele! — Alquimista de Aço.
Capítulo I — Outubro de 2026: a primeira transmutação proibida
Nossa história começa na França.
Na madrugada de 11 para 12 de outubro de 2026, centenas de estabelecimentos comerciais enfrentaram problemas provocados por ataques aos sistemas informatizados de refrigeração.
Entre os grupos atingidos estavam lojas ligadas a Intermarché, Coopérative U, Carrefour, E.Leclerc e Monoprix.
Segundo a cobertura do jornal Le Monde, determinados invasores conseguiram alterar parâmetros relacionados ao descongelamento e ao controle térmico dos equipamentos.
Em um dos episódios relatados, o ciclo de descongelamento foi prolongado de aproximadamente uma para oito horas.
Pense no significado disso.
Uma operação de descongelamento é absolutamente normal em determinados equipamentos frigoríficos.
O objetivo é remover gelo acumulado, preservando a eficiência da refrigeração.
O problema surge quando alguém altera indevidamente sua duração, frequência ou temperatura.
Um recurso criado para conservar a eficiência do equipamento pode passar a produzir o efeito oposto.
É quase uma transmutação alquímica.
O recurso continua existindo.
O equipamento continua ligado.
Mas seu comportamento foi modificado.
No universo de Edward Elric, seria como alterar discretamente a composição de um círculo de transmutação.
Uma pequena diferença nos símbolos produziria uma transformação inteiramente inesperada.
Na engenharia industrial, uma pequena alteração em um parâmetro crítico também pode produzir consequências enormes.
E o resultado francês foi grave: mercadorias descartadas, interrupção de operações e investigações sobre os mecanismos utilizados.
A grande curiosidade
O ataque não precisava necessariamente destruir o refrigerador.
Era suficiente fazer com que o equipamento deixasse de cumprir sua função essencial durante tempo suficiente.
Essa distinção é importantíssima.
O objetivo de um sistema de segurança industrial não é apenas impedir que máquinas sejam destruídas.
É garantir que elas continuem operando dentro de limites seguros.
Capítulo II — Novembro: o ataque atravessa fronteiras
Três semanas depois, em 2 de novembro, novos incidentes atingiram estabelecimentos em diferentes países europeus.
A lista de locais com ocorrências relatadas incluiu:
Bélgica;
Suécia;
Irlanda;
Luxemburgo;
Países Baixos;
Estônia;
Finlândia;
Itália;
Portugal.
Na Bélgica, lojas de redes como Carrefour, Delhaize e Intermarché relataram problemas.
Na Suécia, estabelecimentos das redes ICA e Coop também foram afetados.
Na Irlanda, a rede SuperValu informou incidentes em treze lojas.
E há uma informação especialmente relevante para nós, lusófonos: sete estabelecimentos Intermarché em Portugal foram relacionados à ocorrência.
Segundo declarações divulgadas pela imprensa, uma das hipóteses investigadas em Portugal envolvia um prestador externo responsável pela gestão de sistemas de refrigeração.
Isso nos leva a uma pergunta fundamental.
Como alguém consegue interferir em geladeiras de supermercados localizados em países diferentes?
Edward Elric poderia imaginar um gigantesco círculo de transmutação desenhado sobre o continente europeu.
Mas a explicação técnica é muito menos fantástica.
Ela envolve redes, equipamentos conectados, controladores industriais, software legado e mecanismos de acesso remoto.
E há uma ressalva importante: até 4 de novembro de 2026, as autoridades não haviam identificado publicamente, de maneira conclusiva, os responsáveis nem demonstrado que todos os incidentes pertenciam a uma única operação coordenada.
A semelhança entre ataques é uma pista investigativa.
Não é, por si só, uma prova de autoria comum.
Capítulo III — Edward Elric descobre a Tecnologia Operacional
Para compreender esses ataques, precisamos conhecer uma sigla:
OT — Operational Technology.
Em português, tecnologia operacional.
Enquanto a tecnologia da informação, ou TI, concentra-se no processamento de informações, a tecnologia operacional está diretamente associada ao controle e ao monitoramento de equipamentos e processos físicos.
Vamos comparar.
Num supermercado, os sistemas tradicionais de TI podem cuidar do faturamento, cadastro de produtos, controle financeiro, inventário, pagamentos eletrônicos e integração com fornecedores.
Já os sistemas OT podem controlar equipamentos de refrigeração, sensores térmicos, compressores, ventilação, válvulas e alarmes.
Naturalmente, os dois mundos se comunicam.
Um exemplo:
O sistema de gestão precisa saber se determinada mercadoria está disponível.
Já o sistema de refrigeração precisa garantir que ela permaneça armazenada em condições adequadas.
Um acompanha a informação.
O outro preserva fisicamente o produto.
A arquitetura de uma instalação conectada
Imagine a seguinte estrutura:
INTERNET
|
ACESSO REMOTO
|
REDE DE CONTROLE
|
SISTEMA SUPERVISOR
|
CONTROLADOR INDUSTRIAL
|
+-----+-----+
| |
SENSOR ATUADOR
| |
TEMPERATURA COMPRESSOREsse é um esquema conceitual, não uma reprodução dos sistemas efetivamente atacados.
O sensor mede uma condição física.
O controlador interpreta essa medida.
O atuador modifica alguma coisa no ambiente.
Um compressor pode ser ligado ou desligado.
Uma válvula pode ser acionada.
Um ciclo de descongelamento pode começar.
Tudo isso permite controle preciso e economia de energia.
Porém, se alguém conseguir modificar indevidamente os parâmetros aceitos pelo controlador, poderá interferir no processo físico.
Edward observa o esquema.
— Então o controlador é como o círculo de transmutação?
— Mais ou menos — responde Alphonse. — Ele transforma informações em ações físicas.
— E quem controla seus parâmetros controla o resultado!
Exatamente.
Essa é a essência dos sistemas ciberfísicos.
Capítulo IV — A verdadeira alquimia: transformar bits em prejuízo
O aspecto mais impressionante desses ataques é a relação desproporcional entre a operação digital e a consequência econômica.
Imagine um estabelecimento fictício com cem mil euros em mercadorias refrigeradas.
Vamos supor que o sistema apresente uma condição térmica inadequada durante várias horas.
O equipamento poderá ser recuperado.
O software poderá ser restaurado.
As configurações poderão voltar aos valores normais.
Mas os alimentos não necessariamente poderão ser recuperados.
A conservação depende de fatores como temperatura efetiva, duração da exposição, natureza do produto e histórico de armazenamento.
Um alimento que sofreu uma interrupção inadequada na cadeia de frio não se torna automaticamente seguro porque foi congelado outra vez.
Esse é o ponto central.
O dano digital pode ser reversível.
O dano físico e econômico pode ser permanente.
O caso dos 50 graus
Diversas reportagens mencionaram equipamentos configurados ou indicando temperaturas de 50 °C.
É necessário distinguir uma temperatura de referência manipulada, uma leitura apresentada pelo controlador e a temperatura efetivamente alcançada pelo alimento.
Não são necessariamente a mesma coisa.
Em alguns sistemas, os indicadores podem registrar parâmetros internos ou condições específicas de operação.
Portanto, afirmar que todos os alimentos chegaram a 50 °C seria tecnicamente incorreto.
Mas mesmo sem atingir esse extremo, a perda prolongada de refrigeração pode comprometer completamente um estoque.
Curiosidade: por que o ataque noturno é tão perigoso?
Durante a madrugada, muitos supermercados estão fechados.
Há menos funcionários presentes.
Alertas podem depender de supervisão remota.
Uma falha detectada apenas na abertura da loja já pode ter provocado prejuízos substanciais.
Em sistemas industriais, o tempo entre o início da anomalia e sua detecção é tão importante quanto a própria anomalia.
Capítulo V — Os fantasmas do legado: quando o antigo continua conectado
Agora chegamos a um tema bastante familiar para quem trabalha com mainframes.
Sistemas legados.
Essa expressão costuma ser utilizada equivocadamente como sinônimo de tecnologia ruim ou ultrapassada.
Mas legado não significa necessariamente insegurança.
Um sistema COBOL desenvolvido há décadas pode continuar perfeitamente adequado, desde que seja mantido, documentado, monitorado e protegido.
O problema surge quando uma tecnologia antiga permanece exposta a ameaças modernas sem controles compatíveis.
Nos incidentes europeus, pesquisadores e fornecedores apontaram riscos relacionados a equipamentos antigos, software sem atualização, configurações inadequadas e credenciais de fábrica.
Alguns produtos já haviam ultrapassado seu período de suporte.
Isso significa que determinadas vulnerabilidades podem permanecer sem correções disponibilizadas pelo fabricante.
O paradoxo da longevidade
Considere duas instalações.
A primeira usa um computador industrial antigo, mas permanece devidamente isolada, com acesso controlado, monitoramento independente e procedimentos de manutenção.
A segunda utiliza um controlador relativamente moderno, mas deixa sua administração remota acessível sem autenticação adequada.
Qual é necessariamente mais segura?
Não podemos decidir apenas pela idade dos equipamentos.
A segurança depende da arquitetura, da manutenção, dos controles de acesso e da exposição real.
É uma lição que vale tanto para ambientes industriais quanto para o IBM Z.
Um mainframe moderno pode possuir mecanismos robustos de segurança e auditoria.
Mesmo assim, integrações externas, serviços distribuídos ou aplicações periféricas mal protegidas podem introduzir riscos.
Da mesma forma, um controlador frigorífico confiável pode tornar-se vulnerável caso sua interface de administração seja exposta indevidamente.
A lição de Edward Elric
Na alquimia, conhecer os elementos não basta.
É preciso compreender as relações entre eles.
Na segurança, proteger individualmente os componentes não basta.
Precisamos compreender as conexões, dependências e pontos de confiança.
Capítulo VI — O pequeno grande problema dos fornecedores externos
Uma parte importante das investigações envolve a forma como supermercados contratam serviços de manutenção e monitoramento.
Muitas empresas não administram diretamente todos os equipamentos frigoríficos.
Elas podem contratar especialistas responsáveis por monitorar temperaturas, verificar alarmes, diagnosticar problemas e realizar ajustes remotos.
Isso é extremamente útil.
Imagine centenas de supermercados espalhados por várias regiões.
Enviar técnicos diariamente a cada estabelecimento seria caro e pouco eficiente.
O monitoramento remoto permite detectar problemas antecipadamente.
Entretanto, também introduz uma nova dependência.
Se um fornecedor consegue administrar equipamentos em muitas lojas, as credenciais e conexões utilizadas por esse fornecedor tornam-se particularmente sensíveis.
Um comprometimento pode atingir mais de uma organização.
Esse é um risco de cadeia de fornecimento digital.
Em Portugal, a suspeita divulgada sobre o envolvimento de um prestador externo ilustra por que esse modelo precisa ser investigado.
Mas atenção: suspeitar de uma conexão de terceiros não prova que o fornecedor tenha sido invadido.
Pode haver outras formas de comprometimento, incluindo equipamentos individualmente expostos.
A investigação precisa examinar registros, credenciais, conexões, configurações e evidências forenses.
Uma pergunta para gestores
Sua empresa sabe exatamente quais fornecedores possuem acesso remoto aos equipamentos?
E consegue revogar esse acesso rapidamente?
Se a resposta for não, existe uma questão de governança que merece atenção.
Capítulo VII — O alquimista encontra o COBOL
Chegou a hora de nossa missão prática.
Edward Elric está indignado.
— Como assim vocês têm sensores, computadores, redes e sistemas corporativos, mas ainda conseguem perder um estoque inteiro?
Alphonse responde:
— Irmão, podemos construir um programa para identificar anomalias e produzir alertas.
— Então tragam o COBOL!
É importante esclarecer uma coisa.
COBOL não é normalmente a linguagem responsável pelo controle direto de compressores industriais.
Essas funções costumam ser desempenhadas por controladores especializados e sistemas de automação.
Contudo, COBOL pode participar perfeitamente do processamento empresarial de informações relacionadas à cadeia de frio.
Por exemplo:
receber registros de sensores;
validar dados enviados por sistemas externos;
analisar exceções;
produzir relatórios;
apoiar auditorias;
alimentar processos de gestão de risco;
registrar eventos para investigação.
Esse é exatamente o tipo de integração em que sistemas corporativos podem agregar valor.
Vamos desenvolver um pequeno laboratório didático.
Capítulo VIII — Laboratório 01: construindo um monitor de temperatura em COBOL
Objetivo: criar um programa que receba uma temperatura e determine se ela está dentro do intervalo definido para um equipamento hipotético.
Nosso exemplo utilizará uma faixa didática entre −22 °C e −15 °C.
Esses valores não constituem uma norma universal de segurança alimentar. Na vida real, os limites dependem do equipamento, do produto e dos requisitos aplicáveis.
O programa será apenas um simulador de validação, não um controlador físico de refrigeração.
Passo 1 — Entender o problema
Precisamos de três informações:
A temperatura recebida.
O limite mínimo.
O limite máximo.
Nosso algoritmo será simples.
Se a temperatura estiver abaixo do mínimo, emitiremos um alerta.
Se estiver acima do máximo, também emitiremos um alerta.
Caso contrário, consideraremos a leitura dentro da faixa didática.
Passo 2 — Escrever o programa
O exemplo abaixo utiliza sintaxe COBOL em formato livre, adequada para estudo em compiladores que suportam esse formato.
>>SOURCE FORMAT FREE
identification division.
program-id. FRIOALRT.
environment division.
configuration section.
repository.
function all intrinsic.
data division.
working-storage section.
01 ws-entrada pic x(20).
01 ws-temperatura pic s9(3)v9(2).
01 ws-temp-minima pic s9(3)v9(2)
value -22.00.
01 ws-temp-maxima pic s9(3)v9(2)
value -15.00.
01 ws-temp-exibicao pic -(3)9.99.
procedure division.
principal.
display "BELLACOSA MAINFRAME"
display "MONITOR DIDATICO DE FRIO"
display "Informe a temperatura:"
accept ws-entrada
if test-numval(trim(ws-entrada)) not = 0
display "ERRO: VALOR INVALIDO"
goback
end-if
compute ws-temperatura =
function numval(trim(ws-entrada))
move ws-temperatura to ws-temp-exibicao
evaluate true
when ws-temperatura < ws-temp-minima
display "ALERTA: ABAIXO DO MINIMO"
when ws-temperatura > ws-temp-maxima
display "ALERTA: ACIMA DO MAXIMO"
when other
display "TEMPERATURA NA FAIXA"
end-evaluate
display "LEITURA: "
ws-temp-exibicao
goback.Passo 3 — Compreender o código
Vamos examinar os elementos mais importantes.
IDENTIFICATION DIVISION
Identifica o programa.
Neste exemplo, seu nome é FRIOALRT.
WORKING-STORAGE SECTION
Define as variáveis utilizadas durante o processamento.
A variável ws-temperatura utiliza um campo numérico assinado com duas casas decimais.
A cláusula PIC S9(3)V9(2) permite representar temperaturas positivas e negativas dentro de sua capacidade numérica.
A letra V indica uma posição decimal implícita.
ACCEPT
Recebe uma informação fornecida pelo operador.
Num sistema real, a temperatura poderia chegar por arquivo, mensagem ou interface com outro sistema.
TEST-NUMVAL
Ajuda a verificar se a informação textual recebida pode ser interpretada como número.
É uma validação inicial.
Em sistemas reais, também precisamos verificar o intervalo permitido, a precisão, os limites de armazenamento e a origem da leitura.
EVALUATE TRUE
Permite testar condições e selecionar o tratamento adequado.
É uma estrutura particularmente útil quando desejamos organizar regras de classificação.
Passo 4 — Executar os testes
Imagine os seguintes resultados:
| Temperatura informada | Resultado esperado |
|---|---|
| −18,00 °C | Dentro da faixa |
| −23,00 °C | Abaixo do mínimo |
| −12,00 °C | Acima do máximo |
| 5,00 °C | Acima do máximo |
| 50,00 °C | Acima do máximo |
Ao executar, informe os valores com ponto decimal, como -18.00, de acordo com o formato previsto pelo exemplo.
Uma observação técnica: para uso com dados reais, também é importante validar limites antes da conversão para um campo de tamanho fixo, evitando truncamentos ou incompatibilidades.
Passo 5 — A principal limitação
Nosso programa identifica uma temperatura fora do intervalo.
Mas isso não significa que ele consiga determinar a causa.
Uma temperatura alta pode resultar de:
porta aberta;
falha mecânica;
interrupção de energia;
degelo normal;
manutenção;
sensor defeituoso;
configuração incorreta;
interferência maliciosa.
Um alerta é uma observação.
Não é automaticamente uma conclusão forense.
Edward Elric aprende rapidamente a diferença:
— Então meu programa pode dizer que a geladeira está quente, mas não pode afirmar que um hacker foi o responsável?
Exatamente.
E é por isso que sistemas de monitoramento precisam preservar evidências e trabalhar com informações contextualizadas.
Capítulo IX — Laboratório 02: detectando anomalias em sequência
Vamos evoluir o raciocínio.
Imagine que recebemos temperaturas a cada cinco minutos.
Uma única leitura anormal já merece atenção.
Mas uma sequência de medições pode revelar algo muito mais interessante.
Considere este cenário hipotético:
| Horário | Temperatura |
|---|---|
| 01:00 | −18 °C |
| 01:05 | −18 °C |
| 01:10 | −17 °C |
| 01:15 | −12 °C |
| 01:20 | −5 °C |
| 01:25 | 4 °C |
| 01:30 | 12 °C |
O que podemos observar?
A temperatura está subindo rapidamente.
Isso pode indicar uma anomalia importante.
Mas precisamos considerar o comportamento esperado durante ciclos operacionais, a localização do sensor e a confiabilidade dos dados.
Exercício para o estudante COBOL
Crie um programa que:
Leia um arquivo com identificador do equipamento, horário e temperatura.
Verifique se cada registro possui formato válido.
Compare a temperatura com os limites configurados.
Conte ocorrências consecutivas acima do limite.
Produza um relatório de exceções.
Registre os dados originais sem sobrescrevê-los.
Para um iniciante, esse exercício permite praticar leitura sequencial de arquivos, estruturas de dados, condicionais, contadores e relatórios.
Para um estudante mais avançado, podemos incluir validação de sequência temporal, tratamento de registros duplicados e controle de integridade.
Uma melhoria fundamental
Imagine que o próprio controlador comprometido forneça as temperaturas utilizadas pelo monitoramento.
O atacante poderia, dependendo das capacidades do sistema, interferir também nas informações exibidas.
Por isso, sensores independentes e mecanismos separados de alerta podem ser valiosos.
É o princípio de não confiar exclusivamente no mesmo componente que estamos tentando supervisionar.
Capítulo X — Laboratório 03: o que JCL tem a ver com geladeiras?
Agora vamos trazer o problema para um ambiente IBM z/OS.
Imagine uma organização que recebe periodicamente arquivos de medições enviados por uma plataforma externa.
Um processamento batch pode analisar esses registros e gerar relatórios.
Nosso fluxo hipotético seria:
SISTEMA DE REFRIGERACAO
|
EXPORTACAO
|
ARQUIVO DE LEITURAS
|
IBM z/OS
|
JCL
|
PROGRAMA COBOL
|
RELATORIO DE ALERTAS
|
EQUIPE OPERACIONALNo mundo corporativo, essa arquitetura é perfeitamente plausível.
O mainframe não precisa controlar o compressor.
Ele pode trabalhar na consolidação e análise das informações recebidas.
Um exemplo didático de JCL, para um programa COBOL previamente compilado e catalogado, seria:
//FRIOJOB JOB (ACCT),'BELLACOSA',
// CLASS=A,MSGCLASS=X
//STEP01 EXEC PGM=FRIOBATCH
//STEPLIB DD DSN=BM.LOADLIB,DISP=SHR
//ENTRADA DD DSN=BM.FRIO.LEITURAS,
// DISP=SHR
//RELAT DD DSN=BM.FRIO.RELATORIO,
// DISP=(NEW,CATLG,DELETE),
// SPACE=(TRK,(5,5)),
// DCB=(RECFM=FB,LRECL=120,
// BLKSIZE=0)
//SYSOUT DD SYSOUT=*Esse JCL ilustra a execução de um segundo programa, chamado FRIOBATCH, que seria desenvolvido para processar arquivos.
Ele não executa diretamente nosso programa interativo FRIOALRT.
Essa distinção é importante.
O primeiro programa recebe uma informação pelo terminal.
O segundo seria uma versão batch, com arquivos definidos na FILE-CONTROL e seus respectivos descritores de registros.
Os nomes de datasets, classes, biblioteca de carga e parâmetros precisam ser adaptados ao ambiente real.
E onde entra a segurança?
A execução pode ser protegida por controles do z/OS e políticas RACF.
Podemos estabelecer permissões específicas para os datasets.
Podemos registrar as execuções.
Podemos separar usuários responsáveis por processamento daqueles autorizados a administrar a infraestrutura.
Também podemos direcionar relatórios para sistemas corporativos de monitoramento.
Mas não devemos cometer um erro conceitual.
Um relatório batch executado periodicamente não substitui um sistema de segurança industrial em tempo real.
Se uma câmara frigorífica estiver aquecendo rapidamente, esperar pelo próximo processamento noturno pode ser tarde demais.
O mecanismo primário de proteção precisa funcionar no tempo adequado ao risco físico.
Capítulo XI — O caso dos bancos de sangue: quando a consequência pode ser humana
Em 4 de novembro de 2026, surgiu uma informação ainda mais preocupante.
A Reuters noticiou que sistemas de monitoramento e controle de armazenamento refrigerado ligados a três instalações regionais do serviço francês de sangue também haviam sido afetados.
Os incidentes foram detectados.
As equipes atuaram.
O material foi protegido ou transferido para equipamentos não conectados aos sistemas comprometidos.
Segundo as informações divulgadas, não houve prejuízo às reservas de sangue.
Esse episódio demonstra por que devemos tratar a segurança de sistemas OT com extremo cuidado.
Uma falha em um congelador comercial pode produzir perdas financeiras significativas.
Uma falha em equipamentos que preservam medicamentos, sangue ou outros materiais sensíveis pode introduzir riscos sanitários.
Felizmente, no episódio francês relatado, as medidas de contingência evitaram perdas dos materiais armazenados.
Edward Elric e o valor da vida
Aqui nossa analogia com Fullmetal Alchemist ganha profundidade.
Edward e Alphonse aprendem dolorosamente que não é possível reduzir a vida humana a uma simples lista de ingredientes.
Da mesma forma, nenhuma análise de risco deve reduzir as consequências de uma falha industrial apenas ao valor contábil do equipamento.
A segurança precisa considerar pessoas, processos e impactos indiretos.
Uma organização pode substituir um computador.
Pode reinstalar um programa.
Pode comprar outro sensor.
Mas determinados prejuízos não são recuperáveis com uma simples restauração de backup.
Capítulo XII — Quem são os alquimistas criminosos?
Uma pergunta aparece inevitavelmente.
Quem realizou esses ataques?
Até 4 de novembro de 2026, não havia atribuição pública conclusiva a um grupo específico.
Também não existiam evidências suficientes para afirmar que uma determinada potência estrangeira estivesse por trás das ocorrências.
É necessário separar fatos de hipóteses.
Sabemos que houve manipulação de sistemas de refrigeração em diversos estabelecimentos.
Sabemos que equipamentos conectados e tecnologias antigas estiveram entre as preocupações identificadas.
Sabemos que diferentes autoridades iniciaram investigações.
Mas ainda existem perguntas sem resposta.
Os ataques foram coordenados?
Uma mesma pessoa ou grupo participou de todas as ocorrências?
Os invasores pretendiam extorquir dinheiro?
Queriam demonstrar capacidade técnica?
Estavam buscando provocar prejuízo econômico deliberado?
Existe algum componente de sabotagem política ou estratégica?
Todas são perguntas legítimas.
Nenhuma delas deve ser transformada automaticamente em conclusão.
Guerra híbrida?
A expressão guerra híbrida descreve, entre outras coisas, a combinação de diferentes instrumentos de pressão, incluindo operações digitais, econômicas e informacionais.
Um ataque contra a cadeia de abastecimento pode ser compatível com uma estratégia de desestabilização.
Entretanto, a natureza do alvo não comprova a identidade ou a motivação dos atacantes.
Atribuição exige evidências técnicas, contexto operacional e investigação consistente.
O bom analista não é aquele que encontra rapidamente um culpado.
É aquele que consegue distinguir o que conhece daquilo que ainda precisa descobrir.
Capítulo XIII — Dez medidas para proteger a cadeia de frio
Vamos transformar nossa investigação em conhecimento prático.
1. Inventariar os equipamentos
A organização precisa saber quais controladores utiliza, onde estão instalados e quais versões de software executam.
Não conseguimos proteger adequadamente aquilo que desconhecemos.
2. Revisar acessos remotos
Toda conexão externa deve possuir uma justificativa operacional.
Acessos desnecessários precisam ser removidos.
3. Substituir credenciais de fábrica
Senhas padrão compartilhadas entre equipamentos representam um risco conhecido.
Credenciais devem ser individualizadas e protegidas.
4. Utilizar autenticação forte
Sempre que suportado pela arquitetura, o acesso remoto deve utilizar autenticação multifator e mecanismos de identificação individual.
5. Segmentar redes
Controladores industriais não devem compartilhar indiscriminadamente a mesma superfície de acesso dos serviços corporativos.
A comunicação entre ambientes precisa ser controlada.
6. Atualizar com planejamento
Atualizações de firmware e software devem ser avaliadas conforme as orientações do fabricante e os requisitos de disponibilidade do ambiente.
Em instalações críticas, alterações exigem testes e procedimentos de contingência.
7. Implantar monitoramento independente
Sensores e alarmes independentes podem ajudar a identificar problemas mesmo quando o sistema principal de controle apresenta falhas.
8. Proteger limites operacionais
Quando a arquitetura permitir, mecanismos locais de segurança devem restringir configurações perigosas.
Esses limites precisam respeitar as especificações técnicas do equipamento.
9. Preparar planos de contingência
O supermercado precisa saber o que fazer quando perder o controle remoto dos equipamentos.
Isso pode envolver procedimentos locais, equipamentos alternativos e transferência de mercadorias.
10. Realizar exercícios de resposta
Uma equipe treinada consegue agir com mais rapidez.
O objetivo não é apenas restaurar computadores.
É preservar a segurança operacional e reduzir consequências físicas.
Capítulo XIV — Easter eggs: a alquimia escondida na computação
Como tradição do Bellacosa Mainframe, nossa história merece algumas curiosidades.
Easter egg 01 — A automação industrial nasceu antes da Internet moderna
Sistemas de controle industrial já existiam muito antes de a Internet se tornar popular.
A supervisão remota evoluiu gradualmente, utilizando diferentes tecnologias de comunicação.
A conexão generalizada desses equipamentos a redes modernas trouxe benefícios, mas também novas ameaças.
Easter egg 02 — O IBM System/360 e a alquimia da compatibilidade
Em 1964, a IBM anunciou o System/360, uma família de computadores concebida para oferecer compatibilidade arquitetural entre diferentes modelos.
A ideia de preservar investimentos em software enquanto o hardware evolui ajudou a estabelecer uma tradição importante no universo mainframe.
Aqui encontramos uma diferença interessante.
Longevidade acompanhada de manutenção e evolução arquitetural é uma qualidade.
Longevidade acompanhada de abandono e exposição pode tornar-se um problema.
Easter egg 03 — O COBOL também nasceu de uma necessidade de continuidade
COBOL surgiu em 1959, quando organizações precisavam desenvolver aplicações empresariais mais portáveis e compreensíveis.
Décadas depois, continua presente em processamento corporativo.
Seu valor não está na idade, mas na capacidade de atender necessidades reais de negócios.
Easter egg 04 — A Lei da Troca Equivalente funciona como uma metáfora econômica
Na computação, uma alteração de configuração pode custar apenas alguns bytes.
Mas as consequências podem atingir milhões de euros.
A equivalência aqui não é física.
É uma metáfora sobre responsabilidade.
Toda decisão técnica possui consequências, e uma economia aparentemente pequena em manutenção ou segurança pode produzir custos muito maiores no futuro.
Easter egg 05 — A armadura de Alphonse e a defesa em profundidade
Alphonse possui uma armadura impressionante.
Mas sua existência depende de algo muito mais delicado: o vínculo de sua alma com a armadura.
Na segurança, equipamentos robustos também podem depender de componentes discretos e críticos.
Um dispositivo industrial extremamente resistente pode perder sua proteção se a interface que controla suas configurações permanecer vulnerável.
É o clássico problema do elo fraco.
Easter egg 06 — Roy Mustang não deveria administrar refrigeradores
Nosso Coronel das Chamas seria uma escolha particularmente inadequada para supervisionar uma cadeia de frio.
Brincadeiras à parte, a separação de responsabilidades é um princípio importante.
Nem todo usuário precisa possuir poderes administrativos.
Permissões excessivas aumentam o impacto potencial de erros e comprometimentos.
Capítulo XV — O que um programador COBOL deve aprender com essa história?
Talvez você esteja começando a estudar COBOL e imaginando:
"O que supermercados europeus e equipamentos industriais têm a ver comigo?"
A resposta é: muito mais do que parece.
Primeiro, aprendemos que informações não existem isoladamente.
Um dado pode representar uma transação bancária, uma peça de estoque, uma remessa de medicamentos ou a temperatura de uma câmara frigorífica.
Segundo, descobrimos que validação não é um luxo.
Dados recebidos de sistemas externos precisam ser tratados como informações cuja origem, integridade e consistência devem ser verificadas.
Terceiro, percebemos a importância da rastreabilidade.
Um programa corporativo deve permitir compreender o que foi processado, quando, por qual origem e com qual resultado.
Quarto, entendemos a diferença entre detectar uma anomalia e explicar sua causa.
Um relatório pode mostrar que a temperatura aumentou.
Mas determinar se isso resultou de defeito mecânico, erro humano ou ataque exige outros elementos.
Quinto, aprendemos que integração entre sistemas exige responsabilidade.
Um programa COBOL que recebe informações de sensores industriais faz parte de uma cadeia de confiança.
Ele precisa tratar falhas, registros inválidos, duplicidades e inconsistências temporais.
E existe uma sexta lição.
O desenvolvedor corporativo precisa compreender o negócio que seu software protege.
Um cálculo correto executado com dados errados ainda pode produzir uma decisão incorreta.
Uma aplicação disponível vinte e quatro horas por dia não garante que o processo físico associado esteja funcionando adequadamente.
Disponibilidade, integridade, confidencialidade e segurança operacional são dimensões relacionadas, mas distintas.
Capítulo XVI — A transmutação final: quando a recuperação digital não recupera o mundo físico
Voltemos ao supermercado.
São oito horas da manhã.
A equipe técnica conseguiu restabelecer o funcionamento dos controladores.
Os equipamentos estão novamente refrigerando.
As conexões suspeitas foram desativadas.
Os especialistas começaram a investigar os registros disponíveis.
O sistema informatizado parece ter voltado ao normal.
Missão cumprida?
Não exatamente.
Ainda existem produtos que precisam ser avaliados.
Mercadorias que precisam ser descartadas.
Fornecedores que precisam ser acionados.
Funcionários que precisam reorganizar o estabelecimento.
Clientes que encontrarão prateleiras vazias.
E gestores que precisarão explicar os prejuízos.
Edward Elric contempla a situação.
— Então consertar a máquina não desfaz tudo o que aconteceu?
Alphonse responde:
— Não, irmão. Podemos recuperar o sistema, mas não necessariamente os alimentos.
Essa talvez seja a maior diferença entre um ataque tradicional contra informação e um ataque contra um processo físico.
Em muitos incidentes digitais, a recuperação de um backup confiável pode restaurar parte significativa da operação.
Num incidente ciberfísico, o mundo real não possui um botão universal de desfazer.
Uma mercadoria deteriorada não volta ao estado original porque restauramos a configuração de um controlador.
Uma consequência sanitária não desaparece porque reinstalamos o sistema operacional.
Um equipamento danificado pode precisar de reparos físicos.
A segurança digital passa, portanto, a fazer parte da segurança material das organizações.
Epílogo — A verdadeira Pedra Filosofal da cibersegurança
Na história de Fullmetal Alchemist, a Pedra Filosofal representa uma possibilidade extraordinária: superar limitações normalmente impostas à alquimia.
Mas a busca por esse poder revela consequências morais profundas.
No mundo da informática também procuramos soluções capazes de resolver todos os problemas.
Firewalls perfeitos.
Antivírus infalíveis.
Inteligência artificial capaz de detectar qualquer ameaça.
Redes completamente protegidas.
Mas essa Pedra Filosofal digital não existe.
A segurança depende de engenharia, manutenção, treinamento, governança e monitoramento contínuo.
Depende de conhecer os equipamentos.
De compreender as integrações.
De avaliar fornecedores.
De reduzir acessos desnecessários.
De preservar registros confiáveis.
E de preparar pessoas para agir quando as proteções falharem.
Os incidentes europeus de outubro e novembro de 2026 são uma demonstração dramática de que a transformação digital também amplia nossas responsabilidades.
Uma conexão remota pode economizar milhares de deslocamentos técnicos.
Pode melhorar a eficiência energética.
Pode antecipar falhas.
Pode reduzir perdas de alimentos.
Mas a mesma conectividade, quando inadequadamente protegida, pode transformar um benefício operacional em uma vulnerabilidade grave.
É a nossa Lei da Troca Equivalente tecnológica.
Não porque segurança e prejuízo sejam inevitavelmente equivalentes, mas porque toda arquitetura envolve escolhas, dependências e consequências.
Edward Elric termina seu café, observa o terminal e sorri.
— Agora compreendi. A verdadeira alquimia não é transformar chumbo em ouro.
Alphonse inclina a cabeça.
— Então o que é, irmão?
— É transformar conhecimento em prevenção!
E, lá no fundo do CPD, um programador COBOL acrescenta silenciosamente mais uma regra ao seu programa de validação.
Não para derrotar sozinho todos os hackers do planeta.
Mas para fazer aquilo que bons profissionais de tecnologia sempre fizeram:
compreender os sistemas, identificar riscos e construir soluções mais confiáveis.
Porque, no mundo real, a melhor transmutação é aquela que transforma informação em proteção antes que o desastre aconteça.
☕ Bellacosa Mainframe — Onde o COBOL encontra a História, a Cibersegurança e a Cultura Pop.
"O verdadeiro legado não está na idade do código, mas no conhecimento que nos permite mantê-lo seguro."
Fontes e referências para aprofundamento
Reuters, 2 a 4 de novembro de 2026 — Cobertura dos incidentes europeus, investigação e riscos de sistemas industriais conectados.
Associated Press, 2 e 3 de novembro de 2026 — Reportagens sobre supermercados afetados, temperaturas anormais e tecnologias de refrigeração.
AFP e Euronews, 2 e 3 de novembro de 2026 — Países atingidos, declarações das redes comerciais e ocorrências em Portugal.
Le Monde, 13 de outubro de 2026 — Investigação dos primeiros ataques em supermercados franceses.
BleepingComputer, 2 de novembro de 2026 — Análise dos incidentes e dos estabelecimentos afetados.
NIST SP 800-82 Rev. 3 — Guide to Operational Technology (OT) Security, referência para segurança de sistemas de tecnologia operacional.
Nota editorial: os acontecimentos e declarações jornalísticas foram verificados até 4 de novembro de 2026. Os diálogos de Edward e Alphonse Elric são ficcionais, utilizados exclusivamente como recurso didático. Os exemplos COBOL e JCL representam laboratórios educativos e não devem ser utilizados como sistemas de segurança física sem projeto, validação e certificação apropriados.
