Bellacosa Mainframe e os riscos ocultos no mainframe

☕ Um Café no Bellacosa Mainframe

🌀 DOUTOR ESTRANHO E AS 15 PORTAS INVISÍVEIS DO MAINFRAME

RACF, SMF, TCP/IP, CICS, Db2, IMS, MFA, TLS, phishing, DDoS, malware, SQL Injection, Zero Trust, Red Team — e o dia em que Stephen Strange descobriu que o invasor mais perigoso não precisava quebrar a porta porque alguém já havia lhe emprestado a chave.

Sob a tutela do Doutor Estranho, Mestre das Artes Místicas — e, por algumas horas, improvável instrutor de segurança do z/OS.

🎬 PRÓLOGO — O PORTAL QUE APARECEU NO MEIO DO ISPF

Nosso jovem programador COBOL estava diante de uma tela ISPF.

Nada particularmente emocionante.

OPTION ===> 3.4

Datasets.

Copybooks.

JCL.

COBOL.

Aquele universo confortável onde um programa começa educadamente com:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. PAYROLL.

Até que surgiu um círculo dourado no meio da sala.

Faíscas.

O programador recuou.

Do portal saiu o Doutor Estranho.

— Você é o programador COBOL?

— Sim.

— Então temos um problema.

— ABEND?

— Pior.

Strange abriu outro portal.

Do outro lado havia uma arquitetura inteira:

Internet
   │
Firewall
   │
API Gateway
   │
TCP/IP
   │
IBM Z
   │
 ┌─┼──────────────┐
 │ │              │
CICS             IMS
 │                │
COBOL            COBOL
 │                │
Db2              Db2
 │
RACF

O jovem ficou aliviado.

— Ah! Mainframe. Estamos seguros.

Strange fechou o portal.

— É exatamente por isso que estou aqui.

☕

🏰 CAPÍTULO 1 — MAINFRAME NÃO É UMA DIMENSÃO FORA DA INTERNET

Existe uma imagem clássica do mainframe:

uma máquina enorme, fechada, isolada, protegida por paredes invisíveis e administrada por pessoas misteriosas que falam coisas como:

APF
LPAR
RACF
SMF
VTAM
IPL
PARMLIB

Durante décadas, parte dessa percepção fez algum sentido porque muitos ambientes mainframe eram extremamente controlados.

Mas o IBM Z moderno participa de arquiteturas distribuídas.

Ele conversa com:

aplicações web;
dispositivos móveis;
parceiros;
cloud;
APIs;
MQ;
Kafka;
Linux;
OpenShift;
bancos distribuídos;
sistemas corporativos;
ferramentas DevOps.

Portanto, nossa primeira regra é:

Mainframe não é sinônimo de isolamento.

O IBM Z pode possuir dezenas ou centenas de caminhos de comunicação com o restante da organização.

O Doutor Estranho desenharia isso como vários portais:

             ☁ CLOUD
                │
                ▼
 MOBILE ──► API ─────────┐
                         │
 PARTNER ─► MQ ──────────┤
                         ▼
                    ┌─────────┐
 INTERNET ─────────►│  IBM Z  │
                    └─────────┘
                         ▲
 DEVOPS ─► PIPELINE ─────┤
                         │
 USERS ──► TN3270 ───────┘

Cada portal é útil.

E cada portal também precisa ser protegido.

🌐 CAPÍTULO 2 — SIM, EXISTE TCP/IP NO MAINFRAME

O iniciante COBOL frequentemente conhece:

COBOL
JCL
CICS
Db2
VSAM

mas esquece que existe uma enorme infraestrutura embaixo disso.

z/OS possui Communications Server, incluindo uma implementação completa da pilha TCP/IP.

Consequentemente, conceitos tradicionais de segurança de redes continuam importantes:

IP
TCP
UDP
DNS
TLS
certificados
sockets
portas
firewall
IPSec

Isso significa que um atacante interessado em reconhecer um ambiente pode procurar serviços acessíveis.

Não precisa começar pensando:

“Vou atacar COBOL.”

Ele pode pensar:

“O que existe neste endereço?”

Essa diferença é enorme.

🔭 CAPÍTULO 3 — O OLHO DE AGAMOTTO FAZ PORT SCANNING?

Imagine Strange olhando para uma máquina:

HOST
 │
 ├── porta A
 ├── porta B
 ├── porta C
 └── porta D

