Inteligência Artificial na Segurança Bancária sem Mistérios

Bellacosa Mainframe e a inteligencia artificial na seguranca bancaria

☕ Um Café no Bellacosa Mainframe

Inteligência Artificial na Segurança Bancária sem Mistérios

O Guia do Programador COBOL Padawan para Entender Biometria, Fraudes, Autenticação Contínua e os Escudos Digitais da Frota Estelar

Imagine, jovem programador COBOL Padawan, que você está sentado diante de um terminal 3270 em uma madrugada silenciosa.

Ao lado do teclado, uma caneca de café ainda quente. Na tela verde, um programa aparentemente simples processa uma transferência bancária. Ele recebe uma conta de origem, uma conta de destino, um valor e uma data. Depois de algumas validações, o sistema autoriza ou rejeita a operação.

Durante décadas, essa lógica pareceu suficiente.

O cliente informava a senha correta, o saldo era consultado, os limites eram verificados e a transação seguia seu caminho pelos corredores eletrônicos do banco.

Mas a galáxia financeira mudou.

Hoje, o usuário pode estar acessando o banco por um celular, conectado a uma rede pública, utilizando reconhecimento facial, fazendo um PIX para um novo destinatário e movimentando um valor muito diferente de seu padrão habitual.

Ao mesmo tempo, o criminoso pode possuir a senha verdadeira, o CPF, o número do telefone, documentos vazados, gravações da voz da vítima e até uma cópia artificial de seu rosto produzida por inteligência artificial.

A pergunta deixou de ser apenas:

“A senha está correta?”

Agora o banco precisa perguntar:

“Essa operação parece realmente estar sendo realizada pelo cliente?”

Essa mudança representa uma das maiores transformações na história da segurança bancária.

A segurança deixou de ser apenas um portão na entrada do sistema. Ela passou a acompanhar o cliente durante toda a jornada.

É como se os sistemas financeiros tivessem aprendido uma antiga lição da Frota Estelar:

Não basta identificar quem entrou na nave. É necessário observar o que essa pessoa faz depois de entrar.

Prepare o café, ajuste seu comunicador e abra uma nova sessão no TSO. Nossa missão será entender como inteligência artificial, biometria, autenticação multifator, análise comportamental, modelos de risco e mainframes trabalham juntos para proteger o sistema financeiro moderno.

---

1. O velho modelo: usuário, senha e confiança

Durante muito tempo, a segurança digital funcionou com uma lógica simples.

O usuário informava:

• identificação;

• senha;

• eventualmente um código adicional.

Se tudo estivesse correto, o acesso era concedido.

Em pseudocódigo COBOL, poderíamos imaginar algo assim:

IF SENHA-INFORMADA = SENHA-CADASTRADA
    MOVE 'S' TO ACESSO-AUTORIZADO
ELSE
    MOVE 'N' TO ACESSO-AUTORIZADO
END-IF

A lógica é clara, objetiva e fácil de compreender.

O problema é que ela responde apenas a uma pergunta:

A credencial apresentada corresponde à credencial armazenada?

Ela não responde:

• quem digitou a senha;

• onde a senha foi digitada;

• em qual dispositivo;

• em qual horário;

• em qual contexto;

• com qual intenção;

• se o comportamento é compatível com o histórico do cliente.

Se um criminoso roubar a senha verdadeira, o sistema tradicional poderá tratá-lo como usuário legítimo.

Esse é um dos princípios fundamentais para compreender a segurança moderna:

Uma credencial válida não significa necessariamente uma identidade legítima.

Senhas podem ser descobertas por phishing, engenharia social, vazamentos de dados, malware, observação física, reutilização em vários serviços ou manipulação psicológica.

Um cliente pode entregar voluntariamente um código de segurança acreditando estar falando com um funcionário do banco.

Nesse caso, tecnicamente, as informações estão corretas. Porém, a operação continua sendo fraudulenta.

A segurança bancária moderna precisou evoluir de uma validação estática para uma avaliação contínua de risco.

---

2. O criminoso não precisa arrombar a porta

Existe uma imagem clássica do invasor digital: alguém tentando quebrar uma senha, explorar uma falha ou invadir um servidor.

