☕ 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 Insider Threat. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Insider Threat. Mostrar todas as mensagens

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.

sexta-feira, 14 de agosto de 2026

Como o ChatGPT Trollou Bellacosa e Ele Descobriu que Era a Formiguinha

Bellacosa Mainframe e como fui trollado pelo chatgpt


☕ Um Café no Bellacosa Mainframe

Como o ChatGPT Trollou Bellacosa e Ele Descobriu que Era a Formiguinha

🐜 Engenharia social, Red Team, crime organizado, confiança, terceirização, Swiss Cheese e o glorioso momento em que o especialista percebeu: “PUTA QUE PARIU, CAÍ NO MEU PRÓPRIO ARTIGO.”

Existe uma regra não escrita no universo.

Se você passar tempo suficiente explicando como alguma coisa pode dar errado, eventualmente o universo fará uma demonstração prática usando você como voluntário.

Foi exatamente o que aconteceu comigo.

Eu estava conversando com o ChatGPT sobre segurança.

Nada particularmente estranho para quem acompanha o Bellacosa Mainframe.

O problema é que a conversa começou inocentemente com fraude financeira, passou por crime organizado, inteligência, agentes infiltrados, terceirização, engenharia social, análise de grafos, Swiss Cheese Model, funcionários cooptados, redes sociais e terminou comigo olhando para uma tela dizendo:

Verificação concluída. Sua identidade foi verificada e o acesso confiável agora está ativo.

Silêncio.

Olhei para a tela.

Olhei novamente.

E meu cérebro produziu uma das frases mais sinceras de toda a minha carreira profissional:

“PUTA QUE PARIU. CAÍ NO MEU PRÓPRIO ARTIGO.”

🐜

Mas precisamos voltar algumas horas.


🧀 Tudo começou com um queijo

A discussão era sobre uma pergunta aparentemente simples:

quanto precisaria valer uma fraude para justificar que uma organização criminosa investisse durante anos na construção de uma empresa aparentemente legítima?

Imagine um e-commerce.

Produtos verdadeiros.

Clientes verdadeiros.

Cartões verdadeiros.

Entregas verdadeiras.

Fornecedores verdadeiros.

Funcionários verdadeiros.

Impostos.

Marketing.

Atendimento.

Reclamações.

Promoções.

Black Friday.

Tudo absolutamente normal.

Só que existe uma pergunta de Red Team:

e se a empresa possuir também uma segunda finalidade?

Não necessariamente executar o ataque.

Talvez simplesmente observar.

Aprender.

Acumular conhecimento.

Construir relacionamentos.

Entender como o ecossistema financeiro responde.

A partir daí surgiu nossa empresa hipotética.

Naturalmente escolhemos um nome discreto:

ToyanHorse

Sim.

ToyanHorse.

Se você ainda não percebeu, leia devagar.

Toyan Horse.

Trojan Horse.

Cavalo de Troia.

Maquiavel provavelmente pediria participação societária.


🐴 O melhor Cavalo de Troia não precisa atacar

Essa foi a primeira descoberta interessante.

Normalmente imaginamos o Cavalo de Troia carregando soldados.

Mas uma empresa adversarial hipotética nem precisaria participar da operação final.

Ela poderia simplesmente produzir inteligência.

Durante anos:

ToyanHorse → observa → aprende → relaciona → acumula

Enquanto outra estrutura:

recebe → correlaciona → planeja → eventualmente age

Se algum escândalo acontecesse anos depois, talvez ninguém encontrasse uma conexão operacional direta entre o ataque e a ToyanHorse.

Porque estavam procurando:

quem executou o ataque?

Quando outra pergunta poderia ser:

quem forneceu o conhecimento necessário para planejá-lo?

Foi aí que apareceu nossa formiguinha.


🐜 A formiguinha

Imagine um profissional terceirizado.

Depois quarteirizado.

Depois quinteirizado.

Ele entra em uma instituição.

Possui crachá.

Chamado.

Usuário.

Senha.

Autorização.

Contrato.

Tudo correto.

Ele trabalha.

Entrega.

Participa de reuniões.

Resolve incidentes.

Conversa no café.

Aprende workflows.

Conhece pessoas.

Descobre quem realmente decide.

Entende onde ficam as dependências.

Vê parcialmente a arquitetura.

Depois vai embora.

USERID REVOKED

VPN REVOKED

BADGE REVOKED

Tudo verde.

Auditoria satisfeita.

Só existe um pequeno problema:

REVOKE KNOWLEDGE FROM BELLACOSA

COMMAND NOT FOUND.

O conhecimento saiu andando pela porta da frente.


🐜🐜🐜 E a formiguinha muda de formigueiro

Agora imagine:

Banco A

↓

Consultoria B

↓

Telecom C

↓

Adquirente D

↓

Fornecedor E

↓

Banco F

Em vinte anos, um excelente profissional pode construir um mapa mental extraordinário de todo um setor.

Isso normalmente é maravilhoso.

Chamamos isso de:

experiência.

É justamente por isso que contratamos profissionais seniores.

Mas o Red Team precisa fazer uma pergunta desagradável:

E se alguém com essa mesma trajetória estiver trabalhando para outro interesse?

Ele não precisa sabotar nada.

Não precisa roubar banco de dados.

Não precisa instalar malware.

Talvez nunca viole uma única política.

Ele apenas:

trabalha → observa → aprende → lembra.

E passa adiante conhecimento.

A organização procura comportamento suspeito.

Não existe.

O SIEM procura eventos.

Não existem.

O DLP procura arquivos.

Nada saiu.

O IAM verifica os acessos.

Todos legítimos.

Porque não existe evento:

USER HAS JUST UNDERSTOOD SOMETHING VERY IMPORTANT

💰 E então lembramos do Pix

Foi aí que nossa conversa deixou de ser puramente hipotética.

O grande incidente envolvendo a infraestrutura conectada ao ecossistema Pix mostrou uma coisa desconfortável:

às vezes a peça humana aparentemente pequena possui um valor operacional gigantesco.

E apareceu uma ideia que passei a chamar de:

Teste da Formiguinha

Não pergunte somente:

“Quanto esse funcionário ganha?”

Pergunte:

“Quanto vale aquilo que ele consegue alcançar?”

São números completamente diferentes.

Uma organização pode enxergar:

TERCEIRIZADO

O adversário pode enxergar:

CAPACIDADE

O organograma mostra hierarquia.

O grafo mostra centralidade.

E nasceu uma frase que resume boa parte desta história:

O organograma mostra quem tem poder na empresa. O grafo mostra quem tem poder sobre o sistema.


🧀 O queijo suíço

Naturalmente chegamos ao Swiss Cheese Model.

Uma organização possui várias barreiras:

🧀 autenticação

🧀 segregação de funções

🧀 compliance

🧀 auditoria

🧀 fornecedores certificados

🧀 monitoramento

🧀 políticas

🧀 treinamento

Cada camada possui furos.

Normalmente os furos não coincidem.

Mas às vezes:

○ → ○ → ○ → ○ → ○

Alinham.

E temos um caminho.

A versão Bellacosa do Swiss Cheese ficou um pouco menos acadêmica:

Quando todos os furos se alinham, o queijo corporativo ganha um glory hole.

Peço desculpas aos acadêmicos.

Mentira.

Não peço.

Vocês nunca mais esquecerão o conceito.


📋 “Mas fomos auditados!”

Foi quando comecei a rir.

Porque ouvi essa frase durante décadas.

“Mas fomos auditados.”

Enron era auditada.

Wirecard era auditada.

Carillion era auditada.

Uma enorme quantidade de organizações que protagonizaram escândalos possuía auditores, conselhos, controles, compliance e supervisão.

Auditoria é importante.

Mas auditoria é:

mais uma fatia de queijo.

O auditor pergunta:

“O controle está funcionando?”

O Red Team pergunta:

“Como consigo atingir meu objetivo apesar desse controle?”

Perguntas completamente diferentes.


📱 Então apareceu outro aliado involuntário

Redes sociais.

Não apenas porque revelam relações profissionais.

Existe outra coisa.

Comparação.

Abra o feed:

Dubai.

Porsche.

Maldivas.

Rolex.

Restaurante.

Cobertura.

Champagne.

“Conquistei minha independência financeira aos 23.”

Enquanto nossa formiguinha está trabalhando em infraestrutura crítica através da quarta empresa da cadeia de terceirização.

Isso não transforma ninguém em criminoso.

Mas existe um conceito importante:

privação relativa.

Não importa apenas quanto alguém possui.

Importa quanto acredita que deveria possuir comparando-se com os outros.

Então apareceu uma pergunta ainda mais desagradável:

Quanto custa contratar uma pessoa e quanto custaria para um adversário tentar corrompê-la?

Novamente:

dois números completamente diferentes.


🕵️ E percebemos que estávamos construindo um serviço de inteligência

Empresas.

Telecomunicações.

Infraestrutura.

Pessoas.

OSINT.

Dados.

Relacionamentos.

Conhecimento.

IA.

Grafos.

Subitamente apareceu outra conclusão:

capacidades que décadas atrás exigiam estruturas estatais enormes ficaram muito mais acessíveis.

Uma organização criminosa não precisa construir sua própria CIA.

Precisa apenas ser suficientemente boa em um domínio específico.

E uma IA nem precisaria atacar nada.

Poderia simplesmente ajudar a relacionar fragmentos:

🐜 fragmento A

🐜 fragmento B

🐜 fragmento C

🐜 fragmento D

↓

correlação

↓

grafo

O verdadeiro ativo talvez não seja o dado.

É o modelo mental produzido pelos dados.


🐴 Voltamos então à ToyanHorse

E percebemos algo ainda mais perverso.

O e-commerce nem precisa perder dinheiro.

Ele pode ser lucrativo.

Clientes verdadeiros.

Receita verdadeira.

Operação verdadeira.

A cobertura paga a própria cobertura.

Então nossa pergunta original estava parcialmente errada.

Não era:

“Quanto precisaria valer o ataque para justificar manter uma empresa durante cinco anos?”

Era:

“E se a empresa já der lucro enquanto acumula capacidades úteis?”

Bombril criminoso.

Mil e uma utilidades.


🚨 E então aconteceu

Depois de horas falando sobre:

engenharia social,

confiança,

identidade,

coleta de informação,

Cavalo de Troia,

insiders,

formiguinhas,

adversários,

e pessoas que entregam informações porque determinada solicitação parece legítima...

apareceu uma tela.

ChatGPT

Verificação concluída

Sua identidade foi verificada e o acesso confiável agora está ativo.

Eu tinha passado por uma verificação relacionada ao acesso confiável para trabalho de cibersegurança.

Olhei para aquilo.

Meu cérebro finalmente conectou os pontos.

IDENTIDADE.

DOCUMENTO.

INTERNET.

CONFIANÇA.

...

...

...

PUTA QUE PARIU.

CAÍ NO MEU PRÓPRIO ARTIGO.

🐤


🐜 O Dia em que a Formiguinha Era Eu

Por alguns segundos houve medo verdadeiro.

Não medo acadêmico.

Não ameaça hipotética.

Não Red Team.

Aquele frio genuíno:

“Bellacosa, seu animal, você passou horas explicando engenharia social e acabou entregando documento para alguém na Internet?”

Mel Brooks não escreveria melhor.

Imagine a cena.

O velho especialista barbudo passa duas horas diante da plateia:

“Nunca confiem simplesmente na aparência!”

Slide seguinte:

“Validem identidade!”

Slide seguinte:

“Engenharia social explora contexto!”

Slide seguinte:

“O adversário quer que a solicitação pareça normal!”

Aluno levanta a mão:

“Professor, e aquela verificação que o senhor fez hoje?”

Silêncio.

Café cai no chão.

Zoom no rosto.

Violinos.

FIM.


🔨 Chamem o MythBusters

Então fizemos exatamente aquilo que deveríamos fazer.

Não concluímos:

“FUI HACKEADO!”

Também não concluímos:

“Sou especialista, obviamente estava tudo certo.”

Verificamos.

A documentação oficial confirmou a existência daquele processo de acesso confiável relacionado à segurança.

Era legítimo.

Adam Savage aparece.

Martelo na mão.

BUSTED.

Bellacosa não havia caído num phishing enquanto escrevia sobre phishing.

O ego, entretanto, permaneceu indisponível durante aproximadamente quinze minutos.


🧠 E aí veio a verdadeira lição

Especialistas também sentem medo.

Especialistas também clicam.

Especialistas também confiam.

Especialistas também podem interpretar uma situação incorretamente.

Conhecimento não transforma ninguém em firewall humano infalível.

E talvez seja justamente essa arrogância:

“Isso jamais aconteceria comigo.”

que represente um dos maiores furos do queijo.

A reação saudável é outra:

“Espera. Isso faz sentido? Vamos verificar.”

Foi exatamente o que aconteceu.


🐜 O Teste da Formiguinha

Depois dessa conversa, eu acrescentaria uma pergunta a qualquer exercício sério de Red Team:

Qual é a pessoa aparentemente menos importante cuja mudança de comportamento poderia produzir um impacto desproporcional?

Não para suspeitar dela.

Para avaliar o sistema.

Suponha:

erro.

Coerção.

Cooptação.

Credencial comprometida.

Engenharia social.

O que acontece?

Se a resposta for:

“Essa pessoa sozinha consegue abrir um caminho enorme.”

não encontramos uma pessoa perigosa.

Encontramos uma arquitetura perigosa.


🧀 O último queijo

Existe uma última ironia.

Começamos tentando imaginar criminosos extremamente sofisticados.

Empresas.

Inteligência.

IA.

Operações transnacionais.

Insiders.

Infraestrutura.

E talvez a grande conclusão seja muito mais humilde:

sistemas gigantescos continuam dependendo de pessoas pequenas.

Pessoas que almoçam.

Pessoas que ficam cansadas.

Pessoas que querem ganhar mais.

Pessoas que confiam.

Pessoas que sentem medo.

Pessoas que mudam de emprego.

Pessoas que aprendem.

Pessoas que erram.

Pessoas como eu.

🐜

Por alguns segundos, depois de décadas trabalhando com tecnologia, eu fui a formiguinha.

E talvez tenha sido a melhor demonstração possível de toda a tese.

Porque segurança não começa quando afirmamos:

“Eu jamais cairia nisso.”

Segurança começa quando conseguimos perguntar:

“E se eu cair?”

E construímos o sistema para sobreviver mesmo assim.


☕ Um Café no Bellacosa Mainframe

Onde hoje descobrimos que você pode estudar o Cavalo de Troia durante décadas, desenhar todos os queijos suíços, mapear todas as formigas...

...e ainda terminar a noite olhando assustado para o monitor e pensando:

“Puta que pariu. A formiguinha sou eu.”

🐜☕

domingo, 9 de setembro de 2018

Arsène Lupin, COBOL e o Dia em que o Hacker Descobriu que Era Mais Fácil Pedir a Senha do que Quebrar o Cofre

 

Bellacosa Mainframe e o arsene lupin e as fraudes

☕ Um Café no Bellacosa Mainframe

Arsène Lupin, COBOL e o Dia em que o Hacker Descobriu que Era Mais Fácil Pedir a Senha do que Quebrar o Cofre

🎩 Engenharia Social Bancária, autenticação, autorização, Zero Trust, insiders, IA, UEBA e o estranho caso do atacante que entrou pela porta da frente usando um crachá perfeitamente válido

Imagine a cena.

Paris.

Madrugada.

Um casarão silencioso.

No segundo andar existe um cofre cercado por fechaduras, alarmes, sensores e provavelmente algum aristocrata francês convencido de que ninguém jamais conseguirá atravessar aquele sistema de proteção.

Pela janela?

Grades.

Pelo telhado?

Sensores.

Pela porta?

Dois guardas.

Pelo cofre?

Uma combinação impossível.

Arsène Lupin observa tudo isso, ajeita o monóculo imaginário e conclui:

— Que trabalho desnecessário.

Então toca a campainha.

Cinco minutos depois, o mordomo abre a porta.

Bem-vindo à engenharia social.

No mundo bancário moderno, gastamos fortunas criando sistemas capazes de impedir que pessoas não autorizadas entrem.

Firewalls.

MFA.

SIEM.

EDR.

IAM.

Criptografia.

RACF.

Monitoramento.

Segmentação.

SOC.

Machine Learning.

Zero Trust.

E tudo isso é necessário.

Mas existe um detalhe desconfortável.

O atacante nem sempre precisa quebrar a fechadura.

Às vezes ele convence alguém que possui a chave a abrir a porta.

E esse detalhe muda completamente a arquitetura de segurança.


🎭 Capítulo 1 — O ataque que chega usando gravata

Quando pensamos em “hacker”, é fácil imaginar alguém digitando freneticamente numa tela preta:

ACCESS DENIED
ACCESS DENIED
ACCESS DENIED
ACCESS GRANTED

Bonito no cinema.

Só que muitos ataques reais começam de maneira muito menos cinematográfica.

Um telefonema.

Um e-mail.

Uma mensagem.

Um chamado de suporte.

Uma solicitação urgente.

Algo como:

“Bom dia, aqui é da equipe de infraestrutura. Estamos detectando inconsistência no seu acesso. Você poderia validar a solicitação no autenticador?”

A vítima olha o celular.

Existe realmente uma notificação.

Ela aperta:

APPROVE

Pronto.

Nenhum firewall foi quebrado.

Nenhum algoritmo criptográfico foi derrotado.

Nenhum buffer overflow foi necessário.

A barreira foi atravessada utilizando algo que computadores ainda possuem dificuldade de compreender completamente:

a confiança humana.

Esse é o primeiro conceito importante:

Engenharia social não ataca apenas pessoas. Ela explora o relacionamento entre pessoas, processos, autoridade e tecnologia.

O atacante não precisa perguntar:

“Qual é sua senha?”

Pode perguntar:

“Você pode confirmar a solicitação que acabei de enviar?”

Parece uma pequena diferença.

