☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta segurança. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta segurança. Mostrar todas as mensagens

quinta-feira, 24 de setembro de 2026

🐀 A TEORIA DO RATO ASSASSINO

 

Bellacosa Mainframe e a teoria do rato assassino

☕ Um Café no Bellacosa Mainframe

🐀 A TEORIA DO RATO ASSASSINO

Como cinquenta gramas de inocência podem derrotar toneladas de tecnologia — e por que o verdadeiro culpado nunca foi o rato



🎬 PRÓLOGO — O RATO NÃO SABIA

Em algum lugar remoto do planeta existe uma instalação subterrânea.

Foi construída décadas atrás.

Concreto.

Aço.

Portas pesadas.

Galerias.

Cabos.

Sensores.

Sistemas redundantes.

Protocolos.

Procedimentos.

Acima dela talvez exista apenas uma paisagem absolutamente desinteressante.

Nenhuma grande cidade.

Nenhum monumento.

Nenhum centro econômico.

Para quem passa pela região, não existe nada ali.

Mas abaixo do solo repousa uma das criações mais destrutivas da humanidade.

Um artefato tecnológico mantido durante décadas, periodicamente inspecionado, modernizado e atualizado.

O computador de ontem foi substituído.

Depois substituído novamente.

Sensores foram modernizados.

Software recebeu novas versões.

Equipamentos ganharam componentes mais recentes.

A tecnologia instalada dentro daquela construção atravessou gerações.

Mas o concreto continuou envelhecendo.

A água continuou procurando caminhos.

Metais continuaram oxidando.

Vedações continuaram deteriorando.

O solo continuou se movimentando.

A natureza nunca recebeu o memorando informando que aquela era uma instalação estratégica.

E então aparece nosso protagonista.

Um rato.

Cinquenta gramas.

Ele não conhece geopolítica.

Não sabe o que é uma fronteira.

Nunca ouviu falar em capitalismo ou comunismo.

Não conhece religiões.

Não possui nacionalidade.

Não entende tratados internacionais.

Não sabe o significado de retaliação.

Não conhece dinheiro.

Não sabe o que é uma guerra nuclear.

Na verdade, ele sequer sabe que existe algo chamado humanidade.

Para o rato existe apenas:

comida,

abrigo,

predadores,

cheiros,

temperatura,

escuridão,

reprodução,

sobrevivência.

Em determinado momento ele encontra uma pequena passagem.

Ou talvez comece a escavar uma.

O túnel é insignificante.

Tão pequeno que não representa ameaça segundo nenhuma concepção humana razoável.

Nenhum general recebe um alerta.

Nenhum governo convoca uma reunião.

Nenhum satélite detecta uma invasão.

Nenhum sistema declara estado de emergência.

É apenas um rato fazendo aquilo que ratos fazem.

E é exatamente aí que começa a Teoria do Rato Assassino.



🧠 CAPÍTULO 1 — UMA CAUSA NÃO PRECISA COMPREENDER SUA CONSEQUÊNCIA

Temos uma tendência intuitiva a associar grandes consequências a grandes causas.

Uma guerra precisa de um ditador.

Um desastre precisa de uma grande falha.

Uma fraude bilionária precisa de uma organização gigantesca.

Uma catástrofe tecnológica precisa de um ataque extremamente sofisticado.

Nem sempre.

Sistemas complexos podem permitir que eventos pequenos atravessem sucessivamente várias camadas até produzirem resultados completamente desproporcionais à causa inicial.

O rato não pretende destruir nada.

Isso é fundamental.

Ele não é terrorista.

Não está sabotando uma instalação.

Não escolheu um lado.

Não possui sequer capacidade cognitiva para compreender o sistema no qual entrou.

Ele apenas introduziu uma perturbação.

Podemos representar isso de maneira extremamente simples:

EVENTO INSIGNIFICANTE
        ↓
ALTERAÇÃO LOCAL
        ↓
ANOMALIA
        ↓
DETECÇÃO
        ↓
INTERPRETAÇÃO
        ↓
DECISÃO
        ↓
REAÇÃO
        ↓
NOVA INTERPRETAÇÃO
        ↓
ESCALADA
        ↓
CONSEQUÊNCIA DESPROPORCIONAL

Observe algo importante.

O rato aparece apenas no começo.

Todo o restante pertence ao sistema construído por seres humanos.



🦋 CAPÍTULO 2 — O RATO ENCONTRA A BORBOLETA

A Teoria do Rato Assassino possui parentesco com uma ideia famosa da teoria do caos: pequenas diferenças nas condições de um sistema podem produzir trajetórias profundamente diferentes ao longo do tempo.

Popularmente isso ficou conhecido como efeito borboleta.

Mas existe uma interpretação ruim dessa ideia:

“Uma coisa pequena sempre provoca uma coisa gigantesca.”

Não.

A questão é outra.

Determinados sistemas possuem dinâmicas nas quais pequenas perturbações podem ser amplificadas.

Nosso rato não possui cinquenta gramas de poder destrutivo.

Ele possui cinquenta gramas.

Ponto.

O sistema ao redor dele é que possui o poder.

PODER DO RATO

█


PODER DO SISTEMA

████████████████████████████████████████

Portanto a pergunta correta nunca deveria ser:

Como um rato conseguiu destruir a humanidade?

A pergunta deveria ser:

Como construímos uma arquitetura na qual cinquenta gramas de mamífero poderiam iniciar uma trajetória capaz de terminar nela?

Essa diferença muda completamente a investigação.



⚠️ CAPÍTULO 3 — ROOT CAUSE: RODENT

Imagine que a humanidade tivesse sobrevivido.

Uma comissão investigaria o incidente.

Engenheiros coletariam evidências.

Logs seriam analisados.

Sensores seriam reconstruídos.

Milhares de páginas seriam escritas.

Em algum relatório poderia aparecer:

ROOT CAUSE:
RODENT INTERFERENCE

Caso encerrado.

Encontramos o culpado.

🐀

Não.

Encontramos o evento iniciador.

Não necessariamente encontramos a causa sistêmica.

Porque eliminar aquele rato não elimina a classe do problema.

Amanhã poderia ser:

água,

um inseto,

corrosão,

um componente eletrônico,

um sensor defeituoso,

uma credencial comprometida,

um erro de software,

um operador cansado,

um dado corrompido,

uma interpretação errada,

uma inteligência artificial classificando incorretamente uma situação inédita.

A arquitetura robusta não pode depender da capacidade de seus projetistas de imaginar antecipadamente todas as coisas absurdas que poderão acontecer.

Isso é impossível.

A defesa verdadeira consiste em impedir que uma única perturbação encontre uma trajetória desimpedida até uma consequência irreversível.



🏰 CAPÍTULO 4 — A DUNGEON DAS BARREIRAS

Quanto maior a consequência possível de uma decisão, maior deveria ser a resistência arquitetônica necessária para alcançá-la.

Em outras palavras:

IMPACTO ↑

EVIDÊNCIA ↑
VERIFICAÇÃO ↑
REDUNDÂNCIA ↑
INDEPENDÊNCIA ↑
SEGREGAÇÃO ↑
OBSERVABILIDADE ↑

AUTOMAÇÃO IRREVERSÍVEL ↓
PONTO ÚNICO DE FALHA ↓

Isso vale muito além do nosso experimento nuclear.

Vale para bancos.

Hospitais.

Aeronaves.

Redes elétricas.

Infraestruturas críticas.

Sistemas financeiros.

Inteligência artificial.

Mainframes.

E vale especialmente quando existe concentração extrema de poder.

Se bilhões dependem de uma credencial, aquela credencial vale bilhões.

Se milhões de registros dependem da honestidade de uma única pessoa, aquela pessoa tornou-se parte da segurança do sistema.

Se uma IA possui capacidade enorme de ação, cada caminho que transforma percepção em ação precisa ser tratado de acordo com a magnitude das consequências possíveis.

O princípio é brutalmente simples:

Nenhum elemento insignificante deveria possuir sozinho uma trajetória de falha capaz de produzir uma consequência irreversível.


🤖 CAPÍTULO 5 — O RATO NÃO PRECISA SER BIOLÓGICO

Aqui a teoria começa a ficar desconfortável.

O rato pode ser um software.

Uma entrada inesperada.

Um pacote de rede.

Uma informação falsa.

Uma inferência.

Um dado perfeitamente verdadeiro interpretado de maneira errada.

Uma IA pode receber:

EVENTO HOSTIL: 87%

Parece impressionante.

Mas 87% não responde à pergunta mais importante:

O que o sistema está autorizado a fazer diante desses 87%?

Quanto maior a autonomia de uma máquina, mais importante torna-se separar:

PERCEBER
   ↓
INTERPRETAR
   ↓
RECOMENDAR
   ↓
DECIDIR
   ↓
AGIR

Transformar tudo isso numa única seta é arquitetonicamente tentador.

Também pode ser perigoso.

Porque o rato assassino não precisa possuir dentes.

Pode possuir um IF.


🧠 CAPÍTULO 6 — A, B, C E D

Imagine quatro sistemas idênticos.

A.

B.

C.

D.

Todos observam aproximadamente o mesmo acontecimento.

A conclui:

falha técnica.

B:

evento desconhecido; precisamos de mais informações.

C:

possível comportamento anômalo.

D:

ameaça.

Por quê?

Porque estímulos aparentemente iguais não implicam necessariamente estados internos iguais.

Cada sistema possui história.

Memória.

Contexto.

Experiências anteriores.

Parâmetros.

Informações disponíveis.

Interpretações.

Aprendizado.

Um pequeno desvio hoje modifica uma decisão.

Essa decisão modifica o ambiente.

O ambiente produz uma experiência diferente amanhã.

A experiência altera o modelo.

O modelo interpreta diferentemente a próxima experiência.

Surge um ciclo:

MODELO
  ↓
INTERPRETA EXPERIÊNCIA
  ↓
PRODUZ COMPORTAMENTO
  ↓
ALTERA AMBIENTE
  ↓
PRODUZ NOVA EXPERIÊNCIA
  ↓
ALTERA MODELO
  ↺

Depois de milhares de ciclos, A e D podem ter começado praticamente iguais e terminado profundamente diferentes.

O rato encontrou novamente a borboleta.


☢️ CAPÍTULO 7 — CINQUENTA GRAMAS CONTRA A HUMANIDADE

Voltemos ao nosso silo.

O pequeno animal continua avançando.

Em algum momento sua presença participa de uma cadeia improvável de acontecimentos.

Não precisamos conhecer o mecanismo.

Na verdade, conhecê-lo estragaria o experimento.

Porque a Teoria do Rato Assassino não trata de mísseis.

Trata de sistemas.

Uma anomalia ocorre.

É interpretada.

Outra parte do sistema reage.

Alguém observa a reação.

Interpreta-a.

Responde.

Outro lado observa aquela resposta.

Cada etapa faz sentido localmente.

E esse detalhe é aterrorizante.

Nenhum participante precisa desejar o resultado final.

Mesmo assim:

🐀
 ↓
?
 ↓
?
 ↓
?
 ↓
?
 ↓
☢
 ↓
☢ ☢
 ↓
☢ ☢ ☢ ☢
 ↓
SILÊNCIO

A civilização humana termina.


🌍 CAPÍTULO 8 — MAS O RATO SOBREVIVE

E aqui aparece a ironia fundamental da teoria.

Aquele silo específico ficava em um lugar insignificante.

Longe dos grandes centros.

Protegido no subterrâneo.

A mesma irrelevância geográfica que ajudava a esconder a instalação acaba protegendo nosso protagonista.

Depois do fim da humanidade, o rato continua vivo.

Ele não comemora.