O atacante faz algo conceitualmente semelhante.

Ele tenta entender:

HOST
 ↓
PORTAS
 ↓
SERVIÇOS
 ↓
TECNOLOGIAS
 ↓
SUPERFÍCIE DE ATAQUE

Isso é reconhecimento.

Uma porta acessível pode indicar a presença de um determinado serviço.

E aqui aparece uma mudança importante na mentalidade do programador:

Segurança começa muito antes do COBOL.

Seu programa pode estar impecável.

Mas existe toda uma cadeia até alguém chegar nele.

CLIENTE
   ↓
REDE
   ↓
FIREWALL
   ↓
TLS
   ↓
API
   ↓
CICS
   ↓
COBOL
   ↓
Db2

Qualquer elo merece atenção.

💥 CAPÍTULO 4 — DDoS E O FEITIÇO DOS DEZ MIL PEDIDOS

Suponha que Wong diga:

— Mestre, nosso CICS consegue processar uma quantidade absurda de transações.

Strange responde:

— Excelente.

Wong continua:

— Então somos imunes a DDoS.

Silêncio constrangedor.

DDoS significa Distributed Denial of Service.

O objetivo não precisa ser “quebrar o mainframe”.

Pode ser simplesmente tornar determinado serviço indisponível.

Imagine:

           Bot
            │
Bot ────────┼──────── Bot
            │
Bot ────────┼──────── Bot
            │
            ▼
       API Gateway
            │
            X
            │
           CICS

Curiosamente, CICS pode estar saudável.

CPU pode estar normal.

Db2 pode estar normal.

COBOL pode estar esperando trabalho.

Mas o gateway ficou saturado.

Para o cliente:

“O mainframe caiu.”

Para o sysprog:

“O mainframe nem percebeu.”

Essa diferença é importantíssima em incidentes.

Disponibilidade precisa ser analisada fim a fim.

🕵️ CAPÍTULO 5 — MAN-IN-THE-MIDDLE: DORMAMMU NO MEIO DA CONVERSA

Temos:

CLIENTE ─────────────────► SERVIDOR

Tudo parece perfeito.

Mas imaginemos:

CLIENTE ──► ATACANTE ──► SERVIDOR

O intermediário tenta observar ou manipular a comunicação.

É o princípio do Man-in-the-Middle.

No mundo empresarial entram mecanismos como:

TLS
certificados digitais
IPSec
AT-TLS

E aqui existe uma característica muito interessante do z/OS: Application Transparent TLS — AT-TLS.

A ideia é poderosa porque permite aplicar proteção TLS através da infraestrutura TCP/IP para aplicações adequadamente configuradas, reduzindo a necessidade de cada aplicação implementar diretamente toda a lógica TLS.

É quase um feitiço de Strange:

Aplicação antiga
      │
      ▼
   AT-TLS
      │
      ▼
Comunicação protegida

O programa pode continuar fazendo aquilo que sabe fazer.

A infraestrutura acrescenta proteção ao redor dele.

Essa capacidade de modernizar ao redor do legado é uma das características fascinantes do ecossistema mainframe.

🔑 CAPÍTULO 6 — RACF NÃO É UM CAMPO DE FORÇA

Agora Strange chega diante de uma porta.

Nela está escrito:

RACF

O jovem programador sorri.

— Pronto. Ninguém passa.

Strange pergunta:

— O que é RACF?

— Segurança.

— Resposta perigosa.

RACF é muito mais precisamente parte fundamental da infraestrutura responsável por identidades, autenticação, autorização e proteção de recursos em muitos ambientes z/OS.

Simplificando:

QUEM É VOCÊ?
      │
      ▼
AUTENTICAÇÃO
      │
      ▼
O QUE VOCÊ PODE FAZER?
      │
      ▼
AUTORIZAÇÃO

Essas duas perguntas não são iguais.

Um usuário pode ser realmente:

USER123

mas USER123 não deveria necessariamente acessar:

PROD.PAYROLL.MASTER

Identidade não significa autorização universal.

🔨 CAPÍTULO 7 — FORÇA BRUTA CONTRA O PORTAL

O infográfico original apresenta brute force.

Conceitualmente:

USER01
  │
  ├── senha1
  ├── senha2
  ├── senha3
  ├── senha4
  ├── senha5
  └── ...

O atacante tenta inúmeras possibilidades.

Por isso políticas de autenticação, bloqueios, monitoramento, MFA e outros controles são importantes.