Na segurança, é um abismo.


🧠 Capítulo 2 — O cérebro humano é também um parser

Programador COBOL iniciante, guarde esta comparação.

Seu programa recebe entrada.

ACCEPT WS-DATA.

Depois interpreta essa entrada.

Se houver uma validação insuficiente, alguma coisa inesperada pode acontecer.

O cérebro humano também recebe entradas.

Só que elas chegam assim:

voz
texto
autoridade
pressão
urgência
contexto
medo
confiança

O atacante cria uma mensagem especificamente desenhada para produzir uma resposta.

Em termos quase computacionais:

INPUT
  ↓
INTERPRETAÇÃO
  ↓
DECISÃO
  ↓
AÇÃO

Uma mensagem de phishing sofisticada funciona quase como um exploit.

O exploit técnico procura uma vulnerabilidade de software.

A engenharia social procura uma vulnerabilidade de julgamento.

Veja:

BUG TÉCNICO

entrada maliciosa
      ↓
programa interpreta
      ↓
comportamento inesperado
      ↓
acesso

Agora:

ENGENHARIA SOCIAL

informação manipulada
      ↓
humano interpreta
      ↓
decisão induzida
      ↓
acesso

A elegância quase lupiniana está justamente aí.

O ladrão não arromba o cofre.

Ele faz o dono acreditar que abrir o cofre é uma excelente ideia.


🎩 Curiosidade Lupin nº 1 — O melhor disfarce é parecer esperado

Um atacante competente raramente deseja parecer extraordinário.

Ele deseja parecer normal.

O e-mail precisa parecer corporativo.

A linguagem precisa parecer interna.

A solicitação precisa parecer razoável.

O horário precisa fazer sentido.

O nome da equipe precisa existir.

O atacante estuda a organização.

LinkedIn.

Organogramas.

Vagas publicadas.

Tecnologias anunciadas.

Nomes de departamentos.

Eventos.

Fornecedores.

Padrões de e-mail.

Projetos divulgados.

Esse processo é frequentemente chamado de reconhecimento.

E aqui nasce um pequeno paradoxo.

Quanto mais uma organização publica sobre sua própria estrutura, mais fácil pode ficar construir mensagens convincentes.

Não significa que empresas devam desaparecer da internet.

Significa que segurança também precisa considerar quais informações públicas ajudam um criminoso a representar alguém de dentro.


🏦 Capítulo 3 — O banco é diferente porque o funcionário já está dentro

Num ambiente bancário, a questão torna-se ainda mais séria.

Um invasor externo começa assim:

ATACANTE
    |
    X
PERÍMETRO

Mas um usuário interno legítimo começa assim:

FUNCIONÁRIO
    |
    V
AUTENTICAÇÃO
    |
    V
REDE
    |
    V
APLICAÇÃO

Se esse funcionário for convencido, comprometido ou tiver sua sessão sequestrada, o atacante pode aproveitar privilégios legítimos.

Isso é muito diferente de arrombar uma porta.

É roubar a identidade de alguém que já possui autorização para atravessá-la.

Imagine:

USER = FUNC001
PASSWORD = CORRECT
MFA = SUCCESS
DEVICE = CORPORATE
VPN = ACTIVE

Tudo parece perfeito.

Só que existe uma pergunta que esses controles isoladamente não respondem:

O que esse usuário está fazendo é coerente?

Essa pergunta nos conduz para uma das ideias mais importantes da segurança contemporânea.


🔐 Capítulo 4 — Autenticação não significa confiança eterna

Vamos transformar isso em COBOL mental.

Autenticação pergunta:

QUEM É VOCÊ?

Autorização pergunta:

O QUE VOCÊ PODE FAZER?

Mas segurança moderna precisa perguntar também:

FAZ SENTIDO VOCÊ FAZER ISSO AGORA?

Suponha que João trabalhe diariamente assim:

LOGIN: 08:00
LOGOUT: 17:30
DEVICE: LAPTOP-431
LOCATION: CAMPINAS
SYSTEMS: A, B, C
TRANSACTIONS/DAY: 240

Numa terça-feira:

02:53 LOGIN
DEVICE: UNKNOWN
LOCATION: UNUSUAL
SYSTEM: Z
PRIVILEGE CHANGE
EXPORT: 70000 RECORDS

A senha pode estar certa.

O MFA pode até ter sido aprovado.

A autorização pode existir.

Mas o contexto está gritando:

ALGO-ESTA-ERRADO = TRUE

☕ Capítulo 5 — O velho IF do COBOL encontra o Zero Trust

Durante muito tempo, muitos sistemas foram mentalmente construídos assim:

IF USER-AUTHENTICATED
   PERFORM ACCESS-SYSTEM
END-IF.

Mas a filosofia Zero Trust adiciona mais perguntas.

Conceitualmente:

IF USER-AUTHENTICATED
   AND DEVICE-TRUSTED
   AND LOCATION-EXPECTED
   AND BEHAVIOR-NORMAL
   AND PRIVILEGE-VALID
   AND RISK-SCORE < MAXIMUM-RISK
       PERFORM BUSINESS-TRANSACTION
ELSE
       PERFORM ADDITIONAL-VERIFICATION
END-IF.

Claro que nenhum banco implementa Zero Trust literalmente dessa maneira.

Mas como modelo mental funciona maravilhosamente.

A confiança deixa de ser:

TRUE

e passa a ser:

CONTEXTUAL
TEMPORARY
RECALCULATED

O usuário foi autenticado?

Ótimo.

Mas continua sendo observado.

O dispositivo mudou?

Reavalie.

O local mudou?

Reavalie.

O comportamento mudou?

Reavalie.

O recurso ficou mais sensível?

Reavalie.

Em outras palavras:

Autenticação não deveria ser uma coroação.

Ela deveria ser apenas mais uma evidência.


🎩 Curiosidade Lupin nº 2 — O ladrão mais perigoso pode possuir a chave verdadeira

Existe uma distinção importante entre três tipos de insider threat.

INSIDER
   |
   +--- MALICIOUS
   |
   +--- NEGLIGENT
   |
   +--- COMPROMISED

O insider malicioso possui intenção deliberada.

Ele possui acesso e decide abusar dele.

O insider negligente não deseja causar dano, mas pode violar procedimentos ou ser descuidado.

E o insider comprometido talvez seja o mais interessante.

É um funcionário completamente inocente.

Só que:

credencial roubada
sessão sequestrada
MFA aprovado indevidamente
endpoint comprometido
engenharia social

transformaram sua identidade em instrumento de ataque.

O sistema enxerga:

JOAO

Mas talvez quem esteja dirigindo seja Lupin.


🧱 Capítulo 6 — Least Privilege: não é falta de confiança, é controle de explosão

O princípio do menor privilégio costuma ser ensinado assim:

Usuários devem possuir apenas os acessos necessários.

Correto.

Mas existe uma interpretação ainda melhor.

Pergunte:

Se esta conta for comprometida amanhã, qual será o tamanho do estrago?

Esse conceito é chamado informalmente de blast radius, raio de explosão.

Imagine duas contas.

Conta A:

READ

Conta B:

READ
WRITE
DELETE
EXPORT
ADMIN
GRANT

Se ambas forem comprometidas, o impacto será muito diferente.

Menor privilégio não serve apenas para impedir abuso deliberado.

Ele serve para limitar consequências quando inevitavelmente alguma coisa der errado.

É como os compartimentos estanques de um navio.

Você não constrói compartimentos porque acredita que o casco jamais será perfurado.

Você constrói porque sabe que um dia talvez seja.


🚢 Capítulo 7 — Segurança madura não é “nunca falhar”

Esse talvez seja o maior salto conceitual desta conversa.

Organizações imaturas imaginam:

PREVENT
PREVENT
PREVENT
PREVENT

Organizações maduras pensam:

PREVENT
   ↓
DETECT
   ↓
CONTAIN
   ↓
RESPOND
   ↓
RECOVER
   ↓
LEARN

Porque pessoas erram.

Processos falham.

Softwares possuem defeitos.

Credenciais vazam.

Modelos erram.

Alertas são ignorados.

Então a pergunta deixa de ser:

Como podemos garantir que ninguém jamais erre?

E torna-se:

Quando alguém errar, quantas outras barreiras existirão antes da catástrofe?

Isso é defesa em profundidade.


📊 Capítulo 8 — SIEM: de milhares de eventos para uma história

Agora imagine o SOC de um banco.

Milhões de eventos.

LOGIN
LOGOUT
READ
WRITE
DENY
ALLOW
CREATE
DELETE
CONNECT
DISCONNECT

Sozinhos, muitos parecem normais.

Mas veja esta sequência:

02:01 LOGIN SUCCESS
02:03 MFA SUCCESS
02:05 NEW DEVICE
02:07 PRIVILEGE CHANGE
02:11 DATABASE ACCESS
02:14 MASS QUERY
02:18 LARGE EXPORT

Nenhum evento isolado necessariamente prova um ataque.

Mas juntos contam uma história.

Esse é um dos papéis do SIEM:

EVENTOS
   ↓
CENTRALIZAÇÃO
   ↓