Esse tipo de ataque continua existindo.

Porém, muitos golpes atuais seguem um caminho mais silencioso.

O fraudador pode convencer a própria vítima a:

• instalar um aplicativo;

• compartilhar a tela;

• fornecer um código;

• transferir dinheiro;

• cadastrar um novo dispositivo;

• autorizar um pagamento;

• entregar informações pessoais.

O criminoso não precisa destruir os escudos da nave.

Ele pode convencer o oficial de segurança a desativá-los.

Essa é a essência da engenharia social.

Os ataques modernos exploram não apenas sistemas, mas também emoções humanas:

• medo;

• urgência;

• autoridade;

• curiosidade;

• ganância;

• confiança;

• pressão psicológica.

Uma mensagem pode dizer:

“Sua conta será bloqueada em dez minutos.”

Outra pode afirmar:

“Identificamos uma compra suspeita. Confirme seus dados agora.”

O cliente, preocupado, segue as instruções do próprio fraudador.

Por isso, proteger apenas a senha é insuficiente. O sistema precisa avaliar o contexto completo da operação.

---

3. A autenticação não termina no login

No modelo antigo, o login era considerado o grande momento da segurança.

A sequência era:

Identificação
      ↓
Senha
      ↓
Acesso autorizado

Depois do acesso, o sistema passava a confiar no usuário.

No modelo moderno, a sequência é muito mais ampla:

Identificação
      ↓
Senha ou credencial
      ↓
Biometria
      ↓
Dispositivo
      ↓
Localização
      ↓
Comportamento
      ↓
Análise de risco
      ↓
Monitoramento da sessão
      ↓
Reavaliação a cada operação

A autenticação tornou-se contínua.

Isso significa que uma sessão pode começar com baixo risco e, alguns minutos depois, apresentar sinais suspeitos.

Por exemplo:

1. O cliente acessa o aplicativo em seu celular habitual.

2. Consulta o saldo.

3. Navega normalmente.

4. Em seguida, cadastra um novo favorecido.

5. Solicita um empréstimo.

6. Transfere imediatamente todo o valor.

7. O destino é uma conta nunca utilizada.

8. O comportamento de digitação é diferente.

9. O aparelho parece estar sendo controlado remotamente.

Cada ação, isoladamente, pode ser legítima.

Porém, o conjunto forma um padrão de alto risco.

A inteligência artificial consegue observar essa sequência em tempo real e recalcular a probabilidade de fraude.

Em outras palavras, o sistema deixa de perguntar apenas:

“Quem entrou?”

E passa a perguntar constantemente:

“O que está acontecendo agora?”

---

4. Zero Trust: nunca confiar automaticamente

Um dos conceitos mais importantes da segurança moderna é o chamado Zero Trust.

O nome pode parecer severo, mas sua lógica é bastante racional:

Nunca confie automaticamente. Sempre verifique.

Isso não significa tratar todos os clientes como criminosos.

Significa não depender de uma única prova de identidade.

Mesmo um usuário autenticado precisa continuar sendo avaliado.

Na Frota Estelar, possuir um uniforme não seria suficiente para acessar o núcleo de dobra. O sistema também verificaria:

• identidade;

• patente;

• autorização;

• localização;

• horário;

• missão;

• contexto;

• nível de risco.

No setor bancário, acontece algo semelhante.

Uma transferência pode exigir verificações adicionais conforme o risco.

Por exemplo:

EVALUATE NIVEL-RISCO
    WHEN 'BAIXO'
        PERFORM AUTORIZAR-TRANSACAO
    WHEN 'MEDIO'
        PERFORM SOLICITAR-SEGUNDO-FATOR
    WHEN 'ALTO'
        PERFORM BLOQUEAR-TRANSACAO
        PERFORM GERAR-ALERTA
    WHEN OTHER
        PERFORM ENCAMINHAR-ANALISE-MANUAL
END-EVALUATE

Esse exemplo mostra um ponto importante: segurança moderna não é apenas “permitir” ou “negar”.

Ela pode aplicar diferentes respostas:

• liberar;

• solicitar biometria;

• solicitar token;