Mas surgiu uma alternativa mais sutil.

🌧️ CAPÍTULO 8 — PASSWORD SPRAYING

Em vez de tentar mil senhas contra um usuário:

ADMIN
senha001
senha002
senha003
...

a ideia do password spraying é tentar poucas senhas contra muitos usuários:

              Welcome2026

USER001 ─────────┤
USER002 ─────────┤
USER003 ─────────┤
USER004 ─────────┤
USER005 ─────────┘

Isso procura explorar senhas previsíveis evitando produzir a mesma sequência óbvia de falhas contra uma única conta.

A lição defensiva é preciosa:

Uma senha tecnicamente aceita pelo sistema não significa necessariamente uma boa credencial.

E aqui MFA ganha enorme importância.

🧙 CAPÍTULO 9 — MFA: VOCÊ TEM A CHAVE, MAS CADÊ O SEGUNDO ARTEFATO?

Imagine que Mordo roube sua senha.

Sem MFA:

USER
 +
PASSWORD
    │
    ▼
 acesso

Com autenticação multifator, existe outra prova de identidade.

Conceitualmente:

algo que você sabe
        +
algo que você possui/obtém
        │
        ▼
     identidade

Isso muda dramaticamente o valor de uma senha roubada.

Não significa invulnerabilidade.

Significa mais uma camada.

E segurança madura funciona exatamente assim.

🎣 CAPÍTULO 10 — PHISHING: O FEITIÇO QUE NÃO PRECISA INVADIR O RACF

Talvez Strange pudesse passar uma semana tentando quebrar uma fortaleza.

Ou poderia simplesmente bater à porta:

— Olá. Sou da equipe de suporte. Preciso da sua senha.

Essa é a essência da engenharia social.

Considere:

Assunto:
URGENTE - SUA CONTA SERÁ BLOQUEADA

Clique para validar sua identidade.

O usuário acessa uma página falsa e entrega:

USERID
PASSWORD

Observe o que não aconteceu:

Nenhum RACF foi “hackeado”.

Nenhum CICS foi explorado.

Nenhum COBOL foi modificado.

Nenhum Db2 sofreu SQL Injection.

A pessoa entregou a credencial.

Por isso phishing é tão poderoso.

Ele ataca algo extremamente complexo:

o ser humano.

🐳 CAPÍTULO 11 — WHALING: POR QUE ATACAR O APRENDIZ SE POSSO ATACAR O FEITICEIRO SUPREMO?

Whaling é phishing direcionado a pessoas particularmente valiosas.

No contexto mainframe, imagine alguém com capacidade de:

administrar segurança
alterar produção
gerenciar certificados
alterar pipelines
administrar banco
gerenciar CICS
administrar sistemas

Agora compare:

1.000 usuários comuns

com:

1 administrador extremamente privilegiado

Do ponto de vista de risco, essa identidade privilegiada merece proteção extraordinária.

Daí conceitos como:

least privilege, separation of duties, privileged access management, MFA e auditoria.

Nunca dê uma Infinity Stone quando a pessoa só precisa de uma chave de fenda.

🎟️ CAPÍTULO 12 — PASSTICKET: UMA CREDENCIAL QUE NÃO QUER SER UMA SENHA ETERNA

O ecossistema RACF possui outro conceito interessante: PassTicket.

De maneira simplificada, podemos imaginá-lo como uma credencial temporária associada ao usuário e aplicação.

Em vez de espalhar uma senha permanente por diversas integrações:

PASSWORD
   │
   ├── sistema A
   ├── sistema B
   ├── sistema C
   └── sistema D

podemos ter arquiteturas de autenticação mais adequadas nas quais a credencial reutilizável não precisa viajar dessa maneira.

É uma boa oportunidade para o iniciante aprender um princípio maior:

Credenciais são segredos. Quanto menos lugares precisarem conhecê-las, melhor.

🦠 CAPÍTULO 13 — EXISTE MALWARE NO MULTIVERSO MAINFRAME?

O infográfico lista:

vírus, worms, Trojan, ransomware, spyware, rootkits, keyloggers, botnets, backdoors, loaders e malware sem arquivo.

Devemos evitar dois extremos.

O primeiro:

“Tudo funciona exatamente como num PC Windows.”

Errado.

O segundo:

“Mainframe não pode ter malware.”

Também é uma simplificação perigosa.