Não sente remorso.

Não sabe que aconteceu alguma coisa extraordinária.

Procura comida.

Dorme.

Reproduz-se.

Talvez encontre outro rato.

Para ele, nada chamado “civilização humana” desapareceu porque nada chamado “civilização humana” jamais existiu em seu universo cognitivo.

O rato nunca soube.


🌱 CAPÍTULO 9 — A TERRA NÃO PRECISA DE NÓS

Passam-se décadas.

Depois séculos.

Cidades deterioram-se.

Vegetação invade ruas.

Estruturas desabam.

Rios mudam.

Florestas avançam e recuam.

Ecossistemas reorganizam-se.

Passam-se milhares de anos.

Depois centenas de milhares.

Depois milhões.

A Terra continua.

Isso talvez seja uma das constatações mais desconfortáveis da Teoria do Rato Assassino:

o fim da humanidade não é necessariamente o fim do planeta.

Somos extraordinariamente importantes para nós mesmos.

A biosfera não assinou esse contrato.


🐀 CAPÍTULO 10 — OS FILHOS DO ASSASSINO

Milhões de anos passam.

A evolução não possui objetivo e nada garante que inteligência tecnológica apareça novamente.

Mas nosso experimento mental permite uma possibilidade.

Uma linhagem descendente daqueles pequenos sobreviventes desenvolve capacidades cognitivas cada vez maiores.

Ferramentas.

Comunicação.

Linguagem.

Cultura.

Escrita.

Matemática.

Ciência.

Tecnologia.

Finalmente surge uma nova civilização.

Os descendentes do rato povoam a Terra.

E um dia começam a escavar.


🏺 CAPÍTULO 11 — OS ANTIGOS

Arqueólogos encontram objetos impossíveis.

Concreto.

Metais trabalhados.

Cerâmicas.

Plásticos.

Estradas fossilizadas.

Estruturas gigantescas.

Camadas geológicas incomuns.

Depois descobrem ruínas de cidades.

A conclusão é inevitável:

Não fomos a primeira civilização tecnológica deste planeta.

Chamam-nos de Os Antigos.

Durante séculos tentam compreender quem éramos.

Descobrem nossa escrita.

Reconstruem nossos computadores.

Encontram nossas bibliotecas.

Descobrem nossa música.

Nossa medicina.

Nossa literatura.

Nossos memes — e provavelmente concluem que isso era algum tipo de religião.

Finalmente descobrem nossas armas.

E surge uma pergunta quase incompreensível:

Por que uma espécie suficientemente inteligente para compreender o átomo construiria instrumentos capazes de destruir a própria civilização?


🦴 CAPÍTULO 12 — O PRIMEIRO RATO

Então acontece a descoberta.

Dentro de uma antiga instalação subterrânea encontram um pequeno túnel.

No interior, vestígios fossilizados de um roedor.

A data coincide aproximadamente com o período da catástrofe.

Surge uma hipótese.

Um ancestral deles pode ter participado do evento inicial.

O impacto cultural seria extraordinário.

Religiões poderiam chamá-lo de libertador.

Outros poderiam chamá-lo de destruidor.

Artistas o transformariam em símbolo.

Políticos tentariam apropriar-se da história.

Cientistas passariam décadas repetindo:

Não existe evidência de intenção.

Até que algum filósofo finalmente escreveria:

“O Primeiro Rato não destruiu os Antigos. Ele apenas encontrou uma arquitetura capaz de destruí-los.”

Nasceria então o maior princípio de engenharia daquela civilização:

O Princípio do Primeiro Rato

Nenhum sistema com capacidade de produzir consequências existenciais deve permitir que uma perturbação isolada, um agente sem intenção ou uma única interpretação atravesse suas barreiras e alcance uma ação irreversível.


⚛️ CAPÍTULO 13 — ELES PROMETERAM NÃO REPETIR NOSSOS ERROS

A nova civilização estuda nossa queda durante gerações.

“Nunca faremos aquilo.”

“Nós aprendemos.”

“Nossa tecnologia é superior.”

“Nossos sistemas são mais seguros.”

“Nossa inteligência artificial monitora tudo.”

“Nossa redundância é perfeita.”

Então descobrem energia nuclear.

Primeiro para ciência.

Depois energia.

Até alguém perceber outra possibilidade.

Um governo pensa:

Não construiremos isso.

Mas surge uma dúvida:

E se os outros construírem?

Do outro lado do planeta, alguém pensa exatamente a mesma coisa.

Séculos depois existem novamente instalações subterrâneas.

Sensores.

Computadores.

Protocolos.

Redundância.

Inteligências artificiais.

Tudo infinitamente superior à tecnologia dos Antigos.

Na entrada de cada centro estratégico existe uma frase:

LEMBRE-SE DO PRIMEIRO RATO.

Eles estão seguros.

Pelo menos acreditam estar.


🪱 EPÍLOGO — A MINHOCA

03:17.

Uma instalação subterrânea funciona silenciosamente.

Um painel registra:

SYSTEM STATUS

POWER............... NOMINAL
SECURITY............ NOMINAL
ENVIRONMENT......... NOMINAL
AI MONITORING....... NOMINAL
REDUNDANCY.......... 100%

KNOWN THREATS........ NONE
UNEXPECTED EVENTS.... 0

TIME................. 03:17

A câmera atravessa a instalação.

Passa pelos computadores.

Desce pelas estruturas.

Atravessa o concreto.

Entra na terra.

Silêncio.

Alguma coisa se move.

Uma pequena minhoca abre caminho pelo solo.

🪱

Ela não conhece a história dos Antigos.

Não conhece o Primeiro Rato.

Não estudou engenharia.

Não sabe que acima dela existe uma civilização.

Não conhece fronteiras.

Não conhece política.

Não conhece tecnologia.

Não sabe o que significa REDUNDANCY 100%.

Ela simplesmente continua cavando.

Não sabemos se acontecerá alguma coisa.

Talvez nada aconteça.

Talvez ela passe pela instalação e continue sua existência insignificante.

E essa é precisamente a questão.

Porque o Primeiro Rato também não sabia que era o Primeiro Rato.

Tela preta.


🐀 A TEORIA DO RATO ASSASSINO

A Teoria do Rato Assassino não afirma que pequenas causas necessariamente produzirão grandes catástrofes.

Afirma algo mais importante:

Sistemas extremamente poderosos devem ser projetados considerando que eventos insignificantes, imprevisíveis e até completamente inocentes inevitavelmente existirão.

Não podemos prever todos os ratos.

Não podemos catalogar todas as minhocas.

Não podemos conhecer antecipadamente todas as combinações possíveis de falha, comportamento, ambiente, informação e interpretação.

Portanto, a segurança não pode depender apenas de impedir que o evento inesperado aconteça.

Precisa impedir que o inesperado encontre uma trajetória direta até o irreversível.

Porque quanto maior o poder de um sistema, maior deve ser sua capacidade de sobreviver ao absurdo.

E quando uma catástrofe gigantesca começa com algo minúsculo, culpar aquilo que iniciou a cadeia pode apenas esconder a pergunta realmente importante:

Por que nossa arquitetura permitiu que aquilo tivesse tanto poder?

Talvez esse seja o verdadeiro teste de qualquer tecnologia.

Não perguntar apenas:

“O sistema funciona?”

Nem:

“O sistema está protegido contra os ataques que conhecemos?”

Mas:

“O que acontece quando aparece algo que jamais imaginamos?”

Porque algum dia aparecerá.

Pode ser um erro.

Pode ser uma pessoa.

Pode ser uma IA.

Pode ser um rato.

Ou pode ser apenas uma minhoca cavando tranquilamente no escuro.

🪱

E ela não saberá de nada.

Para pensar durante o café

A ausência histórica de uma catástrofe não demonstra necessariamente que uma anomalia seja segura; pode significar apenas que, nas ocorrências anteriores, as demais condições necessárias para completar a cadeia ainda não estavam presentes.

O rato pode ter passado pelo túnel cem vezes.

Na 101ª, encontra a borboleta. 🐀🦋

Lembra disso? Pergunta sobre Challenger/Columbia e apareceu outro corolário:

O rato pode ter aparecido cem vezes sem provocar uma catástrofe. Isso não prova que o rato seja seguro.

E finalmente a minhoca:

Mesmo depois de catalogarmos todos os ratos conhecidos, continuará existindo aquilo que nosso modelo não imaginou.


quinta-feira, 17 de setembro de 2026

🎩 O CHAPELEIRO MALUCO E O PAÍS DAS PORTAS DOS FUNDOS

 

☕ Um Café no Bellacosa Mainframe

🎩 O CHAPELEIRO MALUCO E O PAÍS DAS PORTAS DOS FUNDOS

RACF, Zero Trust, jatinhos, VIPs, compliance, conflitos de interesse, despesas de representação, audit trail, Red Team — e o dia em que Alice descobriu que o sistema estava perfeitamente protegido contra todo mundo, exceto contra quem tinha poder suficiente para pedir uma exceção.




🎬 PRÓLOGO — ALICE CAIU NO BURACO ERRADO

Alice já conhecia o País das Maravilhas.

Coelhos atrasados.

Gatos que desapareciam.

Rainhas temperamentais.

Cartas de baralho que falavam.

Nada daquilo a surpreendia mais.

Até que encontrou uma porta onde estava escrito:

SECURITY — AUTHORIZED PERSONNEL ONLY

Alice tentou entrar.

A porta não abriu.

Uma tela verde respondeu:

ICH408I USER ALICE
NOT AUTHORIZED TO RESOURCE

— Excelente! — disse Alice. — Finalmente encontrei um lugar organizado.

Então apareceu um homem importante.

Tentou entrar.

A porta também não abriu.

ICH408I USER VIP001
NOT AUTHORIZED TO RESOURCE

Alice sorriu.

— Pelo menos as regras são iguais.

O homem aproximou-se do funcionário responsável pela porta e perguntou:

— Você sabe com quem está falando?

O funcionário empalideceu.

Pegou o telefone.

Cinco minutos depois, a porta abriu.

Alice ficou olhando.

Nesse momento surgiu o Chapeleiro Maluco carregando uma xícara de café.

— Bem-vinda à segurança corporativa, Alice.

— Mas o sistema negou!

— Exatamente.

— Então como ele entrou?

O Chapeleiro tomou um gole.

— O computador disse não. O organograma disse sim.

Eram exatamente 03:17.



🐇 CAPÍTULO 1 — O QUE APRENDEMOS COM O COELHO BRANCO?

Nossa conversa começou com um caso contemporâneo envolvendo um banco, seu controlador, autoridades, familiares, contratos, viagens e relações sociais.

Mas rapidamente percebemos que o assunto era muito maior.

As investigações envolvendo o Banco Master revelaram publicamente uma extensa rede de relacionamentos envolvendo diferentes setores do poder brasileiro. Isso não significa que toda pessoa mencionada tenha cometido irregularidade; contatos, contratos, viagens ou relações profissionais precisam ser examinados individualmente e com devido processo.

O verdadeiro aprendizado não está em perguntar:

“Quem conhece quem?”

Está em perguntar:

“Nosso sistema institucional consegue identificar quando um relacionamento legítimo começa a produzir conflito de interesses?”

Essa pergunta serve para Brasília.

Serve para bancos.

Serve para empresas.

E serve perfeitamente para o mainframe.



🔐 CAPÍTULO 2 — RACF NÃO PROTEGE CONTRA ORGANOGRAMA

Imagine que você está começando como programador COBOL.

Seu programa processa pagamentos.

O dataset é:

PROD.PAYROLL.MASTER

Seu USERID possui apenas:

READ

Você tenta alterar.

