Bellacosa Mainframe e a segurança bloquear 10k ataques nao é garantia de segurança

☕ UM CAFÉ NO BELLACOSA MAINFRAME

☠️ SHIROE ENTRA NO SOC — VOCÊ BLOQUEOU 10 MIL ATAQUES. E DAÍ?

Métricas de segurança, MTTD, MTTR, dwell time, attack paths, RACF, CICS, Db2, MQ, adversary capability — e o dia em que um programador COBOL descobriu que CC 0000 nem sempre significa vitória

Imagine que você chega para trabalhar numa segunda-feira.

Café na mão.

TSO aberto.

ISPF funcionando.

SDSF mostrando aquele universo maravilhoso de jobs, mensagens e coisas que podem explodir antes das nove da manhã.

Então chega um relatório da área de segurança:

SECURITY MONTHLY REPORT

ATTACKS DETECTED.............. 10.742
ATTACKS BLOCKED............... 10.731
SUCCESS RATE.................. 99,89%

Excelente!

Palmas.

Dashboard verde.

PowerPoint verde.

Executivos felizes.

Talvez até apareça um gráfico subindo para a direita — porque gráfico corporativo precisa subir para a direita.

Então alguém sentado no fundo da sala levanta a mão.

Óculos.

Cara de quem já calculou vinte possibilidades enquanto todos comemoravam.

É Shiroe, de Log Horizon.

Ele olha para o dashboard e pergunta:

“E quantos atacantes perderam a capacidade de continuar atacando?”

Silêncio.

O analista responde:

— Bloqueamos 10.731 ataques.

Shiroe ajeita os óculos.

— Eu não perguntei quantos ataques vocês bloquearam.

E pronto.

Acabamos de transformar uma reunião de SOC em uma raid de Log Horizon.

Porque existe uma diferença gigantesca entre:

medir atividade defensiva

e

medir resultado estratégico da defesa.

Pegue seu café.

Hoje o COBOLZEIRO vai descobrir que até um:

COND CODE 0000

pode esconder uma derrota.

---

🎬 CAPÍTULO 1 — PRIMEIRO: O QUE DIABOS É UMA MÉTRICA?

Vamos começar do começo.

Uma métrica é uma medida utilizada para observar alguma característica de um sistema, processo ou atividade.

No mainframe fazemos isso o tempo inteiro.

Podemos medir:

CPU TIME
ELAPSED TIME
I/O
EXCP
TRANSACTIONS
RESPONSE TIME
STORAGE
THROUGHPUT
ABENDS

Se você executa um programa COBOL batch que processa um milhão de registros, pode registrar:

INPUT RECORDS........ 1.000.000
PROCESSED.............   999.999
REJECTED..............         1

Agora vem uma pegadinha.

Qual número é mais importante?

999.999 registros corretos?

Ou aquele único registro rejeitado?

Depende.

Se o registro rejeitado representar uma atualização de R$ 3,72, provavelmente não teremos uma catástrofe.

Mas imagine que represente:

R$ 47.000.000,00

De repente:

99,9999% SUCCESS

não parece tão maravilhoso.

Segurança possui exatamente esse problema.

Podemos bloquear:

10.000 ataques

e deixar passar:

1 ataque

Mas se aquele único ataque conseguir atingir um ativo crítico, a porcentagem bonita perde grande parte do significado.

Primeira lição de Shiroe:

Uma métrica sem contexto pode medir perfeitamente a coisa errada.

---

🧙 CAPÍTULO 2 — SHIROE E O TABULEIRO DE XADREZ

Shiroe é perfeito como tutor para esse assunto porque sua principal arma não é força bruta.

É estratégia.

Ele não olha apenas:

quem bate mais forte?

Ele pensa:

qual é o objetivo?
quais recursos existem?
quais são as dependências?
qual é a posição do adversário?
quais movimentos ainda estão disponíveis?
quanto custa cada movimento?
o que acontece três movimentos depois?

Cybersecurity deveria funcionar exatamente assim.

Imagine um atacante tentando entrar numa organização.

Ele possui:

infraestrutura
credenciais
malware
conhecimento
tempo
dinheiro
pessoas
vulnerabilidades
ferramentas

Esses elementos formam sua capacidade operacional.

O objetivo da defesa não deveria ser somente impedir uma requisição.

Idealmente, queremos reduzir a capacidade do adversário de repetir ou ampliar sua operação.

---

⚔️ CAPÍTULO 3 — BLOCK NÃO É DISRUPT

Suponha que um endereço IP tente autenticar 10.000 vezes.

Seu firewall bloqueia tudo.

SOURCE: 203.0.113.X

ATTEMPTS.............. 10.000
BLOCKED............... 10.000

Perfeito.

Mas amanhã:

SOURCE: OUTRO IP

ATTEMPTS.............. 10.000

Depois:

OUTRO IP
OUTRA CONTA
OUTRO HORÁRIO
OUTRO USER-AGENT
OUTRO ENDPOINT

Você está bloqueando ataques.

Mas talvez não esteja prejudicando significativamente a operação adversária.

Podemos representar assim:

ATACANTE
   |
   +-- tentativa
   |      |
   |      X BLOCK
   |
   +-- tentativa
   |      |
   |      X BLOCK
   |
   +-- tentativa
   |      |
   |      X BLOCK
   |
   +-- tentativa...

Isso pode virar um gigantesco jogo de whack-a-mole digital.

Bate aqui.

Aparece ali.

Bate ali.

Aparece acolá.

O problema estratégico é:

CAPACIDADE DO ADVERSÁRIO = INTACTA

---

📊 CAPÍTULO 4 — TRÊS NÍVEIS DE MÉTRICAS

Shiroe pega o quadro branco e desenha três níveis.

          SEGURANÇA

              |
     +--------+--------+
     |        |        |
 ATIVIDADE RESULTADO  EFEITO

Nível 1 — Métricas de atividade

São números como:

alerts generated
attacks detected
attacks blocked
malware detected
emails rejected
IPs blocked
WAF requests denied
authentication failures

São úteis.

O problema é transformá-las automaticamente em sinônimo de segurança.

Bloquear um milhão de requisições automatizadas pode ser menos relevante que descobrir uma única credencial privilegiada comprometida.

---

⏱️ CAPÍTULO 5 — MÉTRICAS OPERACIONAIS

Subimos um nível.

Agora queremos saber quanto tempo demoramos para perceber e responder.

Entram conceitos como:

MTTD
MTTR
DWELL TIME

MTTD — Mean Time To Detect

É o tempo médio necessário para detectar determinado incidente ou condição.

Imagine:

Intrusão............. 10:00
Detecção............. 10:45

MTTD aproximado...... 45 minutos

Quanto menor, normalmente melhor, desde que estejamos comparando coisas equivalentes.

---

MTTR

Aqui existe uma pequena pegadinha terminológica.

Dependendo da organização, MTTR pode significar:

Mean Time To Respond
Mean Time To Repair
Mean Time To Recover
Mean Time To Remediate

Portanto, antes de comparar dois dashboards, descubra o que aquela empresa chama de MTTR.

Isso parece detalhe.

Não é.

É possível duas empresas dizerem:

MTTR = 30 minutos

e estarem medindo coisas completamente diferentes.

---

👻 CAPÍTULO 6 — DWELL TIME

Agora aparece um conceito muito interessante.

Dwell time representa, de maneira geral, quanto tempo o adversário permanece no ambiente antes de ser descoberto ou expulso, conforme a definição operacional adotada.

Imagine:

COMPROMISE
    |
    |-------------------------------|
                                    |
                                 DETECTION

Quanto maior esse intervalo, maior pode ser a oportunidade para:

reconhecimento
movimento lateral
roubo de credenciais
persistência
coleta de dados
exfiltração

Mas Shiroe novamente pergunta:

“Depois que vocês expulsaram o atacante, ele podia voltar?”

A sala fica silenciosa novamente.

Porque descobrimos outra métrica.

---

🧟 CAPÍTULO 7 — O ADVERSÁRIO REGENERATIVO

Imagine um boss de MMORPG.

