Bellacosa Mainframe aprenda a proteger seu mainframe

☕ Um Café no Bellacosa Mainframe

🕶️ FRANK FARMER E O MAINFRAME QUE PRECISAVA DE UM GUARDA-COSTAS

Nmap, Shodan, Burp Suite, Nessus, Wireshark, OSINT, RACF, SAF, SMF, zSecure, CICS, Db2, IMS, MQ, USS, APIs, Zero Trust — e o dia em que um programador COBOL descobriu que proteger o mainframe não significava ficar parado na porta do datacenter.

Sob a tutela de Frank Farmer, de O Guarda-Costas.

🎬 PRÓLOGO — EU NÃO PROTEJO A MÁQUINA. EU PROTEJO O CAMINHO ATÉ ELA.

O jovem programador COBOL olhou para o enorme IBM Z instalado atrás do vidro do datacenter.

Portas controladas.

Câmeras.

Crachás.

Biometria.

Seguranças.

Firewalls.

RACF.

Criptografia.

Ele sorriu.

— Frank, ninguém entra aqui.

Frank Farmer não respondeu imediatamente.

Continuou olhando para o ambiente.

Depois perguntou:

— O mainframe conversa com alguma coisa?

— Claro.

— Com o quê?

O programador começou a contar.

— Aplicativos mobile, APIs, servidores Linux, Windows, MQ, parceiros, cloud, estações dos desenvolvedores, VPN, CICS, Db2...

Frank interrompeu:

— Então existem muitas portas.

— Mas o mainframe está protegido.

Frank olhou novamente para ele.

— Eu não perguntei se o mainframe estava protegido. Perguntei quantos caminhos chegam até ele.

Silêncio.

Naquele instante começaria uma das aulas mais importantes da carreira daquele jovem programador.

Porque segurança de mainframe não começa necessariamente no mainframe.

Às vezes começa em um e-mail.

Em um notebook.

Em uma API.

Em uma senha.

Em uma configuração esquecida.

Em um certificado.

Em uma biblioteca.

Ou simplesmente em alguém dizendo:

— Confia em mim.

Pegue o café.

Hoje Frank Farmer será nosso guarda-costas.

🏰 CAPÍTULO 1 — O MAINFRAME NÃO É UMA ILHA

Existe uma imagem confortável do mainframe:

          IBM Z
     ┌──────────────┐
     │              │
     │     z/OS     │
     │              │
     └──────────────┘

       INDESTRUTÍVEL

Seria maravilhoso.

Mas um ambiente empresarial moderno parece muito mais com isto:

                INTERNET
                    │
              FIREWALL / WAF
                    │
               API GATEWAY
                    │
        ┌───────────┴───────────┐
        │                       │
      CLOUD                  MOBILE
        │                       │
        └───────────┬───────────┘
                    │
                 TCP/IP
                    │
              ┌─────┴─────┐
              │   IBM Z   │
              └─────┬─────┘
                    │
     ┌──────────────┼──────────────┐
     │              │              │
   CICS            MQ         z/OS Connect
     │              │              │
   COBOL           IMS            APIs
     │
   Db2 / VSAM

Esse desenho muda completamente nossa visão de segurança.

Frank Farmer não protegeria apenas a porta do datacenter.

Ele estudaria:

quem entra, quem sai, quem conversa com quem, quais caminhos existem e quais relações de confiança foram criadas.

Essa é a primeira lição.

A superfície de ataque do mainframe pode existir muito além do próprio mainframe.

🔎 CAPÍTULO 2 — NMAP: FRANK COMEÇA CONTANDO AS PORTAS

Imagine Frank chegando a uma mansão que precisa proteger.

Antes de qualquer coisa ele pergunta:

Quantas portas?

Quantas janelas?

Existe garagem?

Entrada de serviço?

Túnel?

Portão lateral?

No mundo TCP/IP fazemos algo conceitualmente semelhante.

Ferramentas como Nmap ajudam profissionais autorizados a identificar hosts, portas e serviços.

Podemos pensar:

HOST
 │
 ├── 22   SSH
 ├── 443  HTTPS
 ├── xxxx serviço
 └── yyyy serviço

Mas aqui aparece um erro comum do iniciante.

Encontrar:

PORT 22 OPEN

não significa:

SISTEMA VULNERÁVEL

Significa:

Existe alguma coisa ouvindo aqui.

Agora começa a investigação.

Qual serviço?

Qual versão?

Quem pode conectar?