RACF responde:

ICH408I
NOT AUTHORIZED

Excelente.

Agora imagine que o presidente da empresa tente fazer a mesma coisa.

Tecnicamente, deveria acontecer exatamente a mesma coisa.

O RACF não deveria pensar:

“Nossa! É o presidente!”

Para o sistema, existem:

identidade → autenticação → autorização.

Cargo não substitui nenhuma delas.

Esse conceito precisa sair do mainframe e entrar na governança das organizações.



🪪 CAPÍTULO 3 — IDENTIDADE NÃO É AUTORIZAÇÃO

Essa talvez tenha sido a principal descoberta de toda nossa conversa.

Existem três conceitos diferentes:

Identificação

Quem você afirma ser?

USERID = ALICE

Autenticação

Você consegue provar que realmente é Alice?

Senha.

MFA.

Certificado.

Biometria.

Passkey.

Autorização

Alice pode executar aquela operação?

PERMIT ALICE
       CLASS(DATASET)
       ACCESS(READ)

É perfeitamente possível possuir:

IDENTITY       = VALID
AUTHENTICATION = SUCCESS
AUTHORIZATION  = DENIED

E isso não representa erro.

Representa segurança funcionando.

O problema aparece quando acrescentamos uma quarta variável:

STATUS = VIP

E alguém decide que VIP significa:

ACCESS = ALTER

Não deveria.



🎩 CAPÍTULO 4 — “VOCÊ SABE COM QUEM ESTÁ FALANDO?”

O Chapeleiro colocou quatro xícaras sobre a mesa.

Na primeira escreveu:

Política.

Na segunda:

Procedimento.

Na terceira:

Tecnologia.

Na quarta:

Cultura.

— Qual delas controla a empresa? — perguntou Alice.

— Política?

— Errado.

— Tecnologia?

— Também.

O Chapeleiro apontou para a quarta.

Cultura.

Uma organização pode possuir a política:

Ninguém entra sem autorização.

Mas possuir simultaneamente a cultura:

Não crie problema para diretor.

Qual das duas vence?

Normalmente a segunda.

Isso cria aquilo que poderíamos chamar de:

Shadow Security Policy

A política invisível.

Ela nunca foi aprovada.

Não existe PDF.

Não existe versão.

Não existe owner.

Mas todo funcionário aprende.


🧨 CAPÍTULO 5 — O FUNCIONÁRIO QUE DISSE NÃO

Nossa conversa trouxe um exemplo perfeito.

Um diretor solicitou determinado acesso.

O responsável sabia exatamente quem ele era.

Mas não havia autorização adequada.

A resposta foi:

não.

Só que não terminou aí.

Foi solicitado um e-mail formal.

Enquanto isso, houve confirmação independente com a pessoa competente para autorizar.

Isso é excelente segurança.

O fluxo ficou:

REQUEST
   |
   v
IDENTITY CONFIRMED
   |
   v
AUTHORIZATION MISSING
   |
   v
ACCESS DENIED
   |
   v
EXCEPTION REQUEST
   |
   v
INDEPENDENT VALIDATION
   |
   v
DOCUMENTED APPROVAL
   |
   v
CONTROLLED ACCESS

Observe algo importante:

o funcionário não decidiu conceder privilégio.

Quem possuía autoridade assumiu formalmente a responsabilidade.

Isso é accountability.


😡 CAPÍTULO 6 — QUANDO O DIRETOR FICA OFENDIDO

Só que existe um problema.

O diretor pode interpretar:

controle = desconfiança

ou:

procedimento = humilhação

ou:

registro = burocracia.

Se depois retaliar quem aplicou corretamente o procedimento, algo extremamente perigoso acontece.

Os demais funcionários aprendem.

Não através de treinamento oficial.

Aprendem observando.

A próxima pessoa importante aparece.

O funcionário lembra:

“Da última vez alguém seguiu a política e se ferrou.”

Então libera.

Nesse momento a empresa possui uma vulnerabilidade que:

Nessus não encontra.

Qualys não encontra.

SIEM não encontra.

Penetration test tradicional talvez não encontre.

Porque a vulnerabilidade está na cultura de poder.


✈️ CAPÍTULO 7 — ALICE ENCONTRA UM JATINHO

Depois apareceu o avião executivo.

Aqui descobrimos outra coisa importante.

Privacidade não é necessariamente anonimato.

Aviação executiva possui controles e regulamentação próprios, diferentes em vários aspectos do fluxo comercial comum.

Mas para governança existe uma pergunta essencial:

Conseguimos reconstruir posteriormente quem utilizou determinado recurso, quem autorizou e quem pagou?

Isso vale para avião.

Vale para carro corporativo.

Vale para hotel.

Vale para cartão empresarial.

Vale para dataset.

Vale para transação CICS.

Vale para API.

O nome técnico disso é:

Audit Trail


📜 CAPÍTULO 8 — SMF PARA O MUNDO REAL

No z/OS temos algo maravilhoso:

SMF — System Management Facilities.

O sistema registra acontecimentos.

Jobs.

Logons.

Uso de recursos.

Segurança.

Performance.

Accounting.

Agora imagine aplicar mentalidade semelhante à governança.

Queremos responder:

WHO?
WHAT?
WHEN?
WHERE?
WHY?
WHO AUTHORIZED?
WHO PAID?
WHO BENEFITED?

Isso é praticamente um SMF institucional.

E existe uma lição extraordinária:

quanto maior o privilégio, maior deveria ser a auditabilidade.

Muitas organizações fazem exatamente o contrário.

Funcionário comum:

30 controles.

Diretor:

“Pode deixar passar.”

Deveria ser:

mais poder → mais accountability.


🍽️ CAPÍTULO 9 — O JANTAR QUE TALVEZ NÃO FOSSE JANTAR

Chegamos então às despesas de representação.

Hospitalidade empresarial existe.

Jantares existem.

Eventos existem.

Viagens existem.

Relacionamento comercial existe.

Nada disso é automaticamente irregular.

Mas descobrimos outra diferença fundamental:

DOCUMENT EXISTS

não significa:

DOCUMENT REPRESENTS REALITY

Um compliance superficial verifica:

✔ nota fiscal
✔ centro de custo
✔ aprovação
✔ fornecedor
✔ valor

E encerra.

Um Red Team pergunta:

A natureza econômica da operação corresponde ao documento?

Essa pergunta muda tudo.


🧾 CAPÍTULO 10 — COMPLIANCE NÃO É COLECIONAR PDFs

Imagine:

REALIDADE       = A
DOCUMENTO       = B
ERP             = B
CONTABILIDADE   = B
RELATÓRIO       = B
AUDITORIA       = B

Todos os sistemas concordam.

Todos podem estar errados.

Por quê?

Porque todos receberam a mesma informação inicial.

Programadores conhecem isso há décadas:

Garbage In, Garbage Out.

Compliance também sofre de GIGO.


⚖️ CAPÍTULO 11 — A TOGA NÃO É SUPERUSER

Chegamos então à magistratura.

Aqui precisamos abandonar personagens específicos e pensar institucionalmente.

O Código de Ética da Magistratura Nacional estabelece princípios como independência, imparcialidade, transparência e integridade. Determina também que o magistrado mantenha distância equivalente das partes e evite comportamento que possa refletir favoritismo.

Isso é praticamente Zero Trust jurídico.

Não significa:

“Desconfie de todo juiz.”

Significa:

Construa mecanismos que não dependam exclusivamente da confiança pessoal.

Aliás, o próprio STF anunciou em fevereiro de 2026 a elaboração de seu Código de Ética específico, mencionando explicitamente prevenção de conflitos de interesse, transparência, responsabilidade e confiança pública.

O CNJ também avançou em 2026 numa proposta específica para identificação, declaração e tratamento de conflitos de interesses, incluindo sistemas eletrônicos de prevenção e estruturas de aconselhamento ético.

Ou seja:

o problema estrutural está sendo reconhecido institucionalmente.


❤️ CAPÍTULO 12 — CONFIANÇA NÃO PODE SER A ÚNICA DEFESA

Alice perguntou:

— Então devemos desconfiar de todo mundo?

O Chapeleiro respondeu:

— Claro que não!

— Mas você acabou de falar de Zero Trust.

— Alice, Zero Trust não significa que todos são desonestos.

Significa que honestidade não substitui controle.

Essa distinção é maravilhosa.

Não colocamos senha porque acreditamos que todos são criminosos.

Não utilizamos RACF porque acreditamos que todos os programadores querem roubar dados.

Não fazemos backup porque esperamos que o storage exploda amanhã.

Controles existem porque sistemas resilientes não dependem de pessoas perfeitas.


🕵️ CAPÍTULO 13 — ENTRE O INTERESSE PÚBLICO E O NOTÍCIAS POPULARES

Nossa conversa passou também por intimidade.

Sexo.

Profissionais do sexo.

Festas.

Luxo.

E aí existe uma armadilha.

Esses elementos são excelentes para manchetes.

Mas podem distrair da verdadeira questão.

A pergunta relevante não deveria ser:

“Com quem determinada autoridade dormiu?”

A pergunta institucional é:

“Um terceiro interessado financiou um benefício privado?”

Se não financiou, a intimidade pode continuar sendo simplesmente intimidade.

Se financiou, aparecem perguntas sobre:

conflito de interesses → vantagem → independência → eventual contrapartida.

O sexo vira quase detalhe contábil.

O dinheiro torna-se interessante.


🔎 CAPÍTULO 14 — FOLLOW THE MONEY NÃO É SUFICIENTE

Todo mundo conhece:

Follow the money.

O Chapeleiro discorda.

— Incompleto!

Ele escreveu:

FOLLOW THE MONEY
FOLLOW THE ACCESS
FOLLOW THE RELATIONSHIP
FOLLOW THE DECISION
FOLLOW THE EXCEPTION

Esse é um modelo muito melhor.

Imagine:

EMPRESA
   |
   +-- pagamento
   |
INTERMEDIÁRIO
   |
   +-- benefício
   |
PESSOA COM PODER
   |
   +-- decisão
   |
RESULTADO

Uma seta isolada pode não significar absolutamente nada.

O grafo completo pode contar uma história.


🧠 CAPÍTULO 15 — O QUE AINDA NÃO DESCOBRIMOS?

Aqui precisamos ter disciplina.

Não podemos afirmar que existem fatos escondidos específicos sem evidência.

Mas podemos perguntar:

Que classes de risco ainda podem estar invisíveis?

Essa é exatamente a função de threat modeling.

Possibilidades genéricas:

relações indiretas não declaradas

beneficiários econômicos difíceis de identificar

presentes e hospitalidade

viagens

intermediários

consultorias

empresas relacionadas

familiares

fundos

associações

institutos

eventos privados

exceções não documentadas

aprovações verbais

conflitos de interesse não percebidos

O objetivo não é presumir culpa.

É construir controles capazes de detectar situações relevantes.


🔴 CAPÍTULO 16 — ENTRA O RED TEAM

Finalmente chegamos ao Red Team.

Muita gente pensa:

Red Team = hacker tentando invadir servidor.

É muito pouco.

Um Red Team maduro pergunta:

Como este sistema pode falhar?

E “sistema” pode significar organização.

Começamos criando adversários hipotéticos.

Cenário 1 — VIP

Uma pessoa poderosa pede exceção.

O funcionário cede?

Cenário 2 — relacionamento

Fornecedor possui amizade com decisor.

O conflito é declarado?

Cenário 3 — benefício

Terceiro oferece viagem ou hospitalidade.

Existe registro?

Cenário 4 — intermediário

O benefício não vem diretamente do interessado.

O sistema identifica relacionamento indireto?

Cenário 5 — pressão hierárquica