HP............... 100.000
REGEN............. 10.000/min

Sua party causa:

DAMAGE............. 9.000/min

Depois de uma hora, alguém comemora:

TOTAL DAMAGE
540.000

Fantástico!

Só existe um pequeno problema.

O boss continua com praticamente toda sua capacidade de combate porque regenera mais rápido que o grupo consegue produzir dano líquido.

😂

Agora troque:

DAMAGE

por:

ATTACKS BLOCKED

Seu SOC pode produzir:

10.000 bloqueios/mês

enquanto o adversário recompõe:

IP
credenciais
infraestrutura
malware
domínios
tokens
contas

mais rapidamente do que você reduz sua capacidade.

O número de bloqueios cresce.

A segurança estratégica permanece quase igual.

---

🕸️ CAPÍTULO 8 — ATTACK PATHS: A DUNGEON DO RACF

Agora vamos entrar no mainframe.

Imagine:

USER01
  |
  +--> GROUPA
          |
          +--> DATASET

Descobrimos uma permissão inadequada.

Removemos:

PERMIT USER01

Problema resolvido?

Shiroe responde:

— Depende.

Porque pode existir:

USER01
   |
 GROUPA
   |
 GROUPB
   |
 FACILITY
   |
 SURROGAT
   |
 JCL
   |
 STC
   |
 CICS
   |
 DB2

Aqui aparece o conceito de attack path.

O atacante não precisa necessariamente possuir uma autorização direta sobre o objetivo.

Ele precisa encontrar um caminho possível até ele.

Isso é muito parecido com uma dungeon.

O objetivo está aqui:

             [DB2]

Mas existem caminhos:

USER
 |
 +---- A ---- B ---- DB2
 |
 +---- C ---- D ---- DB2
 |
 +---- E ---- F ---- G ---- DB2
 |
 +---- H ---- CICS ---- DB2

Remover uma permissão pode eliminar um caminho.

Mas talvez sobrem três.

Uma métrica operacional poderia dizer:

PERMISSIONS REMOVED = 1

Uma métrica estratégica perguntaria:

ATTACK PATHS BEFORE = 4
ATTACK PATHS AFTER  = 3

Isso conta uma história muito diferente.

---

🏰 CAPÍTULO 9 — CICS, COBOL E DB2

Imagine agora uma arquitetura:

INTERNET
   |
API GATEWAY
   |
z/OS CONNECT
   |
CICS
   |
COBOL
   |
DB2

Um atacante dispara:

100.000 REQUESTS

O gateway bloqueia:

99.990

Dashboard:

99,99% BLOCKED

Sensacional.

Mas dez chegaram adiante.

Uma delas utiliza uma combinação válida de identidade, autorização e operação.

Ela chega:

API
 |
CICS TRANSACTION
 |
COBOL PROGRAM
 |
DB2

Do ponto de vista do dashboard:

DEFENSE SUCCESS = 99,99%

Do ponto de vista do atacante:

OBJECTIVE ACHIEVED = YES

Eis por que segurança precisa conhecer impacto, e não somente volume.

---

🐌 CAPÍTULO 10 — LOW AND SLOW

Agora aparece outra criatura perigosa.

O atacante barulhento faz:

10.000
20.000
50.000

tentativas.

Ele aparece facilmente nos gráficos.

Mas outro atacante pode fazer:

SEGUNDA..... login
TERÇA....... nada
QUARTA...... consulta
QUINTA...... nada
SEXTA....... alteração pequena

Talvez cada ação isolada pareça perfeitamente legítima.

É o conceito de operação low and slow.

Pouco volume.

Longo período.

Baixa assinatura.

Imagine que seu SOC possua um ranking:

TOP SECURITY EVENTS

1. 42.000 authentication failures
2. 31.000 WAF blocks
3. 17.000 port scans
4. 1 successful privileged login

Qual merece maior investigação?

Possivelmente o número quatro.

Volume não é sinônimo de risco.

---

💰 CAPÍTULO 11 — O ATACANTE TAMBÉM TEM ROI

Shiroe desenha outra equação.

ATTACK COST < EXPECTED RETURN

