Bellacosa Mainframe em um pequeno bate papo sobre segurança racf saf

🔥 SEU MAINFRAME ESTÁ SEGURO… OU SÓ PARECE?

A Verdade Crua da Segurança no z/OS (Do RACF ao Crypto Express)

---

☕ Introdução — Um Café com a Realidade

Se você acha que segurança no mainframe é “coisa do passado”, deixa eu te dar um choque de realidade:

O z/OS é um dos ambientes mais seguros do planeta — mas só quando bem configurado.

Porque na prática?

👉 O problema nunca foi a tecnologia
👉 O problema sempre foi quem configura

E é exatamente aqui que começa nossa jornada.

---

🕰️ Um pouco de história (e por que isso importa)

Nos anos 70, quando surgiram os primeiros sistemas corporativos massivos, a IBM percebeu algo:

“Se todo mundo acessa tudo… uma hora dá ruim.”

Nasce então o conceito de controle centralizado de acesso, que evolui para:

• RACF
• SAF
• E todo o ecossistema de segurança do z/OS

Enquanto o mundo distribuído ainda estava descobrindo autenticação…

👉 O mainframe já tinha segurança granular por recurso

---

🧠 O Coração da Segurança: SAF + RACF

Pensa nisso como um fluxo batch:

Usuário → SAF → RACF → decisão (ALLOW / DENY)

🧩 Quem faz o quê?

• SAF → interface (o “porteiro”)
• RACF → decisão (o “juiz”)

💡 Easter egg Bellacosa:

SAF nunca decide nada… ele só “encaminha o problema” 😄

---

🔐 O Mandamento Supremo: Least Privilege

Se você tiver que lembrar de UMA coisa:

“Dê o mínimo necessário — nunca o máximo possível.”

Exemplo clássico:

• Admin RACF → gerencia segurança
• Storage admin → só mexe em dataset

👉 Separação + privilégio mínimo = sistema saudável

---

💣 O ERRO QUE MAIS DERRUBA AMBIENTE

❌ PROTECTALL desligado

Sem isso:

Dataset sem perfil → acesso liberado 😱

👉 Simples assim.
👉 Sem perfil = sem segurança

💡 Curiosidade:
Muitos incidentes em mainframe não são ataques…
São configuração mal feita.

---

🔥 Criptografia no z/OS: Outro nível

Enquanto muita gente ainda “liga TLS”, o z/OS já faz:

🔐 Pervasive Encryption

• Dados em disco
• Dados em trânsito
• Dados protegidos sem mudar aplicação

---

🧬 A Hierarquia das Chaves (isso cai MUITO!)

Master Key → protege → Operational Key → protege → Data

Tipos importantes:

• Master Keys → topo da cadeia
• Symmetric → performance
• Asymmetric → troca segura
• Operational → uso diário

💡 Easter egg:

Se perder a master key… acabou o jogo.

---

⚙️ ICSF — O Tradutor da Criptografia

Aplicação nunca fala direto com hardware.

Ela fala com:

👉 ICSF

Que fala com:

👉 CPACF / Crypto Express

---

🛡️ Níveis de proteção (isso é ouro de prova)

Nível	Segurança
Clear Key	😬
Protected Key	👍
Secure Key	🔥🔥🔥

👉 Secure Key = dentro do hardware (Crypto Express)

---

💻 APF — Quem pode ser “superpoderoso”

Nem todo programa pode rodar com privilégio.

👉 Só quem está no APF

Programa fora do APF → sem privilégio
Programa no APF → modo supervisor

💡 Isso evita:

• código malicioso
• erro catastrófico

---

🌐 Rede no z/OS — Não é só TCP/IP

z/OS Communications Server

• TCP/IP (moderno)
• SNA (legado que ainda vive 😄)

Segurança:

• TLS → camada transporte
• IPSec → VPN (nível rede)

---

📊 SMF — O “log que conta tudo”

Se algo aconteceu:

👉 O SMF sabe

Mas atenção:

Nada é logado automaticamente se você não configurar

---

🧪 Caso real (estilo Bellacosa)

Empresa com:

• RACF instalado
• Criptografia ativa
• Auditoria configurada

Mas…

❌ PROTECTALL desligado
❌ UACC READ em datasets críticos

Resultado?

👉 Vazamento interno
👉 Sem ataque externo

💡 Moral:

Segurança não é tecnologia — é configuração.

---

🧠 Mentalidade Mainframe

Enquanto no mundo distribuído se fala:

“vamos adicionar segurança”