Primeiro precisamos perguntar:

qual ambiente?

Um IBM Z pode hospedar:

IBM Z
 │
 ├── z/OS
 │    └── UNIX System Services
 │
 ├── Linux on Z
 │
 └── múltiplas LPARs

Linux on Z é Linux executando na arquitetura IBM Z.

USS fornece um ambiente UNIX dentro do z/OS.

Portanto, a superfície de segurança moderna é muito maior que:

COBOL + JCL

🚪 CAPÍTULO 14 — A BACKDOOR QUE NÃO PARECIA BACKDOOR

Agora chegamos a algo especialmente interessante para programadores.

Imagine código como:

       IF CUSTOMER-ID = '99999999'
           MOVE 'Y' TO AUTHORIZED
       END-IF.

Se isso tivesse sido deliberadamente colocado para contornar controles, teríamos uma porta lógica escondida.

Não precisamos de um vírus cinematográfico.

Uma backdoor pode ser:

código escondido
conta esquecida
permissão excessiva
biblioteca inadequadamente protegida
configuração insegura
script
procedimento operacional
integração confiável demais

Esse é um dos pontos mais importantes deste artigo.

Cybersecurity não é caça a malware.

É caça a caminhos de abuso.

💉 CAPÍTULO 15 — SQL INJECTION CHEGA AO Db2?

Imagine:

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

O atacante talvez nem saiba que existe um IBM Z.

Ele só encontrou uma aplicação.

Se dados externos forem utilizados inadequadamente na construção de comandos SQL, podemos criar vulnerabilidades na camada da aplicação.

Isso nos dá outra máxima:

Hardware seguro não transforma automaticamente software inseguro em software seguro.

O programa precisa respeitar práticas de desenvolvimento seguro.

🧬 CAPÍTULO 16 — O MULTIVERSO DEVOPS E O ATAQUE À SUPPLY CHAIN

Strange abre outro portal.

Não há hacker.

Há Git.

Developer
    │
    ▼
   Git
    │
    ▼
Pipeline
    │
    ▼
 Build
    │
    ▼
Artifact
    │
    ▼
 Deploy
    │
    ▼
Production

O jovem pergunta:

— Onde está o atacante?

Strange responde:

— Essa é a pergunta errada. Pergunte onde ele poderia interferir.

Agora tudo muda.

Developer ── credencial?
Git ───────── proteção?
Pipeline ─── segredo?
Build ─────── integridade?
Artifact ─── adulteração?
Deploy ───── autorização?
Production ─ segregação?

O programa malicioso não precisa chegar como:

VIRUS.EXE

Pode chegar como:

PAYROLL.CBL

passar pelo build e transformar-se em um load module perfeitamente executável.

Esse é o perigo da supply chain.

📜 CAPÍTULO 17 — SMF: O LIVRO DE VISHANTI DO z/OS

Depois de um incidente surge a pergunta mais importante:

O que aconteceu?

Precisamos reconstruir eventos.

QUEM?
 ↓
QUANDO?
 ↓
ONDE?
 ↓
QUAL RECURSO?
 ↓
QUAL AÇÃO?
 ↓
QUAL RESULTADO?

É aqui que SMF — System Management Facilities — se torna extremamente importante.

O z/OS produz uma riqueza extraordinária de registros operacionais.

Quando combinamos diferentes fontes:

SMF
 │
RACF
 │
TCP/IP
 │
CICS
 │
Db2
 │
IMS
 │
MQ
 │
USS
 ▼
SIEM
 ▼
SOC

podemos construir uma visão muito mais completa.

O objetivo não é apenas descobrir:

“Houve ACCESS DENIED?”

Queremos descobrir:

“Esse comportamento faz sentido?”

Essa é uma pergunta muito mais poderosa.

⚠️ CAPÍTULO 18 — O EVENTO MAIS ASSUSTADOR PODE SER “ACCESS ALLOWED”

Imagine um log:

USERA
RESOURCE: PAYROLL
ACCESS: ALLOWED

Tudo certo?

Talvez.

Mas e se USERA tiver sido vítima de phishing?

Então:

credencial válida
+
autorização válida
+
operação válida

pode produzir:

atividade maliciosa

E essa é uma das grandes lições da segurança moderna.

Um sistema tradicional procura:

ACCESS DENIED

Uma investigação moderna também pergunta:

Por que este ACCESS ALLOWED aconteceu?

