Bellacosa Mainframe lab seu cics sob ataque

🔥💀 COBOL SECURITY LAB — “SEU CICS SOB ATAQUE”

Hands-on prático com CICS + DB2 para aprender segurança na marra

---

☕ INTRODUÇÃO

Você não vai só aprender…

👉 você vai:

• explorar vulnerabilidade
• corrigir
• validar

💣 exatamente como um atacante faria

---

🧪 LAB 1 — SQL INJECTION NO DB2

🎯 Objetivo

Mostrar como um COBOL pode ser vulnerável

---

💻 Código vulnerável

IDENTIFICATION DIVISION.
PROGRAM-ID. LOGIN.

DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-USER     PIC X(20).
01 WS-PASS     PIC X(20).

PROCEDURE DIVISION.

EXEC SQL
  SELECT NAME INTO :WS-USER
  FROM USERS
  WHERE NAME = :WS-USER
  AND PASSWORD = :WS-PASS
END-EXEC.

---

💣 Ataque

Input:

' OR '1'='1

---

💥 Resultado

👉 bypass de autenticação

---

✅ Correção

IF WS-USER NOT ALPHABETIC
   DISPLAY "INVALID INPUT"
   STOP RUN
END-IF.

---

💬 Insight

👉 validação é a primeira defesa

---

🧪 LAB 2 — BUFFER / TAMANHO DE INPUT

🎯 Objetivo

Evitar overflow e dados inválidos

---

💻 Problema

01 WS-NAME PIC X(10).

Input:

AAAAAAAAAAAAAAAAAAAAAAAAAAAA

---

💥 Resultado

👉 truncamento / corrupção

---

✅ Correção

IF LENGTH OF WS-NAME > 10
   DISPLAY "INPUT TOO LONG"
END-IF.

---

🧪 LAB 3 — HARDCODED PASSWORD

🎯 Objetivo

Eliminar segredo no código

---

❌ Código

MOVE "DB123456" TO WS-PASS.

---

💣 Problema

👉 vazamento garantido

---

✅ Correção

• usar RACF
• usar external security

👉 RACF

---

🧪 LAB 4 — VALIDAÇÃO DE COMMAREA (CICS)

🎯 Objetivo

Proteger entrada CICS

---

💻 Código vulnerável

MOVE DFHCOMMAREA TO WS-DATA.

---

💣 Problema

👉 dados maliciosos

---

✅ Correção

IF EIBCALEN = 0
   DISPLAY "NO DATA"
   RETURN
END-IF.

---

🧪 LAB 5 — LOGGING SEGURO

🎯 Objetivo

Evitar vazamento de dados

---

❌ Errado

DISPLAY "PASSWORD: " WS-PASS.

---

💣 Problema

👉 senha em log

---

✅ Correção

DISPLAY "LOGIN ATTEMPT".

---

🧪 LAB 6 — CONTROLE DE ACESSO (RACF)

🎯 Objetivo

Simular autorização

---

💻 Exemplo

CALL 'RACROUTE' USING ...

---

💬 Resultado

👉 só usuários autorizados acessam

---

🧪 LAB 7 — INTEGRAÇÃO COM API (RISCO REAL)

🎯 Objetivo

Simular API via CICS

---

💣 Problema

👉 input externo não confiável

---

✅ Solução

• validar JSON
• sanitizar campos

---

🧪 LAB 8 — TRATAMENTO DE ERRO

🎯 Objetivo

Não expor sistema

---

❌ Errado

DISPLAY SQLCODE.

---

💣 Problema

👉 revela estrutura interna

---

✅ Correto

DISPLAY "ERROR OCCURRED".

---

🧪 LAB 9 — CONTROLE DE TRANSAÇÃO

🎯 Objetivo

Evitar inconsistência

---

💻 Uso

EXEC CICS SYNCPOINT
END-EXEC.

---

💬 Importante

👉 protege integridade

---

🧪 LAB 10 — SIMULAR ATAQUE REAL

🎯 Objetivo

Mentalidade hacker

---

💻 Faça

• testar inputs inválidos
• tentar bypass
• observar comportamento

---

💥 Resultado

👉 descobrir falhas reais

---

🧠 VISÃO FINAL

Você fez:

• ataque
• defesa
• validação

👉 isso é segurança real

---

💬 FRASE FINAL

“Mainframe não é seguro por ser forte…
é seguro quando você fecha as portas certas.”

 

Bellacosa Mainframe DEVSECOPS na pratica

🔥💀 SEU COBOL NO IBM z17 ESTÁ SEGURO… OU SÓ AINDA NÃO FOI TESTADO POR UM ATACANTE?

Do RACF ao DevSecOps: o guia definitivo de Application Security para quem mantém sistemas que não podem falhar

---

☕ INTRODUÇÃO — A VERDADE QUE QUASE NINGUÉM FALA

Se você trabalha com COBOL no mainframe, provavelmente já ouviu isso:

“Mainframe é seguro por natureza.”

👉 Não.
Ele é resiliente, confiável e robusto — mas segurança de aplicação não vem de fábrica.