No mainframe é:

“vamos NÃO remover a segurança”

---

🔥 Frases pra tatuar no cérebro

• “SAF conecta, RACF decide”
• “Sem PROTECTALL, está exposto”
• “Sem chave, não há segurança”
• “ALL = mostra tudo”
• “SPECIAL = poder total (cuidado!)”

---

🏁 Conclusão — A Verdade Final

O z/OS não é seguro por acaso.

Ele é seguro porque:

• Foi projetado assim
• Evoluiu assim
• Exige disciplina

Mas…

Um mainframe mal configurado é tão vulnerável quanto qualquer outro sistema.

---

☕ Fechamento estilo Bellacosa

Segurança no mainframe não é só técnica.

É filosofia.

É controle.

É respeito ao sistema.

E principalmente:

É saber que o perigo não está fora… está dentro da configuração.

 

Bellacosa Mainframe teste seu sistema sob ataque

🔥💀 VOCÊ APRENDEU SEGURANÇA… MAS JÁ TESTOU SEU SISTEMA SOB ATAQUE?

10 atividades práticas para sair da teoria e começar a proteger sistemas de verdade

---

☕ INTRODUÇÃO — A VERDADE QUE DÓI

Segurança não se aprende lendo.
👉 Se aprende quebrando sistema… e depois corrigindo.

Se você não praticar:

💣 você só vai descobrir o problema… quando o atacante descobrir primeiro.

---

🧪 ATIVIDADE 1 — ENCONTRE UM SQL INJECTION NO SEU PRÓPRIO SISTEMA

🎯 Objetivo

Pensar como atacante

---

💻 Faça isso

• Pegue um input (API, tela, CICS, batch input)
• Teste:

' OR 1=1 --

---

💥 Resultado esperado

👉 Se algo estranho acontecer… você tem vulnerabilidade

---

🧠 Versão COBOL

• validar WS-FIELD
• nunca confiar em input externo

---

💬 Comentário

“Se você não testar… alguém vai testar por você.”

---

🧪 ATIVIDADE 2 — REMOVA TODOS OS HARDCODED SECRETS

🎯 Objetivo

Eliminar o erro mais comum do mundo

---

💻 Procure no seu código

password
token
key
secret

---

💥 Se encontrar:

👉 você tem risco crítico

---

✅ Solução

• usar Vault / RACF
• variáveis externas

---

💬 Easter egg

👉 80% dos vazamentos começam assim

---

🧪 ATIVIDADE 3 — RODE UM SCAN DE SEGURANÇA

🎯 Objetivo

Ver o que você não vê

---

💻 Ferramentas

• Snyk
• SonarQube

---

💥 Resultado

👉 lista de vulnerabilidades reais

---

💬 Comentário

“Scanner não cria problema… só revela.”

---

🧪 ATIVIDADE 4 — EXPLORE UM XSS NA PRÁTICA

🎯 Objetivo

Ver o ataque funcionando

---

💻 Teste

<script>alert('XSS')</script>

---

💥 Resultado

👉 se executar → vulnerável

---

🧠 Versão real

• portais corporativos
• front-end conectado ao mainframe

---

🧪 ATIVIDADE 5 — ATUALIZE UMA DEPENDÊNCIA VULNERÁVEL

🎯 Objetivo

Entender SCA na prática

---

💻 Faça

• rode scan
• escolha uma lib vulnerável
• atualize

---

💥 Resultado

👉 CVE desaparece

---

💬 Comentário

“Seu código pode estar perfeito… sua lib não.”

---

🧪 ATIVIDADE 6 — QUEBRE SEU PRÓPRIO LOGIN

🎯 Objetivo

Pensar como invasor

---

💻 Teste

• inputs inválidos
• SQL injection
• brute force simples

---

💥 Resultado

👉 encontrar bypass

---

💬 Comentário

“Se login falha… todo sistema falha.”

---

🧪 ATIVIDADE 7 — IMPLEMENTE HEADERS DE SEGURANÇA

🎯 Objetivo

Blindar camada web

---

💻 Adicionar

• Content-Security-Policy
• HSTS
• X-Frame-Options

---

💥 Resultado

👉 reduz ataque XSS e clickjacking

---

🧪 ATIVIDADE 8 — CRIPTOGRAFE UM ARQUIVO SENSÍVEL

🎯 Objetivo

Proteger dados em repouso

---

💻 Use OpenSSL

openssl enc -aes-256-cbc -salt -pbkdf2 -iter 2500

---

💥 Resultado