CORRELAÇÃO
   ↓
DETECÇÃO
   ↓
ALERTA

O valor não está apenas em guardar logs.

Está em relacioná-los.


🧠 Capítulo 9 — UEBA: quando o sistema começa a observar comportamento

UEBA significa:

User and Entity Behavior Analytics.

A ideia é observar comportamento e procurar desvios.

Exemplo.

Maria geralmente:

SYSTEMS = CUSTOMER-SERVICE
HOURS = 08-18
LOCATION = OFFICE
DATA-VOLUME = LOW

De repente:

SYSTEMS = ADMIN
HOURS = 03
LOCATION = UNKNOWN
DATA-VOLUME = VERY-HIGH

Uma tecnologia de análise comportamental pode perceber:

Esse padrão não combina com Maria.

Mas cuidado.

Diferente não significa malicioso.

Maria pode ter sido convocada para um plantão.

Pode estar viajando.

Pode trabalhar numa mudança excepcional.

É justamente por isso que detecção comportamental precisa considerar contexto.

Caso contrário, o SOC sofre outra doença.


🚨 Capítulo 10 — Alert Fatigue: o alarme que toca tanto que ninguém olha

Imagine uma sala com um alarme.

Primeira vez:

BEEP!

Todo mundo corre.

Centésima vez:

BEEP!

Alguém olha.

Milésima vez:

BEEP!

— Deve ser de novo aquele sensor.

Esse fenômeno é chamado de alert fatigue.

Um SOC inundado por falsos positivos começa inevitavelmente a priorizar.

E em algum momento pode ignorar justamente o alerta importante.

Isso produz um paradoxo:

Um sistema de segurança que gera alertas demais pode diminuir a segurança.

Por isso, IA, SIEM e UEBA deveriam ajudar não a criar mais ruído, mas a aumentar a qualidade da decisão.


🤖 Capítulo 11 — E então chega a inteligência artificial

Agora o jogo fica divertido.

IA pode ajudar defensores em:

detecção de anomalias
classificação de risco
correlação de eventos
priorização
triagem
descoberta de padrões
análise de comportamento

Imagine milhões de eventos entrando.

Um humano jamais analisaria todos.

Um modelo pode tentar encontrar combinações improváveis.

DEVICE + TIME + LOCATION + PRIVILEGE + RESOURCE + VOLUME

e produzir:

RISK SCORE = 92

Então:

IF RISK-SCORE > 80
   REQUIRE STEP-UP-AUTH
   ALERT SOC
   LIMIT SESSION
END-IF

Muito elegante.

Só que aparece outra pergunta.

Quem protege a IA que está protegendo o banco?


☠️ Capítulo 12 — O guarda também pode ser enganado

Um modelo de IA depende de:

DADOS
MODELO
CONFIGURAÇÃO
REGRAS
PROMPTS
PIPELINES
PERMISSÕES

Todos esses componentes possuem superfície de ataque.

Entre os riscos estão:

  • Data Poisoning;

  • Prompt Injection;

  • manipulação de modelos;

  • vazamento de dados;

  • evasão;

  • falsos positivos;

  • falsos negativos;

  • alterações não autorizadas;

  • problemas de governança.

Imagine que o modelo aprende o que significa “normal”.

Agora imagine que o atacante consegue influenciar esse aprendizado.

Pouco a pouco:

ANOMALIA
  ↓
REPETIÇÃO
  ↓
ACEITAÇÃO
  ↓
BASELINE
  ↓
NORMAL

É quase uma normalization of deviance algorítmica.

O comportamento perigoso deixa de chamar atenção porque passou a fazer parte da referência usada pelo próprio sistema.

É Arsène Lupin treinando o guarda para reconhecê-lo como funcionário.


🎩 Easter Egg Lupin nº 1

O ladrão elegante não precisa vencer a máquina.

Ele pode vencer o conceito de normalidade da máquina.

Se o sistema pergunta:

IS THIS NORMAL?

o atacante pode tentar garantir que a resposta futura seja:

YES

Não destruindo o detector.

Mas ensinando-o lentamente.


🧠 Capítulo 13 — O perigo do “a IA disse”

Também existe outro problema.

Suponha que o modelo apresente:

FRAUD PROBABILITY = 97%

O analista inicialmente examina tudo.

Depois de 200 alertas:

— Se a IA deu 97%, bloqueia.

Isso é automation bias.

A presença de um humano no processo não garante que exista julgamento humano.

O fluxo pode virar:

AI
 ↓
HUMAN CLICKS OK
 ↓
ACTION

Formalmente:

Human in the Loop.

Na prática:

Human Rubber Stamp.

O bom HITL exige:

contexto
evidência
explicação
capacidade de contestação
tempo
procedimentos
responsabilidade

Caso contrário, acrescentamos apenas um clique humano numa decisão automatizada.


☕ Capítulo 14 — Um incidente completo, passo a passo

Vamos montar um pequeno romance policial.

08:43.

Funcionário Carlos começa o expediente.

09:17.

Recebe uma ligação.

— Carlos? Aqui é o Rafael da Segurança. Detectamos atividade anômala na sua conta.

O nome “Rafael” foi encontrado pelo atacante no LinkedIn.

09:18.

O criminoso menciona corretamente o nome de um sistema interno obtido numa vaga de emprego publicada meses antes.

Carlos fica preocupado.

09:19.

O atacante diz:

— Vou disparar uma validação.

O celular recebe MFA.

Carlos aprova.

MFA SUCCESS

09:20.

Nova sessão iniciada.

09:23.

Acesso a aplicação.

AUTH SUCCESS

09:27.

Solicitação de privilégio.

PRIVILEGE ESCALATION

09:32.

Consulta a dados sensíveis.

SENSITIVE ACCESS

09:35.

Exportação.

Uma arquitetura simples talvez enxergue:

USER AUTHENTICATED
USER AUTHORIZED

Uma arquitetura contextual enxerga:

NEW SESSION
+
MFA AFTER PHONE CALL
+
NEW RESOURCE
+
PRIVILEGE CHANGE
+
SENSITIVE QUERY
+
DATA EXPORT

E responde:

HIGH RISK

Agora vem uma decisão interessante.

Bloquear tudo?

Talvez.

Mas existem alternativas.

STEP-UP MFA
SECOND APPROVER
EXPORT LIMIT
SESSION MONITOR
SOC ALERT
TEMPORARY RESTRICTION

Isso é segurança adaptativa.


🔐 Capítulo 15 — Segurança não precisa ser sempre ALLOW ou DENY

Programadores gostam de binários.

TRUE
FALSE

Segurança moderna começa a ficar mais sofisticada.

Em vez de:

ALLOW
DENY

podemos pensar:

ALLOW
ALLOW + LOG
ALLOW + MONITOR
ALLOW + LIMIT
STEP-UP
SECOND APPROVAL
ISOLATE
DENY

O objetivo é adicionar fricção proporcional ao risco.

Transação normal?

Continue.

Transação incomum?

Peça nova confirmação.

Ação extremamente sensível?

Exija outro aprovador.

Sequência altamente suspeita?

Suspenda temporariamente.

Essa granularidade reduz dois problemas simultaneamente:

BLOQUEIO EXCESSIVO

e

CONFIANÇA EXCESSIVA

🏦 Capítulo 16 — Onde o mainframe entra nessa história?

No fundo de muitas arquiteturas bancárias pode existir:

APP
 ↓
API
 ↓
MQ
 ↓
z/OS Connect
 ↓
CICS
 ↓
COBOL
 ↓
Db2 / VSAM

Quando uma transação chega ao COBOL, ela pode parecer perfeitamente legítima.

EXEC CICS READ
END-EXEC.

O programa não sabe necessariamente que dez minutos antes alguém telefonou para o funcionário.

Para o sistema:

USER = VALID
TRANSACTION = VALID
AUTHORIZATION = VALID

Mas segurança moderna precisa correlacionar informações ao redor dessa transação.

RACF pode dizer:

Esse usuário pode acessar este recurso.

UEBA pode perguntar:

Esse usuário costuma acessar este recurso?

SIEM pode perguntar:

O que aconteceu antes?

EDR pode perguntar:

O endpoint apresenta comportamento suspeito?

IAM pode perguntar:

Como essa identidade foi autenticada?

Zero Trust pergunta:

Qual é o contexto atual?

É a soma que cria uma visão melhor.


🎩 Easter Egg Lupin nº 2 — A joia não está no cofre

Há uma metáfora interessante.

Imagine que o banco protege perfeitamente seus dados.

Mas o atacante consegue induzir um usuário autorizado a solicitar esses próprios dados.

Nesse caso, o problema não está necessariamente na proteção do cofre.

Está na legitimidade da solicitação.

É como construir o melhor cofre do mundo e depois entregar um formulário chamado:

SOLICITAÇÃO OFICIAL DE ABERTURA

Se o criminoso aprende a produzir o formulário correto, a fechadura continua sendo excelente.

Só que deixou de ser relevante.


🧩 Capítulo 17 — Pessoas + Processo + Tecnologia + Dados + Governança