E aqui vai o ponto que muda tudo:

💣 Os mesmos erros que derrubavam sistemas há 20 anos… continuam sendo explorados hoje.

---

🧠 UM POUCO DE HISTÓRIA (ANTES DO “CYBER” EXISTIR)

Nos tempos de:

• cartões perfurados
• terminais 3270
• batch noturno

Segurança era baseada em:

👉 controle físico e acesso restrito

💬 Easter egg:

“Se você não estava na sala do mainframe… você não atacava o sistema.”

Hoje?

👉 qualquer API exposta conecta seu sistema ao mundo.

---

🔐 O NASCIMENTO DA SEGURANÇA NO MAINFRAME

Ferramentas como o RACF surgiram para resolver:

• quem pode acessar
• o que pode acessar
• quando pode acessar

👉 Foi o início do que hoje chamamos de Identity & Access Management

---

💣 O PROBLEMA MODERNO

Hoje temos:

• APIs
• integração com cloud
• microservices
• mobile apps

👉 E seu COBOL continua sendo o backend crítico

---

💥 Resultado:

O mainframe virou alvo indireto

---

🔥 OWASP — O MANUAL DO ATACANTE

A OWASP lista as principais vulnerabilidades.

E aqui vai o choque:

👉 SQL Injection, XSS e falhas de validação continuam no topo.

💬 Curiosidade:

A lista de 2007 é assustadoramente parecida com a atual.

---

💣 SQL INJECTION NO COBOL (SIM, EXISTE)

❌ Código vulnerável

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

Se WS-NAME vier contaminado…

💥 você abriu a porta

---

💣 Ataque clássico

' OR '1'='1

👉 bypass de autenticação

---

✅ Correção

• validar input
• restringir caracteres
• checar SQLCODE

---

💬 Insight:

“O problema não é o SQL… é confiar no input.”

---

🌐 XSS — O ATAQUE QUE NÃO ESTÁ NO COBOL… MAS TE AFETA

Você pode pensar:

👉 “isso é problema de frontend”

Errado.

Se seu sistema:

• expõe API
• retorna dados sem sanitização

💥 você participa do ataque

---

🧪 SAST, DAST E SCA — OS 3 PILARES

🔍 SAST (Static Analysis)

Analisa código sem executar

👉 detecta:

• lógica insegura
• SQL injection

---

🌐 DAST (Dynamic Analysis)

Testa sistema rodando

👉 simula atacante real

---

📦 SCA (Dependências)

👉 detecta vulnerabilidades em:

• bibliotecas
• frameworks
• integrações

💣 Insight:

“Seu código pode estar perfeito… mas sua dependência pode te comprometer.”

---

🔐 SECRETS — O ERRO QUE MAIS DERRUBA EMPRESA

❌ Clássico COBOL

MOVE "PASSWORD123" TO WS-PASS

💥 vazamento garantido

---

✅ Correto

• usar RACF
• usar controle externo
• nunca hardcode

---

💬 Easter egg:

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

---

🔄 DEVSECOPS NO MAINFRAME

Antes:

👉 segurança no final

Hoje:

👉 segurança no início

---

🔥 Pipeline moderno

código → scan → teste → deploy → monitoramento

---

Mesmo no mainframe, isso já é realidade com:

• pipelines CI/CD
• integração com APIs
• automação de testes

---

🧱 CICS — O PONTO CRÍTICO

💣 Problema

MOVE DFHCOMMAREA TO WS-DATA

👉 sem validação

---

✅ Correção

• validar tamanho
• validar conteúdo
• tratar EIBCALEN

---

🗄️ DB2 — ONDE O DADO VIRA RISCO

• SQL mal construído
• input não validado
• retorno ignorado

👉 tudo isso vira vulnerabilidade

---

💥 ERROS QUE CAUSAM INCIDENTES

• input sem validação
• senha em log
• dependência vulnerável
• falta de monitoramento

---

💬 Curiosidade:

Grandes incidentes não acontecem por falhas complexas…
mas por erros básicos ignorados.

---

🧠 MENTALIDADE — O QUE SEPARA OS PROFISSIONAIS

Dev comum:

👉 “funciona”

Dev sênior (seguro):

👉 “resiste a ataque”

---

☕ PARA PENSAR NO CAFÉ

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

---

🧪 PASSO A PASSO PRÁTICO (APLICÁVEL HOJE)

1. Valide TODO input
2. Remova secrets do código
3. Revise SQL crítico
4. Analise dependências
5. Teste como atacante
6. Automatize segurança

---

💣 REALIDADE FINAL

Seu sistema pode:

• processar milhões de transações
• rodar há décadas
• nunca ter caído

👉 e ainda assim estar vulnerável

---

💬 FRASE FINAL

“Mainframe não é seguro por ser forte…
é seguro quando você fecha as portas certas.”

---

🚀 CONCLUSÃO

Application Security não é moda.
Não é ferramenta.
Não é opcional.

👉 É responsabilidade de quem escreve código.

---

Se você domina COBOL e agora entende segurança…

🔥 você não é mais só dev
👉 você é um guardião de sistemas críticos