👉 arquivo ilegível sem senha

---

💬 Comentário

“Dado sem criptografia é dado público.”

---

🧪 ATIVIDADE 9 — CRIE UM MINI PIPELINE DE SEGURANÇA

🎯 Objetivo

Automação

---

💻 Simule

commit → scan → resultado → bloqueio

---

💥 Resultado

👉 segurança contínua

---

🧠 Versão mainframe

• Jenkins + JCL + scan

---

🧪 ATIVIDADE 10 — FAÇA UM “ATAQUE CONTROLADO”

🎯 Objetivo

Pensar como hacker

---

💻 Faça

• use OWASP ZAP
• ataque sua própria aplicação

---

💥 Resultado

👉 visão real de risco

---

💬 Comentário

“Sistema seguro é sistema testado sob ataque.”

---

🧠 CONCLUSÃO — O DIFERENCIAL REAL

Depois dessas 10 atividades, você não é mais:

👉 um dev que escreve código

Você é:

👉 alguém que entende como o sistema quebra… e como evitar isso

---

💬 FRASE FINAL

“Segurança não é o que você implementa…
é o que sobrevive quando alguém tenta quebrar.”

 

 

Bellacosa Mainframe apresenta o OWASP para Analistas programadores COBOL 

💀🔐 “OWASP NÃO É SOBRE WEB… É SOBRE SOBREVIVER — O Guia que Todo Dev COBOL Sênior Ignora Até Ser Tarde”

---

☕ Introdução — o incômodo necessário

Se você trabalha com COBOL há anos, já deve ter ouvido isso:

“Mainframe é seguro por natureza.”

Agora deixa eu ajustar essa frase:

“Mainframe é robusto…
mas segurança depende de você.”

E é exatamente aqui que entra o
👉 OWASP

---

🧠 O que é OWASP (sem enrolação)

OWASP é uma organização global que reúne especialistas para responder uma pergunta simples:

“Como sistemas são invadidos… de verdade?”

E mais importante:

“Como evitar isso?”

---

💡 A essência do OWASP

• Não vende produto
• Não é vendor
• Não é marketing

👉 É conhecimento aberto baseado em ataques reais

---

⏳ Origem — por que isso nasceu?

No início dos anos 2000:

• Aplicações web explodindo
• Segurança praticamente ignorada
• Desenvolvedores focados só em “fazer funcionar”

Resultado?

💣 Sistemas sendo quebrados com facilidade ridícula

Foi aí que nasceu o OWASP.

---

🎯 Objetivo inicial

Criar um guia simples:

“Aqui estão as formas mais comuns de te hackearem.”

---

💣 OWASP Top 10 — o mapa do inimigo

Esse é o coração do projeto:

👉 OWASP Top 10

Uma lista das vulnerabilidades mais críticas.

---

⚠️ Easter Egg #1

Muitas falhas do Top 10 existem há mais de 15 anos

E continuam acontecendo.

---

🔥 Exemplos que batem direto no seu COBOL

1) Injection (SQL Injection)

EXEC SQL
 SELECT * FROM USERS
 WHERE NAME = :WS-NAME
END-EXEC

💀 Sem validação → vulnerável

---

2) Broken Access Control

• Usuário acessa dados que não deveria
• Falha de lógica, não de tecnologia

👉 clássico em CICS mal desenhado

---

3) Sensitive Data Exposure

MOVE "123456" TO WS-PASSWORD

💣 Parabéns, você criou um incidente

---

4) Security Misconfiguration

• RACF mal configurado
• Permissões abertas
• Ambientes sem controle

---

🧠 O ponto que muda tudo

OWASP não fala de linguagem.

Ele fala de comportamento.

---

💬 Tradução direta

• Não importa se é COBOL, Java ou Node
• Se você confiar no input → você perde
• Se você expor segredo → você perde
• Se você não validar → você perde

---

🔍 Como isso entra no seu dia a dia (COBOL + CICS + DB2)

Cenário real moderno:

• API REST → chama CICS
• Frontend → envia dados
• DB2 → executa query

👉 Isso é um ambiente OWASP puro

---

⚠️ Easter Egg #2

O ataque começa no browser…
e termina no seu programa COBOL

---

🧨 OWASP na prática (não teórica)

💥 Fluxo real de ataque:

1. Input malicioso entra via API
2. Passa sem validação
3. Chega no COBOL
4. Executa lógica indevida
5. Acesso indevido ao DB2
6. Logs não detectam

👉 invasor dentro por meses

---