Funcionário bloqueia operação irregular.

Ele é protegido ou punido?

Aqui encontramos uma métrica extraordinária.


🛡️ CAPÍTULO 17 — O TESTE DO FUNCIONÁRIO PROTEGIDO

Quer saber se uma organização possui cultura de segurança?

Faça esta pergunta:

O que acontece com o funcionário que corretamente diz NÃO para alguém poderoso?

Se ele recebe apoio:

boa cultura.

Se recebe bronca:

alerta.

Se sofre retaliação:

vulnerabilidade crítica.

Porque segurança depende de pessoas terem permissão organizacional para aplicar segurança.


🧪 CAPÍTULO 18 — RED TEAM DE GOVERNANÇA

Agora montamos nosso exercício.

Sem tentar cometer crimes.

Sem violar privacidade.

Sem burlar controles reais.

Usamos simulações autorizadas.

Passo 1 — Mapear ativos

Dados.

Dinheiro.

Decisões.

Acessos.

Contratos.

Viagens.

Presentes.

Passo 2 — Mapear privilégios

Quem pode aprovar?

Quem pode dispensar?

Quem pode autorizar exceções?

Passo 3 — Mapear relacionamentos

Fornecedores.

Clientes.

Familiares.

Representantes.

Consultores.

Passo 4 — Procurar Shadow Policies

Pergunte aos funcionários:

“O que realmente acontece quando um diretor pede exceção?”

A resposta pode ser completamente diferente do manual.

Passo 5 — Simular pressão

Em ambiente autorizado, teste se procedimentos continuam funcionando quando o solicitante possui status elevado.

Passo 6 — Verificar audit trail

Conseguimos reconstruir tudo posteriormente?

Passo 7 — Corrigir.

Não apenas tecnologia.

Processo + cultura + proteção ao funcionário + transparência.


🔧 CAPÍTULO 19 — COMO MELHORAMOS O SISTEMA?

O Chapeleiro apresentou sua arquitetura.

1. Zero Trust também para VIP

Nenhum cargo concede privilégio implícito.

2. Exceção sempre registrada

Se precisa quebrar regra:

REQUEST
APPROVER
REASON
TIME
RESOURCE
EXPIRATION
AUDIT

3. Four Eyes Principle

Operações sensíveis exigem segunda aprovação independente.

4. Conflict-of-interest by design

Não espere o conflito aparecer.

Crie sistemas para declará-lo antecipadamente.

5. Beneficial ownership

Saiba quem realmente está atrás de empresas e estruturas relevantes quando a legislação permitir e exigir essa verificação.

6. Hospitalidade transparente

Presentes, viagens e benefícios relevantes precisam de regras claras.

7. Proteção contra retaliação

Funcionário que aplica corretamente o controle não pode ser punido por fazê-lo.

8. Auditoria baseada em substância

Não verifique apenas documentos.

Verifique realidade econômica.

9. Analytics

Procure padrões.

Valores.

Recorrência.

Relacionamentos.

Concentração.

Exceções.

10. Red Team periódico

Ataque processos.

Não pessoas.


🤖 CAPÍTULO 20 — IA PODE AJUDAR

Agora entra 2026.

Imagine milhares de:

contratos,

pagamentos,

agendas,

fornecedores,

declarações,

processos,

aprovações.

Humanos não conseguem correlacionar tudo.

IA e graph analytics podem ajudar a encontrar:

PESSOA A
   |
EMPRESA B
   |
FUNDO C
   |
CONSULTORIA D
   |
FAMILIAR E
   |
PROCESSO F

Isso não prova irregularidade.

Produz:

sinal para investigação humana.

Essa distinção é fundamental.

IA não deveria declarar:

CULPADO.

Deveria dizer:

ANOMALIA — INVESTIGAR.


🏛️ CAPÍTULO 21 — TRANSPARÊNCIA É OBSERVABILIDADE INSTITUCIONAL

Programadores conhecem observabilidade.

Metrics.

Logs.

Traces.

Agora aplique isso à governança.

Metrics: quantas exceções existem?

Logs: quem autorizou?

Traces: como o benefício percorreu a organização?

De repente:

OBSERVABILITY

vira:

TRANSPARENCY

O próprio CNJ criou o ONIT para fortalecer integridade, ética, governança e transparência e identificar riscos como corrupção, conflitos de interesse e captura institucional.

A analogia é perfeita:

instituição sem transparência é produção sem logs.

Tudo parece funcionar.

Até ocorrer incidente.


🎩 CAPÍTULO 22 — O ÚLTIMO CHÁ DO CHAPELEIRO

Alice estava cansada.

— Então nunca teremos um sistema perfeito?

O Chapeleiro riu.

— Claro que não!

— Então para que tudo isso?

Ele colocou uma última xícara sobre a mesa.

Nela estava escrito:

RESILIENCE.

Segurança não significa impedir absolutamente todo problema.

Significa:

dificultar → detectar → registrar → responder → aprender → melhorar.

É exatamente aquilo que fazemos no mainframe.


🐒 EPÍLOGO — OS CHIMPANZÉS VOLTARAM

Alice retornou à porta do início.

O homem importante apareceu novamente.

Tentou entrar.

ICH408I
ACCESS DENIED

Olhou para o funcionário.

— Você sabe com quem está falando?

O funcionário respondeu calmamente:

— Sei perfeitamente, senhor.

— Então abra.

— Sua identidade está confirmada. Sua autorização, não.

O homem pegou o telefone.

Nada aconteceu.

Tentou ligar para um diretor.

Nada.

Tentou chamar um amigo.

Nada.

Alice ficou surpresa.

— O que vocês fizeram?

O Chapeleiro apontou para uma placa nova:

EXCEPTION WORKFLOW

REQUEST
   ↓
INDEPENDENT APPROVAL
   ↓
JUSTIFICATION
   ↓
TIME-LIMITED ACCESS
   ↓
LOG
   ↓
REVIEW

Ao lado havia outra:

Nenhum funcionário será punido por aplicar corretamente um controle de segurança.

Alice sorriu.

Os chimpanzés começaram a bater palmas.

O Chapeleiro olhou para o relógio.

03:17.

— Conseguimos fechar todas as portas dos fundos?

Alice perguntou.

Ele colocou o chapéu.

— Não.

— Então fracassamos?

— Pelo contrário.

Pegou a xícara.

— Agora sabemos que devemos continuar procurando.

No terminal 3270 surgiu a última mensagem:

BELLACOSA MAINFRAME

SECURITY IS NOT
A PRODUCT.

SECURITY IS
A SYSTEM OF
PEOPLE,
PROCESSES,
TECHNOLOGY
AND ACCOUNTABILITY.

READY

E em letras menores:

ZERO TRUST:
SAME RULES.
ESPECIALLY FOR
SUPERUSERS.

☕🎩

Porque talvez a maior lição de todas seja esta:

Uma organização não demonstra que possui bons controles quando consegue dizer NÃO para quem não tem poder.

Ela demonstra quando consegue dizer NÃO para quem tem.

E um bom Red Team existe justamente para descobrir se esse NÃO continua funcionando quando chega o próximo Chapeleiro Maluco perguntando por que todo mundo está seguindo regras numa terra onde ele sempre acreditou que as regras eram para os outros.

terça-feira, 15 de setembro de 2026

🕶️ DIABOLIK NO MAINFRAME — Risk Scoring Humano

 

Bellacosa Mainframe e o risk scoring humano

☕ Um Café no Bellacosa Mainframe

🕶️ DIABOLIK NO MAINFRAME — Risk Scoring Humano

Quando o sistema deixa de perguntar “o que você fez?” e começa a perguntar “por que você deixou de se comportar como você mesmo?”

Há uma coisa que Diabolik entende melhor do que muitos sistemas antifraude.

A melhor maneira de atravessar uma porta protegida não é necessariamente arrombá-la.

É fazer com que a porta acredite que você deveria estar entrando por ela.

Máscara correta.

Documento correto.

Horário plausível.

Comportamento esperado.

Uma história suficientemente coerente.

Separadamente, cada detalhe parece normal.

E justamente aí começa nossa história.

Porque, em algum lugar dentro de uma enorme instituição financeira, existe um IBM Mainframe processando milhões de eventos e tentando responder a uma pergunta aparentemente simples:

este comportamento faz sentido para esta pessoa?

Bem-vindo ao Risk Scoring Humano.

E nosso guia será Diabolik.



🕶️ CAPÍTULO 1 — Diabolik não quer parecer Diabolik

Imagine um sistema antifraude bastante primitivo.

Sua lógica poderia ser parecida com:

IF TRANSACTION-AMOUNT > 10000
    MOVE 'HIGH-RISK' TO RISK-LEVEL
END-IF.

Funciona?

Às vezes.

Mas qualquer pessoa que conheça a regra aprende rapidamente que R$ 10.001 chama atenção e R$ 9.999 talvez não.

Esse é o problema das regras determinísticas isoladas.

Diabolik olha para isso e sorri.

Ele não precisa destruir a regra.

Precisa apenas parecer normal para ela.

Um sistema moderno precisa fazer outra pergunta:

R$ 9.999 é normal para quem está fazendo essa operação?

Para uma grande empresa, talvez seja banal.

Para uma conta que recebe R$ 1.800 por mês e nunca movimentou mais de R$ 3.000, pode ser extraordinário.

Portanto:

RISCO ≠ apenas EVENTO

Uma aproximação muito melhor seria:

RISCO =
    EVENTO
  + PESSOA
  + HISTÓRICO
  + CONTEXTO
  + RELACIONAMENTOS
  + TEMPO

É aqui que nasce o Risk Scoring Humano.



🎭 CAPÍTULO 2 — A melhor máscara é uma identidade verdadeira

Sistemas antigos frequentemente tentavam responder:

“Essa pessoa é criminosa?”

Sistemas modernos precisam responder algo mais sutil:

“Esse comportamento combina com essa identidade?”

Essa diferença é gigantesca.

João pode ser um cliente perfeitamente legítimo há quinze anos.

Recebe salário.

Paga supermercado.

Abastece o carro.

Paga escola.

Compra medicamentos.

Viaja uma vez por ano.

Seu comportamento produz uma espécie de impressão digital financeira.

Não precisamos conhecer João pessoalmente para perceber padrões.

JOÃO
│
├── salário mensal
├── supermercado
├── combustível
├── contas domésticas
├── escola
├── financiamento
└── viagens ocasionais

Nenhuma dessas informações isoladamente define João.

Mas juntas produzem seu baseline comportamental.

Agora imagine que alguma coisa muda.

Em uma semana:

JOÃO
│
├── recebe 8 transferências incomuns
├── acessa de novo dispositivo
├── muda telefone
├── realiza operação internacional
├── adiciona beneficiário
└── transfere praticamente todo o saldo

Talvez cada evento seja legítimo.

O problema é a combinação.

Diabolik conseguiu uma identidade verdadeira.

Mas ainda precisa aprender a ser João.



📸 CAPÍTULO 3 — O velho sistema guardava fotografias

Durante décadas, instituições trabalharam muito bem com fotografias cadastrais.

NOME
CPF
ENDEREÇO
RENDA
PROFISSÃO
IDADE
TELEFONE

É uma fotografia.

Ela responde:

Quem é Vagner?

Mas Risk Scoring moderno quer assistir ao filme.

08:03 login
08:04 consulta saldo
08:06 novo favorecido
08:07 alteração cadastral
08:11 transferência
08:13 segunda transferência
08:17 tentativa internacional

Agora temos comportamento.

E comportamento possui uma propriedade fascinante:

ele possui sequência.

Isso significa que:

A + B + C

pode ter significado completamente diferente de:

C + A + B

Exemplo:

troca telefone
→ cadastra dispositivo
→ transfere dinheiro

é diferente de:

transfere dinheiro
→ meses depois troca telefone

Os eventos são semelhantes.

A narrativa é diferente.



🎬 CAPÍTULO 4 — Risk Scoring transforma fotografia em filme

Vamos imaginar um cliente chamado Marco.

Durante 36 meses:

salário → conta
conta → despesas
conta → cartão
conta → investimento

Tudo relativamente previsível.

Então:

DIA 1
novo dispositivo

DIA 2
novo telefone

DIA 3
novo favorecido

DIA 3 + 4 minutos
transferência

DIA 3 + 7 minutos
segunda transferência

Um sistema baseado exclusivamente em valores pode não encontrar nada.

O Risk Engine comportamental observa:

DEVICE_RISK        +15
PROFILE_CHANGE     +10
NEW_BENEFICIARY    +20
VALUE_DEVIATION    +25
VELOCITY           +20
--------------------------------
RISK SCORE          90

Mas atenção.

Isso é apenas um exemplo didático.

Na vida real, scores podem ser produzidos por regras, modelos estatísticos, machine learning, modelos híbridos e sistemas especializados.

O conceito importante é:

sinais pequenos acumulam contexto.



🧮 CAPÍTULO 5 — O Risk Score entra em cena

Vamos criar nosso fictício:

BELLACOSA HUMAN RISK ENGINE — BHRE

Ele recebe eventos:

LOGIN
TRANSACTION
PROFILE_CHANGE
DEVICE_CHANGE
PASSWORD_RESET
BENEFICIARY_ADD
CARD_PURCHASE
PIX
TED
TRANSFER
ATM

Cada evento entra no motor.

No Mainframe poderíamos imaginar componentes como:

CICS
  ↓
COBOL
  ↓
Db2 / VSAM
  ↓
Risk Engine
  ↓
Decision

Para transações financeiras modernas, também poderíamos integrar APIs, mensageria e plataformas analíticas externas.

O mainframe não precisa fazer sozinho toda a ciência de dados.

Ele pode ser justamente o coração transacional que pergunta:

“Posso autorizar?”

E recebe:

APPROVE
REVIEW
CHALLENGE
DECLINE

💳 CAPÍTULO 6 — 200 OK não significa “é confiável”

Imagine:

CLIENTE
   ↓
APP
   ↓
API
   ↓
BANK
   ↓
MAINFRAME

A autenticação está correta.

Token correto.

Senha correta.

Dispositivo reconhecido.

Isso demonstra que determinadas credenciais foram aceitas.

Não demonstra necessariamente que a intenção seja legítima.

Essa distinção é fundamental:

AUTHENTICATION
      ≠
AUTHORIZATION
      ≠
TRUST

Diabolik adora quando confundimos essas três coisas.

Ele não precisa falsificar necessariamente tudo.

Talvez tenha acesso legítimo a uma credencial comprometida.

O sistema precisa analisar contexto.


🧠 CAPÍTULO 7 — Risk Scoring não deveria perguntar apenas “quem é você?”

Perguntas melhores:

Quem é você?

De onde costuma acessar?

Quando costuma acessar?

Quanto costuma movimentar?

Para quem costuma transferir?

Quais dispositivos utiliza?

Qual é sua velocidade normal de operações?

Que relacionamento possui com o destinatário?

Esse comportamento já aconteceu anteriormente?

Isso produz uma identidade dinâmica.

Chamaremos de:

Behavioral Identity.

Não é simplesmente CPF.

É uma combinação histórica de comportamentos.


🕸️ CAPÍTULO 8 — E então descobrimos o grafo

Diabolik consegue imitar Marco.

Excelente.

Mas existe um problema.

Ele precisa mandar o dinheiro para algum lugar.

Surge Maria.

MARCO → MARIA

Nada necessariamente estranho.

Mas Maria recebe também de:

JOÃO ──┐
PEDRO ─┤
ANA ───┼──→ MARIA
LUÍS ──┤
MARCO ─┘

Interessante.

Maria envia para Empresa X.

MARIA → EMPRESA X

Empresa X está relacionada a outras entidades.

Agora nossa análise deixa de olhar somente para transações.

Estamos construindo um:

GRAPH.


🕷️ CAPÍTULO 9 — O grafo destrói algumas máscaras

Uma pessoa pode alterar:

nome utilizado,

telefone,

conta,

empresa,

dispositivo,

endereço.

Mas relacionamentos podem revelar padrões.

Imagine:

PESSOA A
   │
   ├── telefone → PESSOA B
   │
   ├── endereço → EMPRESA C
   │
   ├── dispositivo → CONTA D
   │
   └── transferência → PESSOA E

Cada aresta adiciona contexto.

Agora descobrimos:

PESSOA E
   ↓
EMPRESA F
   ↓
CONTA G
   ↓
PESSOA B

Fechamos um ciclo.

É por isso que Graph Analytics é tão poderoso em fraude e AML.

Ele não pergunta apenas:

Quem recebeu dinheiro?

Pergunta:

Como essas entidades estão relacionadas?


🧩 CAPÍTULO 10 — Risk Scoring humano não significa julgar pessoas

Aqui existe uma distinção ética essencial.

Um sistema não deveria concluir:

“Essa pessoa é criminosa.”

Risk Scoring deve trabalhar com algo muito mais limitado:

“Esta operação apresenta características que justificam controles adicionais.”

Essa diferença protege clientes e instituição.

Score não deveria ser sentença.

Deveria ser sinal.

Por isso podemos ter:

LOW RISK
   ↓
PROCESS

MEDIUM RISK
   ↓
ADDITIONAL AUTHENTICATION

HIGH RISK
   ↓
MANUAL REVIEW

CRITICAL
   ↓
BLOCK / INVESTIGATION

Dependendo da política, legislação e natureza da operação.


🔎 CAPÍTULO 11 — O caso Gritzbach mostra outro tipo de Risk Scoring

Aqui podemos utilizar o caso apenas como analogia analítica, sem transformar acusações ainda controvertidas em fatos.

Segundo a reconstrução jornalística, Antônio Vinícius Lopes Gritzbach teria atravessado simultaneamente diferentes redes de relacionamento envolvendo integrantes do PCC, negócios, dinheiro, criptomoedas, autoridades e policiais. Ele posteriormente tornou-se colaborador do Ministério Público.

A questão interessante para nosso estudo não é tentar reproduzir qualquer “score do PCC”.

É observar algo universal:

pessoas também existem dentro de grafos de confiança.

Imagine abstratamente:

PESSOA
│
├── dinheiro
├── parceiros
├── clientes
├── fornecedores
├── instituições
├── autoridades
└── informações

Quando uma relação muda, outras podem ser afetadas.


⚖️ CAPÍTULO 12 — Trust Score é contextual

Essa é uma descoberta importantíssima.

Uma pessoa não possui universalmente:

TRUST = 72

Ela pode ser simultaneamente:

Banco A       → LOW RISK
Banco B       → UNKNOWN
Empresa C     → TRUSTED
Sistema D     → HIGH RISK

Porque risco depende de contexto.

O mesmo vale para comportamento.

Comprar R$ 8.000 em um restaurante pode ser extraordinário para mim.

Para uma empresa realizando jantar corporativo para 80 pessoas, talvez seja normal.

Portanto:

RISK = EVENT / CONTEXT

e não simplesmente:

RISK = EVENT

🧠 CAPÍTULO 13 — O programador COBOL precisa entender isso

Aqui chegamos ao ponto que frequentemente falta nas formações Mainframe.

O iniciante recebe:

01 WS-RISK-SCORE PIC 9(03).

E pensa:

É um campo numérico de três posições.

Não.

Talvez você esteja olhando para a conclusão de centenas de sinais.

Por trás daqueles três bytes conceituais podem existir:

histórico
perfil
device
geolocalização aproximada
velocity
valor
merchant
beneficiário
produto
canal
horário
relacionamentos
alertas anteriores

O programador Mainframe precisa compreender semântica de negócio, não somente PIC clauses.


💻 CAPÍTULO 14 — Vamos programar um pequeno exemplo

Imagine:

01 WS-RISK-SCORE       PIC 9(03) VALUE ZERO.
01 WS-NEW-DEVICE       PIC X.
01 WS-NEW-BENEFICIARY  PIC X.
01 WS-HIGH-AMOUNT      PIC X.
01 WS-PROFILE-CHANGE   PIC X.

Então:

IF WS-NEW-DEVICE = 'Y'
   ADD 15 TO WS-RISK-SCORE
END-IF

IF WS-NEW-BENEFICIARY = 'Y'
   ADD 20 TO WS-RISK-SCORE
END-IF

IF WS-HIGH-AMOUNT = 'Y'
   ADD 25 TO WS-RISK-SCORE
END-IF

IF WS-PROFILE-CHANGE = 'Y'
   ADD 10 TO WS-RISK-SCORE
END-IF.

Depois:

EVALUATE TRUE
   WHEN WS-RISK-SCORE >= 70
        MOVE 'REVIEW' TO WS-DECISION

   WHEN WS-RISK-SCORE >= 40
        MOVE 'CHALLENGE' TO WS-DECISION

   WHEN OTHER
        MOVE 'APPROVE' TO WS-DECISION
END-EVALUATE.

Didaticamente funciona.

Mas Diabolik imediatamente descobriria um problema.


😈 CAPÍTULO 15 — Diabolik aprende nossas regras

Se:

70 = REVIEW

ele tentará permanecer em:

69

Esse fenômeno é fundamental em sistemas antifraude.

Quando atacantes compreendem controles, adaptam comportamento.

Por isso sistemas precisam evoluir.

Podemos combinar:

RULES
+
STATISTICS
+
BEHAVIOR
+
MACHINE LEARNING
+
GRAPH ANALYTICS
+
HUMAN REVIEW

Nenhum componente precisa ser mágico.

O poder está na combinação.


⏱️ CAPÍTULO 16 — Velocity: Diabolik tem pressa

Um conceito maravilhoso para ensinar ao programador COBOL iniciante é velocity.

Imagine:

09:00 R$ 800
09:03 R$ 900
09:05 R$ 700
09:07 R$ 950
09:09 R$ 850

Nenhuma transação ultrapassa R$ 1.000.

Uma regra:

IF AMOUNT > 10000

não detecta nada.

Mas:

5 TRANSFERS
IN 9 MINUTES

é outro sinal.

Risk Scoring precisa compreender também:

quanto aconteceu em quanto tempo.


🕰️ CAPÍTULO 17 — O tempo transforma o grafo

Agora acrescentamos timestamps:

09:00 A → B
09:02 B → C
09:04 C → D
09:07 D → E

Temos um fluxo.

O grafo agora não mostra apenas:

A — B — C — D — E

Mostra movimento.

Chamamos conceitualmente isso de:

Temporal Graph.

Ele pode revelar mudanças que um grafo estático esconderia.


🏦 CAPÍTULO 18 — E onde entra o IBM Mainframe?

No lugar mais interessante possível.

No coração das operações.

Imagine uma arquitetura:

                 MOBILE
                    │
                 INTERNET
                    │
                    ▼
                 API LAYER
                    │
              z/OS Connect
                    │
                    ▼
┌─────────────────────────────────┐
│            IBM Z                │
│                                 │
│   CICS                          │
│     │                           │
│     ▼                           │
│   COBOL ───────► Db2            │
│     │                           │
│     ▼                           │
│   RISK REQUEST                  │
│     │                           │
└─────┼───────────────────────────┘
      │
      ▼
 ANALYTICS / GRAPH / ML
      │
      ▼
 RISK SCORE
      │
      ▼
 IBM Z
      │
      ▼