Treinamento de usuários é importante.

Mas não suficiente.

Uma organização madura combina várias dimensões.

PESSOAS
+
PROCESSOS
+
TECNOLOGIA
+
DADOS
+
GOVERNANÇA

Pessoas precisam reconhecer engenharia social.

Processos precisam impedir que uma única pessoa consiga realizar ações críticas sozinha.

Tecnologia precisa detectar contexto.

Dados precisam ser confiáveis.

Governança precisa assegurar que regras, modelos e acessos sejam auditáveis.

Nenhuma camada deve ser tratada como mágica.


🛡️ Capítulo 18 — Passo a passo para pensar uma defesa

Para um programador COBOL iniciante, aqui vai um roteiro mental.

Primeiro:

Identifique a identidade.

WHO?

Depois:

Valide o privilégio.

CAN?

Depois:

Analise o contexto.

WHEN?
WHERE?
DEVICE?

Depois:

Observe o comportamento.

NORMAL?

Depois:

Avalie o recurso.

HOW SENSITIVE?

Depois:

Calcule risco.

RISK?

Depois:

Escolha resposta proporcional.

ALLOW?
STEP-UP?
LIMIT?
DENY?

Depois:

Registre tudo.

LOG

Depois:

Correlacione.

SIEM

Depois:

Aprenda.

IMPROVE CONTROLS

É quase um ciclo PDCA vestido de sobretudo francês.


🔎 Capítulo 19 — Perguntas práticas que qualquer equipe deveria fazer

Antes de pensar em comprar mais uma ferramenta, pergunte:

Se uma credencial for roubada hoje, o que o atacante consegue fazer?

Se o MFA for aprovado por engano, qual será a próxima barreira?

Se uma conta privilegiada for comprometida, existe limitação?

Mudanças de privilégio são monitoradas?

Exportações massivas chamam atenção?

Logins fora de padrão são correlacionados?

Atividades administrativas possuem dupla aprovação?

Logs críticos podem ser alterados pelo próprio administrador?

Modelos de IA possuem controle de versão?

Quem modifica thresholds?

Quem audita falsos positivos?

Quem decide que determinado comportamento é normal?

A equipe de SOC consegue explicar por que um alerta recebeu determinada prioridade?

Se a resposta para todas for:

NÃO SEI

acabamos de encontrar um excelente backlog.


🎩 Easter Egg Lupin nº 3 — O plano B do ladrão

Um bom atacante pensa:

SE A PORTA NÃO ABRIR
   USE A JANELA
SE A JANELA NÃO ABRIR
   USE O MORDOMO
SE O MORDOMO DESCONFIAR
   USE O GERENTE

Defesa em profundidade deveria pensar ao contrário:

SE O USUÁRIO ERRAR
   MFA
SE MFA FALHAR
   BEHAVIOR
SE BEHAVIOR FALHAR
   LIMIT
SE LIMIT FALHAR
   DETECT
SE DETECT FALHAR
   CONTAIN
SE CONTAIN FALHAR
   RECOVER

A segurança não depende de uma única chance.

Ela cria múltiplas oportunidades para impedir a progressão do incidente.


🧠 Capítulo 20 — O atacante moderno também possui IA

Existe outra transformação importante.

IA não pertence apenas ao defensor.

Atacantes também podem utilizá-la para:

redigir mensagens
personalizar phishing
analisar perfis públicos
traduzir
simular estilos de escrita
automatizar interações
produzir áudio sintético

Isso reduz sinais que antigamente ajudavam vítimas.

O clássico:

“Esse e-mail está escrito errado, deve ser golpe.”

fica menos confiável.

A mensagem pode estar impecável.

A voz pode parecer convincente.

A assinatura pode parecer profissional.

O novo treinamento precisa ensinar:

Credibilidade visual não equivale a legitimidade.


⚠️ Capítulo 21 — O ataque perfeito parece uma terça-feira

O ataque barulhento é mais fácil.

DELETE DATABASE

gera atenção.

O sofisticado tenta parecer rotina.

Um registro hoje.

Outro amanhã.

Uma consulta pequena.

Um privilégio utilizado discretamente.

Isso é chamado frequentemente de comportamento low-and-slow.

Em vez de:

100 GB / 10 MINUTES

pode existir:

50 MB / DAY

durante meses.

O atacante quer ficar abaixo dos thresholds.

Por isso análise de comportamento não pode considerar apenas volume.

Precisa considerar:

sequência
frequência
relação
contexto
histórico

🧙‍♂️ Capítulo 22 — O sysprog paranoico talvez tivesse razão

Veteranos costumam fazer perguntas aparentemente pessimistas:

— E se esse acesso for comprometido?

— E se o batch rodar duas vezes?

— E se alguém tiver permissão demais?

— E se o fallback falhar?

— E se o log estiver errado?

Iniciantes às vezes enxergam isso como excesso de cautela.

Mas sistemas críticos amadurecem justamente porque alguém pensou:

WHAT IF?

Segurança é a disciplina de transformar “e se?” em arquitetura.


☕ Capítulo 23 — A grande lição para quem está começando em COBOL

Você talvez entre no mainframe pensando:

Preciso aprender PIC, COMP-3, PERFORM, JCL, VSAM e Db2.

Sim.

Mas trabalhar em sistemas críticos significa aprender também que uma transação não existe isoladamente.

Por trás daquele:

EXEC SQL
    UPDATE ACCOUNT
END-EXEC

existem perguntas:

Quem chamou?

Por quê?

De onde?

Com qual identidade?

Qual privilégio?

Qual auditoria?

Qual rastreabilidade?

Existe autorização?

Existe segregação?

Existe limite?

Existe rollback?

Existe reconciliação?

Existe monitoramento?

A segurança não começa no firewall.

Ela atravessa toda a aplicação.


🎩 O último truque de Arsène Lupin

Depois de atravessar todo o casarão, Lupin chega diante do cofre.

O dono pergunta:

— Como você abriu a porta?

Lupin responde:

— Eu não abri.

— Então como entrou?

— O senhor abriu para mim.

Esse talvez seja o resumo perfeito da engenharia social.

O atacante moderno nem sempre precisa derrotar nossos controles.

Pode simplesmente encontrar uma maneira de fazer com que nós mesmos os utilizemos em benefício dele.

Por isso, uma arquitetura realmente madura não pergunta apenas:

IS USER AUTHENTICATED?

Nem apenas:

IS USER AUTHORIZED?

Pergunta também:

IS THIS BEHAVIOR EXPECTED?
IS THIS CONTEXT NORMAL?
IS THIS ACTION PROPORTIONAL?
IS THIS SESSION STILL TRUSTWORTHY?

E talvez, principalmente:

IF EVERYTHING ELSE FAILS,
HOW BAD CAN IT GET?

Essa última pergunta separa sistemas frágeis de sistemas resilientes.

Porque segurança bancária não deveria ser construída sobre a esperança de que ninguém jamais erre.

Pessoas erram.

Modelos erram.

Procedimentos falham.

Credenciais são comprometidas.

Ferramentas possuem vulnerabilidades.

Alertas são ignorados.

A verdadeira maturidade aparece quando um desses eventos deixa de significar automaticamente:

GAME OVER

e passa a significar:

CONTROL 1 FAILED
CONTROL 2 ACTIVE
CONTROL 3 MONITORING
SOC ALERTED
DAMAGE CONTAINED

Esse é o coração da defesa em profundidade.

E talvez seja também a maior lição que um programador COBOL pode levar para segurança:

IF USER-AUTHENTICATED
   CONTINUE
ELSE
   STOP RUN
END-IF

era simples demais.

O mundo atual exige algo mais parecido com:

EVALUATE TRUE

   WHEN USER-NOT-AUTHENTICATED
      PERFORM DENY-ACCESS

   WHEN PRIVILEGE-NOT-VALID
      PERFORM DENY-ACCESS

   WHEN CONTEXT-SUSPICIOUS
      PERFORM STEP-UP-VALIDATION

   WHEN BEHAVIOR-ANOMALOUS
      PERFORM SECURITY-REVIEW

   WHEN RESOURCE-CRITICAL
      PERFORM SECOND-APPROVAL

   WHEN OTHER
      PERFORM NORMAL-PROCESSING

END-EVALUATE.

E no comentário do programa talvez exista uma linha que nenhum compilador entende, mas todo profissional de segurança deveria compreender:

*> NÃO CONFUNDA IDENTIDADE VÁLIDA COM INTENÇÃO LEGÍTIMA.

Porque o futuro da segurança bancária não será determinado apenas por quem possui a melhor fechadura.

Será determinado por quem consegue perceber mais rapidamente quando alguém atravessa uma porta perfeitamente autorizado...

...mas não deveria estar entrando naquela sala.

E em algum lugar de Paris, provavelmente Arsène Lupin estaria sorrindo.

Não porque conseguiu quebrar a segurança.

Mas porque ninguém percebeu que ele nunca precisou quebrá-la.

☕ Bem-vindo ao Bellacosa Mainframe.

Onde até o ACCESS GRANTED merece ser interrogado.

sábado, 11 de março de 2017