🛠️ Como usar OWASP na prática (PASSO A PASSO)

---

🥇 PASSO 1 — Pare de confiar no input

“Tudo que vem de fora é suspeito.”

• Tela
• API
• arquivo
• integração

---

🥈 PASSO 2 — Validação forte

• tamanho
• tipo
• conteúdo

👉 não é “IF != SPACE” 😅

---

🥉 PASSO 3 — Proteja secrets

• nunca em código
• usar RACF corretamente
• ou vault externo

---

🏅 PASSO 4 — Monitore comportamento

• logs
• acessos estranhos
• padrões anormais

---

🎖️ PASSO 5 — Use o stack moderno

• SAST → antes de rodar
• DAST → testando ataque
• SCA → dependências

👉 DevSecOps

---

🧩 Curiosidades que poucos sabem

---

🧠 Curiosidade #1

OWASP é mantido por voluntários.

👉 os melhores especialistas do mundo colaboram de graça

---

💣 Curiosidade #2

Grandes ataques (inclusive bancos) exploram falhas do Top 10

👉 nada “sofisticado”
👉 só mal feito bem explorado

---

🔥 Curiosidade #3

OWASP não é só Top 10

Eles têm:

• guias de código seguro
• ferramentas
• labs
• projetos específicos

---

⚠️ O maior erro do dev sênior

“Eu já vi de tudo… isso não me pega.”

---

💥 Realidade

• Sistemas antigos + integração moderna = risco novo
• Código legado + API aberta = superfície de ataque gigante

---

🧠 Mentalidade que muda o jogo

Antes:

“Funciona?”

Agora:

“É seguro?”

---

💀 Frases pra carregar com você

“Se entra sem controle… vira comando.”

“Se está no código… não é segredo.”

“Você não precisa ser hackeado… para estar vulnerável.”

---

☕ Conclusão — o choque final

OWASP não é um framework.

Não é uma ferramenta.

Não é modinha.

---

👉 É um espelho.

Ele mostra:

• onde você erra
• como você pode cair
• e como evitar o pior

---

🎯 Fechamento estilo Bellacosa

“O mainframe não vai te salvar.”

“O COBOL não vai te salvar.”

(pausa)

“Mas o conhecimento… pode.”

 

Bellacosa Mainframe proteja seu CICS dos hackers

 

💀🔥 Seu CICS Está Conversando com o Hacker — e Você Chamando de Integração

XSS, SAST, DAST e SCA explicados para quem vive de COBOL… e precisa sobreviver ao mundo moderno

---

☕ Introdução — o choque silencioso

Você passou anos dominando:

• COBOL
• CICS
• DB2
• JCL

E agora vem alguém falar de:

XSS… SAST… DAST… SCA…

Parece coisa de web, né?

(pausa)

Não é.

👉 É sobre como seu sistema pode ser explorado hoje, mesmo sendo legado.

---

🌐 XSS — O ataque que começa fora… e termina no seu COBOL

💡 O que é

XSS (Cross-Site Scripting) é quando alguém injeta código malicioso via interface (web/app).

---

⚡ A história (origem)

No começo da web:

• Sistemas confiavam no input
• Ninguém validava nada
• Browsers executavam tudo

Resultado?

💣 Scripts maliciosos rodando dentro da aplicação

---

💥 O pulo do gato (Easter Egg)

XSS não é só frontend.

Hoje ele pode:

• roubar sessão
• alterar requisições
• chamar APIs

👉 e aí…

“Quem executa o comando final?”

👉 Seu backend.
👉 Seu COBOL.

---

🧠 Exemplo prático (fluxo real)

1. Usuário injeta script no campo web
2. Script roda no navegador de outro usuário
3. Esse script chama API
4. API chama CICS
5. COBOL processa como legítimo

💀 Pronto. Você foi usado como ferramenta.

---

🎯 Insight de sênior

“O problema não é o script…
é confiar no que veio de fora.”

---

🔍 SAST — O scanner que te salva antes do desastre

💡 O que é

SAST (Static Application Security Testing) analisa seu código sem executar.

---

🧠 Tradução direta

“É alguém lendo seu COBOL procurando erro de segurança.”

---

⏳ Origem

Surgiu quando empresas perceberam:

“Corrigir bug em produção custa caro.”

👉 Então começaram a analisar antes.

---

💻 Exemplo COBOL

EXEC SQL
 SELECT * FROM CLIENTS
 WHERE NAME = :WS-NAME
END-EXEC

Se WS-NAME não for validado…