🔎 CAPÍTULO 19 — RED TEAM: STRANGE PROCURA CAMINHOS, NÃO PAREDES

Agora Strange coloca nosso Padawan diante da arquitetura.

— Encontre a vulnerabilidade.

O garoto começa:

— Vou quebrar o RACF.

— Não.

— Explorar o z/OS?

— Não necessariamente.

— Então o quê?

Strange desenha:

                  DADO CRÍTICO
                       ▲
                       │
              ┌────────┼────────┐
              │        │        │
             Db2      VSAM     IMS
              ▲        ▲        ▲
              └────────┼────────┘
                       │
                     CICS
                       ▲
                       │
                      API
                       ▲
                       │
                 aplicação web

E pergunta:

“Qual é o caminho mais fraco até o objetivo?”

Essa é uma forma muito melhor de pensar em Red Team defensivo e threat modeling.

O objetivo não é demonstrar que “mainframe é inseguro”.

É descobrir onde nossas suposições sobre segurança estão erradas.

🧱 CAPÍTULO 20 — DEFENSE IN DEPTH: AS MÚLTIPLAS DIMENSÕES DA DEFESA

A arquitetura madura não aposta tudo em RACF.

Ela cria camadas:

                 USUÁRIO
                    │
                   MFA
                    │
                 REDE
                    │
                TLS/IPSec
                    │
              FIREWALL/IDS
                    │
                  IBM Z
                    │
                  RACF
                    │
        ┌───────────┼───────────┐
       CICS        IMS         Db2
        │           │           │
        └───────────┼───────────┘
                    │
                APLICAÇÃO
                    │
                  DADOS
                    │
               LOGS / SMF
                    │
                   SIEM
                    │
                   SOC

Isso é Defense in Depth.

Se uma camada falhar, outra continua existindo.

Senha roubada?

MFA.

Comunicação interceptada?

TLS.

Conta comprometida?

Privilégio mínimo reduz o alcance.

Comportamento estranho?

Monitoramento.

Incidente ocorreu?

Auditoria permite investigação.

A pergunta deixa de ser:

“Temos segurança?”

e passa a ser:

“Quantas coisas precisam dar errado para alguém chegar ao ativo crítico?”

Essa é uma pergunta muito melhor.

🧪 CAPÍTULO 21 — LABORATÓRIO MENTAL PARA O PROGRAMADOR COBOL

Quando receber um programa para manutenção, faça este exercício.

Comece desenhando:

ENTRADA
   │
   ▼
PROGRAMA
   │
   ▼
DADOS

Depois expanda:

Quem chama?
    │
Como autentica?
    │
Por onde entra?
    │
Quem autoriza?
    │
Que programa executa?
    │
Que dados acessa?
    │
Que sistema externo chama?
    │
O que fica registrado?

Agora você não está mais apenas lendo COBOL.

Está fazendo threat modeling.

Por exemplo:

Mobile
  │
 API
  │
 CICS
  │
 COBOL
  │
 Db2
  │
 MQ
  │
 parceiro

Pergunte em cada seta:

Quem confia em quem?
Como prova identidade?
Existe criptografia?
Existe autorização?
Existe validação?
Existe auditoria?

A seta é tão importante quanto a caixa.

💡 CAPÍTULO 22 — 10 DICAS PARA O PADAWAN DA SEGURANÇA MAINFRAME

Não confunda RACF com toda a segurança do mainframe. Ele é uma peça fundamental, mas existe uma arquitetura inteira ao redor.
Aprenda TCP/IP. Um programador COBOL moderno ganha muito entendendo portas, TLS, certificados, DNS e sockets.
Entenda identidade e autorização separadamente. Saber quem alguém é não responde ao que essa pessoa deveria fazer.
Conheça SMF. Segurança sem evidência vira opinião.
Aprenda CICS e Db2 pensando também em segurança. Não apenas em funcionalidade.
Entenda APIs. O COBOL pode estar cinco camadas atrás de uma chamada proveniente da Internet.
Estude USS. Existe um universo UNIX dentro do z/OS que muitos desenvolvedores tradicionais quase nunca exploraram.
Entenda DevSecOps. Git, pipeline, build e deploy fazem parte da superfície de confiança.
Nunca pense “ninguém sabe que isso existe”. Obscuridade não deve ser o principal controle.
Pergunte sempre: “E se essa identidade legítima estiver comprometida?” Essa pergunta revela problemas que muitos checklists não encontram.

