Translate

Mostrar mensagens com a etiqueta APIs Mainframe. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta APIs Mainframe. Mostrar todas as mensagens

quarta-feira, 3 de dezembro de 2025

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

 

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