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.