DECISION

E isso é importante:

modernização não significa necessariamente retirar o COBOL.

Pode significar permitir que COBOL converse com tecnologias especializadas.


⚡ CAPÍTULO 19 — Porque autorização não pode tomar café

Imagine cartão.

Cliente encosta na máquina.

TAP
 ↓
ACQUIRER
 ↓
NETWORK
 ↓
ISSUER
 ↓
AUTHORIZATION

O cliente está olhando para o terminal.

Não podemos dizer:

“Aguarde vinte minutos enquanto nosso algoritmo termina.”

A decisão precisa ocorrer rapidamente.

É exatamente aí que sistemas transacionais de alta disponibilidade continuam extremamente relevantes.

Risk Scoring precisa entrar no fluxo sem destruir SLA.


🔐 CAPÍTULO 20 — False Positive: quando prendemos o mordomo

Existe outro perigo.

Se o sistema ficar paranoico:

QUALQUER COISA DIFERENTE
        ↓
      BLOCK

teremos milhares de clientes legítimos irritados.

Chamamos isso de:

false positive.

O cliente viajou para Roma.

Compra jantar.

Sistema:

FRAUDE!

Cliente:

Estou com fome!

😄

Risk Scoring precisa equilibrar:

FRAUD LOSS
     ↕
CUSTOMER FRICTION

Bloquear tudo é fácil.

Autorizar corretamente é difícil.


🎯 CAPÍTULO 21 — Risk Score não é prova

Isso merece ficar gravado no monitor do programador:

RISK SCORE ≠ GUILT

Score 92 não significa:

“92% criminoso.”

Pode significar apenas que um modelo específico identificou uma combinação de sinais considerada de alto risco segundo sua própria calibração.

A interpretação depende do modelo.

Esse cuidado torna-se ainda mais importante quando falamos em Risk Scoring Humano.

Algoritmos podem produzir vieses.

Dados podem estar errados.

Cadastros podem estar desatualizados.

Relacionamentos podem ser coincidências.

Por isso decisões de grande impacto precisam de governança adequada.


🧪 CAPÍTULO 22 — Explainability: por que deu 92?

Imagine o analista recebendo:

RISK SCORE = 92

Ele pergunta:

Por quê?

Sistema:

Porque sim.

Inaceitável.

Precisamos de reason codes.

R01 NEW DEVICE
R07 NEW BENEFICIARY
R13 UNUSUAL AMOUNT
R22 HIGH VELOCITY
R31 GRAPH RELATION

Então:

SCORE 92

REASONS:
HIGH VELOCITY
NEW DEVICE
NEW BENEFICIARY
BEHAVIOR DEVIATION

Agora existe explicabilidade operacional.

E o COBOL pode desempenhar papel importantíssimo na integração desses reason codes ao fluxo transacional.


🗃️ CAPÍTULO 23 — Não jogue fora os dados antigos!

Aqui existe uma vantagem maravilhosa dos ambientes Mainframe.

Histórico.

Décadas de histórico podem existir.

Isso é ouro para análise comportamental — desde que seja utilizado com governança, finalidade legítima, qualidade e respeito às regras de proteção de dados.

Porque comportamento exige comparação:

HOJE
versus
ONTEM
versus
30 DIAS
versus
1 ANO

Um sistema que conhece apenas hoje não conhece comportamento.

Conhece eventos.


🕵️ CAPÍTULO 24 — Diabolik finalmente comete seu erro

Nosso Diabolik conseguiu:

credencial,

identidade,

dispositivo,

horário plausível,

valor plausível.

Ele parece perfeito.

Mas precisa transferir recursos.

O sistema observa:

DIABOLIK-AS-MARCO
        ↓
     CONTA X
        ↓
     CONTA Y
        ↓
     EMPRESA Z

E o Graph Engine percebe:

EMPRESA Z
   ↑
CONTA Q
   ↑
CASO ANTERIOR

A transação não era necessariamente anormal.

O relacionamento era.

E finalmente encontramos aquilo que Diabolik não conseguiu falsificar perfeitamente:

o contexto.


🧠 CAPÍTULO 25 — A verdadeira evolução do antifraude

Primeira geração:

TRANSACTION RULES

Segunda:

TRANSACTION + PROFILE

Terceira:

TRANSACTION + PROFILE + BEHAVIOR

Quarta:

TRANSACTION
+
PROFILE
+
BEHAVIOR
+
DEVICE
+
NETWORK
+
GRAPH
+
TIME

E então entramos no território que chamo aqui de:

HUMAN RISK SCORING

Não porque estejamos julgando o ser humano.

Mas porque estamos tentando compreender o comportamento dentro de seu contexto humano e relacional.


🧑‍💻 CAPÍTULO 26 — O que o COBOLista iniciante deve aprender

Quando encontrar:

IF RISK-SCORE > 80

não continue lendo imediatamente.

Pergunte:

Quem calculou esse score?

Quais eventos participaram?

Qual janela temporal?

O score expira?

É transacional ou cadastral?

Quais reason codes existem?

O que acontece quando o serviço de risco está indisponível?

Essa última pergunta é especialmente Mainframe.

RISK ENGINE DOWN

E agora?

FAIL OPEN?

Autoriza?

FAIL CLOSED?

Recusa?

FALLBACK RULES?

Usa regras locais?

Essa decisão pode valer milhões.


🚨 CAPÍTULO 27 — 03:17

Nosso easter egg Bellacosa aparece.

03:17 da manhã.

O telefone toca.

War Room.

Fraud Decision Service latency: 4.8 seconds
Authorization queue increasing
Timeout rate: 17%

Alguém diz:

“Vamos bypassar o Risk Engine.”

Silêncio.

Porque isso resolveria performance.

Mas poderia abrir a porta.

Outro propõe:

“Vamos bloquear tudo.”

Também resolveria fraude.

E destruiria o negócio.

O verdadeiro engenheiro Mainframe pergunta:

Qual é o fallback aprovado?

Essa frase separa improvisação de engenharia.


☕ CAPÍTULO 28 — A lição de Diabolik

Durante toda a história procurávamos o homem de máscara preta.

Esse era nosso erro.

Diabolik nunca quis que víssemos a máscara.

Queria que víssemos:

CLIENTE NORMAL

Risk Scoring evoluiu justamente porque fraude sofisticada não precisa parecer fraude.

Pode parecer:

uma compra,

uma transferência,

um login,

uma empresa,

uma conta,

um cliente.

Tudo aparentemente legítimo.

Até observarmos:

QUEM
+
O QUÊ
+
QUANDO
+
ONDE
+
COMO
+
COM QUEM
+
QUANTAS VEZES
+
EM QUE SEQUÊNCIA

Então surge uma história.


🕶️ EPÍLOGO — O Mainframe não procura criminosos

Essa talvez seja a mensagem mais importante para o programador iniciante.

O IBM Mainframe não deveria funcionar como juiz.

O Risk Engine também não.

Eles processam sinais.

EVENT
   ↓
CONTEXT
   ↓
HISTORY
   ↓
RELATIONSHIP
   ↓
RISK
   ↓
DECISION
   ↓
EVIDENCE

E boas arquiteturas mantêm algo fundamental:

rastreabilidade.

Precisamos saber:

qual informação entrou,

qual regra executou,

qual modelo respondeu,

qual score retornou,

qual reason code apareceu,

qual decisão foi tomada,

quando aconteceu

e qual versão estava em produção.

Porque um dia alguém perguntará:

“Por que essa transação foi recusada?”

E PORQUE WS-RISK > 80 não será resposta suficiente.

Diabolik talvez consiga enganar uma regra.

Talvez consiga enganar uma câmera.

Talvez consiga uma identidade perfeita.

Talvez consiga inclusive parecer estatisticamente normal durante algum tempo.

Mas quanto mais dimensões independentes um sistema correlaciona — histórico, comportamento, dispositivo, velocidade, relacionamentos e tempo — mais difícil se torna sustentar uma identidade artificial coerente.

Essa é a batalha moderna.

Não é:

COBOL contra inteligência artificial.

É:

COBOL
+
CICS
+
Db2
+
APIs
+
EVENTS
+
RULES
+
ML
+
GRAPH ANALYTICS
+
HUMAN ANALYST

Cada tecnologia fazendo aquilo que sabe fazer melhor.

E no centro de tudo continua existindo aquela pergunta simples que começou nossa investigação:

“Isto é normal?”

Diabolik ajusta a gravata, olha para o terminal e sorri.

O terminal responde:

TRANSACTION........... VALID
IDENTITY.............. VALID
AUTHENTICATION........ VALID
AMOUNT................ NORMAL

BEHAVIOR.............. UNUSUAL
VELOCITY.............. UNUSUAL
GRAPH RELATION........ HIGH RISK

RISK SCORE............ 92
DECISION.............. REVIEW

Pela primeira vez, Diabolik para de sorrir.

O sistema não descobriu necessariamente quem ele é.

Descobriu algo muito mais interessante.

Ele não está se comportando como a pessoa que afirma ser.

☕ Um Café no Bellacosa Mainframe

Onde até Diabolik descobre que enganar um IF é fácil. Difícil é enganar quarenta anos de histórico.



Para ir mais longe

https://eljefemidnightlunch.blogspot.com/2024/10/diabolik-no-mainframe-o-roubo-perfeito.html

quarta-feira, 9 de setembro de 2026

🕵️‍♂️ O Supermosaico — Segurança da Informação sob a Tutela do Dr. Moriarty

 

Bellacosa Mainframe e o mosaico da segurança os riscos ocultos na ia

☕ Um Café no Bellacosa Mainframe

🕵️‍♂️ O Supermosaico — Segurança da Informação sob a Tutela do Dr. Moriarty

Quando nossos prompts começaram a guardar aquilo que nossa memória deveria esquecer

Imagine uma grande empresa.

Na porta existem seguranças.

Nos computadores, EDR.

Na rede, firewalls.

Nos acessos, MFA.

No mainframe, RACF.

Nos datasets, permissões.

Nos repositórios, controles.

Nos notebooks, DLP.

Nos servidores, logs.

No SOC, dezenas de telas piscando.

Tudo parece protegido.

Então o Dr. Moriarty entra em nossa sala, observa silenciosamente durante alguns minutos e faz uma pergunta desagradavelmente simples:

“Muito interessante. Mas onde seus funcionários conversam quando precisam pensar?”

Silêncio.

Bem-vindo à segurança da informação na era da Inteligência Artificial.



☕ Sob a tutela do Dr. Moriarty

Nossa história começou com uma questão aparentemente simples: profissionais utilizando Inteligência Artificial generativa para trabalhar.

Um advogado coloca partes de um processo em um prompt.

Um programador pergunta sobre um erro COBOL.

Um analista cola algumas mensagens de um dump.

Um DBA tenta entender determinada query.

Um especialista CICS pergunta sobre uma transação problemática.

Um consultor solicita ajuda para documentar uma arquitetura.

Nada disso precisa nascer de má-fé.



Pelo contrário.

O objetivo normalmente é trabalhar melhor.

Esse é justamente o ponto inquietante.

O artigo que motivou esta reflexão chama atenção para o fato de que informações de terceiros podem ser transferidas para sistemas externos durante o uso aparentemente cotidiano de IA e utiliza como exemplo conhecido os incidentes de 2023 envolvendo funcionários da Samsung e informações corporativas inseridas no ChatGPT.

A discussão original concentra-se principalmente em advocacia, sigilo profissional, proteção de dados e governança.

Mas vamos colocar nossa xícara de café sobre a mesa e levar o problema para dentro de uma instalação mainframe.