• limitar valor;

• atrasar a operação;

• enviar alerta;

• bloquear temporariamente;

• encaminhar para análise humana.

O sistema adapta a proteção ao risco observado.

---

5. A IA não procura apenas criminosos

Muitas pessoas imaginam que a inteligência artificial possui uma lista de fraudadores conhecidos e compara cada usuário com essa lista.

Isso pode fazer parte do processo, mas é apenas uma pequena parte.

Na prática, a IA busca principalmente anomalias.

Uma anomalia é algo diferente do padrão esperado.

Considere um cliente que, durante vários anos:

• acessa o aplicativo entre 7h e 22h;

• utiliza sempre o mesmo celular;

• mora no interior de São Paulo;

• movimenta valores entre R$ 50 e R$ 1.000;

• realiza pagamentos para poucos destinatários conhecidos.

Agora imagine a seguinte operação:

• acesso às 3h17;

• novo aparelho;

• nova localização;

• uso de VPN;

• tentativa de empréstimo;

• transferência de R$ 48.000;

• destinatário recém-cadastrado.

Nenhum desses elementos, sozinho, prova uma fraude.

Um cliente pode viajar, trocar de celular ou realizar uma transferência elevada.

Mas o conjunto aumenta fortemente o risco.

A IA analisa dezenas ou centenas de sinais ao mesmo tempo.

Ela não pergunta simplesmente:

“Essa pessoa é criminosa?”

Ela pergunta:

“Esse comportamento é compatível com o histórico e o contexto esperado?”

Essa diferença é essencial.

---

6. Machine Learning: ensinando o sistema a reconhecer padrões

O aprendizado de máquina, ou Machine Learning, permite que sistemas identifiquem padrões a partir de grandes volumes de dados.

Um sistema antifraude pode aprender com:

• transações legítimas;

• fraudes confirmadas;

• horários;

• valores;

• localização;

• dispositivos;

• destinatários;

• canais utilizados;

• comportamento de navegação;

• velocidade das ações;

• respostas a autenticações;

• histórico de contestação.

Imagine milhões de transações sendo processadas diariamente.

Nenhum analista humano conseguiria revisar cada uma em tempo real.

A inteligência artificial consegue calcular rapidamente a probabilidade de uma operação ser legítima ou suspeita.

Um modelo simplificado poderia considerar:

Dispositivo conhecido: risco reduzido
Localização habitual: risco reduzido
Valor muito elevado: risco aumentado
Novo favorecido: risco aumentado
Horário incomum: risco aumentado
Biometria válida: risco reduzido
Aparelho comprometido: risco elevado

O resultado final pode ser transformado em um score.

Exemplo:

Score de risco: 12 de 100
Decisão: autorizar

Outro caso:

Score de risco: 87 de 100
Decisão: bloquear e solicitar validação

Para o programador COBOL iniciante, pense no score como um campo calculado a partir de várias condições.

MOVE ZERO TO SCORE-RISCO

IF DISPOSITIVO-NOVO = 'S'
    ADD 20 TO SCORE-RISCO
END-IF

IF LOCALIZACAO-INCOMUM = 'S'
    ADD 25 TO SCORE-RISCO
END-IF

IF VALOR-ACIMA-PADRAO = 'S'
    ADD 30 TO SCORE-RISCO
END-IF

IF BIOMETRIA-VALIDA = 'S'
    SUBTRACT 20 FROM SCORE-RISCO
END-IF

Os modelos reais são muito mais complexos, mas o princípio permanece semelhante: sinais são combinados para apoiar uma decisão.

---

7. Biometria: muito além da impressão digital

A biometria utiliza características humanas para validar a identidade.

As formas mais conhecidas incluem:

• impressão digital;

• reconhecimento facial;

• voz;

• íris;

• geometria da mão.

A grande vantagem é que características biométricas são mais difíceis de compartilhar, esquecer ou digitar acidentalmente em um site falso.

Entretanto, biometria não deve ser tratada como solução mágica.

Uma fotografia pode ser roubada. Uma voz pode ser gravada. Um rosto pode ser reproduzido por deepfake.

Por isso, sistemas modernos utilizam mecanismos chamados de prova de vida, ou liveness detection.

