 |
| Bellacosa Mainframe e diabolik entra no redt eam |
☕ Um Café no Bellacosa Mainframe
🕶️ DIABOLIK NO MAINFRAME — Red Team e a Arte de Atacar as Certezas
O melhor Red Team não pergunta apenas como invadir o mainframe. Pergunta quais certezas precisam deixar de ser verdade para que o próprio ambiente abra caminho para o incidente.
Imagine a cena.
São 03:17.
O IBM Z continua funcionando.
As LPARs estão ativas. CICS responde. Db2 está disponível. JES2 continua processando sua fila. RACF permanece de pé. O SIEM está recebendo eventos. Há redundância de rede. Existe um segundo caminho. Os operadores estão na sala.
No dashboard, quase tudo continua verde.
Então alguém pergunta:
— Estamos seguros?
E Diabolik sorri.
Porque essa é a pergunta errada.
A pergunta interessante é:
Quais coisas precisam deixar de funcionar simultaneamente para transformar uma arquitetura aparentemente segura em uma arquitetura vulnerável?
Bem-vindo ao Red Team.
E, principalmente, bem-vindo ao Red Team visto sob a tutela de Diabolik, o criminoso fictício que não ficou famoso simplesmente pela força bruta.
Diabolik observa.
Planeja.
Estuda pessoas.
Entende rotinas.
Explora confiança.
Procura exceções.
E espera.
Esse último verbo é importantíssimo.
Porque um atacante sofisticado não precisa encontrar um sistema permanentemente vulnerável.
Ele pode esperar pelo momento em que o sistema temporariamente se torna vulnerável.
No mainframe isso muda completamente nossa maneira de pensar segurança.
🕶️ CAPÍTULO 1 — Diabolik não começa pelo RACF
Imagine que contratamos uma equipe para realizar um exercício autorizado de Red Team em uma grande organização que utiliza IBM Z.
A abordagem superficial começaria perguntando:
Qual versão do z/OS?
Existe RACF?
Existe MFA?
Como está a rede?
Quais aplicações estão expostas?
Existem APIs?
Existe USS?
Existe Zowe?
Tudo isso importa.
Mas Diabolik provavelmente começaria antes.
Ele colocaria sobre a mesa uma folha em branco e escreveria:
ASSET
O que realmente estamos protegendo?
Talvez:
CORE BANKING
CARD AUTHORIZATION
PIX
CUSTOMER DATA
PAYROLL
SECURITIES
INSURANCE
CLEARING
SETTLEMENT
Agora outra pergunta:
THREAT ACTORS
De quem estamos protegendo esses ativos?
Depois:
TRUST
Em quem o funcionamento desses sistemas confia?
Finalmente:
ASSUMPTIONS
Quais condições acreditamos que sempre serão verdadeiras?
É aqui que a investigação começa a ficar interessante.
Porque podemos descobrir que a organização possui milhões investidos em tecnologia, mas toda aquela arquitetura depende de algumas premissas extremamente humanas.
Por exemplo:
O operador seguirá o procedimento.
A conta privilegiada será usada corretamente.
O segundo link estará disponível.
O backup será recuperável.
O certificado será renovado.
O alerta será investigado.
A mudança será registrada.
O fornecedor continuará confiável.
A conta de serviço permanecerá protegida.
Alguém interromperá o processo se algo der errado.
Diabolik circula essa última frase.
"Alguém interromperá."
Será?
🎭 CAPÍTULO 2 — Red Team não é apenas invasão
Existe uma caricatura bastante comum de Red Team.
Alguém de moletom preto diante de seis monitores digitando furiosamente:
ACCESS GRANTED
Pronto.
Invadimos.
Mas Red Team maduro é muito mais interessante.
O exercício autorizado tenta colocar determinadas premissas defensivas sob pressão.
Pergunta:
Se um adversário real estivesse estudando nossa organização, quais caminhos poderiam levá-lo aos ativos importantes?
Isso envolve tecnologia, mas também:
identidade;
processos;
segregação de funções;
configuração;
monitoramento;
fornecedores;
procedimentos;
comportamento;
contingência;
comunicação;
resposta a incidentes;
governança.
Nosso estudo anterior chegou exatamente a esse ponto: o Red Team deixa de olhar apenas para o controle isolado e começa a investigar a arquitetura de confiança.
No mainframe isso é extraordinariamente importante.
Porque IBM Z raramente vive sozinho.
Temos algo parecido com:
USER
↓
DEVICE
↓
NETWORK
↓
IDENTITY
↓
APPLICATION
↓
CICS / IMS
↓
COBOL
↓
DB2 / VSAM
Mas existem dezenas de arestas laterais:
APIs
MQ
FTP/SFTP
z/OS Connect
USS
Zowe
Schedulers
DevOps
CI/CD
Cloud
Distributed Systems
Service Accounts
Vendors
Automation
Segurança é um grafo.
E cada aresta representa alguma forma de confiança.
🕸️ CAPÍTULO 3 — Diabolik desenha o grafo
Pegue um programa COBOL aparentemente inocente:
BILLING01
Talvez ele leia:
CUSTOMER
ACCOUNT
TRANSACTION
PRODUCT
e atualize:
INVOICE
O iniciante poderia pensar:
PROGRAM → DATABASE
Diabolik desenharia:
USER
│
▼
RACF ID
│
┌──────┴──────┐
▼ ▼
CICS BATCH
│ │
▼ ▼
BILLING01 JCL/JES
│ │
┌────┴────┐ │
▼ ▼ ▼
DB2 VSAM DATASET
│
▼
CUSTOMER
Depois continuaria:
CI/CD ──────► LOADLIB
▲
│
DEVELOPER ──────┘
SERVICE ACCOUNT ──► AUTOMATION
API ──► z/OS Connect ──► CICS
MQ ──► APPLICATION
Agora temos algo muito mais interessante.
Porque a pergunta deixou de ser:
O Db2 está protegido?
Passou a ser:
Quantos caminhos diferentes podem produzir uma alteração relevante no estado desse negócio?
Esse é pensamento de Red Team.
🔐 CAPÍTULO 4 — RACF não protege contra todas as formas de confiança
RACF é extraordinariamente importante.
Mas existe uma armadilha conceitual:
RACF = SEGURANÇA
Não.
RACF é uma parte da arquitetura de segurança.
Imagine:
USER01
READ DATASET.A
USER01
UPDATE DATASET.B
USER01
EXECUTE TRANSACTION.C
USER01
SUBMIT JOB.D
Cada permissão individualmente pode ter justificativa.
Auditor pergunta:
READ A?
OK.
UPDATE B?
OK.
CICS C?
OK.
JOB D?
OK.
Quatro verdes.
Diabolik pergunta:
READ A
+
UPDATE B
+
TRANSACTION C
+
JOB D
=
?
Essa é uma pergunta completamente diferente.
Não estamos mais analisando permissões isoladas.
Estamos analisando capacidade acumulada.
O usuário talvez não possua uma permissão perigosa.
Pode possuir uma combinação perigosa de permissões legítimas.
Essa diferença é fundamental.
🧩 CAPÍTULO 5 — Compartmentalization
Aqui aparece um princípio antigo de segurança e inteligência: compartimentalização.
Compare:
USUÁRIO A
├── desenvolvimento
├── aprovação
├── implantação
├── produção
├── auditoria
└── rollback
com:
DEV → desenvolvimento
APPROVER → aprovação
OPS → implantação
SEC → segurança
AUDIT → auditoria
Por que dividir?
Porque comprometimento possui blast radius.
Se uma identidade conhece, controla ou executa tudo, comprometer aquela identidade potencialmente compromete tudo.
O mesmo raciocínio vale para pessoas.
Vale para contas técnicas.
Vale para pipelines.
Vale para fornecedores.
Vale para APIs.
Vale para certificados.
Vale até para informações aparentemente banais.
Não precisamos transformar cada funcionário em suspeito.
O objetivo é exatamente o contrário: construir um sistema no qual a confiança em uma única pessoa não seja suficiente para destruir o modelo inteiro.
👤 CAPÍTULO 6 — Insider Threat não significa vilão
Quando falamos em insider threat, muita gente imediatamente imagina:
FUNCIONÁRIO TRAIDOR
Esse é apenas um cenário.
Insider risk pode envolver:
malícia
erro
negligência
coerção
engenharia social
credencial comprometida
procedimento inadequado
excesso de privilégio
informação excessiva
automação mal configurada
Imagine um analista autorizado.
Ele não deseja prejudicar ninguém.
Mas possui:
PRODUCTION ACCESS
Recebe uma solicitação aparentemente normal.
Executa determinada atividade.
O problema talvez não seja:
BAD EMPLOYEE
Pode ser:
BAD PROCESS
Um sistema resiliente deve presumir que humanos eventualmente erram.
Por isso temos segregação.
Aprovação.
Logging.
Monitoring.
Least privilege.
Dual control.
Change management.
Não porque todo mundo seja criminoso.
Porque confiança absoluta é um controle de segurança péssimo.
🎬 CAPÍTULO 7 — A fotografia virou filme
Aqui chegamos ao nosso Risk Scoring.
A segurança tradicional frequentemente produz fotografias:
USER01 = LOW RISK
Diabolik pergunta:
Quando?
08:00?
11:30?
03:17?
O contexto muda.
Por isso deveríamos pensar:
RISK(t)
Risco como função do tempo.
Imagine:
08:00
USER01
LOCATION = NORMAL
DEVICE = MANAGED
ACTION = NORMAL
RISK = 20
Agora:
03:17
USER01
UNUSUAL CONTEXT
PRIVILEGED ACTION
CHANGE WINDOW
MULTIPLE FAILURES
RISK = ?
O usuário continua sendo USER01.
Mas o contexto deixou de ser o mesmo.
É exatamente por isso que comportamento importa.
Não perguntamos apenas:
WHO ARE YOU?
Perguntamos:
IS WHAT YOU ARE DOING
CONSISTENT WITH
WHAT WE EXPECT?
🧮 CAPÍTULO 8 — Risk Score não é sentença
É importante não transformar Risk Scoring em numerologia.
Podemos imaginar pedagogicamente:
BASELINE.................... 20
privileged operation........ +15
unusual context............. +10
change detected............. +10
control degraded............ +15
unexpected dependency....... +10
-------------------------------
RISK........................ 80
Esses números são ilustrativos.
O princípio importa mais que o peso.
Cada evento altera contexto.
Portanto:
EVENT
↓
CONTEXT
↓
RISK RECALCULATION
↓
DECISION
Isso permite decisões graduais:
ALLOW
CHALLENGE
REQUIRE APPROVAL
LIMIT
ESCALATE
STOP
Diabolik detestaria principalmente a última.
🚨 CAPÍTULO 9 — CHANGE é um evento de segurança
Mainframe conhece Change Management muito bem.
Mudou:
JCL
COBOL
PARMLIB
PROCLIB
LOADLIB
RACF
DB2
CICS
IMS
MQ
NETWORK
CERTIFICATE
Registramos.
Aprovamos.
Testamos.
Ou deveríamos.
Mas Red Team acrescenta outra pergunta:
O que mais mudou como consequência dessa mudança?
Imagine:
PRIMARY LINK DOWN
Temos backup.
Ótimo.
Então:
BACKUP LINK DEGRADED
Ainda funciona.
Então:
MONITORING DELAY
Ainda funciona.
Então:
SECURITY ALERT
Provavelmente falso positivo.
Então alguém diz:
BYPASS
Separadamente:
LINK FAILURE = manageable
BACKUP DEGRADED = manageable
MONITORING DELAY = manageable
ALERT = manageable
BYPASS = manageable
Juntos:
FAILURE
+
DEGRADATION
+
BLINDNESS
+
ALERT
+
BYPASS
=
CRITICAL STATE
Esse é o filme que a fotografia não mostra.
🧀 CAPÍTULO 10 — O queijo suíço chegou à LPAR
Existe uma metáfora maravilhosa para isso: o Swiss Cheese Model.
Imagine várias barreiras.
IDENTITY
████████○████
NETWORK
███○█████████
RACF
█████████○███
APPLICATION
█████○███████
MONITORING
██○██████████
Cada camada possui imperfeições.
Normalmente os buracos não se alinham.
Uma camada compensa a outra.
Mas existe uma condição perigosa:
○
○
○
○
○
│
▼
INCIDENT
Diabolik não precisa destruir todas as fatias.
Precisa encontrar o momento em que os buracos se alinham.
Essa é uma maneira extraordinária de ensinar defesa em profundidade.
💥 CAPÍTULO 11 — Ataque a redundância
Temos:
LPAR A
LPAR B
Excelente.
Mas:
LPAR A ─┐
├── DEPENDENCY X
LPAR B ─┘
Temos realmente redundância?
Talvez tenhamos dois componentes com single point of failure compartilhado.
Isso aparece em inúmeras arquiteturas:
2 SERVERS
1 NETWORK
2 APPLICATIONS
1 DATABASE
2 LINKS
1 PROVIDER
2 ADMINS
1 PRIVILEGED ACCOUNT
2 SYSTEMS
1 CERTIFICATE
Diabolik procura exatamente isso.
Não necessariamente:
WHAT IS MISSING?
Mas:
WHAT DO ALL THESE THINGS
SECRETLY DEPEND ON?
Essa pergunta deveria estar pendurada em toda War Room.
🧠 CAPÍTULO 12 — Normalization of Deviance
Agora aparece um inimigo extremamente humano.
Primeiro:
"Hoje vamos fazer uma exceção."
Nada acontece.
Depois:
"Fizemos isso semana passada."
Nada acontece.
Mais tarde:
"Fazemos sempre assim."
Finalmente:
"Nem sei por que existe essa regra."
Parabéns.
A exceção virou processo.
Isso é normalização do desvio.
E existe um erro lógico perigosíssimo associado:
FIZEMOS 100 VEZES
E NADA ACONTECEU
Portanto:
É SEGURO
Não.
A conclusão correta é:
100 EXECUÇÕES
SEM INCIDENTE
Somente isso.
Ausência histórica de desastre não prova ausência de risco.
🛑 CAPÍTULO 13 — Quem pode apertar STOP?
Essa talvez seja uma das perguntas mais importantes de toda esta história.
Imagine:
NORMAL OPERATION
↓
CHANGE
↓
RISK INCREASE
↓
???
Quem pode dizer:
STOP
?
Existe autoridade?
Existe procedimento?
Existe pressão para continuar?
O operador consegue interromper uma operação crítica?
O gerente aceitará?
O negócio pressionará?
Existe escalation path?
Esse componente organizacional pode ser mais importante que determinado produto de cybersecurity.
O fluxo saudável seria:
CHANGE DETECTED
↓
STOP
↓
ASSESS
↓
RECALCULATE
↓
┌───┴───┐
▼ ▼
CONTINUE ABORT
Não:
CHANGE
↓
"VAI ASSIM MESMO"
⏳ CAPÍTULO 14 — Temporal Attack Surface
Aqui está um conceito delicioso para nossa investigação.
Superfície de ataque normalmente é apresentada como:
PORTS
APIs
SERVICES
USERS
DEVICES
NETWORKS
Mas existe também uma dimensão temporal.
Imagine:
00:00 ───────────────────────── 23:59
│
03:17
│
ATTACK WINDOW
Talvez durante alguns minutos aconteçam simultaneamente:
CHANGE WINDOW
+
REDUCED STAFF
+
DEGRADED CONTROL
+
PRIVILEGED ACTIVITY
+
MONITORING NOISE
Às 09:00 alguém audita:
RACF.......... OK
NETWORK....... OK
CICS.......... OK
DB2........... OK
MONITORING.... OK
Tudo verde.
Mas isso é uma fotografia das 09:00.
O incidente ocorreu às 03:17.
Precisamos reconstruir:
02:55
03:01
03:07
03:12
03:16
03:17
03:18
03:25
Agora temos um filme.
🕵️ CAPÍTULO 15 — Diabolik procura combinações
Uma auditoria convencional pode produzir:
CONTROL A = PASS
CONTROL B = PASS
CONTROL C = PASS
CONTROL D = PASS
Diabolik pergunta:
A + B + C + D = ?
Melhor ainda:
A DEGRADED
+
B BYPASSED
+
C DELAYED
+
D MISINTERPRETED
=
?
Esse é o coração do exercício.
Não testar apenas controles.
Testar interações entre controles.
🔬 CAPÍTULO 16 — Como transformar isso em exercício defensivo
Uma organização pode estruturar um exercício autorizado sem sair tentando "hackear tudo".
Primeiro:
1. IDENTIFY ASSETS
Quais serviços não podem parar?
Depois:
2. MAP TRUST
Quem e o que possui acesso?
Depois:
3. MAP DEPENDENCIES
De que cada componente depende?
Depois:
4. IDENTIFY ASSUMPTIONS
O que estamos assumindo que nunca falhará?
Depois:
5. CREATE SAFE SCENARIOS
Por exemplo:
E se o link primário desaparecer?
E se uma conta privilegiada precisar ser bloqueada?
E se o SIEM ficar temporariamente indisponível?
E se o operador principal não estiver presente?
E se uma mudança emergencial acontecer?
E se um fornecedor estiver indisponível?
E se o segundo caminho compartilhar a mesma dependência?
Depois:
6. OBSERVE RESPONSE
Finalmente:
7. IMPROVE CONTROLS
Esse é Red Team gerando engenharia.
Não espetáculo.
🖥️ CAPÍTULO 17 — O COBOL também entra na investigação
Nosso programador COBOL iniciante talvez esteja pensando:
— Mas eu apenas programo.
Não existe "apenas programo" em sistemas críticos.
Imagine:
IF AUTHORIZED
PERFORM UPDATE-ACCOUNT
END-IF.
A pergunta tradicional é:
AUTHORIZED funciona?
Red Team pergunta:
Quem determina AUTHORIZED?
De onde vem esse estado?
Ele pode ficar obsoleto?
Existe contexto?
Existe logging?
Existe override?
Quem aprova?
O que acontece em erro?
FAIL OPEN ou FAIL CLOSED?
Uma pequena condição COBOL pode representar uma enorme decisão de negócio.
Por isso segurança não termina no RACF.
Ela atravessa aplicação, dados e processo.
🧪 CAPÍTULO 18 — O teste mais perigoso é o pressuposto
Faça uma reunião.
Pergunte:
O que nunca pode acontecer aqui?
Alguém responderá:
"Os dois links nunca cairão juntos."
Anote.
Outro:
"Ninguém compartilha essa conta."
Anote.
Outro:
"Produção nunca recebe alteração sem aprovação."
Anote.
Outro:
"Se o monitoramento parar, perceberemos."
Anote.
Outro:
"Nosso fornecedor cuida disso."
Circule duas vezes.
Essas frases são excelentes candidatas para exercícios defensivos.
Red Team é, em grande parte, uma máquina de transformar:
EU ACHO
em:
NÓS TESTAMOS
🎩 CAPÍTULO 19 — O Easter Egg das 03:17
Nos artigos Bellacosa Mainframe, 03:17 aparece quando alguma coisa resolveu acontecer justamente na hora em que ninguém queria.
Aqui ele ganha significado especial.
Às 03:17 não precisamos imaginar um invasor cinematográfico digitando furiosamente.
Podemos imaginar:
03:17:00 CONTROL A DEGRADED
03:17:03 DEPENDENCY B UNAVAILABLE
03:17:07 AUTOMATION RETRY
03:17:12 OPERATOR OVERRIDE
03:17:18 SECURITY EVENT
03:17:21 ALERT DELAYED
Diabolik não criou necessariamente nenhuma dessas condições.
Ele apenas adoraria descobrir que elas podem coexistir.
E esse é o Easter Egg:
O momento mais perigoso de uma arquitetura talvez não seja quando alguma coisa quebra. É quando várias coisas continuam funcionando mal o suficiente para ninguém decidir parar.
🕶️ CAPÍTULO 20 — A verdadeira lição de Diabolik
Diabolik não deveria nos ensinar a ser criminosos.
Como metáfora de Red Team, deveria ensinar-nos a pensar como adversários para construir sistemas melhores.
Ele não pergunta apenas:
COMO QUEBRO O RACF?
Pergunta:
POR QUE PRECISARIA QUEBRÁ-LO?
Não:
COMO DERRUBO A REDUNDÂNCIA?
Mas:
ELA É REALMENTE INDEPENDENTE?
Não:
COMO ENGANAR O OPERADOR?
Mas:
O PROCESSO DEPENDE DEMAIS DE UMA PESSOA?
Não:
COMO DESATIVAR O ALERTA?
Mas:
O QUE ACONTECE QUANDO O ALERTA
APARECE NO PIOR MOMENTO POSSÍVEL?
Essa mudança de mentalidade é enorme.
☕ EPÍLOGO — O mainframe que confiava demais
Às 03:17 daquela noite imaginária, nosso mainframe não estava sem segurança.
Esse é justamente o problema.
Ele possuía:
RACF
SIEM
MFA
NETWORK SECURITY
SEGREGATION
CHANGE MANAGEMENT
BACKUP
REDUNDANCY
MONITORING
PROCEDURES
Tudo existia.
Mas segurança não é a soma dos produtos instalados.
Segurança é o comportamento da arquitetura quando o mundo deixa de colaborar com nossas premissas.
É por isso que Red Team importa.
Blue Team pergunta:
Estamos detectando ataques?
Purple Team aproxima ataque e defesa.
Auditoria pergunta:
Os controles estão implementados?
Operações pergunta:
O serviço está disponível?
Risk Management pergunta:
Qual é nossa exposição?
E nosso Diabolik imaginário entra silenciosamente na War Room, olha para aquele enorme painel verde e faz outra pergunta:
"Qual dessas coisas verdes precisa ficar amarela para fazer as outras perderem valor?"
Silêncio.
Essa é a pergunta.
Porque o adversário sofisticado não precisa derrotar todas as nossas defesas.
Não precisa derrubar o IBM Z.
Não precisa destruir RACF.
Não precisa comprometer cada aplicação.
Não precisa vencer cada operador.
Pode precisar apenas encontrar:
FAILURE
+
CHANGE
+
EXCEPTION
+
TRUST
+
PREDICTABILITY
+
TIMING
e esperar que essas condições se encontrem.
Por isso eu resumiria toda a filosofia do Bellacosa Red Team Mainframe numa única equação:
SECURITY ≠ CONTROLS
Segurança real é:
SECURITY =
CONTROLS
+
CONTEXT
+
RESILIENCE
+
OBSERVABILITY
+
SEGREGATION
+
GOVERNANCE
+
ABILITY TO STOP
E o Risk Scoring completa:
RISK = RISK(t)
O risco de ontem não é necessariamente o risco de agora.
O usuário continua sendo o mesmo.
O programa COBOL continua sendo o mesmo.
A LPAR continua sendo a mesma.
O RACF continua sendo o mesmo.
Mas alguma coisa mudou.
E CHANGE pode transformar uma arquitetura.
Essa talvez seja a maior lição de Diabolik para quem trabalha com IBM Mainframe:
Não procure somente a vulnerabilidade. Procure a combinação de condições que transforma controles individualmente fortes em uma arquitetura coletivamente fraca.
Porque uma fortaleza não precisa perder todas as muralhas para ser penetrável.
Basta existir uma noite em que a ponte esteja abaixada, o guarda esteja olhando para outro lado, a contingência tenha sido improvisada e alguém diga:
"Está funcionando.
Pode continuar."
E, em algum lugar da War Room, o relógio muda silenciosamente para:
03:17
Diabolik sorri.
O Red Team anota.
E o Blue Team, na manhã seguinte, transforma aquela descoberta em uma arquitetura melhor.