Nove Faltas? CTRL+Z — Quando o Banco de Dados Decide o que é Verdade

 

Bellacosa Mainframe e a o banco de dados alterado

☕ Um Café no Bellacosa Mainframe — Especial Red Team

Nove Faltas? CTRL+Z — Quando o Banco de Dados Decide o que é Verdade

💾 Ferris, registros escolares, integridade de dados e o perigo de confiar cegamente naquilo que aparece na tela

Chicago.

Uma escola.

Um diretor desconfiado.

Um aluno que já acumulou faltas suficientes para transformar o boletim numa pequena investigação administrativa.

E um computador.

A tela mostra um número.

Nove faltas.

O diretor Rooney conhece Ferris Bueller.

Conhece o histórico.

Conhece o comportamento.

Conhece a capacidade quase sobrenatural daquele adolescente de transformar regras em sugestões.

Ele suspeita.

Desconfia.

Quase consegue sentir que alguma coisa está errada.

Mas então acontece algo maravilhoso.

O número muda.

O computador registra outra realidade.

E, naquele instante, Ferris demonstra uma das vulnerabilidades mais antigas e persistentes da tecnologia:

quando a organização confunde o registro com a realidade.

Bem-vindo ao segundo episódio de:

SAVE FERRIS — Red Team para Quem Aprendeu que o Sistema Também Mata Aula

Hoje não vamos falar apenas de hackers.

Vamos falar de algo muito mais assustador.

Dados confiáveis demais.


🖥️ Se o computador diz, deve ser verdade

Quem trabalha com sistemas corporativos já ouviu alguma variação desta frase milhares de vezes:

— O pagamento foi feito?

— Está no sistema.

— O cliente possui autorização?

— Está no sistema.

— O funcionário está ativo?

— Está no sistema.

— A mercadoria saiu?

— Está no sistema.

— A transferência foi aprovada?

— Está no sistema.

— Esse usuário deveria possuir esse acesso?

— Está no sistema.

Maravilhoso.

Então está resolvido.

Exceto por uma pergunta ligeiramente inconveniente:

quem colocou essa informação no sistema?

E outra:

quem poderia alterá-la?

E uma terceira, ainda pior:

como saberíamos que foi alterada?

É aqui que o café começa a ficar forte.


💾 O dado não é a realidade

Essa distinção parece filosófica.

Mas é brutalmente prática.

Um banco de dados não armazena a realidade.

Armazena uma representação dela.

Se uma pessoa nasceu em determinada data, o sistema não armazena o nascimento.

Armazena algo como:

DATA_NASCIMENTO = 1980-03-14

Se um funcionário recebeu um pagamento, o sistema não armazena o ato econômico em si.

Armazena registros dizendo que aquilo ocorreu.

Se Ferris faltou à aula, o computador não armazena a cadeira vazia.

Armazena:

ABSENCES = 9

A diferença parece pequena.

Não é.

Porque a realidade física pode ser difícil de alterar.

O registro digital, às vezes, não.


🔴 Integridade: a palavra que parece chata até destruir sua empresa

Segurança costuma ser ensinada pela famosa tríade:

Confidencialidade
Integridade
Disponibilidade

A maioria das pessoas se apaixona imediatamente pela confidencialidade.

Senhas.

Criptografia.

Dados secretos.

Espionagem.

Hackers.

Tudo muito cinematográfico.

Disponibilidade também recebe atenção.

Sistema caiu?

Pânico.

Mas integridade frequentemente fica no meio, olhando para os lados, como aquele parente esquecido na fotografia.

Até o dia em que alguém altera alguma coisa.

Então todos descobrem que integridade era provavelmente a parte mais importante.

Porque um sistema disponível com dados errados pode ser pior que um sistema indisponível.

Muito pior.


☕ Imagine um banco perfeitamente disponível

Todos os servidores funcionando.

Nenhum downtime.

Rede perfeita.

Banco de dados online.

Aplicação respondendo em 50 milissegundos.

Usuários felizes.

Tudo verde.

Só existe um pequeno detalhe.

Alguém alterou:

SALDO = 10.000

para:

SALDO = 100.000

A disponibilidade está maravilhosa.

A confidencialidade talvez também.

Mas a integridade morreu.

E agora o sistema está funcionando perfeitamente para produzir resultados errados.

Isso é assustador.


🎬 Rooney sabe que alguma coisa está errada

É isso que torna a cena de Ferris tão interessante.

Rooney possui uma coisa que o computador não possui:

contexto.

Ele conhece Ferris.

Ele sabe que aquele número parece estranho.

A intuição diz:

“Isso não está certo.”

Mas organizações modernas frequentemente treinam pessoas a fazer o oposto.

O sistema virou autoridade.

A tela substitui o julgamento.

O operador pergunta.

O sistema responde.

Fim da conversa.

Esse é um tipo perigoso de automação cognitiva.


🧠 “Mas o sistema não pode estar errado”

Ah.

Pode.

Pode estar errado por defeito.

Pode estar errado por erro humano.

Pode estar errado por integração incorreta.

Pode estar errado por dado desatualizado.

Pode estar errado por fraude.

Pode estar errado porque alguém com privilégio alterou o registro.

Pode estar errado porque o próprio processo de entrada nunca foi confiável.

Pode estar errado porque um sistema anterior mandou informação errada.

Pode estar errado porque ninguém percebeu que o campo significava outra coisa.

E pode estar errado porque apareceu um Ferris Bueller.


🔐 Privilégio excessivo: quem pode alterar a verdade?

Aqui entramos num tema delicioso para Red Team.

Imagine um registro escolar.

Quem deveria poder alterar faltas?

Provavelmente poucos usuários.

Talvez professores.

Secretaria.

Administração.

Talvez algum processo automático.

Agora imagine que 40 pessoas possuem acesso.

Ou 400.

Ou uma conta técnica antiga.

Ou uma credencial compartilhada.

Ou um usuário com privilégio administrativo concedido cinco anos atrás para resolver uma emergência.

Você acaba de criar um pequeno mercado negro da verdade.


🪜 Least Privilege não é decoração de PowerPoint

O princípio de menor privilégio é simples:

cada identidade deve possuir apenas os acessos necessários para executar sua função.

Na prática, porém, organizações acumulam privilégios como minha geração acumulava disquetes.

Ninguém quer apagar nada.

Vai que precisa.

Então acontece:

2019 - acesso temporário
2020 - promoção
2021 - projeto emergencial
2022 - migração
2023 - suporte fornecedor
2024 - incidente
2025 - mudança de área
2026 - ninguém lembra por quê

Resultado:

O usuário que deveria consultar possui alteração.

O operador possui administração.

A conta de serviço possui permissões globais.

A aplicação antiga continua autenticando.

E Ferris agradece.


🧾 “Quem alterou isso?”

Essa é provavelmente uma das perguntas mais importantes de qualquer sistema crítico.

Não basta permitir alteração.

É necessário responder:

quem;

quando;

de onde;

qual valor anterior;

qual valor novo;

por qual processo;

com qual identidade;

sob qual autorização.

Isso é trilha de auditoria.

Sem isso, depois do incidente começa o esporte corporativo favorito:

arqueologia de logs.


📜 Antes e depois

Imagine um bom registro:

TIME: 10:42:11
USER: USER123
OBJECT: STUDENT.FERRIS
FIELD: ABSENCES
OLD_VALUE: 9
NEW_VALUE: 2
SOURCE: ADMIN_CONSOLE
SESSION: 883201

Agora temos alguma coisa.

Podemos perguntar:

USER123 deveria fazer isso?

Estava trabalhando naquele horário?

A sessão era legítima?

Houve aprovação?

Existe outro evento relacionado?

O IP é esperado?

O dispositivo é conhecido?

Perceba como a investigação muda.

Sem log:

— Alguém mudou.

Com log:

— Podemos reconstruir a história.


🕵️ Insider Threat: o inimigo já tem crachá

Outra coisa importante.

Quando falamos de ataque, imaginamos frequentemente alguém de fora.

O hacker misterioso.

O russo numa sala escura.

O adolescente no porão.

O grupo criminoso.

Mas muitos sistemas podem ser abusados por quem já possui acesso.

Isso é insider threat.

E insider não significa necessariamente um funcionário maligno tramando destruir a empresa.

Pode ser:

funcionário fraudando;

administrador curioso;

terceirizado abusando de acesso;

usuário cometendo erro;

conta legítima comprometida por atacante externo.

O sistema vê uma identidade autorizada.

Mas não sabe necessariamente se a intenção é legítima.


🧠 O problema da identidade válida

Isso é particularmente perverso.

Defesas tradicionais procuram comportamento obviamente hostil.

Mas imagine:

LOGIN = SUCCESS
MFA = SUCCESS
USER = AUTHORIZED
ACTION = ALLOWED

Tudo certo.

Só que a pessoa por trás da sessão não deveria estar fazendo aquilo.

Ou talvez nem seja a pessoa.

Do ponto de vista técnico, o sistema está funcionando.

Do ponto de vista de segurança, você tem um incidente.

Ferris provavelmente adoraria essa zona cinzenta.