Se isso continuar verdadeiro, o ataque pode continuar economicamente interessante.

Imagine:

1.000.000 tentativas
       |
       v
10.000 credenciais úteis
       |
       v
500 acessos
       |
       v
20 oportunidades
       |
       v
2 monetizações

Seu dashboard comemora:

99,9998% FAILURE RATE

Mas se aquelas duas monetizações produzirem lucro superior ao custo da campanha, o criminoso talvez esteja satisfeito.

Isso é extremamente importante em:

fraude
phishing
credential stuffing
spam
malware commodity
ransomware
golpes financeiros

O atacante não precisa vencer sempre.

Precisa ganhar dinheiro suficientemente frequentemente.

---

💸 CAPÍTULO 12 — AUMENTANDO O CUSTO DO ADVERSÁRIO

Agora temos uma ideia muito mais interessante.

Suponha:

ANTES

Custo operacional........ $1.000
Retorno esperado......... $20.000

Depois das mudanças defensivas:

DEPOIS

Custo operacional....... $15.000
Retorno esperado......... $10.000

Mesmo que você continue recebendo ataques, alterou a economia deles.

Obrigou o adversário a:

comprar infraestrutura nova
obter novas credenciais
mudar ferramentas
reconstruir persistência
buscar vulnerabilidades diferentes
desenvolver novas técnicas
gastar mais tempo
assumir mais risco

Isso é imposição de custo.

Não significa que conseguiremos calcular perfeitamente o custo financeiro real do criminoso.

Frequentemente utilizaremos indicadores indiretos.

Mas a pergunta estratégica permanece excelente:

Quanto mais difícil ficou repetir o ataque?

---

🔄 CAPÍTULO 13 — TIME TO RE-ENTRY

Vamos inventar um indicador útil como modelo mental:

TIME TO RE-ENTRY

Incidente A:

10:00 atacante detectado
10:30 atacante removido
14:00 atacante retornou

Excelente MTTR.

Péssima erradicação.

Agora imagine que, depois de corrigirmos:

credenciais
tokens
persistência
privilégios
configurações
vulnerabilidades
attack paths

o mesmo adversário precisa de meses para reconstruir uma posição comparável.

Nossa capacidade defensiva mudou profundamente.

---

🔐 CAPÍTULO 14 — CONTAS ÓRFÃS E O FANTASMA QUE VOLTA

Aqui entra outra conexão importante.

Imagine um funcionário que saiu da empresa.

Seu usuário principal foi desativado.

Mas ficaram:

service account
API token
SSH key
certificado
credencial de aplicação
grupo secundário
job agendado
surrogate authority

O dashboard de offboarding diz:

USER DISABLED = YES

Tecnicamente correto.

Estratégicamente incompleto.

Shiroe perguntaria:

“Quantas capacidades associadas àquela identidade continuam disponíveis?”

Essa é uma pergunta muito melhor.

---

🧮 CAPÍTULO 15 — GRAFOS MUDAM O JOGO

É aqui que teoria de grafos fica maravilhosa.

Podemos representar identidades, sistemas e permissões como nós:

USER
GROUP
DATASET
CICS
STC
DB2
MQ
API
APPLICATION

E relações como arestas:

MEMBER_OF
CAN_SUBMIT
CAN_EXECUTE
CAN_READ
CAN_IMPERSONATE
CAN_CONNECT
CAN_UPDATE

Agora o problema deixa de ser:

USER01 possui acesso ao DB2?

E vira:

Existe algum caminho entre USER01 e um recurso crítico do DB2?

Matematicamente:

USER01 --> ? --> ? --> ? --> DB2

Isso é muito mais poderoso.

Porque segurança real é frequentemente transitiva.

---

📡 CAPÍTULO 16 — SMF: O HISTORIADOR DA DUNGEON

No z/OS temos uma vantagem fantástica.

Muita coisa deixa rastros.

SMF pode fornecer dados essenciais sobre atividades do sistema e, dependendo dos subsistemas e configurações, podemos correlacionar informações de:

RACF
JES
CICS
DB2
MQ
TCP/IP
USS