Existe TLS?

Como ocorre autenticação?

Que recurso existe atrás daquele serviço?

É produção?

Desenvolvimento?

Homologação?

Frank diria:

Uma porta não é uma invasão. É uma pergunta.

🌍 CAPÍTULO 3 — SHODAN, CENSYS E O MAINFRAME QUE DEIXOU PEGADAS

Aqui encontramos uma área fascinante: OSINT — Open Source Intelligence.

Informações públicas podem revelar muito sobre uma organização sem qualquer necessidade de acessar seus sistemas.

Imagine encontrar anúncios de emprego dizendo:

Procuramos:

COBOL
CICS
Db2
IBM MQ
RACF
z/OS Connect

Outra página diz:

Projeto de modernização CICS.

Outra:

Experiência em IBM MQ obrigatória.

Outra:

Migração de aplicações COBOL.

Separadamente são informações inocentes.

Juntas:

COBOL
  +
CICS
  +
Db2
  +
MQ
  +
z/OS Connect
  =
MAPA TECNOLÓGICO

É como encontrar pedaços de um COPYBOOK espalhados pela Internet.

Ferramentas e fontes de OSINT ajudam a correlacionar domínios, subdomínios, certificados, endereços, tecnologias e informações publicamente disponíveis.

Frank Farmer chamaria isso de:

conhecer o terreno antes que alguém mal-intencionado o conheça melhor do que você.

🕸️ CAPÍTULO 4 — O ATAQUE PODE COMEÇAR LONGE DO COBOL

Agora imagine:

Smartphone
    │
    ▼
Aplicação
    │
    ▼
API
    │
    ▼
Gateway
    │
    ▼
z/OS Connect
    │
    ▼
CICS
    │
    ▼
COBOL
    │
    ▼
Db2

Pergunta:

Onde está o mainframe?

No final.

Onde está a superfície de ataque?

Em vários pontos.

Essa distinção é importantíssima.

O programa COBOL pode estar perfeito e ainda assim existir um problema na camada web, API, autenticação, autorização ou integração.

É aí que ferramentas como Burp Suite, OWASP ZAP e soluções de teste de aplicações entram no cenário.

Não porque sejam "ferramentas COBOL".

Mas porque podem examinar componentes que levam até aplicações executadas no mainframe.

🧪 CAPÍTULO 5 — BURP SUITE NÃO SABE COBOL. E NÃO PRECISA.

Considere:

REQUEST HTTP
     │
     ▼
API
     │
     ▼
z/OS Connect
     │
     ▼
CICS
     │
     ▼
PROG01

Uma ferramenta de segurança web pode estudar o primeiro trecho desse caminho.

Mas ela não responde automaticamente:

Quem pode executar PROG01?

Quem pode alterar sua biblioteca?

Qual transação chama esse programa?

Que perfil RACF protege o recurso?

Que privilégios existem no Db2?

Que fila MQ ele acessa?

E aqui temos uma diferença essencial entre:

testar uma aplicação conectada ao mainframe

auditar profundamente a segurança do mainframe.

São disciplinas relacionadas.

Mas não idênticas.

🛡️ CAPÍTULO 6 — NESSUS NÃO É RACF

Scanners de vulnerabilidade podem encontrar problemas importantíssimos:

TLS obsoleto.

Certificados.

Serviços desnecessários.

Software vulnerável.

Configurações inseguras.

Versões problemáticas.

Tudo isso interessa ao Blue Team.

Mas imagine perguntar ao scanner:

Quais usuários possuem privilégios excessivos no RACF?

Silêncio.

Ou:

Existe uma biblioteca crítica inadequadamente protegida?

Silêncio novamente.

Porque agora saímos do universo de:

NETWORK VULNERABILITY

e entramos em:

MAINFRAME AUTHORIZATION

Precisamos conhecer o território nativo.

🔐 CAPÍTULO 7 — FRANK FARMER CONHECE O RACF

Para o iniciante, RACF muitas vezes parece apenas:

"Aquilo onde fica minha senha."

Não.

Isso seria como dizer que CICS serve para mostrar telas verdes.

RACF participa de um universo muito maior de controle de acesso.

Imagine:

                USER01
                   │
                   ▼
                 RACF
                   │
       ┌───────────┼───────────┐
       │           │           │
    DATASET      CICS         USS
       │           │           │
       ▼           ▼           ▼
     READ       EXECUTE       FILE
    UPDATE