🏦 Agora troque escola por banco

Vamos aumentar um pouco o tamanho do problema.

Em vez de:

ABSENCES = 9

temos:

CREDIT_LIMIT = 50.000

ou:

ACCOUNT_STATUS = ACTIVE

ou:

TRANSFER_APPROVED = YES

Agora integridade deixa de ser tema escolar.

Vira dinheiro.

Compliance.

Auditoria.

Regulação.

Fraude.


🦖 E no mainframe?

Aqui o assunto fica especialmente interessante.

Mainframes são máquinas construídas em torno de processamento confiável.

Transações.

Registros.

Contabilidade.

Bancos.

Seguradoras.

Governos.

Sistemas onde dados não podem simplesmente “mais ou menos” estar corretos.

Imagine um ambiente:

CICS
  ↓
COBOL
  ↓
Db2

O usuário executa uma transação.

O programa altera um registro.

O banco confirma.

Tudo perfeito.

Mas segurança não pergunta apenas:

a transação funcionou?

Pergunta:

quem tinha autoridade para executá-la?


🔐 RACF não lê sua alma

RACF pode controlar quem acessa o quê.

Pode ser extremamente granular.

Pode registrar eventos.

Pode aplicar políticas.

Mas existe uma verdade desconfortável:

um sistema de controle de acesso valida identidade e permissão.

Não intenção.

Se uma conta autorizada é comprometida, o controle pode legitimamente permitir a ação.

Por isso segurança moderna precisa de camadas.

Autenticação.

Autorização.

Monitoramento.

Auditoria.

Detecção comportamental.

Segregação de funções.

Revisão.


🧱 Segregação de funções: não dê a Ferris o lápis e a borracha

Uma das maneiras mais antigas de reduzir fraude é simples:

não permita que uma única pessoa controle todo o processo.

Quem cria não aprova.

Quem solicita não executa.

Quem altera não audita.

Isso é segregation of duties.

Porque se uma pessoa pode:

CREATE
ALTER
APPROVE
DELETE_LOG

então ela basicamente possui a versão corporativa do poder de Ferris sobre suas faltas.

Pode mudar a realidade e apagar as pegadas.

Nada ideal.


🚨 O log também precisa de integridade

Aqui aparece uma pegadinha elegante.

Você criou auditoria.

Excelente.

Mas quem pode alterar o log?

Se o mesmo administrador que modifica dados pode apagar eventos, temos um problema.

É como instalar uma câmera de segurança e deixar o suspeito com a chave da sala onde ficam as gravações.

Logs precisam ser protegidos.

Idealmente enviados para outro ambiente.

Com retenção.

Controles.

Imutabilidade quando possível.

Porque a trilha de auditoria só é útil se também for confiável.


🧼 “Não encontramos evidência”

Outra frase maravilhosa.

Às vezes significa:

não aconteceu.

Às vezes significa:

ninguém procurou direito.

Às vezes:

os logs não existiam.

Às vezes:

os logs foram apagados.

Às vezes:

o evento aconteceu num sistema diferente.

E às vezes:

a investigação estava procurando no lugar errado.

Red Team adora essa questão.

Não basta perguntar:

“O ataque seria bloqueado?”

Pergunte também:

“Seria detectado?”

E depois:

“Conseguiríamos explicar o que aconteceu?”


🧭 Prevenção sem detecção é fé

Imagine duas empresas.

Empresa A possui controles excelentes.

Mas praticamente nenhuma visibilidade.

Empresa B possui controles razoáveis e ótima detecção.

Qual é mais segura?

Depende.

Mas a empresa A talvez nunca saiba quando o controle falhar.

Isso é perigoso.

Nenhum controle é perfeito.

Então Red Team deve testar:

prevenção;

detecção;

resposta.

Ferris pode conseguir alterar o número.

A pergunta seguinte é:

alguém perceberia?


📊 “Está no dashboard”

Em 2026 temos uma nova versão do mesmo problema.

Não apenas:

“Está no sistema.”

Agora temos:

“Está no dashboard.”

O dashboard mostra verde.

Então está tudo bem.

Talvez.

Mas dashboards também são representações.

Eles dependem de:

dados;

regras;

queries;

thresholds;

integrações;

timing.

Se qualquer uma dessas partes estiver errada, você terá uma bela visualização de uma realidade inexistente.


🤖 E agora temos IA dizendo o que é verdade

A coisa ficou ainda mais interessante.

Sistemas modernos podem resumir logs.

Interpretar eventos.

Classificar risco.

Priorizar alertas.

Gerar respostas.

Fantástico.

Mas existe o perigo de transformar:

SYSTEM SAYS

em:

TRUTH

Agora não é apenas um campo no banco.

É uma interpretação automatizada.

E usuários podem confiar demais.

Automation Bias entra pela porta.


🧠 O operador acredita na máquina

Suponha que um analista veja:

RISK SCORE: LOW

Pode relaxar.

Mas como esse score foi calculado?

Quais sinais entraram?

Algum dado estava faltando?

Um atacante conseguiu influenciar a entrada?

O modelo conhece aquele padrão?

A confiança na ferramenta pode ser explorada tanto quanto qualquer outra confiança.

Ferris não precisa enganar apenas pessoas.

Pode enganar as máquinas que ajudam pessoas a decidir.


🧪 Data Poisoning: Ferris aprende estatística

Vamos imaginar uma versão moderna.

Se um sistema aprende padrões históricos, o que acontece se alguém conseguir contaminar esses padrões?

Pouco a pouco, comportamentos anormais podem parecer normais.

Isso é uma forma de data poisoning.

A velha cena de Ferris ganha nova vida.

Ele não precisa apenas alterar:

ABSENCES = 9

Talvez queira alterar o mecanismo que decide o que significa “frequência normal”.

A escala muda.

A filosofia permanece.


🧾 Fonte da verdade não significa fonte infalível

Empresas adoram a expressão:

Single Source of Truth.

É útil.

Evita sistemas discordando.

Centraliza informação.

Mas existe um problema semântico.

Uma fonte única da verdade não é necessariamente verdadeira.

Ela é apenas a fonte que todos concordaram em usar.

Se estiver errada, todos errarão de maneira consistente.

Isso é operacionalmente elegante.

E filosoficamente aterrorizante.


💣 Uma verdade errada propagada perfeitamente

Imagine:

Sistema A registra valor errado.

Sistema B consome.

Sistema C replica.

Data lake armazena.

Dashboard mostra.

IA resume.

Executivo recebe relatório.

Agora temos:

ERRO
 ↓
INTEGRAÇÃO
 ↓
PROPAGAÇÃO
 ↓
ANÁLISE
 ↓
DECISÃO

A cadeia inteira funcionou perfeitamente.

Parabéns.

Você automatizou o erro.


🎯 Red Team precisa atacar a confiança nos dados

Esse tipo de exercício é extremamente valioso.

Não apenas:

“Consigo acessar o banco?”

Mas:

“Consigo modificar um dado crítico?”

“Isso dispara alerta?”

“Qual sistema percebe?”

“Quanto tempo leva?”

“Quem investiga?”

“Existe reconciliação?”

“Existe validação independente?”

“Existe dupla aprovação?”

“Existe trilha?”

Agora estamos testando integridade de verdade.


🧠 A pergunta Bellacosa

Eu faria uma pergunta particularmente desagradável numa War Room:

“Qual dado, se alterado silenciosamente, poderia causar mais estrago sem derrubar nenhum sistema?”

Pense.

Talvez não seja senha.

Talvez seja:

limite de crédito;

status de cliente;

conta bancária de fornecedor;

parâmetro de juros;

identidade;

regra fiscal;

preço;

saldo;

permissão;

modelo de risco.

Isso é uma superfície de ataque completamente diferente.


🚦 Sistema verde, negócio vermelho

Imagine:

CPU normal.

Disco normal.

Rede normal.

Banco online.

CICS respondendo.

MQ fluindo.

APIs funcionando.

Tudo verde.

Só que alguém alterou uma tabela de parâmetros.

Agora cada transação está ligeiramente errada.

Nada cai.

Nada trava.

Nenhum alerta tradicional dispara.

O sistema virou uma máquina perfeitamente funcional de produzir prejuízo.

Esse tipo de incidente é muito mais interessante que simplesmente derrubar um servidor.


🧩 Ferris não quer destruir a escola

Essa é outra razão pela qual a metáfora funciona.

Ferris não quer incendiar o prédio.

Não quer destruir o computador.

Não quer impedir a escola de funcionar.

Quer apenas fazer o sistema acreditar em outra versão da realidade.

Atacantes financeiros frequentemente preferem exatamente isso.

Silêncio.

Discrição.

Mudanças pequenas.

Persistentes.

Porque interrupção chama atenção.

Fraude silenciosa paga melhor.


🕶️ O atacante perfeito talvez pareça um usuário normal

Essa é uma das conclusões mais importantes.

Se a ação maliciosa parece uma ação autorizada, detecção fica difícil.

Por isso precisamos de contexto.

Quem normalmente faz isso?

Em qual horário?

Com qual frequência?