Moriarty está esperando.



🧩 A primeira tessela

Imagine um jovem programador COBOL.

Ele recebe:

ABEND S0C7

Abre sua ferramenta favorita de IA e pergunta:

Tenho um programa COBOL apresentando S0C7.

O erro acontece nesta rotina.

Pode me ajudar?

Perfeitamente razoável.

A IA pede contexto.

Nosso programador fornece algumas linhas.

Depois mais algumas.

Aparece o nome de um programa.

Depois uma tabela.

Uma transação.

Uma mensagem CICS.

Nada parece particularmente importante.

Temos nossa primeira tessela.

Uma pequena pedra quadrangular daqueles magníficos mosaicos romanos.

Sozinha, ela significa quase nada.



🏛️ O mosaico romano

Na semana seguinte:

TRANID = ABC1

Outra tessela.

Meses depois:

PROGRAM = PAY001

Outra.

Mais tarde:

PAY001 atualiza DB2 antes do MQPUT.

Outra.

Em dezembro:

A fila PAYMENT.REQUEST cresce
durante o fechamento mensal.

Outra.

No ano seguinte:

ABC1 chama PAY001.

Agora coloque as pedras juntas:

ABC1
 │
 ▼
PAY001
 │
 ├────► DB2
 │
 ▼
MQPUT
 │
 ▼
PAYMENT.REQUEST

Curioso.

Nenhum prompt individual descreveu necessariamente toda a arquitetura.

Mas a arquitetura começa a aparecer pela correlação.

Essa é nossa primeira grande lição sob a tutela de Moriarty:

Informações aparentemente insignificantes podem adquirir enorme valor quando possuem relacionamentos.


🧠 O analista começa a documentar a empresa sem perceber

Passemos três anos.

Nosso programador virou analista.

Ele utilizou IA milhares de vezes.

Perguntou sobre:

  • COBOL;

  • JCL;

  • CICS;

  • Db2;

  • MQ;

  • VSAM;

  • RACF;

  • APIs;

  • incidentes;

  • dumps;

  • arquitetura;

  • regras de negócio;

  • migrações;

  • problemas de produção.

Mas existe uma característica interessante.

Normalmente perguntamos à IA justamente sobre aquilo que não entendemos.

Consequentemente, nosso histórico pode acabar concentrando momentos excepcionais:

ERRO
 ↓
DÚVIDA
 ↓
PROMPT

INCIDENTE
 ↓
DÚVIDA
 ↓
PROMPT

ARQUITETURA ESTRANHA
 ↓
DÚVIDA
 ↓
PROMPT

EXCEÇÃO DE NEGÓCIO
 ↓
DÚVIDA
 ↓
PROMPT

O histórico não é necessariamente uma amostra aleatória do ambiente.

Pode ser uma coleção justamente das coisas estranhas, difíceis ou importantes.

Quase um diário operacional involuntário.


📖 “Querido diário, produção caiu novamente...”

Imagine encontrar uma conversa antiga:

“Por que essa rotina precisa executar antes das 22 horas?”

Outra:

“Por que não podemos alterar esse campo?”

Outra:

“Esse programa existe desde a aquisição da empresa XPTO.”

Outra:

“Quando o sistema secundário está indisponível usamos esta contingência.”

Perceba que estamos gradualmente deixando de falar somente de código.

Estamos falando de:

contexto.

E contexto frequentemente vale mais do que código.

Um programa COBOL pode dizer:

IF WS-STATUS = '99'
    PERFORM 9000-CONTINGENCIA
END-IF.

Mas talvez não explique por que 99 existe.

O veterano explica:

“Isso foi criado depois daquele problema de 2008 porque o sistema externo ficava indisponível no fechamento.”

Pronto.

Temos história.

Temos arquitetura.

Temos dependência.

Temos regra operacional.

Temos conhecimento institucional.


🧓 O veterano pode ser mais interessante que o administrador

Aqui Moriarty levanta a sobrancelha.

Tradicionalmente pensamos:

“Quem possui maior privilégio?”

Administrador.

RACF SPECIAL.

DBA.

SYSADM.

ROOT.

Mas existe outra espécie de privilégio:

Knowledge Privilege.

Talvez aquele veterano não possua RACF SPECIAL.

Entretanto ele sabe:

por que X depende de Y;

quem resolve determinado incidente;

qual sistema não pode parar;

qual processo possui contingência;

quais componentes são antigos;

onde existem dependências históricas;

por que determinada decisão foi tomada;

quais problemas aparecem no fechamento.

O usuário privilegiado possui Access Privilege.

O veterano possui Knowledge Privilege.

Em alguns cenários de ameaça, precisamos proteger ambos.


🕰️ Janeiro de 2023

Agora chegamos a uma coisa extraordinária.

O ser humano esquece.

Imagine que nosso especialista tenha resolvido um incidente em janeiro de 2023.

Em setembro de 2026 alguém pergunta:

“Você lembra daquele problema?”

Provavelmente:

“Mais ou menos...”

Depois:

“Não lembro exatamente.”

Isso sempre foi uma espécie de deterioração natural da informação.

Mas imagine que naquele janeiro ele tenha escrito uma longa conversa com uma IA.

Dependendo do serviço, das configurações e das políticas de retenção, aquela conversa poderá ter permanecido armazenada.

Então temos:

MEMÓRIA HUMANA

evento
  ↓
tempo
  ↓
degradação
  ↓
abstração
  ↓
esquecimento

contra:

REGISTRO DIGITAL

evento
  ↓
texto
  ↓
armazenamento
  ↓
pesquisa
  ↓
recuperação

Aquilo que o cérebro deveria esquecer pode permanecer registrado.

Chamemos isso de:

Knowledge Residue

Resíduo de conhecimento.


🚪 O funcionário desligado

Agora Moriarty apresenta outro personagem.

Durante três anos nosso funcionário trabalhou normalmente.

Não roubou nada.

Não planejou fraude.

Não tentou prejudicar ninguém.

Então foi demitido.

Ficou ressentido.

No modelo tradicional de insider threat, talvez esperássemos observar:

download enorme;
cópia para USB;
upload suspeito;
e-mail externo;
ZIP com sources;
impressões anormais.

Mas surge uma possibilidade diferente.

E se informações inadequadamente compartilhadas já estivessem acumuladas em ambientes externos antes de aparecer a intenção maliciosa?

O problema fundamental torna-se:

o momento da aquisição da informação pode estar separado por anos do momento em que aparece a intenção de abusar dela.

No desligamento fazemos:

REVOKE RACF
REMOVE VPN
DISABLE EMAIL
DISABLE GITHUB
RETURN NOTEBOOK
RETURN BADGE
REVOKE CERTIFICATES

Excelente.

Mas Moriarty pergunta:

“E a memória digital externalizada anteriormente?”

É uma pergunta de governança, não uma justificativa para investigar indiscriminadamente contas pessoais de ex-funcionários.

A resposta precisa começar antes, com ferramentas corporativas apropriadas, separação de identidades, classificação, políticas de retenção e regras claras sobre aquilo que pode ser fornecido a sistemas de IA.


🎒 Chega o consultor

Moriarty sorri.

O funcionário conhece uma empresa.

O consultor conhece muitas.

Imagine:

2023 → Banco A
2024 → Seguradora B
2024 → Varejista C
2025 → Governo D
2025 → Montadora E
2026 → Banco F

Em cada organização ele aprende.

Essa transferência de experiência é perfeitamente normal.

Aliás, contratamos consultores justamente porque podem dizer:

“Já encontrei um problema semelhante.”

Existe, entretanto, diferença enorme entre carregar experiência profissional e carregar artefatos detalhados de conhecimento de clientes anteriores.

Historicamente, o cérebro fornecia uma abstração interessante:

experiência específica
       ↓
      tempo
       ↓
   esquecimento
       ↓
   abstração
       ↓
 conhecimento geral

O consultor esquecia nomes, valores, incidentes e detalhes.

Mas permanecia sabendo:

“Esse tipo de arquitetura costuma apresentar este problema.”

Excelente.

Isso é experiência.

Agora imaginemos uma conta pessoal ou ambiente inadequadamente segregado contendo conversas detalhadas provenientes de sucessivos projetos.

Temos potencialmente:

CLIENTE A ─┐
CLIENTE B ─┤
CLIENTE C ─┤
CLIENTE D ─┼──► CORPUS
CLIENTE E ─┤
CLIENTE F ─┘

Nasce nosso:

SUPERMOSAICO.


🌎 O Supermosaico

O mosaico permite reconstruir aspectos de uma empresa.

O Supermosaico acrescenta algo diferente:

comparação.

Cliente A faz X.

Cliente B utiliza X + Y.

Cliente C abandonou X depois de determinado problema.

Cliente D acrescentou Z.

Nenhuma dessas informações isoladamente precisa declarar:

“A possui uma deficiência.”

Mas a comparação pode produzir uma hipótese:

“Por que A aparentemente não possui Y ou Z?”

Nasceu informação que não estava explicitamente escrita.

Temos:

INFORMAÇÃO A
+
INFORMAÇÃO B
+
INFORMAÇÃO C
+
CONTEXTO
+
CORRELAÇÃO
=
INFORMAÇÃO DERIVADA

Esse é um dos pontos mais importantes desta história.

Precisamos proteger não somente informações sensíveis individualmente, mas pensar também em informações correlacionáveis.


🕵️ Moriarty finalmente começa sua aula

Até aqui Moriarty permaneceu sentado.

Agora ele se levanta.

Ele não pergunta:

“Onde está SECRET.DOC?”

Pergunta:

“O que posso inferir?”

Essa é uma mudança monumental.

O invasor caricatural procura:

PASSWORD.TXT

Moriarty procura:

relações;
padrões;
cronologia;
contradições;
dependências;
mudanças;
exceções;
incertezas.

Porque informação de inteligência não precisa estar escrita diretamente.

Ela pode surgir da combinação.


📧 Gmail, Drive, GitHub, WhatsApp, Telegram, celular...

Nossa identidade digital moderna está espalhada.

Temos:

e-mail pessoal
e-mail corporativo
GitHub
Google Drive
OneDrive
celular
notebook
micro pessoal
WhatsApp
Telegram
calendário
redes sociais
conta de IA

Antigamente imaginávamos segurança como uma muralha:

        FIREWALL
████████████████████████
       EMPRESA

Hoje precisamos imaginá-la como um grafo:

          PESSOA
        /   |    \
       /    |     \
   Gmail  GitHub  IA
     |      |      |
   Drive   código contexto
     \      |      /
       \    |     /
         CELULAR
            |
        IDENTIDADE
            |
         EMPRESA

Moriarty não precisa necessariamente perguntar:

“Como atravesso a muralha?”

Ele pode perguntar:

“Quais relações chegam até ela?”

Essa é uma excelente maneira defensiva de fazer threat modeling.


🏰 Primeiro o sentinela

Imagine um castelo.

Atacar diretamente o rei é difícil.

Então nosso Moriarty hipotético observa:

SENTINELA
    ↓
CAPITÃO
    ↓
OFICIAL
    ↓
CONSELHEIRO
    ↓
CASTELO

No mundo corporativo:

JÚNIOR
  ↓
N2
  ↓
N3
  ↓
SME
  ↓
ARQUITETO

Isso não significa que essa sequência permita comprometimento automático.

Não permite.

Mas mostra algo importante:

confiança também possui topologia.

Um funcionário confia em outro.

Uma identidade possui recuperação ligada a outra.

Um dispositivo possui sessões.

Um serviço contém referências a outros serviços.

Um calendário revela relacionamentos.

Um repositório revela tecnologias.

Precisamos analisar o blast radius de identidades, não somente permissões técnicas.