A prova de vida tenta verificar se existe uma pessoa real diante do dispositivo.

Ela pode observar:

• profundidade facial;

• movimentos naturais;

• reflexos;

• textura da pele;

• resposta a comandos;

• movimentação dos olhos;

• sincronização labial;

• pequenas variações impossíveis em uma fotografia estática.

Um sistema pode pedir:

“Mova o rosto para a esquerda.”

Ou analisar silenciosamente características tridimensionais.

O objetivo é diferenciar uma pessoa real de:

• fotografia;

• vídeo;

• máscara;

• tela reproduzindo outro rosto;

• conteúdo sintético.

Curiosidade de bordo: em histórias de ficção científica, scanners biométricos quase sempre reconhecem rostos instantaneamente. Na vida real, iluminação, câmera, ângulo, envelhecimento e qualidade do sensor tornam o problema muito mais complexo.

---

8. Biometria comportamental: a assinatura invisível

A biometria tradicional analisa características físicas.

A biometria comportamental analisa como uma pessoa interage com o sistema.

Ela pode observar:

• ritmo de digitação;

• tempo entre teclas;

• força aplicada na tela;

• velocidade do toque;

• inclinação do aparelho;

• forma de segurar o celular;

• movimento do mouse;

• padrão de rolagem;

• tempo de leitura;

• sequência de navegação.

Imagine duas pessoas digitando a mesma senha.

A primeira digita rapidamente, utilizando os dois polegares.

A segunda faz pausas, utiliza um dedo e pressiona determinadas teclas por mais tempo.

O texto é igual, mas o comportamento é diferente.

Essas diferenças formam uma espécie de assinatura invisível.

Outro exemplo:

O cliente legítimo normalmente abre o aplicativo, verifica o saldo, consulta o extrato e depois faz uma transferência.

O fraudador pode entrar diretamente na opção de empréstimo, contratar o valor máximo e transferir imediatamente.

O caminho percorrido dentro da aplicação também é um sinal.

A grande vantagem da biometria comportamental é que ela pode funcionar silenciosamente, sem exigir ações adicionais do usuário.

O cliente legítimo percebe menos fricção.

O fraudador encontra mais barreiras.

---

9. Autenticação contextual: onde, quando, como e com quê

A autenticação contextual analisa as circunstâncias da operação.

Entre os sinais avaliados estão:

• localização;

• endereço IP;

• operadora;

• rede Wi-Fi;

• horário;

• idioma;

• fuso horário;

• modelo do dispositivo;

• versão do sistema;

• navegador;

• resolução da tela;

• presença de VPN;

• histórico do aparelho.

Imagine um cliente que mora em Campinas e acessa o banco às 14h.

Cinco minutos depois, ocorre outro acesso a partir de outro continente.

Fisicamente, isso seria impossível.

Esse tipo de evento pode ser classificado como viagem impossível.

O sistema pode bloquear a nova sessão ou solicitar validação adicional.

Outro exemplo:

Um cliente sempre utiliza o aplicativo em um aparelho Android específico. De repente, ocorre um acesso em um emulador, com sistema modificado e ferramentas de automação.

Esse contexto aumenta o risco, mesmo que a senha esteja correta.

A autenticação contextual não substitui a senha ou a biometria. Ela adiciona mais evidências.

É como uma investigação vulcana: nenhuma conclusão é baseada em uma única pista.

---

10. Token e autenticação multifator

A autenticação multifator combina diferentes tipos de prova.

Os fatores costumam ser divididos em três categorias:

Algo que você sabe

• senha;

• PIN;

• resposta secreta.

Algo que você possui

• celular;

• cartão;

• token físico;

• aplicativo autenticador.

Algo que você é

• rosto;

• impressão digital;

• voz;

• íris.

Usar dois ou mais fatores reduz o risco de uma única credencial comprometida permitir acesso completo.

Porém, até a autenticação multifator pode ser atacada.

Códigos podem ser interceptados. Usuários podem ser convencidos a aprovar notificações. Chips podem ser clonados ou transferidos ilegalmente.

Por isso, o setor caminha para uma combinação mais ampla:

Senha
+
Dispositivo
+
Biometria
+
Contexto
+
Comportamento
+
Análise de risco

Quanto mais coerentes forem os sinais, maior a confiança.

Quanto mais contraditórios, maior a necessidade de verificação.

---

11. A luta contra falsos positivos

Bloquear fraudes é importante.

Mas bloquear clientes legítimos também causa problemas.

Imagine um cliente tentando pagar uma cirurgia, comprar uma passagem ou transferir dinheiro em uma emergência. Se o banco bloquear a operação sem necessidade, a experiência será péssima.

Isso é chamado de falso positivo.

Um falso positivo ocorre quando uma operação legítima é classificada como fraude.

Já um falso negativo ocorre quando uma fraude é classificada como legítima.

O grande desafio é equilibrar os dois.

Se o sistema for rígido demais, bloqueia clientes honestos.

Se for permissivo demais, deixa passar fraudes.

A inteligência artificial ajuda a encontrar um equilíbrio mais preciso.

Em vez de criar uma regra fixa como:

Toda transferência acima de R$ 10.000 deve ser bloqueada.

O sistema pode analisar:

• renda do cliente;

• histórico;

• destinatário;

• horário;

• dispositivo;

• localização;

• motivo;

• frequência;

• comportamento.

Para um cliente, R$ 10.000 pode ser altamente incomum.

Para outro, pode ser uma operação diária.

A análise precisa ser contextual.

---

12. Aprendizado contínuo: o inimigo também evolui

Fraudadores testam constantemente novas técnicas.

Quando os bancos melhoram a autenticação, surgem novos golpes de engenharia social.

Quando os sistemas detectam determinados padrões, os criminosos tentam imitá-los.

Quando a biometria facial avança, aparecem deepfakes mais sofisticados.

É uma corrida permanente.

Por isso, modelos antifraude precisam ser atualizados continuamente.

O ciclo pode ser representado assim:

Fraude acontece
      ↓
Caso é investigado
      ↓
Padrão é identificado
      ↓
Modelo é ajustado
      ↓
Novas transações são protegidas
      ↓
Resultados são monitorados

Esse processo exige participação humana.

Analistas investigam alertas, confirmam fraudes, corrigem classificações e ajudam a melhorar os modelos.

A inteligência artificial não elimina o especialista.

Ela amplia sua capacidade.

Um analista que antes revisava cem casos pode concentrar-se nos casos mais críticos, enquanto o sistema automatiza a triagem inicial.

---

13. Inteligência artificial generativa na segurança bancária

Além dos modelos tradicionais de Machine Learning, a inteligência artificial generativa também pode apoiar equipes de segurança.

Ela pode:

• resumir alertas;

• explicar motivos de bloqueio;

• organizar evidências;

• gerar relatórios;

• auxiliar investigações;

• consultar políticas internas;

• traduzir documentos;

• correlacionar eventos;

• apoiar equipes de atendimento.

Imagine um analista recebendo milhares de logs.

Uma IA pode produzir um resumo:

“A operação foi classificada como alto risco devido a novo dispositivo, localização incomum, valor 14 vezes superior à média e cadastramento recente do beneficiário.”

Isso reduz o tempo necessário para entender o caso.

Porém, decisões críticas não devem depender cegamente de uma resposta gerada.

Modelos generativos podem cometer erros, interpretar dados incorretamente ou produzir explicações convincentes, porém falsas.

Por isso, devem operar com:

• dados confiáveis;

• limites claros;

• revisão humana;

• rastreabilidade;

• controle de acesso;

• monitoramento.

Na ponte da nave, a IA pode ser um excelente oficial científico. Mas o comando final ainda exige responsabilidade.

---

14. LGPD, privacidade e governança

Quanto mais dados são analisados, maior a responsabilidade.

Sistemas antifraude podem processar:

• identidade;

• localização;

• comportamento;

• dispositivo;

• histórico financeiro;

• biometria;

• dados de navegação.

Essas informações são extremamente sensíveis.

No Brasil, a LGPD estabelece princípios para o tratamento de dados pessoais.

Os bancos precisam considerar:

• finalidade;