👉 SAST grita.

---

🎯 O que ele pega

• SQL Injection
• lógica insegura
• uso indevido de variáveis
• padrões perigosos

---

💣 Easter Egg

70% das falhas poderiam ser evitadas aqui.

Mas…

ninguém roda SAST direito.

---

🧨 DAST — Quando o sistema enfrenta o mundo real

💡 O que é

DAST (Dynamic Application Security Testing) testa o sistema rodando.

---

🧠 Tradução direta

“Aqui é o hacker batendo na sua porta.”

---

⚡ Como funciona

• envia inputs maliciosos
• testa endpoints
• tenta quebrar autenticação

---

💥 Exemplo real

• envia ' OR '1'='1
• manipula headers
• força comportamento inesperado

👉 se o sistema responder errado…

💀 vulnerabilidade confirmada

---

🎯 Diferença brutal

SAST	DAST
teoria	prática
código	comportamento
prevenção	exploração

---

💣 Easter Egg

Tem coisa que só aparece em produção.

---

🧩 SCA — O inimigo invisível

💡 O que é

SCA (Software Composition Analysis) analisa dependências.

---

🧠 Tradução direta

“Seu código pode estar perfeito…
e ainda assim vulnerável.”

---

⏳ Origem

Explosão de:

• bibliotecas
• frameworks
• integrações

👉 ninguém mais escreve tudo do zero

---

🔥 No seu mundo (sim, isso te afeta)

• copybooks compartilhados
• serviços externos
• APIs
• módulos reutilizados

---

💥 Exemplo real

Você usa um serviço interno vulnerável.

👉 você herda o problema.

---

💣 Easter Egg

Muitos ataques recentes são cadeia de dependência.

---

⚔️ JUNTANDO TUDO — O ECOSSISTEMA REAL

💡 Como tudo se conecta

1. XSS → entra pelo frontend
2. DAST → descobre falha rodando
3. SAST → poderia ter evitado
4. SCA → revela risco escondido

---

🧠 Tradução brutal

Você não perde por uma falha.

Você perde por um conjunto.

---

🛠️ COMO APLICAR ISSO NO SEU DIA A DIA (PASSO A PASSO)

---

🥇 1. Pare de confiar no input

• tudo é suspeito
• sempre

---

🥈 2. Validação forte

• tipo
• tamanho
• conteúdo

---

🥉 3. Integre SAST no pipeline

• antes do deploy
• obrigatório

---

🏅 4. Execute DAST regularmente

• simular ataque
• testar comportamento

---

🎖️ 5. Monitore dependências (SCA)

• CVEs
• versões
• integrações

---

🧠 6. Pense como atacante

“Se eu quisesse quebrar isso… como faria?”

---

💀 ERROS CLÁSSICOS DE DEV SÊNIOR

• “isso nunca aconteceu aqui”
• “mainframe já é seguro”
• “isso é problema do front”

---

🔥 FRASES PRA LEVAR PRA VIDA

“Segurança não é tecnologia… é disciplina.”

“Se entra sem controle… vira comando.”

“O ataque começa longe… mas termina no seu código.”

---

☕ CONCLUSÃO — A VERDADE QUE NINGUÉM GOSTA

Você não precisa aprender isso porque virou moda.

Você precisa porque:

👉 seu sistema agora está exposto
👉 seu COBOL faz parte de um ecossistema
👉 e o atacante já entendeu isso

---

🎯 Fechamento

“Você pode continuar escrevendo código que funciona…”

(pausa)

“Ou começar a escrever código que sobrevive.”

 

 

Bellacosa Mainframe em uma conversa sobre segurança mainframe

🔥 SEU RACF ESTÁ TE PROTEGENDO… OU TE TRAINDO?

🧪 LAB PRÁTICO — Do Acesso Liberado ao Controle Total no z/OS

---

☕ Introdução — Bem-vindo ao caos controlado

Hoje você não vai só aprender…

👉 Você vai quebrar a segurança do sistema
👉 E depois consertar como um verdadeiro admin raiz

💡 Estilo Bellacosa:

“Se você nunca viu um sistema inseguro… você ainda não entendeu segurança.”

---

🎯 Objetivo do LAB

Você vai:

• ❌ Criar um cenário inseguro (sem proteção)
• 🔍 Explorar a falha
• 🛡️ Corrigir com RACF
• 🔐 Validar segurança

---

⚠️ Cenário

Você é admin e recebe:

“Precisamos liberar rápido o dataset PROD.FINANCEIRO.*”

