Translate

Mostrar mensagens com a etiqueta auditoria. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta auditoria. Mostrar todas as mensagens

segunda-feira, 14 de junho de 2021

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

 

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.”

sábado, 1 de maio de 2021

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

 

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ê.”

 

quinta-feira, 1 de abril de 2021

🧠 💥 Coletânea de ataques hacker em ambiente IBM Mainframe

 

Bellacosa Mainframe apresenta alguns casos de ataques hackers em mainframe

🧠 💥 Coletânea de ataques hacker em ambiente IBM Mainframe

🧪 1. 1965 — O primeiro “hack” da história (IBM 7094 – CTSS)

👉 Sistema: IBM 7094 (CTSS – Compatible Time Sharing System)

O que aconteceu:

  • Um bug no editor criou um arquivo temporário com nome fixo
  • Dois usuários simultâneos causaram:
    • exposição do arquivo de senhas (!)

Impacto:

  • Senhas ficaram visíveis para qualquer usuário

📌 IMPORTANTE:
👉 Isso é considerado o primeiro vazamento de credenciais da história

✔️ Lição:

  • Controle de concorrência e isolamento são fundamentais


🧠 2. 1967 — Primeira invasão de rede (IBM APL Network)

👉 Ambiente: rede experimental IBM APL

O que aconteceu:

  • Estudantes exploraram workspaces compartilhados
  • Conseguiram navegar além do escopo permitido

Impacto:

  • Primeira invasão “não autorizada” documentada em rede

✔️ Lição:

  • Segurança lógica > segurança física


💣 3. 2007 — Primeiro hack documentado em z/OS moderno

👉 Caso citado em estudos de segurança mainframe

Possível alvo:

  • Banco europeu (ex: Nordea Bank)

O que aconteceu:

  • Uso de vulnerabilidades em ambiente z/OS
  • exploração via acesso indireto (provavelmente aplicações)

✔️ Lição:

  • Mainframe moderno também é atacável


🏦 4. 2012 — Caso Nordea Bank / Governo Sueco (O MAIS CLÁSSICO)

👉 Ambiente: IBM z/OS

O que aconteceu:

  • Hackers usaram:
    • z/OS emulado
    • exploração de vulnerabilidades (0-day)
  • Conseguiram:
    • escalar privilégios (SPECIAL)
    • modificar APF
    • acessar dados sensíveis
    • transferir dinheiro (~$850k)

Impacto:

  • Um dos raros casos confirmados de invasão real em mainframe

✔️ Técnica usada:

  • privilege escalation
  • persistência (APF)
  • exfiltração de datasets

✔️ Lição:

  • RACF mal configurado = porta aberta


🏴‍☠️ 5. 2012 — Hacker do Pirate Bay (caso judicial)

👉 Hacker: cofundador do Pirate Bay

O que aconteceu:

  • Invasão de mainframe
  • Roubo de dados governamentais

Impacto:

  • considerado o maior caso de hacking de mainframe na Dinamarca

✔️ Lição:

  • ameaça real não é só técnica — é também judicial/legal


🧾 6. Casos indiretos (2014–2015) — Dados de mainframe expostos

👉 Empresas:

  • Home Depot
  • Anthem
  • Experian

O que aconteceu:

  • Ataque NÃO começou no mainframe
  • MAS:
    • dados críticos estavam no mainframe
    • foram exfiltrados via sistemas distribuídos

Impacto:

  • milhões de registros vazados

✔️ Insight poderoso:
👉 O mainframe NÃO foi invadido diretamente
👉 mas foi comprometido indiretamente

✔️ Lição:

  • o risco está na integração (APIs, middlewares)


⚠️ 7. Casos IBM i (AS/400) — “Nunca foi hackeado” (mito quebrado)

👉 Realidade:

  • já houve invasões documentadas

Problema comum:

  • permissões abertas (*PUBLIC *ALL)
  • falta de auditoria

✔️ Lição:

  • segurança default ≠ segurança real


🧨 8. Engenharia social e insider (o ataque mais comum)

