 |
| 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 0000pode 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
ABENDSSe você executa um programa COBOL batch que processa um milhão de registros, pode registrar:
INPUT RECORDS........ 1.000.000
PROCESSED............. 999.999
REJECTED.............. 1Agora 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,00De repente:
99,9999% SUCCESSnão parece tão maravilhoso.
Segurança possui exatamente esse problema.
Podemos bloquear:
10.000 ataquese deixar passar:
1 ataqueMas 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
ferramentasEsses 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.000Perfeito.
Mas amanhã:
SOURCE: OUTRO IP
ATTEMPTS.............. 10.000Depois:
OUTRO IP
OUTRA CONTA
OUTRO HORÁRIO
OUTRO USER-AGENT
OUTRO ENDPOINTVocê 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 EFEITONí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 failuresSã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 TIMEMTTD — 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 minutosQuanto 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 RemediatePortanto, 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 minutose 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
|
|-------------------------------|
|
DETECTIONQuanto maior esse intervalo, maior pode ser a oportunidade para:
reconhecimento
movimento lateral
roubo de credenciais
persistência
coleta de dados
exfiltraçãoMas 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/minSua party causa:
DAMAGE............. 9.000/minDepois de uma hora, alguém comemora:
TOTAL DAMAGE
540.000Fantá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:
DAMAGEpor:
ATTACKS BLOCKEDSeu SOC pode produzir:
10.000 bloqueios/mêsenquanto o adversário recompõe:
IP
credenciais
infraestrutura
malware
domínios
tokens
contasmais 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
|
+--> DATASETDescobrimos uma permissão inadequada.
Removemos:
PERMIT USER01Problema resolvido?
Shiroe responde:
— Depende.
Porque pode existir:
USER01
|
GROUPA
|
GROUPB
|
FACILITY
|
SURROGAT
|
JCL
|
STC
|
CICS
|
DB2Aqui 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 ---- DB2Remover uma permissão pode eliminar um caminho.
Mas talvez sobrem três.
Uma métrica operacional poderia dizer:
PERMISSIONS REMOVED = 1Uma métrica estratégica perguntaria:
ATTACK PATHS BEFORE = 4
ATTACK PATHS AFTER = 3Isso 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
|
DB2Um atacante dispara:
100.000 REQUESTSO gateway bloqueia:
99.990Dashboard:
99,99% BLOCKEDSensacional.
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
|
DB2Do ponto de vista do dashboard:
DEFENSE SUCCESS = 99,99%Do ponto de vista do atacante:
OBJECTIVE ACHIEVED = YESEis 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.000tentativas.
Ele aparece facilmente nos gráficos.
Mas outro atacante pode fazer:
SEGUNDA..... login
TERÇA....... nada
QUARTA...... consulta
QUINTA...... nada
SEXTA....... alteração pequenaTalvez 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 loginQual 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 RETURNSe 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çõesSeu dashboard comemora:
99,9998% FAILURE RATEMas 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 financeirosO 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.000Depois das mudanças defensivas:
DEPOIS
Custo operacional....... $15.000
Retorno esperado......... $10.000Mesmo 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 riscoIsso é 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-ENTRYIncidente A:
10:00 atacante detectado
10:30 atacante removido
14:00 atacante retornouExcelente MTTR.
Péssima erradicação.
Agora imagine que, depois de corrigirmos:
credenciais
tokens
persistência
privilégios
configurações
vulnerabilidades
attack pathso 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 authorityO dashboard de offboarding diz:
USER DISABLED = YESTecnicamente 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
APPLICATIONE relações como arestas:
MEMBER_OF
CAN_SUBMIT
CAN_EXECUTE
CAN_READ
CAN_IMPERSONATE
CAN_CONNECT
CAN_UPDATEAgora 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 --> ? --> ? --> ? --> DB2Isso é 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
USSA 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 QUERYSeparadamente, 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ênciasMas o adversário também aprende:
thresholds
firewall behavior
WAF rules
response codes
architecture
defensive timing
available endpoints
identity behaviorPortanto 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 TIMEMas 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 BYPASSEDE finalmente:
Camada de negócio
CRITICAL SERVICES AFFECTED
TRANSACTIONS AT RISK
DOWNTIME PREVENTED
FINANCIAL EXPOSURE
CUSTOMERS AFFECTED
RECOVERY COST
REGULATORY EXPOSUREAgora 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 privilegiadasPASSO 2 — Mapeie os caminhos
Não procure apenas acessos diretos.
Procure relações.
USER
|
GROUP
|
JCL
|
STC
|
CICS
|
DB2PASSO 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=MEASUREResultado:
ATTACKS DETECTED........... 10.000
ATTACKS BLOCKED............ 10.000
ATTACK PATHS REMOVED............ 0
PERSISTENCE REMOVED............. 0
ADVERSARY COST INCREASE......... 0
ADVERSARY CAPABILITY REDUCED.... 0JES2 responde:
IEF142I SECURITY STEP06
STEP WAS EXECUTED
COND CODE 0000O 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:
ALERTSem:
UNDERSTANDINGTransforma:
EVENTSem:
ATTACK PATHSTransforma:
BLOCKINGem:
DISRUPTIONE transforma:
SECURITY ACTIVITYem:
SECURITY OUTCOMETalvez amanhã seu dashboard diga:
ATTACKS BLOCKED = 100.000Nã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
BLOCKEDO 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
OBJECTIVEEntã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.