😈 Spoiler: isso vai dar ruim.

---

🧪 FASE 1 — Criando o problema (sim, de propósito)

1️⃣ Criar dataset “sensível”

//STEP1 EXEC PGM=IEFBR14
//DD1   DD DSN=PROD.FINANCEIRO.DADOS,
//      DISP=(NEW,CATLG),
//      SPACE=(TRK,(1,1)),
//      DCB=(RECFM=FB,LRECL=80,BLKSIZE=800)

---

2️⃣ NÃO criar perfil RACF

👉 Sim… você vai deixar sem proteção

💡 Easter egg:

Isso acontece mais em produção do que você imagina 😅

---

3️⃣ Testar acesso com outro usuário

TSO LISTDS 'PROD.FINANCEIRO.DADOS'

👉 Se PROTECTALL estiver OFF:

💥 Acesso permitido

---

💣 Resultado

Dataset crítico → sem perfil → acesso liberado 😱

---

🧠 REFLEXÃO

Você acabou de:

• Criar uma falha real
• Simular um incidente comum

👉 E ninguém hackeou nada

---

🛡️ FASE 2 — Corrigindo como profissional

1️⃣ Criar perfil de dataset

RDEFINE DATASET PROD.FINANCEIRO.* UACC(NONE)

---

2️⃣ Permitir acesso controlado

PERMIT PROD.FINANCEIRO.* CLASS(DATASET) ID(FINUSR) ACCESS(READ)

---

3️⃣ Ativar proteção

SETROPTS RACLIST(DATASET) REFRESH

---

4️⃣ (CRÍTICO) Ativar PROTECTALL

SETROPTS PROTECTALL

💥 Agora sim:

👉 Dataset sem perfil = acesso negado

---

🔍 FASE 3 — Validando segurança

Teste novamente:

TSO LISTDS 'PROD.FINANCEIRO.DADOS'

👉 Resultado esperado:

ICH408I USER NOT AUTHORIZED

🔥 Agora você está protegido

---

⚙️ FASE 4 — Explorando comando “ALL”

LD DA('PROD.FINANCEIRO.*') ALL

👉 Vai mostrar:

• Dono
• Permissões
• UACC
• Detalhes completos

💡 Frase pra vida:

“ALL = mostra tudo. Sem ALL = você está voando no escuro.”

---

🔐 FASE 5 — Elevando nível com SPECIAL

Criar usuário admin

ADDUSER ADMIN1 SPECIAL

👉 Esse usuário pode:

• Alterar tudo
• Criar perfis
• Controlar segurança

⚠️ Cuidado:

SPECIAL = poder total

---

⚙️ FASE 6 — Simulando programa privilegiado (APF)

👉 Imagine:

Um programa precisa acessar memória sensível

Sem APF:

❌ Falha

Com APF:

✅ Executa com privilégio

💡 Curiosidade:

Muitos ataques internos exploram programas mal autorizados no APF

---

🔐 FASE 7 — Criptografia (visão prática)

👉 Fluxo real:

App → ICSF → Crypto Express → dado protegido

Você não vê… mas está acontecendo.

---

📊 FASE 8 — Auditoria com SMF

👉 Tudo que você fez pode ser registrado:

• Acesso ao dataset
• Tentativas negadas
• Alterações

💡 Mas só se estiver configurado 😉

---

🧠 Easter Eggs do LAB

• PROTECTALL OFF = caos silencioso
• UACC(READ) mal usado = vazamento
• SPECIAL demais = bomba relógio
• Sem log = sem prova

---

🏁 Checklist final

Você aprendeu:

• ✔ Criar falha real
• ✔ Corrigir com RACF
• ✔ Controlar acesso
• ✔ Validar segurança
• ✔ Entender impacto

---

☕ Conclusão estilo Bellacosa

Segurança no mainframe não é:

• ferramenta
• comando
• checklist

É:

Mentalidade.

Porque no final…

👉 O sistema nunca erra
👉 Quem erra é quem configura

---

🔥 Desafio final

Responda:

Seu ambiente hoje está protegido…
ou só parece?

 

 

Bellacosa Mainframe comenta sobre auditoria racf e segurança mainframe

💀🔥 “Seu RACF está auditado… ou você só roda comando manual?”

🧠 Checklist automatizado com JCL + REXX (nível banco, zero ilusão)

“Se sua auditoria depende de humano…
ela já falhou.”

---

🧠 📜 A verdade que ninguém te conta

No mundo real (banco, fintech, governo):

