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