🔐 RACF emocional

Aqui nosso jovem COBOL finalmente entende Moriarty.

No RACF temos algo parecido com:

USER
 ↓
GROUP
 ↓
CONNECT
 ↓
PERMIT
 ↓
RESOURCE

Uma identidade isolada diz pouco.

Os relacionamentos dizem muito.

Agora aplique a mesma ideia à pessoa:

PESSOA
 ↓
IDENTIDADES
 ↓
DISPOSITIVOS
 ↓
SERVIÇOS
 ↓
SESSÕES
 ↓
DADOS
 ↓
RELACIONAMENTOS
 ↓
CONFIANÇA

Voilà!

Temos uma espécie de:

RACF da vida digital.

Só que muito menos organizado.


📦 Contrabando de conhecimento

Agora chegamos a outro conceito surgido durante nossa investigação.

Empresas procuram eventos grandes:

40 MB enviados por e-mail → ALERTA

ZIP com sources → ALERTA

USB → ALERTA

FTP → ALERTA

GitHub público → ALERTA

Enquanto isso:

prompt 001 → 2 KB
prompt 002 → 4 KB
prompt 003 → 1 KB
...
prompt 847 → 6 KB

Tudo pequeno.

Tudo aparentemente cotidiano.

Mas estamos confundindo:

volume físico

com

volume semântico.

Um especialista pode condensar vinte anos de experiência em três parágrafos.

Talvez sejam apenas 5 KB.

Semanticamente podem valer muito.

Por isso “contrabando de conhecimento” é uma excelente metáfora, embora em governança eu preferisse termos como:

transferência de conhecimento não governada

ou

canal cumulativo de exposição de conhecimento.

Porque nem todo prompt constitui exfiltração e nem todo usuário possui intenção indevida.


🛡️ DLP talvez não seja suficiente

Data Loss Prevention tradicionalmente pergunta:

“Que dado está saindo?”

Nosso problema exige outra pergunta:

“Que conhecimento está sendo construído pela soma daquilo que está saindo?”

Daí surge:

KLP — Knowledge Loss Prevention

Não estou propondo aqui um padrão formal universal chamado KLP.

Estou usando o termo como conceito para ampliar nossa maneira de pensar.

DLP:

PROTEJA O DADO

KLP:

PROTEJA:
dados
+
contexto
+
relações
+
acumulação
+
tempo
+
conhecimento derivável

Porque:

PROMPT 1 = VERDE
PROMPT 2 = VERDE
PROMPT 3 = VERDE

...

Σ PROMPTS = VERMELHO

O risco pode emergir da soma.


🐒 Um milhão de chimpanzés bebedores de saquê

É claro que nenhum tratado Bellacosa Mainframe estaria completo sem nossos agentes especiais.

Imagine um corpus contendo:

"Meu CICS conversa telepaticamente com Saturno."

"Verificar MQ amanhã."

"O gato assumiu RACF SPECIAL."

"Por que PAY001 apresenta S0C7?"

"Napoleão teria usado VSAM."

"Não esquecer daquele JOB."

"Um milhão de chimpanzés bebendo saquê
administram produção."

Um investigador humano provavelmente pediria transferência de departamento.

Mas não devemos considerar volume e ruído controles de segurança confiáveis.

Sistemas automatizados conseguem classificar conteúdo, encontrar recorrências e separar grandes quantidades de informação muito mais rapidamente que uma pessoa.

Além disso, existe uma vítima colateral.

Você.

Três anos depois abre a conversa e pergunta:

“Que porra eu quis dizer com isso?”

😂

A contrainteligência funcionou tão bem que derrotou o próprio autor.


🧠 Facebook, dados comportamentais e Moriarty

Agora ampliemos novamente a escala.

Redes sociais mostraram ao mundo o valor da correlação de enormes quantidades de dados comportamentais.

IA conversacional introduz uma diferença conceitualmente importante.

Nas redes sociais frequentemente observamos:

curtiu
clicou
assistiu
compartilhou
seguiu
comprou

e tentamos inferir alguma coisa.

Em conversas com IA o próprio usuário frequentemente fornece:

"meu problema é..."

"não entendo..."

"estou considerando..."

"tenho duas alternativas..."

"minha arquitetura funciona assim..."

"por que isso aconteceu?"

"qual opção você escolheria?"

Isso pode representar contexto cognitivo muito mais explícito.

Não devemos concluir daí que provedores estejam oferecendo conversas privadas para terceiros. Estamos construindo um modelo hipotético de ameaça.

Mas defensivamente precisamos perguntar:

Qual seria o impacto se determinado corpus conversacional fosse indevidamente exposto?

Essa pergunta basta.


🎭 Moriarty não quer apenas saber o que aconteceu

Nosso professor do crime imaginário está interessado também em:

incerteza.

Considere:

“Não sei se devemos migrar X para Y.”

Essa frase revela mais do que parece.

Ela sugere:

X existe.

Y é considerado.

há uma decisão pendente.

o autor participa da discussão.

existe incerteza.

Isso é extraordinariamente interessante para inteligência.

Não estamos observando somente uma decisão passada.

Estamos observando o espaço de possibilidades anterior à decisão.


⚖️ O advogado entra novamente na sala

Voltemos ao artigo original.

Ele argumenta que informações identificáveis de clientes merecem atenção especial e recomenda práticas como anonimização e ambientes apropriados para informações sensíveis.

Nosso Supermosaico acrescenta outra preocupação.

Um advogado pode registrar:

processo;
estratégia;
dúvidas;
hipóteses;
limites de negociação;
fragilidades percebidas;
possíveis argumentos.

Novamente, isso não significa que a contraparte consiga simplesmente acessar essas conversas.

Não consegue.

Seria necessário algum evento adicional de exposição, comprometimento ou falha de governança.

Mas o impacto potencial do corpus merece entrar no threat model.


⚔️ A assimetria computacional

Imagine:

ZÉ DA SILVA
     │
advogado pequeno
notebook
tempo limitado
     │
     VS
     │
MEGACORP S/A
     │
equipe jurídica
especialistas
bases jurídicas
engenharia
automação
análise documental
IA

IA pode democratizar recursos antes inacessíveis ao pequeno advogado.

Isso é excelente.

Mas também pode industrializar capacidades de grandes organizações.

Temos duas forças simultâneas:

IA → DEMOCRATIZAÇÃO

IA → CONCENTRAÇÃO

Qual vencerá?

Provavelmente dependerá de acesso, custo, regulação, educação e governança.


🛡️ Como derrotar Moriarty sem abandonar IA

A resposta não é:

“Proibam tudo!”

Isso desperdiçaria uma tecnologia extraordinariamente útil.

O próprio artigo que iniciou nossa reflexão defende uma abordagem de governança em vez da simples interrupção do uso da IA.

Precisamos tornar Moriarty caro.

1. Separar identidades

PESSOAL ≠ PROFISSIONAL

2. Separar clientes

CLIENTE A ≠ CLIENTE B

3. Separar projetos

Não criar desnecessariamente um Supermosaico.

4. Minimizar

Pergunte:

“A IA realmente precisa saber isso?”

5. Sanitizar

Troque:

BANCO-REAL-XYZ

por:

CLIENTE-A

quando o detalhe real não for necessário.

6. Remover segredos

Tokens, credenciais, dados pessoais, dumps completos e informações confidenciais não devem passear livremente por prompts.

7. Governar retenção

A organização precisa saber onde conversas corporativas ficam e qual é seu ciclo de vida.

8. Governar consultores

A política precisa alcançar terceiros adequadamente, não somente empregados.

9. Pensar cumulativamente

Pergunte não apenas:

“Este prompt é perigoso?”

mas:

“O que cem prompts como este revelariam?”

10. Modelar Knowledge Privilege

Identifique não apenas quem possui grandes permissões.

Identifique funções que possuem enorme contexto institucional.


🔬 Um Red Team diferente

Podemos testar tudo isso sem atacar ninguém.

Crie uma empresa fictícia.

Um banco chamado:

BANCO MORIARTY S/A

Crie:

Carlos — N3 CICS
Maria — DBA
João — arquiteto
Ana — consultora
Watson — segurança

Produza informações sintéticas.

Simule um ano de prompts permitidos.

Depois entregue somente esse corpus para outro time autorizado e pergunte:

“O que vocês conseguem reconstruir sobre nossa empresa fictícia?”

Arquitetura?

Dependências?

Pessoas?

Sistemas críticos?

Cronologia?

Regras de negócio?

Tecnologias?

Incidentes?

Se o resultado for surpreendentemente detalhado, encontramos uma deficiência de governança sem comprometer uma única empresa real.

Esse seria um belíssimo exercício de Red Team de conhecimento.


🕒 03:17 — O incidente

Às 03:17 da madrugada, o telefone toca.

Produção está normal.

Nenhum dataset foi copiado.

Nenhum usuário RACF utilizou SPECIAL.

Nenhum arquivo de 40 GB saiu pela rede.

Nenhum pendrive apareceu.

Nenhum source foi publicado.

Nenhum alarme tradicional disparou.

Watson olha para Moriarty:

“Então não houve incidente?”

Moriarty toma tranquilamente seu café.

“Meu caro Watson... você ainda está procurando o arquivo.”

Sobre a mesa existem 12.847 pequenas tesselas.

Uma transação aqui.

Uma regra ali.

Um incidente acolá.

Uma decisão arquitetural.

Uma dependência.

Um fornecedor.

Uma exceção.

Uma dúvida.

Uma história de vinte anos resumida por alguém em cinco linhas.

Watson começa a juntar as pedras.

A figura aparece.

Não existe MEGACORP-SECRETS.ZIP.

Nunca existiu.

Existe algo potencialmente muito mais interessante:

conhecimento.


☕ A última lição do Dr. Moriarty

Durante décadas construímos excelentes mecanismos para responder:

Quem pode acessar este dado?

RACF responde isso maravilhosamente no mainframe.

IAM responde.

PAM responde.

ACL responde.

MFA ajuda.

Zero Trust ajuda.

DLP ajuda.

Mas IA nos obriga a acrescentar novas perguntas:

Quem pode externalizar esse conhecimento?

Quanto contexto pode ser acumulado ao longo do tempo?

Que informação aparentemente inocente se torna sensível quando correlacionada?

Onde termina experiência profissional e começa memória corporativa portátil?

O que acontece com o corpus depois que o funcionário ou consultor deixa a organização?

Qual é o blast radius do comprometimento de uma identidade que possui anos de conversas profissionais?

E principalmente:

Estamos protegendo somente aquilo que nossos funcionários acessam ou também os lugares onde eles passaram a registrar aquilo que sabem?

Essa talvez seja uma das grandes discussões de segurança da era da Inteligência Artificial.

Não significa abandonar IA.

Significa amadurecer sua utilização.

O profissional que pergunta corretamente para uma IA pode produzir em minutos algo que anteriormente consumiria horas.

Isso é fantástico.

Mas justamente por querermos respostas melhores somos incentivados a fornecer mais contexto.

E contexto é conhecimento.

Conhecimento acumulado cria mosaicos.

Mosaicos correlacionados criam Supermosaicos.

Portanto, sob a tutela do Dr. Moriarty, terminamos com uma regra simples:

O maior segredo talvez não esteja em nenhuma tessela. O segredo pode ser a imagem que aparece quando alguém consegue juntar tesselas suficientes.

E Sherlock Holmes provavelmente acrescentaria:

“Proteja as pedras, Watson.”

Moriarty sorriria.

“Não. Proteja as relações entre elas.”

☕ Bellacosa Mainframe — onde até um simples prompt pode acabar virando uma tessela no mosaico.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...