 |
| Bellacosa Mainframe e o ataque ao CPD |
☕ Um Café no Bellacosa Mainframe
Spy vs. Spy Entra no CPD — O Dia em que o Espião Preto Roubou uma Senha e Descobriu que Não Precisava Hackear o Mainframe
Ou: por que phishing, ransomware, credenciais roubadas, fornecedores comprometidos, RACF, COBOL e agentes de IA fazem parte da mesma guerra — e por que sobreviver ao ataque vale tanto quanto impedir que ele aconteça
Prólogo — dois espiões, um RACF e uma senha anotada no Post-it
Imagine o CPD.
Ar-condicionado polar. Luzes piscando. Um IBM Z trabalhando silenciosamente enquanto bilhões de transações passam por CICS, Db2, MQ, VSAM e programas COBOL que ninguém ousa desligar numa sexta-feira depois das 17 horas.
O Espião Branco, de Spy vs. Spy, está diante do console.
Tudo verde.
CPU normal.
CICS tranquilo.
Db2 respirando.
JES2 processando.
Nenhum ICH408I.
Nenhum SOC7.
Nenhum operador correndo pelo corredor gritando:
— CAIU PRODUÇÃO!
Logo, estamos seguros.
Certo?
Do outro lado da parede, o Espião Preto observa uma folha de papel.
Nela está escrito:
USERID: XPTO123
PASSWORD: ********Ele olha para o mainframe.
Olha para a senha.
Olha novamente para o mainframe.
Guarda no bolso o kit de hacker cinematográfico que trouxe.
Hoje ele não precisará "hackear o IBM Z".
Alguém já lhe entregou uma identidade.
E essa pequena cena resume boa parte da segurança cibernética moderna.
A indústria gosta de falar sobre inteligência artificial, zero-days, malware polimórfico, ataques sofisticados e hackers praticamente saídos de um filme.
Tudo isso existe.
Mas uma enorme quantidade de incidentes continua dependendo de problemas bem menos glamorosos:
credenciais comprometidas, vulnerabilidades conhecidas, permissões excessivas, sistemas mal configurados, fornecedores confiáveis comprometidos e seres humanos enganados.
O X-Force Threat Intelligence Index 2026 da IBM encontrou aumento de 44% na exploração de aplicações expostas publicamente; 56% das vulnerabilidades divulgadas analisadas não exigiam autenticação para exploração. O número de grupos ativos de ransomware aumentou 49%. (IBM)
Bem-vindo ao nosso café.
Hoje Spy vai tentar entrar.
Spy vai tentar impedir.
E você, jovem padawan do COBOL, ficará no meio dos dois tentando descobrir por que o programa da folha de pagamento não é necessariamente o elo mais fraco da história.
1. Primeira lição: "cyberattack" não é uma coisa só
O infográfico que iniciou nossa conversa apresenta:
phishing;
ransomware;
malware;
DDoS;
insider threats;
SQL injection;
Man-in-the-Middle;
zero-day;
credential stuffing;
supply-chain attacks;
social engineering;
data exfiltration.
A lista é boa para conscientização.
Tecnicamente, porém, existe uma pegadinha.
As coisas não estão todas na mesma camada.
É como criar uma lista de "coisas do mainframe":
COBOL
Db2
arquivo
abend
CICS
SQLCODE -911
RACF
JCLTudo tem relação com mainframe.
Mas claramente não são a mesma espécie de coisa.
Em segurança acontece exatamente isso.
Phishing pode ser vetor inicial.
Social engineering é uma categoria mais ampla de manipulação.
Credential stuffing é uma técnica de tentativa de acesso.
Malware é software malicioso.
Zero-day descreve uma vulnerabilidade ainda sem correção conhecida/disponível no momento relevante.
Ransomware pode ser payload e modelo de extorsão.
DDoS é ataque contra disponibilidade.
Data exfiltration costuma ser uma etapa ou objetivo posterior.
Supply chain descreve um caminho de confiança comprometido.
Portanto, o ataque real pode passar por várias dessas caixas.
Nosso Espião Preto poderia fazer:
PHISHING
|
v
CREDENCIAL ROUBADA
|
v
ACESSO À VPN
|
v
MOVIMENTO LATERAL
|
v
ELEVAÇÃO DE PRIVILÉGIO
|
v
EXFILTRAÇÃO
|
v
RANSOMWARE
|
v
EXTORSÃOEntão o gerente pergunta:
— Qual ataque sofremos?
Resposta:
sim.
Foi uma cadeia.
Essa é nossa primeira grande mudança mental.
2. Espião Preto manda um phishing
Antigamente o phishing clássico parecia produzido por alguém usando Google Translate depois de seis cervejas:
"Estimado cliente Banco Favor atualizar urgentemente senha senão conta ser cancelamento."
Ficava relativamente fácil desconfiar.
Agora entra IA generativa.
O criminoso pode produzir mensagens melhores, contextualizadas, no idioma correto e adaptadas ao ambiente da vítima.
Mais interessante ainda: o ataque não precisa chegar por e-mail.
A Mandiant registrou no M-Trends 2026 que exploits continuaram sendo o vetor inicial mais observado em suas investigações, com 32%, mas o phishing por voz chegou a 11%, tornando-se o segundo vetor observado. (Google Cloud)
Imagine nosso programador COBOL recebendo uma ligação:
— Bellacosa, aqui é o suporte. Estamos migrando o MFA. Você recebeu uma solicitação no telefone?
Recebeu.
— Sim.
— Confirme para sincronizarmos.
Clique.
Pronto.
O Espião Preto não quebrou AES.
Não descobriu uma falha no processador.
Não desmontou RACF em hexadecimal.
Ele atacou um componente muito mais antigo:
HUMANO 1.0Software lançado há aproximadamente 300 mil anos e ainda cheio de comportamento legado.
3. Mas treinamento não resolve tudo
Aqui existe uma ideia perigosa:
"Vamos ensinar os usuários a não clicar."
Devemos ensinar.
Mas alguém clicará.
Imagine uma empresa com 30 mil funcionários.
Mesmo que 99,9% reconheçam determinado ataque, ainda existe uma população potencialmente vulnerável.
Por isso uma arquitetura madura não pode depender exclusivamente de:
NÃO CLIQUE.Ela precisa perguntar:
E SE CLICAR?É a mesma mentalidade de programação.
Um programador COBOL iniciante talvez escreva:
DIVIDE WS-A BY WS-B
GIVING WS-C.O experiente pergunta:
E se
WS-Bfor zero?
Segurança funciona da mesma maneira.
O iniciante pergunta:
Como impedir phishing?
O arquiteto pergunta:
O que acontecerá se amanhã alguém cair em phishing?
Essa segunda pergunta produz arquitetura defensiva.
4. O RACF entra na história
Agora chegamos ao mainframe.
RACF não é simplesmente "a senha do mainframe".
Ele faz parte da infraestrutura de segurança do z/OS e trabalha fundamentalmente com identidade, autenticação e autorização.
Simplificando brutalmente:
QUEM É VOCÊ?
|
v
PODE PROVAR?
|
v
O QUE VOCÊ PODE FAZER?Suponha que o usuário JOAO01 tenha acesso a determinado recurso.
O sistema recebe uma solicitação.
RACF verifica a identidade e as autorizações correspondentes.
Se não houver permissão, podemos encontrar nosso velho conhecido:
ICH408IE o Espião Branco sorri.
ACCESS DENIED.
Mas existe uma questão muito mais interessante.
E se o Espião Preto estiver usando as credenciais verdadeiras de João?
Para o sistema:
USERID = JOAO01
PASSWORD = CORRETA
MFA = APROVADOAutenticação bem-sucedida.
Agora entramos no problema moderno:
identidade válida não significa comportamento legítimo.
João pode ter direito a consultar determinado dataset.
Mas João costuma fazer isso às 10h.
Agora aparece às 03:17 tentando consultar 40 mil registros e acessar ambientes que raramente toca.
É aqui que autenticação precisa encontrar:
least privilege, monitoramento, comportamento, auditoria, segregação de funções e controles contextuais.
5. Credential stuffing — Gundam1979 ataca novamente
Nosso Espião Preto descobre num vazamento:
vagner@example.com
Gundam1979!Testa em outro sistema.
Funciona.
Testa outro.
Funciona.
Outro.
Funciona novamente.
Isso é a essência do credential stuffing: aproveitar combinações de credenciais obtidas anteriormente e testá-las em outros serviços.
Não houve quebra criptográfica da senha.
Houve reutilização.
É um daqueles problemas que parecem pequenos até você perceber o tamanho do ecossistema de identidades atual:
VPN
Microsoft 365
Google Workspace
GitHub
Cloud
SaaS
ServiceNow
portais internos
ferramentas DevOps
ambientes administrativos
IA corporativaE aqui temos uma curiosidade extremamente 2026.
O X-Force relatou mais de 300 mil conjuntos de credenciais associados a chatbots de IA anunciados na dark web em 2025, em grande parte ligados a infostealers. (IBM)
Isso é importante porque uma conta de IA empresarial pode conter ou alcançar informações interessantes:
prompts, documentos, código, conversas, projetos e eventualmente integrações.
A identidade digital está ficando muito maior que USERID + PASSWORD.
6. Ransomware — o vírus virou empresa
O Espião Preto coloca um disquete na mesa.
O Espião Branco olha.
— Ransomware?
Não exatamente.
Pensar ransomware apenas como:
INFECTAR
|
CRIPTOGRAFAR
|
COBRARficou insuficiente.
Hoje podemos encontrar operações compostas por:
ACESSO INICIAL
|
v
PERSISTÊNCIA
|
v
CREDENCIAIS
|
v
MOVIMENTO LATERAL
|
v
DESCOBERTA
|
v
EXFILTRAÇÃO
|
v
CRIPTOGRAFIA
|
v
EXTORSÃOE às vezes a criptografia nem precisa ser o elemento principal.
Se o atacante já roubou informações altamente sensíveis, pode ameaçar publicá-las.
O ransomware tornou-se também um problema de:
continuidade de negócio.
Isso muda tudo.
O diretor de segurança não deveria perguntar apenas:
Nosso EDR detectará ransomware?
Também precisa perguntar:
Se perdermos sistemas críticos hoje, quanto tempo levaremos para operar novamente?
7. Backup que o atacante consegue apagar não é seu amigo
Spy Preto observa o ambiente.
Encontra produção.
Encontra backup.
E percebe que a mesma estrutura privilegiada consegue atingir ambos.
💣
O M-Trends 2026 chama atenção para atacantes visando infraestrutura de backup, identidade e virtualização justamente para dificultar a recuperação da vítima. (Google Cloud)
Esse detalhe é enorme.
Porque segurança deixa de ser:
PROTEGER PRODUÇÃOe passa a incluir:
PROTEGER PRODUÇÃO
+
PROTEGER A CAPACIDADE DE RECUPERAR PRODUÇÃOÉ quase a versão cyber da velha sabedoria de CPD:
backup não é aquilo que você gravou.
Backup é aquilo que você conseguiu restaurar.
8. Malware — às vezes Spy nem leva bomba
Spy Preto abre sua mala.
Malware?
Talvez não seja necessário.
O ambiente já possui ferramentas administrativas.
PowerShell.
SSH.
RDP.
Scripts.
Ferramentas remotas.
Utilitários legítimos.
Por que introduzir um executável obviamente suspeito quando é possível abusar de ferramentas que o administrador utiliza todos os dias?
É o universo de técnicas frequentemente chamadas de Living off the Land.
A própria ENISA destaca o uso de ferramentas e serviços legítimos para disfarçar atividade maliciosa. (ENISA)
Essa situação é maravilhosa do ponto de vista defensivo porque destrói uma regra infantil:
PROGRAMA RUIM = ATAQUE
PROGRAMA BOM = SEGURONão.
Uma ferramenta legítima executada:
pela pessoa errada;
no momento errado;
contra o ativo errado;
com objetivo errado;
pode participar de um ataque.
9. SQL Injection — o fóssil que ainda morde
Nosso jovem COBOL olha para SQL Injection e pergunta:
— Mas isso não é coisa dos anos 1990?
Spy Preto começa a rir.
Erros antigos não desaparecem porque inventamos Kubernetes.
Imagine uma aplicação que constrói SQL de maneira insegura concatenando entrada externa.
O problema conceitual é:
DADO DO USUÁRIO
+
COMANDO SQLacabarem misturados de forma que a entrada consiga alterar a intenção da consulta.
A defesa moderna envolve consultas parametrizadas/prepared statements, validação adequada, privilégios mínimos e práticas seguras de desenvolvimento.
Para o COBOLzeiro trabalhando com Db2, a grande lição não é decorar payloads de SQL injection.
É entender a fronteira:
dados devem continuar sendo dados; instruções devem continuar sendo instruções.
Curiosamente, essa mesma frase reaparece na segurança de IA.
Guarde-a.
É nosso primeiro easter egg.
10. Zero-day — o monstro debaixo da cama
Zero-days assustam.
E devem assustar.
Mas existe um fenômeno engraçado.
A empresa compra 17 ferramentas caríssimas para detectar o ataque do futuro enquanto deixa sem patch uma vulnerabilidade conhecida.
O Espião Preto agradece.
A Mandiant encontrou exploração de vulnerabilidades em 32% das intrusões investigadas em 2025, mantendo exploits como vetor inicial mais observado pelo sexto ano consecutivo. (Google Cloud)
E atenção:
EXPLOIT ≠ ZERO-DAYUm exploit pode atacar vulnerabilidade conhecida.
Portanto, antes de temer exclusivamente o desconhecido:
inventarie ativos, descubra exposição, priorize vulnerabilidades, aplique patches e monitore aquilo que está olhando para a Internet.
O básico continua sendo surpreendentemente revolucionário.
11. DDoS — Spy não quer entrar; quer impedir você de trabalhar
Até agora estávamos tentando impedir Spy Preto de entrar.
DDoS muda a pergunta.
Ele talvez não queira entrar.
Quer que ninguém consiga entrar.
Bem-vindo à famosa tríade:
CIA
CONFIDENTIALITY
INTEGRITY
AVAILABILITYConfidencialidade:
quem não deve ver não vê.
Integridade:
aquilo que deveria ser X não foi transformado secretamente em Y.
Disponibilidade:
o serviço está acessível quando necessário.
DDoS ataca principalmente a terceira.
A ENISA registrou DDoS como cerca de 76,7% dos incidentes de seu conjunto analisado, fortemente influenciado por campanhas hacktivistas. Isso não quer dizer que 76,7% de toda invasão empresarial mundial seja DDoS; significa que ele dominou numericamente aquele dataset e metodologia. (ENISA)
Essa distinção é uma excelente aula sobre estatística em cybersecurity:
número sem contexto também pode atacar você.
12. Supply chain — Spy descobriu a entrada de fornecedores
O CPD possui:
MFA
SIEM
SOC
EDR
PAM
RACF
DLP
segmentação
firewallsSpy Preto observa tudo.
Impenetrável?
Ele olha para a porta lateral.
FORNECEDORES.
Ah.
A empresa confia em:
bibliotecas,
software,
consultorias,
SaaS,
CI/CD,
MSPs,
APIs,
repositórios,
integradores,
componentes open source.
A pergunta passa a ser:
Quem você autorizou a confiar em nome de você?
O X-Force 2026 relata que grandes incidentes envolvendo supply chain ou terceiros cresceram quase quatro vezes desde 2020, com confiança em identidades de desenvolvimento, CI/CD e integrações SaaS fazendo parte dessa superfície. (IBM)
Portanto:
sua superfície de ataque não termina onde termina seu crachá.
Ela se estende pela cadeia de confiança.
13. Insider threat — Spy Branco também pode causar o incidente
E agora a MAD Magazine nos presenteia com uma inversão.
Spy Preto não faz nada.
Spy Branco envia o arquivo errado para o destinatário errado.
💥
Incidente.
Insider threat não significa necessariamente:
funcionário maligno vendendo segredos numa garagem às 23h.
Também pode envolver erro ou negligência:
permissão excessiva
arquivo enviado errado
segredo em repositório
configuração incorreta
dados copiados para serviço inadequado
credencial compartilhada
phishingA identidade era legítima.
A ação, não.
Novamente chegamos ao mesmo ponto:
autenticação é necessária, mas não suficiente.
14. Data exfiltration — finalmente encontramos o cofre
Spy Preto passou duas semanas caminhando pela empresa.
O objetivo talvez nunca tenha sido "dominar o servidor".
Ele queria:
dados de clientes
propriedade intelectual
credenciais
código-fonte
documentos financeiros
contratos
segredos comerciaisA exfiltração é frequentemente o momento em que o ativo sai do ambiente controlado.
Por isso DLP, monitoramento, classificação de dados, controle de acesso e telemetria importam.
Mas existe outra palavra fundamental:
visibilidade.
Você não pode responder adequadamente ao que não consegue observar.
15. Spy Preto pode estar tomando café conosco há duas semanas
Essa talvez seja uma das informações mais assustadoras da conversa.
O M-Trends 2026 encontrou aumento da mediana global de dwell time de 11 para 14 dias nas investigações analisadas. Casos envolvendo espionagem e trabalhadores norte-coreanos de TI tiveram mediana de 122 dias. (Google Cloud)
Dwell time é, simplificando, quanto tempo o adversário permanece antes de ser detectado.
Pense nisso.
Spy Preto não está:
ATAQUE!!!
ALARME!!!
EXPLOSÃO!!!Ele pode estar:
observando
enumerando
aprendendo
coletando
esperando
movendo-sesilenciosamente.
Isso transforma logs em patrimônio.
Porque quando finalmente encontramos Spy Preto, precisamos perguntar:
Quando ele entrou?
Por onde?
O que acessou?
Que credenciais utilizou?
Para onde foi?
O que levou?
Sem telemetria suficiente, começamos a investigação praticamente com:
DISPLAY WTFInfelizmente esse comando ainda não foi implementado no z/OS.
16. O caminho até o mainframe pode começar muito longe do mainframe
Essa parte é essencial para o COBOLzeiro.
Existe a imagem mental:
HACKER
|
v
MAINFRAMEO ataque corporativo pode parecer muito mais com:
NOTEBOOK
|
v
IDENTIDADE CORPORATIVA
|
v
VPN
|
v
SERVIDOR INTERMEDIÁRIO
|
v
FERRAMENTA ADMINISTRATIVA
|
v
CREDENCIAL
|
v
z/OS
|
+----> CICS
|
+----> Db2
|
+----> datasets
|
+----> aplicações COBOLPercebe?
O COBOL talvez não tenha vulnerabilidade nenhuma.
O criminoso chegou usando uma estrada de confiança construída ao redor dele.
Essa é uma das razões pelas quais segurança mainframe não pode viver isolada do restante da cybersecurity empresarial.
17. Least privilege — dê a Spy apenas a chave do banheiro
Imagine:
USER01precisa consultar cinco datasets.
Por comodidade alguém concede acesso a cinquenta.
Funciona.
Durante cinco anos ninguém reclama.
Até a conta ser comprometida.
Agora o atacante herdou cinquenta acessos.
Esse é o blast radius.
Privilégio mínimo significa:
conceder somente aquilo que a função realmente necessita.
Não é burocracia.
É contenção.
Se uma conta for comprometida, queremos:
COMPROMISSO
|
v
PEQUENO RAIOe não:
COMPROMISSO
|
+-------------------------------+
| EMPRESA INTEIRA |
+-------------------------------+O objetivo moderno não é apenas impedir o primeiro dominó.
É aumentar a distância entre os dominós.
18. Agora entra uma personagem nova: Inteligência Artificial
Spy Preto olha para o agente de IA.
O agente pode:
ler documentos
consultar sistemas
usar APIs
gerar código
enviar mensagens
acionar ferramentas
processar dadosSpy sorri novamente.
Porque agora aparece uma categoria interessante:
identidades não humanas e agentes com autoridade.
Se uma aplicação tradicional recebe entrada maliciosa, esperamos que ela trate aquilo como dados.
Mas um LLM trabalha justamente interpretando linguagem.
Lembra do easter egg da SQL Injection?
Dados devem permanecer dados; instruções devem permanecer instruções.
Voltamos ao mesmo problema sob nova forma.
Em SQL injection, dados podem interferir na consulta quando a aplicação é construída inseguramente.
Em sistemas baseados em LLM, conteúdo não confiável pode tentar influenciar o comportamento do modelo.
E quando esse modelo tem ferramentas...
a discussão deixa de ser apenas:
O chatbot respondeu uma bobagem?
e passa a incluir:
Que ações o agente está autorizado a executar?
Isso coloca IA no território de IAM, least privilege, logging, segregação, governança e segurança de aplicações.
19. O verdadeiro perímetro agora é confiança
Durante décadas desenhamos:
INTERNET
|
FIREWALL
|
EMPRESAFora = perigoso.
Dentro = confiável.
Esse modelo ficou insuficiente.
Agora temos:
usuários
fornecedores
SaaS
cloud
APIs
home office
CI/CD
dispositivos
agentes de IA
service accounts
mainframeO perímetro tornou-se difuso.
Por isso conceitos de Zero Trust ganharam tanta importância.
A pergunta deixa de ser:
Está dentro da rede?
E passa a ser continuamente:
QUEM?
O QUÊ?
POR QUÊ?
DE ONDE?
QUANDO?
COM QUAL DISPOSITIVO?
COM QUAL PRIVILÉGIO?
COMPORTAMENTO É COMPATÍVEL?O RACFzeiro provavelmente olha para isso e pensa:
Vocês finalmente descobriram que autorização importa?
😏
20. Prevenir não basta
Spy Branco instalou tudo.
Firewall.
EDR.
MFA.
PAM.
SIEM.
IDS.
IPS.
DLP.
Antivírus.
Spy Preto consegue passar por uma defesa.
Acabou?
Não.
Uma organização madura trabalha com um ciclo:
PREPARE
|
v
PREVENT ---> DETECT
^ |
| v
LEARN <---- RESPOND
^ |
| v
+-------- RECOVERPrevent — tente impedir.
Detect — perceba rapidamente.
Respond — contenha.
Recover — restaure a operação.
Learn — descubra por que aconteceu.
Prepare — esteja pronto antes do próximo.
É aqui que cybersecurity encontra cyber resilience.
21. O painel estava verde, mas a empresa estava sendo roubada
Outra lição fundamental para quem vem do mainframe:
CPU = OK
CICS = UP
Db2 = UP
MQ = UP
JES2 = OKnão significa:
SECURITY = OKUm atacante pode preferir manter tudo funcionando.
Por quê?
Porque derrubar sistema produz alerta.
Roubar silenciosamente produz dados.
O melhor ambiente para espionagem não é um servidor quebrado.
É um servidor perfeitamente saudável fazendo exatamente aquilo que o atacante pediu com uma credencial autorizada.
Isso é quase perversamente elegante.
22. Da segurança de sistemas para segurança da operação
Chegamos à melhor ideia do post original:
cybersecurity está migrando de "protecting systems" para "protecting business operations".
Isso não significa abandonar proteção de sistemas.
Significa perceber o objetivo final.
Uma empresa não existe para manter CPU verde.
Existe para:
vender
pagar
receber
produzir
transportar
atender
processar
entregarNo banco:
transacionar.
Na indústria:
produzir.
No hospital:
atender pacientes.
Na companhia aérea:
operar voos.
Portanto, a pergunta do executivo deveria evoluir de:
Quantos ataques bloqueamos?
para:
Se uma defesa falhar, conseguimos continuar entregando o serviço essencial?
23. As quatro letras que o COBOLzeiro deveria conhecer
MTTD
Mean Time to Detect.
Quanto demoramos para perceber?
MTTR
Dependendo do contexto, Mean Time to Respond/Recover.
Quanto demoramos para responder ou recuperar?
RTO
Recovery Time Objective.
Quanto tempo o negócio tolera ficar sem determinado serviço?
RPO
Recovery Point Objective.
Quanto de dados podemos tolerar perder em termos temporais?
Exemplo simplificado:
RPO = 15 minutos
RTO = 2 horasIsso significa, conceitualmente:
podemos aceitar perder até aproximadamente 15 minutos de dados conforme a estratégia definida, e queremos restaurar o serviço dentro de duas horas.
Não significa que magicamente conseguiremos.
Por isso testes de recuperação importam.
24. Curiosidade Bellacosa — backup não é Disaster Recovery
Esta merece um café.
Ter:
BACKUPnão significa possuir:
DISASTER RECOVERYVocê precisa saber:
onde está,
se está íntegro,
se pode ser acessado,
quem consegue restaurar,
quanto demora,
quais dependências existem,
se credenciais sobreviveram,
se documentação existe,
se o ambiente alternativo funciona.
E, principalmente:
testar.
A primeira vez que você tenta restaurar o ambiente crítico não deveria ser às 03:42 enquanto um diretor pergunta a cada 90 segundos:
— Já voltou?
25. Um pequeno playbook para o COBOLzeiro
Você não precisa virar analista de malware amanhã.
Mas pode começar a pensar como defensor.
Passo 1 — descubra o que seu programa acessa
Pergunte:
Quais datasets?
Quais tabelas?
Quais filas MQ?
Quais transações CICS?
Quais APIs?
Quais arquivos?Passo 2 — descubra quem executa
Usuário?
Started task?
Batch?
Service account?
Aplicação?
Passo 3 — questione privilégios
Essa identidade realmente precisa de tudo aquilo?
Passo 4 — descubra dependências externas
Seu COBOL recebe dados de:
API?
arquivo distribuído?
MQ?
cloud?
fornecedor?
Passo 5 — pense no dado
Ele contém informação sensível?
Como está protegido?
Quem consegue copiá-lo?
Passo 6 — observe erros e comportamento
Tentativas repetidas?
Horários incomuns?
Volumes estranhos?
Acessos inesperados?
Passo 7 — pergunte pela recuperação
Se isso desaparecer agora:
como voltamos?
Essa pergunta vale ouro.
26. A árvore correta de um ataque
Eu substituiria mentalmente o infográfico original por isto:
RECONHECIMENTO
|
v
ACESSO INICIAL
_________/ | \_________
/ | \
phishing exploit supply chain
\ | /
\____________|____________/
|
v
IDENTIDADE
|
v
EXECUÇÃO
|
v
PERSISTÊNCIA
|
v
PRIVILEGE ESCALATION
|
v
MOVIMENTO LATERAL
|
+-------+-------+
| |
v v
EXFILTRAÇÃO DISRUPÇÃO
| |
v v
EXTORSÃO RANSOMWAREAgora conseguimos entender a operação.
Não é uma coleção de monstros.
É uma sequência.
27. Easter egg — ACME Cybersecurity Corporation
O Espião Branco recebe uma caixa:
ACME
ULTIMATE CYBER SECURITY
ZERO TRUST
AI POWERED
QUANTUM READY
MILITARY GRADEEle instala.
Painel verde.
SECURITY SCORE: 100%.
Spy Branco vai tomar café.
Spy Preto entra pela porta porque alguém deixou um crachá sobre a mesa.
BOOM.
Fim do quadro.
Essa seria provavelmente a melhor versão Spy vs. Spy de cybersecurity.
Porque ferramentas importam enormemente.
Mas nenhuma ferramenta corrige automaticamente:
governança ruim
privilégio excessivo
ativos desconhecidos
patch atrasado
processo quebrado
backup não testado
visibilidade insuficiente
confiança excessivaA própria análise do X-Force 2026 enfatiza exatamente essa persistência de lacunas em controles fundamentais apesar da adoção crescente de IA por atacantes e defensores. (IBM)
28. A grande lição para quem está começando em COBOL
Você talvez tenha entrado no mainframe pensando:
Quero aprender
PERFORM,PIC,COMP-3, JCL, VSAM, Db2 e CICS.
Perfeito.
Aprenda.
Mas lembre-se:
o programa não vive sozinho.
Ele vive dentro de uma organização.
E essa organização possui:
PESSOAS
+
IDENTIDADES
+
APLICAÇÕES
+
DADOS
+
REDES
+
FORNECEDORES
+
PROCESSOS
+
CLOUD
+
MAINFRAMECybersecurity conecta tudo isso.
Você não precisa transformar cada programador COBOL em pentester.
Mas um bom desenvolvedor corporativo precisa começar a perguntar:
Quem deveria executar isso?
Quem deveria acessar este dado?
O que acontece se uma entrada for maliciosa?
Estamos registrando aquilo que importa?
O privilégio é realmente necessário?
Qual sistema confia neste?
O que acontece se essa dependência for comprometida?
Como recuperamos?
Essas perguntas transformam um simples codificador em alguém que entende sistemas empresariais.
Epílogo — Spy Preto finalmente encontra o mainframe
Depois de phishing, credenciais, fornecedores, VPN, servidores, APIs, agentes de IA e muita confusão, nosso Espião Preto finalmente chega diante do IBM Z.
Ele prepara a bomba ACME.
Digita:
USERID ===> SPYBLACK
PASSWORD ===> ********Enter.
O terminal responde:
ICH408I USER(SPYBLACK) GROUP(ACME)
NAME(UNKNOWN SPY)
INSUFFICIENT ACCESS AUTHORITYSpy Preto olha furioso para a tela.
Spy Branco aparece atrás dele tomando café.
Sorri.
Mas não comemora muito.
Porque sabe uma coisa que aprendemos durante toda esta conversa:
um ICH408I não significa que a guerra terminou.
Significa apenas que aquele caminho foi bloqueado.
A verdadeira segurança está em construir várias camadas:
identidade
+
MFA
+
least privilege
+
patching
+
segmentação
+
logging
+
monitoramento
+
backup protegido
+
resposta a incidentes
+
recuperação
+
governança
+
pessoas treinadasE aceitar uma verdade incômoda:
algum controle, algum dia, falhará.
A maturidade começa quando essa constatação deixa de produzir pânico e começa a produzir arquitetura.
Por isso a pergunta definitiva de 2026 não é:
"Como podemos impedir todos os ataques?"
É:
"Quando um atacante conseguir ultrapassar uma das nossas defesas, quantas outras encontrará antes de chegar ao negócio — e quão rapidamente conseguiremos detectá-lo, contê-lo e recuperar a operação?"
Esse é o verdadeiro salto de cybersecurity para cyber resilience.
E talvez seja a melhor lição que Spy vs. Spy poderia ensinar dentro de um CPD:
Spy Preto nunca deixará de tentar.
Spy Branco nunca construirá a defesa perfeita.
Mas entre uma bomba ACME, um ICH408I, um backup restaurável e uma xícara de café existe uma coisa chamada engenharia de resiliência.
E no mainframe, onde aplicações COBOL podem continuar executando décadas depois de seus autores terem ido embora, essa palavra deveria soar bastante familiar.
Porque sobreviver ao próximo incidente não é muito diferente de sobreviver aos últimos cinquenta anos de computação corporativa:
não é ausência de mudança.
É a capacidade de continuar operando apesar dela. ☕🖥️💣
Sem comentários:
Enviar um comentário