• necessidade;

• transparência;

• segurança;

• prevenção;

• responsabilização;

• direitos do titular.

Não basta dizer:

“Usamos muitos dados porque segurança é importante.”

A instituição precisa demonstrar:

• por que os dados são necessários;

• como são protegidos;

• quem pode acessá-los;

• por quanto tempo são mantidos;

• como decisões são tomadas;

• como incidentes são tratados.

Também existem exigências relacionadas a:

• prevenção à lavagem de dinheiro;

• conhecimento do cliente;

• monitoramento de operações;

• auditoria;

• gestão de riscos;

• identidade digital;

• controles internos.

A segurança precisa proteger o cliente sem transformar o sistema em uma máquina de vigilância sem limites.

Esse equilíbrio é um dos maiores desafios éticos e regulatórios da era da IA.

---

15. IA explicável e responsabilidade

Imagine receber a seguinte mensagem:

“Sua transação foi bloqueada pela inteligência artificial.”

Isso não explica nada.

Em sistemas críticos, decisões precisam ser auditáveis.

O banco deve conseguir responder:

• qual modelo tomou a decisão;

• qual versão estava em uso;

• quais dados foram considerados;

• quais sinais aumentaram o risco;

• quem revisou o caso;

• qual política foi aplicada.

Esse campo é conhecido como Explainable AI, ou IA explicável.

Nem todo modelo complexo é fácil de explicar. Porém, instituições financeiras precisam buscar formas de tornar decisões compreensíveis e rastreáveis.

Um relatório pode mostrar:

Motivos principais do bloqueio:

1. Novo dispositivo.
2. Localização incompatível.
3. Transferência 20 vezes superior à média.
4. Beneficiário cadastrado há menos de cinco minutos.
5. Comportamento de navegação fora do padrão.

Isso ajuda:

• analistas;

• auditores;

• reguladores;

• atendimento;

• clientes;

• equipes jurídicas.

A responsabilidade não pode ser transferida para a máquina.

Dizer “o algoritmo decidiu” não encerra a discussão.

---

16. Onde entra o mainframe?

Agora chegamos ao território familiar do programador COBOL Padawan.

Muitos grandes bancos continuam utilizando mainframes para processar operações críticas.

O IBM Z pode participar de funções como:

• manutenção de contas;

• atualização de saldos;

• processamento de cartões;

• liquidação;

• crédito;

• cadastro;

• movimentação financeira;

• auditoria;

• processamento em lote;

• integração com redes externas.

A inteligência artificial não necessariamente substitui esses sistemas.

Ela pode atuar ao redor deles ou integrada a eles.

Uma arquitetura simplificada poderia ser:

Aplicativo móvel
      ↓
API de autenticação
      ↓
Biometria e análise de dispositivo
      ↓
Motor antifraude com IA
      ↓
Score de risco
      ↓
API bancária
      ↓
CICS / IMS / Db2 / COBOL
      ↓
Autorização ou rejeição

O programa COBOL pode receber um indicador de risco.

Exemplo:

01  DADOS-TRANSACAO.
    05 CONTA-ORIGEM        PIC 9(10).
    05 CONTA-DESTINO       PIC 9(10).
    05 VALOR-TRANSACAO     PIC 9(11)V99.
    05 SCORE-RISCO         PIC 9(03).
    05 STATUS-BIOMETRIA    PIC X.
    05 DISPOSITIVO-NOVO    PIC X.

IF SCORE-RISCO GREATER THAN 80
    MOVE 'B' TO STATUS-TRANSACAO
    PERFORM REGISTRAR-BLOQUEIO
ELSE
    PERFORM PROCESSAR-TRANSFERENCIA
END-IF

Esse é apenas um exemplo didático.

Em uma arquitetura real, a decisão pode envolver motores especializados, regras, APIs, filas, eventos, banco de dados, monitoração e aprovação humana.

O ponto principal é:

O mainframe não está separado da inteligência artificial. Ele pode ser parte central da cadeia de decisão.

A IA funciona como sensor e oficial de análise.

O core bancário funciona como motor transacional.

Ambos precisam conversar de maneira rápida, confiável e segura.

---