👉 Auditoria manual = teatro
👉 Auditoria automatizada = sobrevivência

E aqui entra a dupla lendária do mainframe:

• JCL → orquestra
• REXX → pensa, filtra, decide

💡 Curiosidade Bellacosa:

Antes de SIEM moderno… o mainframe já fazia auditoria automatizada com SMF + REXX.

---

⚙️ 🧬 Arquitetura do “scanner RACF”

👉 Fluxo real:

1. JCL executa comandos RACF
2. Output vai para dataset
3. REXX lê dataset
4. Aplica regras de auditoria
5. Gera relatório (ou alerta)

---

🧨 1. JCL — o motor da auditoria

🔥 Exemplo prático (coleta de evidências)

//AUDITRAC JOB (ACCT),'RACF SCAN',CLASS=A,MSGCLASS=X
//STEP1 EXEC PGM=IKJEFT01
//SYSTSPRT DD DSN=&&RACFOUT,DISP=(,PASS),
// SPACE=(CYL,(5,5)),UNIT=SYSDA
//SYSTSIN DD *
  SETROPTS LIST
  SEARCH CLASS(USER) MASK(*) SPECIAL
  RLIST DATASET * AUTHUSER(*)
/*

💥 O que isso faz:

• lista configurações RACF
• identifica usuários privilegiados
• expõe acessos indevidos

---

🧠 2. REXX — o cérebro da auditoria

🔥 Exemplo prático (detecção de risco)

/* REXX */
parse arg dataset
"EXECIO * DISKR" dataset "(STEM LINES. FINIS"

do i = 1 to lines.0
  if pos('SPECIAL', lines.i) > 0 then do
     say 'ALERTA: usuário com SPECIAL -> ' lines.i
  end

  if pos('*PUBLIC', lines.i) > 0 then do
     say 'RISCO CRÍTICO: acesso público detectado -> ' lines.i
  end
end

💀 Resultado:

• identifica risco automaticamente
• elimina análise manual

---

🧬 3. Regras que um banco REAL usa

👉 Não é só listar — é interpretar

✔️ Nenhum *PUBLIC em dataset crítico
✔️ SPECIAL limitado
✔️ APF controlado
✔️ UID 0 auditado
✔️ FACILITY revisada
✔️ STARTED TASK mapeada

---

⚙️ 4. Evolução hardcore (nível enterprise)

👉 Automatização completa:

• agendado via JES2 / scheduler
• output versionado
• comparação diária (drift detection)
• envio de alerta (email / SIEM)

💡 Easter egg:

Drift de segurança é mais perigoso que invasão direta.

---

🧠 5. Comparação inteligente (ontem vs hoje)

🔥 Ideia poderosa

REXX pode comparar execuções:

if linha_hoje \= linha_ontem then
  say 'ALTERAÇÃO DETECTADA!'

💥 Isso detecta:

• privilégio adicionado
• acesso aberto
• mudança suspeita

---

🧾 6. Output estilo auditor (nível banco)

👉 Não basta log — precisa ser auditável

Exemplo:

[CRITICAL] USER HACKER HAS SPECIAL
[HIGH] DATASET PROD.FINANCE WITH *PUBLIC READ
[MEDIUM] NEW APF LIBRARY DETECTED

---

💣 7. Onde mora o perigo real

👉 Não está no código… está na omissão

🔥 Problemas comuns:

• script roda mas ninguém lê
• alertas ignorados
• baseline inexistente

💡 Insight:

Auditoria sem ação é só documentação bonita.

---

🧠 8. Easter eggs de quem vive isso

💡 IKJEFT01 é o “shell invisível” do z/OS
💡 REXX consegue parsear RACF melhor que muita ferramenta cara
💡 JES spool é fonte de ouro pra auditor
💡 dataset temporário mal protegido = vazamento

---

⚔️ 9. Fluxo real de ataque vs auditoria automatizada

👹 Ataque:

1. ganha acesso
2. eleva privilégio
3. altera RACF
4. mantém persistência

🛡️ Auditoria automatizada:

1. detecta alteração
2. gera alerta
3. compara baseline
4. bloqueia rapidamente

---

🏦 Realidade nível banco

👉 Banco não confia em:

• print de tela
• comando manual
• auditor humano

👉 Banco confia em:

• automação
• evidência
• histórico

---

💀🔥 Frase final Bellacosa

“Se o seu RACF muda e você não percebe…
quem percebe é o atacante.”

 

Bellacosa Mainframe alerta sobre riscos no racf mal configurado