Agora começamos a enxergar segurança.

Não basta perguntar:

Quem é você?

Precisamos perguntar:

O que você pode fazer?

Autenticação responde principalmente:

QUEM É VOCÊ?

Autorização responde:

O QUE VOCÊ PODE FAZER?

Frank imediatamente entenderia a diferença.

Reconhecer alguém não significa entregar-lhe todas as chaves da casa.

🚪 CAPÍTULO 8 — SAF: O SEGURANÇA QUE PERGUNTA AO PORTEIRO

Outro nome que o iniciante precisa guardar:

SAF — System Authorization Facility.

De maneira simplificada, podemos imaginar:

Aplicação/Subsistema
        │
        ▼
       SAF
        │
        ▼
 RACF / Security Manager
        │
        ▼
      PROFILE
        │
        ▼
   DECISÃO DE ACESSO

A ideia é poderosa.

Um componente precisa decidir se determinado usuário pode acessar um recurso.

Em vez de cada aplicação inventar seu próprio sistema de segurança, existe uma arquitetura integrada para solicitar essa decisão.

É quase como Frank dizendo:

— Não decida sozinho quem entra. Pergunte à segurança.

🗝️ CAPÍTULO 9 — QUEBRAR SENHA TALVEZ NEM SEJA O PROBLEMA

A imagem original mostrava ferramentas como Hashcat, John the Ripper e Hydra.

Elas pertencem ao universo de testes de credenciais e senhas em contextos autorizados.

Mas no mainframe aparece uma pergunta ainda mais interessante:

E se a credencial legítima já possuir autoridade demais?

Considere:

USER01
 │
 ├── DATASET.A  READ
 ├── DATASET.B  UPDATE
 ├── CICS       acesso
 ├── USS        acesso
 └── MQ         autoridade

Talvez ninguém precise "quebrar" nada.

O problema pode ser privilégio excessivo.

Esse é um princípio central:

Least Privilege

Cada identidade deve possuir somente as permissões necessárias para desempenhar sua função.

Nem mais.

Nem menos.

🐧 CAPÍTULO 10 — FRANK ENCONTRA UNIX DENTRO DO MAINFRAME

Então nosso programador faz uma descoberta:

$ ls
$ cd
$ grep
$ ssh

— Frank! Colocaram Linux no z/OS!

Não.

😂

Bem-vindo ao UNIX System Services — USS.

O z/OS possui um ambiente UNIX/POSIX integrado.

Isso significa que profissionais de segurança também precisam compreender conceitos como:

directories
files
permissions
processes
shell
SSH
scripts
TCP/IP

Mas existe uma diferença crítica:

USS continua vivendo dentro do ecossistema de segurança do z/OS.

Isso cria uma ponte fascinante entre:

MUNDO UNIX
     ↕
    USS
     ↕
z/OS / SAF / RACF

Para alguém estudando segurança ofensiva e defensiva, USS merece um capítulo inteiro.

📡 CAPÍTULO 11 — WI-FI NÃO PRECISA CHEGAR AO MAINFRAME

A imagem original também apresentava ferramentas de segurança wireless.

O iniciante pode perguntar:

— Meu IBM Z não está no Wi-Fi. Então isso não interessa.

Frank aponta para o notebook do operador.

E desenha:

Wi-Fi
  │
  ▼
Notebook
  │
  ▼
Credenciais
  │
  ▼
VPN
  │
  ▼
Rede corporativa
  │
  ▼
Terminal / SSH / Aplicação
  │
  ▼
IBM Z

Agora ficou interessante.

Uma organização precisa proteger cadeias, não apenas máquinas.

O atacante não necessariamente começa atacando o ativo mais forte.

Pode procurar o elo mais fraco conectado a ele.

🎭 CAPÍTULO 12 — O FIREWALL NÃO PROTEGE CONTRA "CONFIA EM MIM"

Frank Farmer sabe que pessoas também fazem parte da arquitetura.

Imagine:

Firewall        OK
RACF            OK
TLS             OK
MFA             OK
CICS            OK
SIEM            OK

Telefone toca.

— Boa tarde. Estamos resolvendo o incidente INC00317. Preciso confirmar algumas informações...

Espere.

00317?

☕ Easter egg localizado.

03:17.

O horário em que todo incidente importante do Bellacosa Mainframe parece decidir acordar. 😁

O problema agora não é buffer overflow.

É confiança.

Engenharia social procura explorar comportamentos humanos:

autoridade aparente, urgência, medo, curiosidade, confiança e vontade de ajudar.

Por isso segurança também envolve:

PROCESSOS
+
TREINAMENTO
+
SEGREGAÇÃO DE FUNÇÕES
+
APROVAÇÃO
+
VERIFICAÇÃO

Frank Farmer provavelmente resumiria:

Se alguém consegue convencer seu funcionário a abrir a porta, a resistência da fechadura deixou de ser o problema principal.

📜 CAPÍTULO 13 — SMF: A CÂMERA DE SEGURANÇA DO REINO

Agora chegamos a um dos tesouros do z/OS:

SMF — System Management Facilities

Quem trabalha com observabilidade já conhece a importância do SMF.

Na segurança ele também é extremamente relevante.

Pense nele como uma enorme fonte de evidências produzidas pelo sistema e seus componentes.

Dependendo dos registros habilitados e das aplicações envolvidas, podemos reconstruir partes importantes de:

QUEM
 │
 ▼
FEZ O QUÊ
 │
 ▼
QUANDO
 │
 ▼
ONDE
 │
 ▼
COM QUAL RESULTADO

E isso muda completamente uma investigação.

🕵️ CAPÍTULO 14 — FORENSE MAINFRAME NÃO É APENAS PROCURAR ARQUIVOS APAGADOS

No mundo distribuído, ferramentas forenses podem trabalhar com:

memória, discos, imagens, arquivos, tráfego e artefatos.

No z/OS precisamos ampliar nossa visão.

Podemos precisar correlacionar:

SMF
RACF
SYSLOG
OPERLOG
JES spool
CICS
Db2
MQ
TCP/IP
USS
SIEM

Imagine:

02:58 USER01 autentica
03:02 JOBABC inicia
03:04 recurso XYZ é acessado
03:08 programa executa
03:10 conexão externa ocorre
03:17 alerta dispara

Uma informação isolada talvez não conte nada.

Correlacionadas, elas contam uma história.

Isso é investigação.

🔍 CAPÍTULO 15 — zSECURE: FRANK GANHA UMA CENTRAL DE SEGURANÇA

Se RACF é parte fundamental do controle de acesso, precisamos também de instrumentos especializados para analisar esse universo.

Aqui aparece a família IBM zSecure.

Ela possui recursos voltados a administração, auditoria, compliance, análise e alertas de segurança no IBM Z.

O ponto importante para nosso jovem COBOLero é compreender que ferramentas tradicionais de scanner e ferramentas especializadas em z/OS enxergam problemas diferentes.

Compare:

SCANNER DE REDE

porta
TLS
serviço
versão
configuração

com:

ANÁLISE z/OS

identidades
grupos
profiles
autorizações
configurações
exposições
compliance
eventos

Um não substitui o outro.

Eles se complementam.

🧙 CAPÍTULO 16 — CARLa: QUANDO FRANK APRENDE A FAZER PERGUNTAS

Outro nome curioso:

CARLa.

Ela é utilizada no ecossistema zSecure para consulta e análise de informações de segurança.

Para o programador iniciante, podemos fazer uma analogia imperfeita, mas útil:

SQL
 ↓
consulta dados

CARLa
 ↓
consulta/analisa informações
de segurança do ambiente

Não são a mesma coisa.

A analogia serve apenas para criar o primeiro mapa mental.

Em segurança, saber formular perguntas é tão importante quanto possuir ferramentas.

Por exemplo:

Quem possui determinado privilégio?

Quais recursos possuem proteção inadequada?

Quais identidades possuem determinada autoridade?

Onde existem exceções?

O que mudou?

Essa mentalidade transforma segurança em investigação.

🧠 CAPÍTULO 17 — O PENTESTER ENCONTROU COBOL

Agora Frank acompanha um especialista que encontra:

EXEC CICS
   READ FILE('CUSTOMER')
   INTO(WS-CUSTOMER)
   RIDFLD(WS-CUSTOMER-ID)
END-EXEC.

Ele diz:

— Encontrei COBOL.

O programador mainframe responde:

— Você encontrou o começo das perguntas.

Qual transação executa esse programa?

Qual usuário?

Qual região CICS?

Qual FILE?

Quem pode acessar?

Que dataset existe por trás?

Quem pode modificar a load library?

Existe Db2 envolvido?

MQ?

Qual informação é registrada?

Percebeu?

O código não vive sozinho.

Temos:

IDENTIDADE
    │
    ▼