A grande evolução ocorre quando deixamos de perguntar apenas:

QUANTOS EVENTOS?

e começamos a perguntar:

QUAL SEQUÊNCIA?

Por exemplo:

LOGIN
  |
AUTHORIZATION CHANGE
  |
JOB SUBMISSION
  |
CICS ACCESS
  |
DB2 QUERY

Separadamente, talvez cada evento pareça pouco interessante.

Correlacionados, contam uma história.

É praticamente transformar SMF em narrativa.

---

🧠 CAPÍTULO 17 — O ADVERSÁRIO TAMBÉM APRENDE

Aqui Shiroe fica particularmente sério.

Cada vez que alguém ataca, existe uma troca de informação.

O defensor aprende:

TTPs
origens
horários
ferramentas
alvos
padrões
sequências

Mas o adversário também aprende:

thresholds
firewall behavior
WAF rules
response codes
architecture
defensive timing
available endpoints
identity behavior

Portanto existe uma pergunta extraordinária:

Depois de cada confronto, quem aprendeu mais?

Isso muda completamente a mentalidade.

---

📈 CAPÍTULO 18 — COMO EU MONTARIA O DASHBOARD

Eu manteria as métricas tradicionais.

Elas continuam importantes.

Camada operacional

ATTACKS DETECTED
ATTACKS BLOCKED
ALERTS
INCIDENTS
MTTD
MTTR
DWELL TIME

Mas acrescentaria outra camada.

Camada estratégica

ATTACK PATHS REMOVED

COMPROMISED IDENTITIES REVOKED

PERSISTENCE MECHANISMS REMOVED

REPEAT COMPROMISE RATE

RE-ENTRY TIME

CRITICAL EXPOSURE REDUCTION

PRIVILEGE PATHS REMAINING

CONTROLS BYPASSED

E finalmente:

Camada de negócio

CRITICAL SERVICES AFFECTED

TRANSACTIONS AT RISK

DOWNTIME PREVENTED

FINANCIAL EXPOSURE

CUSTOMERS AFFECTED

RECOVERY COST

REGULATORY EXPOSURE

Agora conseguimos contar uma história completa:

EVENT
  |
  v
CONTROL
  |
  v
INCIDENT
  |
  v
ADVERSARY EFFECT
  |
  v
BUSINESS EFFECT

---

🧪 CAPÍTULO 19 — PASSO A PASSO PARA UM SOC MAIS MADURO

Shiroe finalmente escreve o plano da raid.

PASSO 1 — Identifique ativos críticos

Pergunte:

O que não pode parar?

O que não pode vazar?

O que não pode ser alterado?

Pode ser:

Db2
CICS
IMS
MQ
datasets
APIs
dados financeiros
credenciais privilegiadas

---

PASSO 2 — Mapeie os caminhos

Não procure apenas acessos diretos.

Procure relações.

USER
  |
GROUP
  |
JCL
  |
STC
  |
CICS
  |
DB2

---

PASSO 3 — Observe comportamento

Correlacione eventos ao longo do tempo.

Principalmente para encontrar comportamento low-and-slow.

---

PASSO 4 — Depois do incidente, não pergunte somente “bloqueamos?”

Pergunte:

qual acesso desapareceu?
qual credencial morreu?
qual persistência foi removida?
qual vulnerabilidade foi eliminada?
qual caminho deixou de existir?

---

PASSO 5 — Tente responder à pergunta brutal

ELE CONSEGUE VOLTAR?

Se sim:

COMO?

Essa resposta talvez revele o verdadeiro trabalho ainda pendente.

---

🎮 CAPÍTULO 20 — O EASTER EGG DO JES2

Depois de toda a investigação, nosso COBOLZEIRO resolve automatizar o processo.

O job fica assim:

//SECURITY JOB
//* SHIROE WAS HERE
//*
//STEP01 EXEC PGM=DETECT
//STEP02 EXEC PGM=BLOCK
//STEP03 EXEC PGM=CONTAIN
//STEP04 EXEC PGM=ERADICATE
//STEP05 EXEC PGM=DISRUPT
//STEP06 EXEC PGM=MEASURE