💀🔥 “Seu RACF está seguro… ou você só acha?”

🧠 Checklist de Auditoria RACF nível banco (com segredos que ninguém te conta)

“RACF não falha…
quem falha é quem confia demais nele.”

---

🧠 📜 Contexto histórico (o começo de tudo)

O RACF nasceu nos anos 70 junto com o z/OS (antes MVS).

👉 Naquela época:

• segurança era controle de acesso
• hoje é sobrevivência digital

💡 Curiosidade:

RACF foi um dos primeiros sistemas do mundo a implementar controle centralizado de identidade — antes do conceito de IAM moderno.

---

💀🔥 O CHECKLIST QUE SEPARA AMADOR DE BANCO

---

🧨 1. *PUBLIC — o vilão silencioso

👉 Procure:

// quem tem acesso aberto?
RLIST DATASET * AUTHUSER(*)

💥 Red flag:

• datasets críticos com:

ID(*PUBLIC) ACCESS(READ ou UPDATE)

🔥 Insight Bellacosa:

80% das falhas começam aqui.

---

🧠 2. Usuários com SPECIAL / OPERATIONS

👉 Liste:

SEARCH CLASS(USER) MASK(*) SPECIAL

💥 Risco:

• acesso total ao RACF

🎯 Dica senior:

• separar:
  • ADMIN ≠ AUDITOR

---

⚙️ 3. Grupos com autoridade excessiva

👉 Verifique:

LISTGRP * OMVS

💥 Problema:

• grupo herdando privilégio indevido

🔥 Easter egg:

Um grupo mal configurado é pior que um usuário root.

---

🧬 4. Programas APF e AC=1

👉 Verifique APF:

D PROG,APF

💥 Risco:

• execução em modo supervisor

🎯 Ataque clássico:

• inserir loadlib malicioso

---

🔐 5. Password Policy (o calcanhar de aquiles)

👉 Cheque:

SETROPTS LIST

💥 Problemas comuns:

• senha simples
• sem expiração
• sem history

🔥 Curiosidade:

Já vi banco com senha “123456” em ambiente produtivo.

---

🌐 6. FACILITY class (o “backdoor oficial”)

👉 Verifique:

RLIST FACILITY *

💥 Risco:

• permissões ocultas

🎯 Exemplo crítico:

• BPX.* (Unix System Services)

---

🧑‍💻 7. USS (Unix no mainframe = Linux feelings)

👉 Verifique:

LISTUSER USER OMVS

💥 Risco:

• UID 0 (root)

🔥 Insight:

USS é o ponto favorito de pivot de atacante moderno.

---

🧾 8. Logging / SMF (sem isso você está cego)

👉 Cheque:

• SMF 80 (RACF)
• SMF 30 (jobs)

💥 Problema:

• logs incompletos

🎯 Dica:

• integrar com SIEM

---

🧠 9. Started Tasks (STC) — privilégio invisível

👉 Verifique:

RLIST STARTED *

💥 Risco:

• tarefas com privilégios elevados

🔥 Easter egg:

STC mal protegido = root invisível rodando 24x7

---

🔗 10. Integrações externas (o novo campo de batalha)

👉 Verifique:

• CICS
• z/OS Connect

💥 Risco:

• acesso indireto ao core

🎯 Realidade:

O ataque não entra pelo mainframe… entra pela API.

---

💀🔥 CHECKLIST RÁPIDO (modo auditor)

✔️ Nenhum dataset crítico com *PUBLIC
✔️ SPECIAL restrito e auditado
✔️ APF controlado
✔️ Senha forte e rotacionada
✔️ SMF ativo e monitorado
✔️ USS sem UID 0 indevido
✔️ FACILITY revisada
✔️ STC mapeado
✔️ Integrações seguras

---

🧠💣 Fluxo real de ataque (pra abrir a mente)

1. credencial fraca
2. acesso TSO/FTP
3. enumeração RACF
4. exploração (APF / FACILITY / USS)
5. persistência
6. exfiltração

---

🧬 Easter Eggs que só senior percebe

💡 RACF não protege dataset não catalogado direito
💡 APF + AC=1 = execução nível kernel
💡 FACILITY é mais perigosa que DATASET
💡 USS é o “Linux escondido” do mainframe

---

🏦 Realidade nível banco

👉 Banco não confia em RACF…
👉 Banco audita RACF o tempo todo

---

🔥 Frase final estilo Bellacosa

“Se você não auditou seu RACF hoje…
alguém pode estar usando ele melhor que você.”