TRANSAÇÃO
    │
    ▼
PROGRAMA
    │
    ▼
RECURSO
    │
    ▼
DADO

E cada ligação possui implicações de segurança.

🕸️ CAPÍTULO 18 — FRANK DESENHA UM GRAFO

Aqui está talvez a ideia mais importante deste café.

Pare de pensar apenas em ferramentas.

Pense em caminhos.

Exemplo:

FUNCIONÁRIO
     │
     ▼
NOTEBOOK
     │
     ▼
VPN
     │
     ▼
USERID
     │
     ▼
RACF GROUP
     │
     ▼
DATASET
     │
     ▼
LOAD LIBRARY
     │
     ▼
PROGRAMA
     │
     ▼
CICS
     │
     ▼
Db2

Outro:

INTERNET
   │
   ▼
MOBILE
   │
   ▼
API
   │
   ▼
z/OS Connect
   │
   ▼
CICS
   │
   ▼
COBOL
   │
   ▼
MQ

Outro:

FORNECEDOR
    │
    ▼
VPN
    │
    ▼
SSH
    │
    ▼
USS
    │
    ▼
SCRIPT
    │
    ▼
JCL
    │
    ▼
BATCH

Isso é Attack Path Analysis em espírito: compreender os caminhos possíveis entre identidades, sistemas, permissões e ativos.

🔵 CAPÍTULO 19 — BLUE TEAM

O Blue Team pergunta:

Como protegemos?

No mainframe podemos pensar em camadas:

                 BLUE TEAM
                     │
        ┌────────────┼────────────┐
        ▼            ▼            ▼
      RACF          SMF         NETWORK
        │            │            │
    ACCESS        EVENTS        TCP/IP
        │            │            │
        └────────────┼────────────┘
                     ▼
                 DETECTION
                     │
                     ▼
                   SIEM

Ele trabalha para:

reduzir exposição, detectar comportamento anormal, fortalecer configurações, controlar privilégios, registrar eventos e responder a incidentes.

🔴 CAPÍTULO 20 — RED TEAM

O Red Team autorizado faz outra pergunta:

Se eu fosse um adversário, quais caminhos tentaria explorar?

Mas isso não significa sair disparando ferramentas contra produção.

Um Red Team profissional trabalha com:

ESCOPO
AUTORIZAÇÃO
REGRAS
LIMITES
EVIDÊNCIAS
SEGURANÇA OPERACIONAL
RELATÓRIO
REMEDIAÇÃO

No mainframe isso é ainda mais importante.

Você não quer descobrir que seu teste de resiliência funcionou derrubando o processamento da folha de pagamento.

😬

🟣 CAPÍTULO 21 — PURPLE TEAM

Agora Frank coloca Red e Blue na mesma sala.

RED TEAM
   │
   │ "encontrei um caminho"
   ▼
PURPLE TEAM
   ▲
   │ "vamos aprender com ele"
   │
BLUE TEAM

O objetivo não é descobrir quem é mais esperto.

É melhorar a defesa.

Red demonstra uma exposição autorizadamente.

Blue verifica se detectaria.

Ambos analisam.

A organização corrige.

Testa novamente.

Isso produz maturidade.

🏗️ CAPÍTULO 22 — PASSO A PASSO PARA O PROGRAMADOR COBOL

Se você está começando agora, não tente aprender cinquenta ferramentas simultaneamente.

Construa o conhecimento em camadas.

Passo 1 — Entenda z/OS.

Aprenda:

TSO
ISPF
JCL
datasets
JES
SDSF

Passo 2 — Entenda aplicações.

COBOL
CICS
Db2
IMS
VSAM
MQ

Passo 3 — Aprenda identidade e autorização.

SAF
RACF
USER
GROUP
PROFILE
RESOURCE
ACCESS

Passo 4 — Entre no USS.

shell
files
directories
permissions
SSH
TCP/IP

Passo 5 — Aprenda observabilidade.

SMF
RMF
logs
SYSLOG
OPERLOG
CICS logs
Db2
MQ

Passo 6 — Estude segurança externa.

OSINT
DNS
TLS
HTTP
APIs
networking
firewalls

Passo 7 — Conheça ferramentas especializadas.

zSecure
SIEM
security analytics
compliance

Somente depois comece a ligar tudo.

🧩 CAPÍTULO 23 — O EXERCÍCIO DE FRANK FARMER

Escolha uma aplicação COBOL fictícia.

Por exemplo:

PAYMENT

Agora pergunte:

Quem chama PAYMENT?

CICS transaction PAY1

Quem chama PAY1?

Talvez:

API

Quem chama a API?

Mobile Banking

Continue:

CLIENTE
   │
   ▼
MOBILE
   │
   ▼
API GATEWAY
   │
   ▼
z/OS CONNECT
   │
   ▼
CICS PAY1
   │
   ▼
COBOL PAYMENT
   │
   ├────► Db2
   │
   └────► MQ

Agora coloque segurança em cada seta.

Pergunte:

Quem autentica?

Quem autoriza?

Existe TLS?

Qual identidade chega ao CICS?

Que autorização existe?

Como o acesso ao Db2 é controlado?

Quem pode alterar PAYMENT?

Onde ficam os logs?

Que SMF é produzido?

Qual alerta seria gerado?

Pronto.

Você deixou de estudar COBOL isoladamente.

Começou a estudar segurança de sistemas empresariais.

💡 CAPÍTULO 24 — CINCO CURIOSIDADES QUE MUDAM A CABEÇA

A primeira: o atacante pode nunca ver ISPF.

Ele pode interagir somente com uma API que termina num programa COBOL.

A segunda: o código mais seguro do mundo não corrige uma autorização excessiva.

A terceira: criptografia não resolve autorização.

TLS pode proteger o caminho enquanto uma identidade perfeitamente autenticada possui permissões inadequadas.

A quarta: logs sem análise não significam detecção.

Registrar milhões de eventos não ajuda se ninguém correlacionar o que importa.

A quinta é talvez a melhor:

segurança não é produto.

Comprar uma ferramenta não instala maturidade.

🕶️ EPÍLOGO — O GUARDA-COSTAS NÃO FICAVA NA PORTA

Algumas semanas depois, o jovem programador encontrou Frank diante do mesmo vidro do datacenter.

O IBM Z continuava ali.

Imponente.

Silencioso.

Processando milhares de transações.

O programador disse:

— Agora entendi.

Frank esperou.

— Segurança do mainframe não é proteger apenas o mainframe.

Frank continuou em silêncio.

— Precisamos proteger identidades, caminhos, interfaces, aplicações, dados e relações de confiança.

Frank finalmente sorriu.

O programador apontou para o IBM Z.

— Então ele precisa de um guarda-costas.

Frank corrigiu:

— Não.

Apontou para todo o datacenter.

Depois para os notebooks.

Depois para a rede.

Depois para o smartphone sobre a mesa.

E finalmente para o programador.

— Todos eles precisam.

O relógio do console marcou:

03:17:00

Nenhum ABEND.

Nenhum alerta.

Nenhuma porta misteriosamente aberta.

Dessa vez 03:17 era apenas um horário.

Frank pegou o café.

SECURITY STATUS
---------------

RACF ............ ACTIVE
SAF ............. ACTIVE
SMF ............. RECORDING
CICS ............ RUNNING
MQ .............. RUNNING
COBOL ........... STILL RUNNING

FRANK FARMER .... WATCHING

☕🕶️

E o jovem programador finalmente compreendeu a grande lição daquele café:

Em cibersegurança, a pergunta mais perigosa não é "alguém consegue invadir meu mainframe?". É "quantos caminhos de confiança levam até aquilo que realmente preciso proteger?"

Porque Nmap pode encontrar portas.

Shodan pode encontrar pegadas.

Burp pode examinar aplicações.

Scanners podem descobrir vulnerabilidades.

Wireshark pode observar pacotes.

RACF pode controlar acessos.

SMF pode preservar evidências.

zSecure pode ajudar a analisar a postura de segurança.

Mas nenhuma ferramenta substitui alguém capaz de olhar para todas essas peças e perceber que elas pertencem ao mesmo sistema.

E talvez seja justamente aí que o velho programador COBOL tenha uma vantagem inesperada.

Ele passou décadas aprendendo que um programa nunca vive sozinho.

Existe JCL.

Existe dataset.

Existe CICS.

Existe Db2.

Existe IMS.

Existe MQ.

Existe RACF.

Existe rede.

Existe gente.

E agora existe uma nova missão:

descobrir quem está protegendo quem.

☕ Um Café no Bellacosa Mainframe

Onde até Frank Farmer descobriu que proteger Whitney Houston talvez fosse mais simples do que mapear todas as relações de confiança de uma LPAR.

Translate

quinta-feira, 6 de setembro de 2018