🥚 EASTER EGG — 03:17 E A DIMENSÃO DO ACCESS ALLOWED

São exatamente:

03:17:04

O SOC recebe um evento.

USER: PRODADM
AUTHENTICATION: SUCCESS

03:17:09:

RESOURCE: PROD.PAYROLL.MASTER
ACCESS: ALLOWED

03:17:14:

PROGRAM: EXECUTED
RESULT: SUCCESS

03:17:31:

TRANSFER: COMPLETED

O jovem programador corre até Strange.

— Mestre! Encontrei o problema!

— Qual?

— RACF falhou!

Strange olha os registros.

— Onde?

— O usuário acessou o arquivo!

— Ele tinha autorização?

— Tinha.

— A autenticação funcionou?

— Sim.

— O programa executou normalmente?

— Sim.

— Então onde está a falha do RACF?

O garoto permanece em silêncio.

Strange abre o Olho de Agamotto e volta alguns minutos no tempo.

03:02.

Um administrador abre um e-mail.

03:04.

Clica num link.

03:05.

Digita suas credenciais.

03:17.

Alguém do outro lado do mundo entra usando uma identidade válida.

Strange congela o tempo.

Na tela não aparece:

ICH408I
ACCESS DENIED

Aparece:

ACCESS ALLOWED

O jovem finalmente entende.

— Estávamos procurando alguém tentando arrombar a porta...

Strange sorri.

— ...quando deveríamos procurar quem roubou a chave.

☕

🌀 EPÍLOGO — O MAIOR FEITIÇO DO MAINFRAME É A CONFIANÇA

Quando começamos esta jornada, tínhamos cinco infográficos mostrando dezenas de ameaças:

DDoS, DoS, Man-in-the-Middle, DNS spoofing, ARP spoofing, sniffing, session hijacking, Evil Twin, port scanning, IP spoofing, brute force, dictionary attacks, credential stuffing, password spraying, phishing, engenharia social, malware, ransomware, spyware, rootkits, botnets, backdoors, SQL Injection, XSS, zero-days e muitas outras.

Transportá-las mecanicamente para o IBM Z seria um erro.

O aprendizado importante é outro.

O mainframe moderno faz parte de um ecossistema.

PESSOA
   │
IDENTIDADE
   │
REDE
   │
INTEGRAÇÃO
   │
APLICAÇÃO
   │
MAINFRAME
   │
DADOS

Segurança precisa acompanhar todo o caminho.

E aqui está talvez a maior evolução mental para um programador COBOL iniciante.

Quando você começou, enxergava:

       IDENTIFICATION DIVISION.
       ENVIRONMENT DIVISION.
       DATA DIVISION.
       PROCEDURE DIVISION.

Depois passou a enxergar:

COBOL
CICS
Db2
VSAM
JCL

Mais tarde:

RACF
SMF
TCP/IP
MQ
USS
APIs
DevOps

Até finalmente perceber:

E confiança é justamente aquilo que cybersecurity tenta administrar.

Zero Trust não significa desconfiar paranoicamente de tudo.

Significa não transformar uma suposição em autorização eterna.

Autentique.

Autorize.

Proteja.

Registre.

Observe.

Correlacione.

Questione.

E principalmente:

não procure apenas portas quebradas. Procure portas que alguém conseguiu abrir normalmente quando não deveria estar ali.

O Doutor Estranho abre seu último portal.

Antes de desaparecer, olha para o jovem programador COBOL e aponta para a tela.

USER PRODADM
ACCESS ALLOWED
03:17

— Strange?

— Sim?

— Afinal, quantas ameaças existem contra um mainframe?

Ele pensa por alguns segundos.

— Em quantos futuros?

— Sim.

— Eu examinei 14.000.605.

— E em quantos estávamos completamente seguros?

Strange atravessa o portal.

— Em nenhum. Segurança não é um estado. É um processo.

O portal fecha.

O programador olha novamente para o ISPF.

OPTION ===>

E percebe que aquela mesma tela de sempre parece diferente.

Não porque o mainframe tenha mudado.

Mas porque agora ele consegue enxergar os portais invisíveis ao redor dele.

☕ Um Café no Bellacosa Mainframe

Porque antes de proteger 60 anos de legado, precisamos compreender por que ele continua funcionando — e por onde alguém tentaria fazê-lo parar.

Translate

domingo, 6 de outubro de 2019