17. Passo a passo de uma transação moderna

Vamos acompanhar uma transferência do início ao fim.

Passo 1 — O cliente abre o aplicativo

O sistema identifica:

• modelo do aparelho;

• versão do sistema;

• endereço IP;

• localização aproximada;

• integridade do dispositivo;

• histórico de uso.

Passo 2 — O cliente autentica

Pode utilizar:

• senha;

• PIN;

• impressão digital;

• reconhecimento facial;

• token.

Passo 3 — O comportamento é observado

O sistema analisa:

• velocidade de navegação;

• forma de digitação;

• sequência de telas;

• padrão de toque;

• tempo de resposta.

Passo 4 — A transferência é criada

São coletados:

• valor;

• destinatário;

• banco;

• horário;

• frequência;

• histórico entre as contas.

Passo 5 — A IA calcula o risco

O modelo compara a operação com:

• padrão do cliente;

• padrões de fraude;

• comportamento de contas semelhantes;

• alertas recentes;

• reputação do dispositivo;

• sinais de comprometimento.

Passo 6 — O motor de decisão atua

A operação pode ser:

• aprovada;

• aprovada com limite;

• submetida a biometria;

• submetida a segundo fator;

• colocada em espera;

• bloqueada;

• enviada para análise.

Passo 7 — O core bancário processa

O sistema transacional verifica:

• saldo;

• limite;

• situação da conta;

• regras financeiras;

• disponibilidade;

• consistência.

Passo 8 — Tudo é registrado

Logs e trilhas de auditoria armazenam:

• decisão;

• horário;

• modelo;

• score;

• fatores utilizados;

• resultado final.

Passo 9 — O sistema aprende

Se a operação for confirmada como fraude, o caso pode alimentar melhorias futuras.

Se o cliente confirmar que era legítima, o sistema também aprende.

Esse ciclo acontece milhões de vezes.

---

18. Dicas para o programador COBOL Padawan

Mesmo que você não trabalhe diretamente com IA, existem conhecimentos importantes para sua carreira.

Entenda a origem dos dados

Pergunte sempre:

• quem gerou o score;

• quando foi calculado;

• qual o formato;

• qual a validade;

• o que fazer se estiver ausente.

Nunca confie cegamente em um campo externo

Um score recebido por API precisa ser validado.

IF SCORE-RISCO NOT NUMERIC
    PERFORM TRATAR-ERRO
END-IF

Registre decisões importantes

Operações críticas precisam de auditoria.

Não basta bloquear. É necessário registrar por quê.

Trate indisponibilidade

O que acontece se o motor de IA estiver fora do ar?

O sistema deve:

• bloquear tudo;

• liberar operações de baixo valor;

• usar regras locais;

• encaminhar para contingência?

Essa decisão precisa ser definida antecipadamente.

Evite decisões sem explicação

Um campo “RISCO-ALTO” pode ser insuficiente.

Sempre que possível, receba códigos de motivo.

01 — Dispositivo novo
02 — Valor anormal
03 — Localização suspeita
04 — Beneficiário recente

Proteja dados sensíveis

Logs não devem expor:

• senha;

• token;

• biometria;

• número completo de cartão;

• informações pessoais desnecessárias.

Pense em performance

Uma análise antifraude não pode levar vários segundos durante uma compra.

Tempo de resposta é parte da experiência e da arquitetura.

Conheça o fluxo completo

O programador não deve enxergar apenas o programa COBOL.

Ele deve compreender:

• canal digital;

• API;

• mensageria;

• motor de risco;

• CICS;

• Db2;

• logs;

• monitoração;

• atendimento;

• auditoria.

É assim que um Padawan se transforma em arquiteto da Frota.

---

19. Curiosidades da galáxia antifraude

Curiosidade 1 — Seu jeito de usar o celular pode identificá-lo

A forma como você inclina o aparelho, toca a tela e digita pode compor um padrão comportamental.

Curiosidade 2 — Uma transação legítima pode parecer suspeita

Comprar uma passagem internacional, trocar de telefone e fazer uma transferência elevada no mesmo dia pode gerar alertas, mesmo sendo legítimo.