👉 Segundo especialistas:

  • A maioria dos ataques não é “hack remoto hollywoodiano”
  • São:
    • insiders
    • credenciais roubadas
    • acesso legítimo abusado

✔️ Lição:

  • RACF + auditoria > firewall


📊 9. Estatística brutal (realidade do mercado)

👉 Apenas 0.1% dos mainframes reportaram breach direto

✔️ Tradução Bellacosa:

  • extremamente seguro
  • MAS quando falha → impacto é gigante


🧠 🔥 Padrões REAIS dos ataques em Mainframe

🧩 Vetores mais comuns

  • má configuração de RACF / ACF2 / Top Secret
  • credenciais roubadas
  • aplicações CICS vulneráveis
  • integração com sistemas distribuídos
  • insiders

⚙️ Técnicas usadas

  • privilege escalation (SPECIAL / OPERATIONS)
  • manipulação de APF
  • execução de REXX malicioso
  • leitura de datasets (PII)
  • exfiltração via FTP / TCP/IP stack

💀 MITO vs REALIDADE

MitoRealidade
Mainframe não é hackeávelÉ, mas difícil
Só ataque externoMaioria é interna
RACF resolve tudoDepende da configuração
Isolado = seguroIntegração quebra isso

🧠 Conclusão estilo Bellacosa

👉 O mainframe NÃO é invulnerável
👉 Ele é mal compreendido

💡 A verdade:

“Mainframe não cai por brute force…
cai por negligência.”


PS: Nunca se esqueça que o inimigo pode estar dentro do castelo. E os demonios riem quando fazemos planos infaliveis. 

segunda-feira, 1 de março de 2021

💀🔥 Top 10 vulnerabilidades reais em z/OS (com exemplos práticos)

 

Bellacosa Mainframe apresenta as 10 vulnerabilidades mais comuns em Mainframe

💀🔥 Top 10 vulnerabilidades reais em z/OS (com exemplos práticos)

“O perigo no mainframe não é o sistema…
é quem configura.”


🧨 1. RACF mal configurado (*PUBLIC liberado)

Cenário clássico:

// Dataset crítico liberado
PERMIT DATASET.PROD.FINANCE CLASS(DATASET) ID(*PUBLIC) ACCESS(READ)

💥 Resultado:

  • qualquer usuário pode ler dados financeiros

✔️ Ataque:

  • exfiltração via TSO, FTP ou batch

🔥 Correção:

  • remover *PUBLIC
  • usar grupos restritos

🧠 2. Usuário com SPECIAL indevido

Erro comum:

  • dar SPECIAL “temporário” e esquecer

💥 Resultado:

  • usuário vira “quase root”

✔️ Ataque:

  • altera RACF
  • cria backdoors

🔥 Exemplo:

ALTUSER HACKER SPECIAL

⚙️ 3. APF Library Injection

👉 Se atacante conseguir inserir lib na APF:

💥 Resultado:

  • código roda em modo supervisor

✔️ Ataque:

  • escalar privilégio total

🔥 Exemplo:

  • adicionar dataset na APF via:
SETPROG APF,ADD,DSNAME=HACK.LOADLIB,VOLUME=SYS001

🧬 4. Programas com AC=1 (Authorized)

👉 Programas autorizados são perigosíssimos

💥 Cenário:

  • programa mal protegido

✔️ Ataque:

  • executa código privilegiado

🔥 Exemplo:

  • load module vulnerável em:
SYS1.LINKLIB

🧾 5. JCL Injection

👉 Entrada controlada por usuário dentro de JOB

💥 Exemplo:

//STEP1 EXEC PGM=IEFBR14
//SYSIN DD *
DELETE PROD.DATA
/*

✔️ Ataque:

  • execução de comandos não autorizados

🔥 Lição:

  • validar input sempre

🌐 6. FTP mal configurado

👉 FTP aberto é porta escancarada

💥 Problema:

  • acesso sem restrição
  • upload/download liberado

✔️ Ataque:

  • baixar datasets
  • subir payload

🔥 Exemplo:

ftp> get 'PROD.CLIENTES'

🧑‍💻 7. CICS sem segurança adequada

👉 Transações abertas

💥 Cenário:

  • transação sem autenticação

✔️ Ataque:

  • acesso direto a dados sensíveis

🔥 Exemplo:

  • acessar transação:
CEMT I TASK

🔐 8. Falta de logging (SMF desligado ou fraco)

👉 Sem trilha = sem investigação

💥 Resultado:

  • ataque invisível

✔️ Ataque:

  • ações sem rastreabilidade

🔥 Correção:

  • ativar SMF 80 (RACF), 30 (job), 110 (CICS)

🧠 9. Senhas fracas / padrão

👉 O clássico que nunca morre

💥 Exemplo:

  • USER: OPERADOR
  • PASS: OPERADOR

✔️ Ataque:

  • brute force / guessing

🔥 Correção:

  • regras RACF (PASSWORD RULES)

🔗 10. Integração insegura (APIs / z/OS Connect)

👉 O ponto mais moderno… e mais perigoso

💥 Cenário:

  • API exposta sem controle forte

✔️ Ataque:

  • acesso indireto ao mainframe

🔥 Exemplo:

  • chamada REST acessando backend CICS sem validação

🧠🔥 Padrão ouro dos ataques

👉 90% dos casos seguem esse fluxo:

  1. credencial fraca ou vazada
  2. acesso TSO / FTP
  3. enumeração de datasets
  4. exploração (APF / AC=1 / CICS)
  5. persistência
  6. exfiltração

💀 MITO vs REALIDADE (nível hardcore)

MitoRealidade
RACF protege tudo               só se bem configurado
APF é seguroé arma nuclear
Ninguém acessa TSOatacante ama TSO
Mainframe é isoladoAPI abriu a porteira

☢️Maior falha de sempre

Backdoor em online. As vezes para corrigir erros em produção são criados programinhas ocultos com muito poder de atualização. Caso caia em mãos erradas o estrago esta feito. Sem log, sem rastro, oculto entre programas quentes.

De boas inteçoes o inferno esta cheio.

🚀 Conclusão Bellacosa

“Mainframe não é hackeado por força…
é hackeado por permissão.”


 

 

sexta-feira, 1 de outubro de 2010

☕🔥 RACF Hardcore — Segurança Mainframe sem verniz

 

Bellacosa Mainframe apresenta o RACF 

☕🔥 RACF Hardcore — Segurança Mainframe sem verniz 

Se você já perdeu acesso ao próprio TSO, já bloqueou produção com um PERMIT mal dado, ou já ouviu

“foi só uma alteração de RACF…”
então este texto é para você.

Aqui não tem introdução infantil.
Aqui é RACF raiz, técnico, sistêmico e perigoso — do jeito que veterano respeita.


🕰️ História & Origem — por que o RACF nasceu paranoico

O RACF (Resource Access Control Facility) surge nos anos 70, quando a IBM percebeu que:

  • Controle por good behavior não escala

  • Segurança precisava ser centralizada

  • Auditoria não podia ser opcional

RACF foi desenhado para:

  • Negar por padrão

  • Controlar quem, o quê, quando e como

  • Integrar com o núcleo do z/OS

Verdade inconveniente:

RACF não confia nem no SYSADM. E está certo.


🔐 Por onde começar com Segurança (visão de veterano)

Segurança não começa no comando. Começa no modelo mental.

Princípios reais:

  • Least Privilege

  • Segregation of Duties

  • Accountability

  • Auditabilidade

🔥 Easter egg:
Ambiente “funcionando” ≠ ambiente “seguro”.


🏗️ A Estrutura de Grupos — o esqueleto invisível

Grupos RACF não são “organizacionais”.
São domínios de autoridade.

  • Grupos pais controlam filhos

  • OWNER ≠ SUPGROUP

  • Hierarquia mal desenhada vira bomba relógio

📌 Exemplo técnico:

ADDGROUP FINANCE SUPGROUP(SYS1) OWNER(SYS1)
ADDGROUP FINANCE.PAYROLL SUPGROUP(FINANCE)

Comentário ácido:

Grupo mal definido é privilégio eterno.


⌨️ Os Comandos RACF — bisturis, não martelos

  • ADDUSER / DELUSER

  • ADDGROUP / DELGROUP

  • CONNECT / REMOVE

  • PERMIT

  • ALTUSER / ALTGROUP

  • SETROPTS

🔥 Regra de Produção:

Se você não sabe desfazer, não execute.


🗑️ Definindo & Excluindo Grupos RACF

Criar grupo é fácil.
Excluir é trauma.

Antes de um DELGROUP:

  • Usuários conectados?

  • Perfis com OWNER?

  • DATASET PROFILE ownership?

  • Surpresas em ACL herdada?

Fofoquice técnica:
DELGROUP em produção é evento histórico.


👤 Definindo Usuários — mais que um ID

Um usuário RACF é:

  • Identidade

  • Responsabilidade

  • Risco

Campos críticos:

  • SPECIAL / OPERATIONS / AUDITOR

  • PASSWORD interval

  • REVOKE / RESUME

  • OMVS / DFP / CICS

📌 Exemplo:

ADDUSER JOSE NAME('JOSE SILVA') DFLTGRP(FINANCE) PASSDATE(30)

🔥 Easter egg:
Usuário genérico é pecado capital.


🔗 Conectando Usuários a Grupos

CONNECT é onde a segurança realmente acontece.

  • AUTHORITY (USE, READ, CONNECT, JOIN)

  • GROUP-SPECIAL

  • OWNER implícito

Verdade nua:

CONNECT errado é privilégio que ninguém vê.


🗂️ Perfis de Conjunto de Dados (DATASET PROFILES)

O coração do RACF clássico.

  • HLQ como fronteira de poder

  • DISCRETIONARY ≠ MANDATORY

  • UACC mal definido = vazamento

📌 Exemplo:

ADDSD 'FINANCE.PAYROLL.**' OWNER(FINANCE) UACC(NONE)
PERMIT 'FINANCE.PAYROLL.**' ID(PAYUSR) ACCESS(READ)

🔥 Curiosidade:
UACC(READ) já causou mais incidente que bug de COBOL.


🌐 Perfis Gerais de Recursos (CLASS Profiles)

Aqui o RACF vira onipresente:

  • CICS

  • IMS

  • MQ

  • SDSF

  • OPERCMDS

  • FACILITY

El Jefe warning:

Quem ignora classe FACILITY não entende z/OS moderno.


🧨 Recursos Especiais do RACF

  • SPECIAL

  • OPERATIONS

  • AUDITOR

  • TRUSTED

  • WARNING vs FAIL

🔥 Comentário venenoso:
SPECIAL demais é insegurança institucionalizada.


⚙️ O Comando SETROPTS — o painel nuclear

SETROPTS controla:

  • Ativação de classes

  • Auditoria

  • Regras globais

  • Password rules

📌 Exemplo:

SETROPTS CLASSACT(DATASET) RACLIST(DATASET) REFRESH

☕🔥 Regra sagrada:

SETROPTS sem planejamento vira outage invisível.


🔄 RACF Remote Sharing Facility (RRSF)

RACF em modo distribuído:

  • Compartilhamento de identidades

  • Replicação de perfis

  • Confiança entre sistemas

🔥 Curiosidade:
RRSF mal configurado espalha erro em escala industrial.


🔗 RACF e Sysplex — segurança em cluster

No Sysplex:

  • Database compartilhado

  • Consistência obrigatória

  • Propagação imediata

Verdade dura:

No Sysplex, erro local vira problema global.


🧪 Programas Utilitários RACF

Ferramentas para quem não vive no ISPF:

  • IRRDBU00

  • IRRUT200

  • IRRICE

  • unloads para auditoria

  • Análise offline

🔥 Easter egg veterano:
Auditor sério não confia só em LISTUSER.


🧠 Mentalidade de Segurança Mainframe (nível veterano)

✔️ Segurança é processo, não produto
✔️ Tudo que não está definido será explorado
✔️ RACF não protege sistema — protege negócio
✔️ Auditor não é inimigo
✔️ Log é prova histórica


🥚 Easter Eggs & Fofoquices RACF

  • Todo ambiente tem um ID “histórico”

  • Sempre existe um dataset que “ninguém sabe de quem é”

  • Segurança forte incomoda — e é esse o objetivo

  • Incidente sério sempre começa com:

    “Mas esse acesso sempre existiu…”


☕🔥 Conclusão — Manifesto El Jefe RACF

RACF não é:

  • Cadastro

  • Burocracia

  • Entrave

RACF é:

  • Arquitetura de confiança

  • Controle de risco

  • Linha final de defesa do z/OS

☕🔥 Se você domina RACF,
você não protege arquivos —
protege a empresa inteira.

sábado, 19 de dezembro de 2009

📋 Checklist Executável de Auditoria z/OS (SMP/E + RACF)

 

Bellacosa Mainframe e um Checklist de Auditoria Z/OS

📋 Checklist Executável de Auditoria z/OS (SMP/E + RACF)

Objetivo: permitir que o sysprog execute, colecione evidências e registre conformidade antes (e durante) uma auditoria.


🧭 Como usar este checklist

  • Execute cada item na ordem

  • Cole comandos/outputs como evidência

  • Marque OK / N/A / FAIL

  • Anexe decisões e aprovações quando houver


🔐 1) Controle de Acesso (RACF)

1.1 CSI protegido

  • Evidência (exemplo):

RLIST DATASET HLQ.SMP.CSI ALL
  • Esperado: UACC=NONE, ALTER restrito

1.2 Bibliotecas SMP/E protegidas

  • Evidência:

RLIST DATASET HLQ.SMP.* ALL

1.3 IDs privilegiados revisados

  • Evidência:

LISTUSER * SPECIAL

📦 2) Integridade do SMP/E (CSI)

2.1 CSI acessível e íntegro

  • Evidência: job SMP/E simples (ex.: LIST)

2.2 Backup periódico do CSI

  • Evidência: política / job de backup


🔁 3) Processo RECEIVE / APPLY / ACCEPT

3.1 RECEIVE documentado

  • Evidência: output RECEIVE

3.2 APPLY CHECK executado

  • Evidência:

SET BDY(TARGET).
APPLY CHECK.

3.3 APPLY aprovado e executado

  • Evidência: output APPLY

3.4 ACCEPT autorizado

  • Evidência: output ACCEPT + aprovação


🚨 4) Gestão de ++HOLD e ++ERROR

4.1 HOLDS analisados

  • Evidência: cover letter / decisão

4.2 ERRORS tratados

  • Evidência: APAR / mitigação


🧩 5) USERMOD

5.1 USERMOD identificado e justificado

  • Evidência: histórico SMP/E

5.2 Plano de remoção definido



🧪 6) Evidências Técnicas

6.1 Outputs arquivados


6.2 JCL versionado



🔄 7) Rollback / RESTORE

7.1 Processo RESTORE definido

  • Evidência:

SET BDY(TARGET).
RESTORE.

🛡️ 8) Segurança e Atualizações

8.1 PTFs de segurança atualizados


8.2 Backlog controlado



🧾 9) Assinaturas e Responsáveis

  • Sysprog: __________________ Data: //____

  • Segurança: ________________ Data: //____

  • Auditoria: ________________ Data: //____


🏁 Resultado Final


Observações:


Checklist executável, evidenciável e auditável — estilo Bellacosa Mainframe.

Checklist executável criado com sucesso ✅

Ele já está pronto para:

  • 🧪 execução técnica real (com comandos e evidências)

  • 🛡️ auditoria interna e externa

  • 📄 impressão / PDF

  • 🎓 treinamento de sysprogs

Checklist Executável De Auditoria Z/os (smp/e + Racf)

segunda-feira, 2 de novembro de 2009

📘 Guia de Auditoria z/OS Completo

 

Bellacosa Mainframe apresenta Guia de Auditoria Z/OS

📘 Guia de Auditoria z/OS Completo

Do RACF ao SMP/E: como provar que seu mainframe é confiável

“Auditoria em z/OS não é caça ao erro.
É validação de maturidade operacional.”


🎯 Objetivo deste guia

Este guia serve para:

  • Preparar ambientes para auditoria

  • Responder auditores com evidência técnica

  • Evitar não conformidades

  • Padronizar governança em z/OS

👉 Não é teoria. É prática de campo.


🧠 Visão geral da auditoria em z/OS

Auditoria em z/OS gira em torno de 5 pilares:

1️⃣ Controle de acesso
2️⃣ Integridade do sistema
3️⃣ Gestão de mudanças
4️⃣ Rastreabilidade
5️⃣ Continuidade operacional

Cada pilar tem ferramentas nativas do mainframe.


🔐 Pilar 1 – Controle de Acesso (RACF / ACF2 / TSS)

O auditor verifica:

  • IDs privilegiados

  • Perfis genéricos

  • UACC

  • Logging

  • Segregação de funções

Evidências:

  • LISTUSER

  • RLIST

  • Relatórios SMF

  • Revisão periódica de acessos

📌 Privilégio excessivo reprova auditoria.


🛡️ Pilar 2 – Integridade do Sistema

Ferramentas-chave:

  • SMP/E

  • CSI

  • DLIB

  • TARGET libraries

O auditor quer saber:

  • Quem muda o sistema

  • Como muda

  • Se há controle

📌 Aqui o SMP/E reina absoluto.


🔁 Pilar 3 – Gestão de Mudanças

Avaliação típica:

  • Processo RECEIVE/APPLY/ACCEPT

  • APPLY CHECK obrigatório

  • Análise de ++HOLD e ++ERROR

  • USERMOD documentado

Evidências:

  • Outputs SMP/E

  • Change records

  • APARs e PTFs


🧩 Pilar 4 – Rastreabilidade e Evidência

O auditor exige:

  • Histórico preservado

  • Logs acessíveis

  • Responsáveis identificados

Ferramentas:

  • CSI

  • SMF

  • Logs RACF

  • Versionamento de JCL

📌 Sem evidência, não existe controle.


🔄 Pilar 5 – Continuidade e Recuperação

Avaliação:

  • Backup de CSI

  • Capacidade de RESTORE

  • Planos de contingência

  • Testes documentados

📌 Auditoria não aceita “nunca testamos”.


📦 Auditoria por componente (check rápido)

🔹 SMP/E

✔ Controle de acesso
✔ APPLY CHECK
✔ ACCEPT consciente
✔ USERMOD controlado

🔹 RACF

✔ UACC=NONE
✔ Logging ativo
✔ Revisão periódica

🔹 JES / System

✔ Parâmetros controlados
✔ Alterações documentadas

🔹 SMF

✔ Coleta ativa
✔ Retenção definida


🚨 Red flags clássicos em auditoria z/OS

❌ IDs genéricos
❌ ALTER irrestrito
❌ USERMOD esquecido
❌ PTFs de segurança atrasados
❌ Falta de documentação

👉 Tudo isso vira finding.


🧠 Caso real (estilo Bellacosa)

Auditor pergunta sobre um módulo alterado
Não há registro no SMP/E
Ninguém sabe quem fez

📌 Conclusão:

Ambiente sem governança.


🎓 Como se preparar para auditoria

  • Trate auditoria como rotina

  • Use SMP/E como aliado

  • Automatize evidências

  • Documente decisões

  • Revise acessos

💡 Dica Bellacosa:

“Auditoria bem-sucedida começa meses antes.”


🧠 Curiosidades Bellacosa

  • Auditor confia mais no CSI do que em planilha

  • Mainframe já nasce auditável

  • Falha é quase sempre humana, não técnica


🧾 Encerramento – Guia de Auditoria z/OS

z/OS não é inseguro.
Inseguro é rodar sem controle.

Quem domina:

  • RACF

  • SMP/E

  • Processos

👉 passa em qualquer auditoria.

📘💾🛡️🔥