De qual dispositivo?

Em qual volume?

Depois de qual evento?

Segurança não pode olhar apenas para:

ALLOW
DENY

Precisa olhar para comportamento.


🔵 Rooney versus o computador

Voltemos a Rooney.

Ele possui intuição.

O computador possui registro.

A segurança madura precisa dos dois.

Dados.

Contexto.

Automação.

Experiência humana.

Nenhum deveria dominar cegamente.

Rooney também pode estar errado.

Sua obsessão por Ferris prova isso.

Mas o computador também pode.

A chave é não transformar nenhuma fonte em autoridade absoluta.


☕ “Está no sistema” não significa “é verdade”

Essa frase deveria estar impressa em muitas salas de operação.

Talvez em letras grandes.

Porque sistemas registram aquilo que conseguimos observar.

E aquilo que alguém informou.

E aquilo que integrações enviaram.

E aquilo que processos permitiram.

Eles não possuem acesso mágico à realidade.

Então sempre precisamos perguntar:

Como esse dado nasceu?

Quem pode alterá-lo?

Como validamos?

Como auditamos?

Como detectamos inconsistências?


🔴 Integridade é confiança verificável

No final, integridade significa uma coisa muito simples:

poder confiar que informação não foi alterada de maneira indevida.

Mas “confiar” não pode significar fé.

Precisa existir evidência.

Controles.

Logs.

Reconciliação.

Segregação.

Revisão.

Detecção.

E capacidade de reconstruir eventos.


🎬 Ferris Bueller e o primeiro ataque à verdade digital

Talvez Ferris não tivesse percebido a profundidade filosófica do que estava fazendo.

Provavelmente só queria matar aula.

Mas aquele computador escolar antecipou um problema que cresceria enormemente nas décadas seguintes.

O mundo passou a depender cada vez mais de registros digitais.

Dinheiro virou registro.

Identidade virou registro.

Propriedade virou registro.

Saúde virou registro.

Reputação virou registro.

Autorizações viraram registros.

E quanto mais a sociedade digitaliza, maior fica o valor de alterar silenciosamente aquilo que ela acredita ser verdade.


☕ Epílogo: nove faltas desapareceram

Rooney olha para Ferris.

Ferris olha para o computador.

O computador olha para ninguém.

Ele apenas executa comandos.

Essa talvez seja a parte mais importante.

A máquina não sabe que está mentindo.

Ela não sabe que está dizendo a verdade.

Ela simplesmente armazena estado.

Nós é que atribuímos confiança.

E é exatamente essa confiança que Red Team deve testar.

Porque entre:

REALITY

e:

DATABASE

existe sempre um caminho.

Alguém coleta.

Alguém transmite.

Alguém grava.

Alguém altera.

Alguém consulta.

Alguém interpreta.

Cada etapa pode falhar.

Cada etapa pode ser abusada.

Cada etapa pode virar uma porta.

Então da próxima vez que alguém disser:

“Mas está no sistema.”

Sirva outro café.

Olhe para Ferris.

E faça a pergunta mais importante:

“Quem disse ao sistema que isso era verdade?”

☕ SAVE FERRIS.

No próximo artigo:

Abe Froman, o Rei da Salsicha de Chicago — A Aula de Engenharia Social que Ninguém Percebeu

Porque talvez você não precise hackear um banco de dados.

Talvez precise apenas convencer alguém de que você deveria estar sentado naquela mesa.

☕ Um Café no Bellacosa Mainframe — Especial Red Team

SAVE FERRIS — Ferris Bueller’s Red Team

Uma série de 12 artigos sobre Red Team, segurança ofensiva, engenharia social, OSINT, integridade de dados, MFA, PAM, rollback, Blue Team, inteligência artificial, RACF e z/OS, usando Ferris Bueller para explorar uma pergunta fundamental: o sistema está realmente seguro ou apenas acredita que está?

  • Red Team
  • OSINT
  • Engenharia Social
  • Blue Team
  • MFA
  • PAM
  • IA Generativa
  • RACF
  • z/OS
  • Mainframe
1

Ferris Bueller Tinha um Plano de Ataque — Red Team Antes de Existir Red Team

Reconhecimento, criatividade adversarial e a ideia de que o verdadeiro alvo nem sempre é a tecnologia: são as suposições de quem construiu o sistema.

Red Team • Recon • Threat Modeling • Criatividade Adversarial
2

Nove Faltas? CTRL+Z — Quando o Banco de Dados Decide o que é Verdade

Integridade de dados, alteração de registros, privilégio, auditoria e a perigosa diferença entre aquilo que aconteceu e aquilo que o banco de dados afirma ter acontecido.

Integridade • Db2 • Auditoria • Insider Threat • Dados
3

Abe Froman, o Rei da Salsicha de Chicago — A Aula de Engenharia Social que Ninguém Percebeu

Pretexting, autoridade inventada e confiança contextual: Identity, Authentication e Authorization não são a mesma coisa.

Engenharia Social • Pretexting • Identity • Authentication
4

“Você Conhece o Diretor Rooney?” — OSINT Antes do Google Existir

Como dados públicos sobre pessoas, tecnologias, hábitos, empresas e relacionamentos podem revelar uma superfície de ataque antes do primeiro scan.

OSINT • Recon • LinkedIn • GitHub • Attack Surface
5

Cameron, Atenda o Telefone — Social Engineering as a Service

Ferris → Cameron → telefone → escola → funcionário → sistema. Nenhuma peça precisa falhar sozinha quando a cadeia inteira possui uma combinação explorável de confiança.

Social Engineering • Swiss Cheese Model • Human Risk
6

O Diretor Rooney Está Procurando Malware no Lugar Errado

Firewall, SIEM, EDR e Zero Trust podem funcionar perfeitamente enquanto engenharia social, Help Desk e processos humanos criam outro caminho até o objetivo.

SOC • SIEM • EDR • Zero Trust • Engenharia Social
7

A Ferrari do Cameron Não Tinha MFA

Privilégio, acesso físico, MFA, PAM, least privilege e o risco de proteger um ativo crítico apenas com medo, confiança e a esperança de que ninguém ousará tocá-lo.

MFA • PAM • Least Privilege • Privileged Access
8

Colocamos a Ferrari em Ré — Por Que Rollback Não É Backup

Rollback, restore, journaling, logs, Db2, VSAM e recuperação: voltar o estado de um sistema não significa apagar as consequências daquilo que aconteceu.

Backup • Restore • Rollback • Db2 • VSAM • Recovery
9

Rooney Invadiu a Casa Errada — Quando o Blue Team Vira o Próprio Incidente

Confirmation Bias, tunnel vision, Sunk Cost, Authority Gradient e o risco de uma resposta defensiva criar mais impacto que o próprio atacante.

Blue Team • SOC • Cognitive Bias • Incident Response
10

FerrisGPT — Agora o Adolescente Tem um Exército de Estagiários Sintéticos

IA generativa, agentes, OSINT automatizado, deepfake, voice cloning e automação transformam o ataque artesanal em uma capacidade paralela e escalável.

Generative AI • Agents • Deepfake • Voice Cloning • OSINT
11

Ferris Entra no Mainframe — RACF, z/OS e o Dia em que SPECIAL Virou o Passe para Chicago

RACF, SAF, ACEE, APF, USS, TSO, CICS, Db2, MQ, z/OS Connect, Zowe e service accounts vistos pela ótica dos caminhos de ataque até o mainframe.

Mainframe • RACF • z/OS • CICS • Db2 • MQ • Zowe
12

“A Vida Passa Muito Rápido” — O Red Team Depois que Todo Mundo Foi Embora

Red Team não termina em “conseguimos entrar”. Ataque deve gerar descoberta, evidência, correção, detecção e aprendizado para deixar a organização mais resiliente.

Red Teaming • Purple Team • Detection • Resilience • Learning

🎬 Página principal da temporada

Ferris Bueller’s Red Team: Como Hackear o Sistema Sem Precisar Roubar a Ferrari do Cameron reúne os doze episódios e conecta Red Team, engenharia social, IA, Blue Team e segurança de mainframe.

☕ Acessar o especial completo SAVE FERRIS

Sobre a série SAVE FERRIS — Red Team

A série SAVE FERRIS, publicada no Bellacosa Mainframe, utiliza situações inspiradas em Ferris Bueller para explicar conceitos de Red Team, cybersecurity, segurança ofensiva, engenharia social, OSINT, Blue Team, Purple Team, Zero Trust, MFA, PAM, inteligência artificial, RACF, IBM z/OS, CICS, Db2, MQ e segurança de mainframe.

O fio condutor é simples: um atacante não precisa necessariamente quebrar a tecnologia. Ele pode explorar relações de confiança, processos, identidades, privilégios, integrações e suposições existentes entre pessoas e sistemas.

A temporada acompanha o ciclo completo: reconhecimento → engenharia social → acesso → privilégio → impacto → detecção → correção → aprendizado.

Para Red Teams e Blue Teams, o objetivo final não é provar quem é mais inteligente, mas encontrar caminhos invisíveis antes que um adversário real os descubra.

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...