Curiosidade 3 — Fraude não é apenas invasão de conta

Também pode envolver:

• abertura de conta falsa;

• documentos adulterados;

• crédito obtido ilegalmente;

• lavagem de dinheiro;

• uso de contas de terceiros;

• identidades sintéticas.

Curiosidade 4 — O cliente pode estar autenticado e ainda assim ser vítima

Em golpes de falsa central, a própria vítima realiza a operação sob orientação do criminoso.

Nesse caso, senha, biometria e dispositivo podem estar corretos.

A análise comportamental e contextual torna-se ainda mais importante.

Curiosidade 5 — Regras antigas ainda têm valor

A IA não elimina regras tradicionais.

Muitas arquiteturas combinam:

• regras fixas;

• modelos estatísticos;

• Machine Learning;

• listas de bloqueio;

• análise humana.

A melhor defesa costuma ser híbrida.

---

20. Easter egg para quem chegou até aqui

Em algum ponto desta missão, talvez você tenha percebido que o sistema antifraude se comporta como o computador da USS Enterprise.

Ele observa milhares de sensores, compara padrões, calcula probabilidades e alerta a tripulação quando algo foge do esperado.

Mas existe uma diferença importante.

Nos episódios clássicos, o computador frequentemente anunciava:

“Intruder alert.”

Nos bancos modernos, o alerta pode ser muito mais discreto.

Talvez o cliente apenas receba uma solicitação de biometria adicional.

Talvez a transferência seja atrasada por alguns segundos.

Talvez um analista receba uma notificação.

Talvez um programa COBOL execute um simples:

MOVE 'N' TO TRANSACAO-AUTORIZADA

Por trás desse único caractere podem existir:

• milhões de registros;

• dezenas de algoritmos;

• centenas de sinais;

• decisões regulatórias;

• motores de risco;

• APIs;

• mainframes;

• criptografia;

• auditoria;

• análise humana.

O humilde MOVE 'N' pode ser o último escudo antes de uma fraude milionária.

Essa é a beleza invisível dos sistemas corporativos.

---

Conclusão: os novos escudos da Frota Financeira

A segurança bancária não pode mais depender apenas de senhas.

O cenário moderno exige uma combinação de:

• inteligência artificial;

• biometria;

• autenticação multifator;

• análise comportamental;

• contexto;

• tokens;

• monitoramento contínuo;

• governança;

• auditoria;

• intervenção humana.

A IA permite analisar enormes volumes de transações em tempo real, identificar comportamentos anormais, calcular riscos e responder antes que o prejuízo aconteça.

A biometria ajuda a validar identidade.

A análise comportamental observa como o cliente interage.

A autenticação contextual avalia onde, quando e em qual dispositivo a operação ocorre.

O mainframe garante que a transação seja processada com consistência, disponibilidade e segurança.

Nenhuma dessas tecnologias funciona perfeitamente sozinha.

A verdadeira força está na integração.

Assim como uma nave da Frota Estelar depende de sensores, escudos, computadores, motores, oficiais e protocolos, um banco moderno depende de várias camadas trabalhando em conjunto.

Para o programador COBOL iniciante, a principal lição é clara:

O código que processa uma transação é apenas uma parte de uma missão muito maior.

Por trás de cada autorização existem decisões de segurança, dados, modelos, regras, APIs, auditoria e responsabilidade.

Aprender COBOL continua sendo importante.

Mas compreender o ecossistema ao redor do COBOL é o que transforma um simples programador em um profissional preparado para os sistemas financeiros do futuro.

Quando você encontrar no código um campo chamado SCORE-RISCO, STATUS-BIOMETRIA, IND-FRAUDE ou COD-MOTIVO-BLOQUEIO, não o veja apenas como mais uma variável.

Veja-o como uma mensagem enviada pelos sensores da nave.

Analise.

Valide.

Registre.

Proteja.

E nunca se esqueça da principal diretriz da segurança moderna:

Confiança não é um estado permanente. É uma conclusão que precisa ser reavaliada continuamente.

Vida longa ao COBOL.

Vida longa ao mainframe.

E que os escudos permaneçam ativos em todas as transações da galáxia financeira.

 

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.