Resultado:

ATTACKS DETECTED........... 10.000
ATTACKS BLOCKED............ 10.000
ATTACK PATHS REMOVED............ 0
PERSISTENCE REMOVED............. 0
ADVERSARY COST INCREASE......... 0
ADVERSARY CAPABILITY REDUCED.... 0

JES2 responde:

IEF142I SECURITY STEP06
STEP WAS EXECUTED
COND CODE 0000

O gerente comemora.

— Job terminou CC 0000!

Shiroe olha para a tela.

Ajeita os óculos.

E responde:

— O programa terminou corretamente. Isso não significa que resolvemos o problema correto.

☠️

E essa talvez seja uma das melhores lições que um programador COBOL pode levar para cybersecurity.

---

☕ EPÍLOGO — NÃO CONTE FLECHAS. DESCUBRA QUEM AINDA CONSEGUE LUTAR.

Segurança operacional pergunta:

Quantos ataques bloqueamos?

Segurança mais madura acrescenta:

Quanto demoramos para detectar?

Depois:

Quanto demoramos para responder?

Depois:

Quanto tempo o adversário permaneceu?

Mas segurança estratégica precisa continuar:

O que o adversário perdeu?

E finalmente:

Ele consegue fazer novamente?

Essa mudança parece pequena.

Não é.

Ela transforma:

ALERTS

em:

UNDERSTANDING

Transforma:

EVENTS

em:

ATTACK PATHS

Transforma:

BLOCKING

em:

DISRUPTION

E transforma:

SECURITY ACTIVITY

em:

SECURITY OUTCOME

Talvez amanhã seu dashboard diga:

ATTACKS BLOCKED = 100.000

Não jogue o dashboard fora.

A métrica continua útil.

Mas coloque Shiroe sentado ao lado do analista.

Faça-o perguntar:

Quantos caminhos eliminamos?

Quantas credenciais comprometidas morreram?

Quantas persistências desapareceram?

Quanto mais caro ficou atacar?

Quanto tempo demorariam para voltar?

Que capacidades ainda possuem?

O que protegemos para o negócio?

Porque bloquear 10 mil ataques pode ser uma vitória.

Pode ser somente rotina.

Pode ser ruído.

Pode ser um adversário testando suas defesas.

Pode ser um atacante aprendendo.

Pode até esconder aquele único evento silencioso que realmente importa.

E é exatamente por isso que o veterano do mainframe aprende cedo a não ficar hipnotizado por números grandes.

Um milhão de registros processados não significa um processamento correto.

Dez milhões de transações não significam disponibilidade adequada.

Um milhão de mensagens no log não significa observabilidade.

E dez mil ataques bloqueados não significam automaticamente que o adversário perdeu.

No final da raid, Shiroe não pergunta quantas espadas foram balançadas.

Ele olha o mapa.

Observa os recursos.

Calcula as rotas restantes.

Verifica quem ainda possui capacidade de combate.

E pergunta:

“Depois de tudo que fizemos, qual movimento ainda resta ao adversário?”

Essa é a pergunta que deveria aparecer no dashboard de todo SOC.

Porque o verdadeiro objetivo da segurança não é produzir uma montanha de:

BLOCKED
BLOCKED
BLOCKED
BLOCKED
BLOCKED

O objetivo é chegar ao ponto em que, diante do ativo crítico, o atacante examine todas as possibilidades e encontre:

USER
 |
 X

CREDENTIAL
 |
 X

PERSISTENCE
 |
 X

PRIVILEGE PATH
 |
 X

CICS
 |
 X

DB2
 |
 X

OBJECTIVE

Então finalmente podemos escrever:

//FINAL    EXEC PGM=SHIROE

ADVERSARY PATHS.............. 0
CRITICAL ASSETS LOST......... 0
BUSINESS IMPACT.............. 0
RE-ENTRY CAPABILITY.......... 0

IEF142I FINAL - STEP WAS EXECUTED - COND CODE 0000

☕ Agora sim, COBOLZEIRO.

Esse CC 0000 significa alguma coisa.