☕ 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

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.

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