 |
| Bellacosa Mainframe e os malwares |
☕ Um Café no Bellacosa Mainframe
🕵️ DICK TRACY E O MALWARE QUE NUNCA ENTROU NO MAINFRAME
RACF, vírus, worms, trojans, ransomware, wipers, spyware, infostealers, backdoors, USS, CICS, Db2, MQ, SMF, TCP/IP, Zero Trust — e o dia em que Dick Tracy descobriu que o criminoso não precisava arrombar a porta se já possuía a chave.
Sob a tutela de Dick Tracy, o detetive que sabia que encontrar o corpo era apenas o começo da investigação.
🎬 PRÓLOGO — HÁ UM VÍRUS NO MAINFRAME!
03:17 da manhã.
O telefone tocou.
O jovem programador COBOL acordou assustado.
— Produção está estranha.
— ABEND?
— Não.
— CICS caiu?
— Não.
— Db2?
— Também não.
— Então qual é o problema?
Do outro lado da linha veio a frase que nenhum programador COBOL esperava ouvir:
— Acho que pegamos um vírus.
O jovem olhou para o terminal.
Aquilo parecia absurdo.
Vírus?
No mainframe?
Ele imaginava vírus como aquelas coisas do PC de casa: anexos de e-mail, executáveis suspeitos, propagandas surgindo na tela e programas dizendo:
SEU COMPUTADOR POSSUI 847 AMEAÇAS! CLIQUE AQUI!
No terminal 3270 não havia pop-up.
Não havia ventoinha girando.
Não havia bateria descarregando.
Muito menos um ícone de caveira piscando sobre o ISPF.
Mas havia alguma coisa.
Um job estava consumindo CPU em horário incomum.
Um usuário havia acessado datasets que normalmente nunca consultava.
Um processo no UNIX System Services aparecera durante a madrugada.
E havia tráfego de rede onde ninguém esperava encontrá-lo.
Nesse momento surgiu Dick Tracy.
Ele olhou para o jovem programador e disse:
— Você está procurando um vírus.
— Sim.
— Esse é o primeiro erro.
— Então o que devemos procurar?
Dick Tracy puxou seu famoso relógio comunicador.
— Comportamento.
Bem-vindo ao mundo da segurança no mainframe.
🕵️ CAPÍTULO 1 — MALWARE NÃO É SINÔNIMO DE VÍRUS
Vamos começar pela primeira confusão.
Todo vírus é malware.
Nem todo malware é vírus.
Podemos imaginar:
MALWARE
│
┌──────────────┼──────────────┐
│ │ │
Virus Worm Trojan
│ │ │
├──────────────┼──────────────┤
│ │ │
Ransomware Spyware Infostealer
│ │ │
├──────────────┼──────────────┤
│ │ │
Wiper Rootkit Backdoor
Malware é o grande guarda-chuva.
Um vírus tradicional infecta outros objetos e possui algum mecanismo de propagação.
Um worm procura espalhar-se.
Um Trojan finge ser algo legítimo.
Ransomware tenta produzir extorsão.
Spyware procura observar.
Infostealers roubam informações.
Wipers destroem.
Backdoors criam caminhos escondidos.
A questão interessante para nós é outra:
Como esses conceitos aparecem quando saímos do notebook e entramos no IBM Z?
Não devemos procurar uma tradução literal.
O mainframe possui arquitetura, sistema operacional, segurança, armazenamento, processos e cultura operacional diferentes.
Portanto, Dick Tracy não procuraria VIRUS.EXE.
Ele procuraria evidências.
🏰 CAPÍTULO 2 — O MAINFRAME NÃO É UMA ILHA
Existe uma visão antiga do mainframe:
┌─────────────────┐
│ MAINFRAME │
│ │
│ COBOL │
│ JCL │
│ CICS │
│ DB2 │
└─────────────────┘
Ninguém entra.
Ninguém sai.
Seria confortável.
Mas não representa um ambiente corporativo moderno.
Podemos encontrar:
Internet
│
Firewall
│
Load Balancer
│
API Gateway
│
z/OS Connect
│
CICS
│
COBOL
│
Db2
E também:
Aplicação distribuída
│
MQ
│
z/OS
│
CICS
│
COBOL
Além disso:
z/OS
├── TCP/IP
├── UNIX System Services
├── SSH
├── APIs
├── Java
├── Python
├── MQ
├── Db2
├── CICS
└── IMS
Isso não significa que o mainframe seja inseguro.
Significa que ele participa da arquitetura corporativa.
E conectividade significa superfície de ataque.
A pergunta madura não é:
"O mainframe está conectado?"
A pergunta é:
"O que está conectado, através de quê, com qual identidade, utilizando qual protocolo e autorizado a fazer o quê?"
Essa é uma pergunta de Dick Tracy.
🦠 CAPÍTULO 3 — VÍRUS: E SE ALGUÉM ALTERAR O PROGRAMA COBOL?
Imagine:
BANK.PROD.LOADLIB
Dentro dela:
AUTORIZA
CADASTRO
PAGAMENTO
TRANSFER
SALDO
Agora suponha que alguém consiga substituir TRANSFER.
O invasor talvez nem precise criar um mecanismo autorreplicante.
Se TRANSFER for chamado milhares de vezes por dia, a própria arquitetura da aplicação distribui o efeito do programa adulterado.
Esse conceito merece um nome informal:
propagação lógica.
O código não precisa copiar-se para 10.000 lugares.
Um componente central comprometido pode ser executado 10.000 vezes.
Por isso LOADLIBs, bibliotecas de produção, pipelines e processos de deployment são tão importantes.
Perguntas:
Quem pode alterar a LOADLIB?
Quem pode promover programas?
Desenvolvedor pode alterar produção?
O artefato produzido no build é exatamente
o artefato colocado em produção?
Existe rastreabilidade?
O jovem COBOL começa a perceber que segurança não começa quando o programa executa.
Começa muito antes.
🐴 CAPÍTULO 4 — O CAVALO DE TROIA APRENDEU COBOL
Agora imagine este código:
IF WS-USER-AUTHORIZED = 'Y'
PERFORM PROCESS-TRANSACTION
END-IF.
Parece normal.
Mas alguém adiciona:
IF WS-USER-ID = 'SUPPORT99'
MOVE 'Y' TO WS-USER-AUTHORIZED
END-IF.
Pronto.
Talvez não exista vulnerabilidade de memória.
Nenhum buffer overflow.
Nenhum vírus.
O próprio programa possui uma regra escondida.
É uma backdoor lógica.
E aqui nasce uma das razões pelas quais Git, revisão de código e DevSecOps também são mecanismos de segurança.
Precisamos conseguir responder:
Quem escreveu?
↓
Quem alterou?
↓
Qual commit?
↓
Quem revisou?
↓
Quem aprovou?
↓
Qual build?
↓
Qual artefato?
↓
Quem promoveu?
↓
Quando chegou à produção?
Código-fonte também é evidência forense.
Dick Tracy aprovaria.
🪱 CAPÍTULO 5 — O WORM DESCOBRIU O TCP/IP
Um worm caracteriza-se especialmente pela capacidade de propagação.
No imaginário do programador iniciante:
Mainframe não pega worm porque mainframe não tem Internet.
Ops.
Temos TCP/IP.
Temos aplicações de rede.
Temos USS.
Temos SSH.
Temos APIs.
Temos integração com sistemas distribuídos.
Isso não significa automaticamente que exista um worm esperando para atacar cada LPAR.
Significa apenas que a premissa:
MAINFRAME = COMPUTADOR SEM REDE
está errada.
Uma análise de segurança deve investigar:
Quais portas estão abertas?
Quais serviços estão escutando?
Quais interfaces estão expostas?
Quais protocolos são utilizados?
Existe TLS?
Quem pode conectar?
Que serviço realmente precisa existir?
Aqui segurança encontra arquitetura.
🔐 CAPÍTULO 6 — RANSOMWARE NÃO PRECISA CRIPTOGRAFAR O DASD INTEIRO
Quando pensamos em ransomware, imaginamos:
arquivos
↓
criptografia
↓
indisponíveis
↓
pedido de resgate
Mas ataques modernos podem combinar indisponibilidade, roubo de dados e extorsão.
A chamada dupla extorsão acrescenta:
ROUBAR
+
CRIPTOGRAFAR
A vítima então enfrenta duas ameaças:
"Se não pagar, você não recupera os dados."
e:
"Se não pagar, divulgamos os dados."
A chamada tripla extorsão pode ampliar a pressão para clientes, parceiros ou outras partes relacionadas.
No mainframe, não precisamos imaginar obrigatoriamente:
ENCRYPT ALL DASD
Um atacante procuraria ativos críticos.
Por exemplo:
Db2
VSAM
IMS
datasets
arquivos USS
configurações
credenciais
aplicações
backups
A questão é impacto.
💀 CAPÍTULO 7 — WIPER: O CRIMINOSO QUE NÃO QUER DINHEIRO
Dick Tracy encontra dois criminosos.
O primeiro diz:
— Dê-me dinheiro e talvez devolva seus dados.
Ransomware.
O segundo diz:
— Não quero dinheiro.
Esse é mais assustador.
Wipers têm como objetivo destruição ou inutilização.
No mundo mainframe, o raciocínio defensivo precisa considerar:
DADOS
│
├── produção
├── cópia
├── backup
└── recuperação
Se todas as cópias estiverem acessíveis pela mesma identidade comprometida, temos um problema arquitetural.
Por isso recuperação não pode signific apenas:
"Temos backup."
Precisamos perguntar:
"Um atacante que compromete produção consegue também destruir nossa capacidade de recuperação?"
Essa pergunta muda completamente a conversa.
👁️ CAPÍTULO 8 — SPYWARE: TALVEZ ELE NÃO QUEIRA SEU TECLADO
No PC doméstico, spyware observa atividades.
No mainframe, o prêmio pode estar atrás da aplicação.
Imagine:
CUSTOMER
ACCOUNT
PAYROLL
CARD
CLAIMS
TRANSACTIONS
Se alguém comprometer uma identidade autorizada a consultar essas informações, talvez nem precise instalar spyware no host.
O atacante possui aquilo que realmente queria:
acesso aos dados.
Por isso segurança de banco de dados e segurança do sistema operacional não podem viver isoladamente.
Imagine:
SQL
│
▼
Db2 authorization
│
▼
Db2
│
▼
datasets
│
▼
z/OS
Proteger apenas a porta da frente não basta se houver caminhos laterais inadequadamente protegidos.
🍪 CAPÍTULO 9 — INFOSTEALER: A INFECÇÃO PODE ESTAR FORA DO MAINFRAME
Aqui está uma das maiores armadilhas.
Imagine que o notebook de um administrador seja comprometido.
Um infostealer consegue roubar:
password
token
session
SSH key
API key
certificate
credencial técnica
Depois:
Notebook comprometido
↓
credencial roubada
↓
VPN
↓
ambiente corporativo
↓
mainframe
Pergunta:
O mainframe foi infectado?
Talvez não.
Existe um incidente envolvendo o mainframe?
Certamente pode existir.
E agora temos o grande problema:
o criminoso pode parecer um usuário legítimo.
🔑 CAPÍTULO 10 — RACF: DICK TRACY ENCONTRA O PORTEIRO
Chegamos ao RACF.
Para o iniciante:
RACF não é simplesmente:
"onde fica a senha."
Ele participa de um modelo muito maior:
IDENTIDADE
↓
AUTENTICAÇÃO
↓
AUTORIZAÇÃO
↓
RECURSO
↓
AUDITORIA
Suponha:
USER01
Quer acessar:
BANK.PROD.CUSTOMER
A pergunta relevante torna-se:
Quem é USER01?
Ele está autenticado?
Qual grupo possui?
Qual perfil protege o recurso?
Qual acesso recebeu?
READ?
UPDATE?
ALTER?
Agora Dick Tracy faz a pergunta incômoda:
E se USER01 estiver sendo utilizado por outra pessoa?
RACF pode estar funcionando corretamente.
A identidade está autenticada.
O acesso está autorizado.
Mas o humano atrás da identidade pode ser o criminoso.
É aí que entram autenticação forte, menor privilégio, auditoria, análise comportamental e Zero Trust.
🚪 CAPÍTULO 11 — A PORTA DOS FUNDOS NÃO PRECISA SER UMA PORTA
Backdoor costuma evocar:
porta TCP secreta
Mas uma backdoor pode ser simplesmente:
IF USER-ID = 'XYZ123'
MOVE 'Y' TO AUTHORIZED
END-IF.
Ou uma conta esquecida.
Ou privilégio temporário que virou permanente.
Ou uma credencial técnica compartilhada.
Ou uma exceção operacional nunca removida.
Essa é uma lição maravilhosa:
Backdoor é um conceito de acesso, não obrigatoriamente uma porta de rede.
🐧 CAPÍTULO 12 — O MALWARE DESCOBRE O USS
O programador COBOL entra no ISPF todos os dias.
Ele conhece:
PDS
PDSE
VSAM
JCL
LOADLIB
Dick Tracy pergunta:
— E /u/app/bin?
Silêncio.
Existe um UNIX dentro do z/OS: UNIX System Services.
Isso muda a superfície de segurança.
Agora temos conceitos como:
directories
files
processes
shell
permissions
UID
GID
SSH
scripts
executables
Portanto, quem investiga segurança z/OS precisa conhecer os dois lados:
| Mundo MVS | Mundo USS |
|---|
| Dataset | File |
| PDS/PDSE | Directory |
| JOB/STC | Process |
| USERID | UID associado |
| RACF | RACF + permissões UNIX |
| LOADLIB | executáveis/bibliotecas |
O invasor não é obrigado a respeitar a fronteira mental do programador COBOL.
Se você só olha datasets, pode deixar metade da casa sem inspeção.
🤖 CAPÍTULO 13 — BOTNET: 100 MIL ZUMBIS BATENDO NA PORTA
Agora o ataque nem precisa comprometer o z/OS.
Imagine:
PC ─────┐
PC ─────┤
PC ─────┤
PC ─────┤
... ├──► API ─► z/OS Connect ─► CICS ─► COBOL
PC ─────┤
PC ─────┘
São máquinas comprometidas formando uma botnet.
Milhares ou milhões de requisições podem produzir pressão sobre a infraestrutura.
O programa COBOL pode estar perfeito.
O RACF pode estar perfeito.
O Db2 pode estar perfeito.
Mesmo assim:
requests ↑
CPU ↑
threads/tasks ↑
Db2 work ↑
I/O ↑
latência ↑
filas ↑
Segurança encontrou performance.
E performance encontrou Capacity Planning.
⛏️ CAPÍTULO 14 — CRYPTOMINER: QUANDO CPU ROUBADA VIRA DINHEIRO
Cryptominers roubam recursos computacionais para mineração.
No mainframe, mesmo deixando a mineração específica de lado, o conceito mais amplo é excelente:
consumo computacional não autorizado.
Imagine que o SMF mostre:
00:00 normal
01:00 normal
02:00 normal
03:00 normal
03:17 █████████████████████ CPU
04:00 normal
O analista de performance pergunta:
— Quem consumiu isso?
Essa pergunta pode virar uma investigação de segurança.
SMF, RMF e outras fontes de telemetria não servem somente para Capacity Planning.
Também ajudam a reconstruir:
O QUE aconteceu?
QUANDO?
QUAL workload?
QUAL identidade?
QUAL recurso?
QUAL origem?
QUAL duração?
Observabilidade pode tornar-se ferramenta forense.
E, naturalmente, alguma coisa sempre acontece às 03:17 no Bellacosa Mainframe.
Easter egg encontrado. ☕😉
🕵️ CAPÍTULO 15 — OS 10 SINAIS DE INFECÇÃO, VERSÃO MAINFRAME
Agora podemos reinterpretar o primeiro infográfico.
No PC temos lentidão, pop-ups, bateria, navegador alterado etc.
No mainframe, procure anomalias como:
01 — CPU inesperadamente alta
02 — jobs desconhecidos
03 — STCs inesperadas
04 — processos USS estranhos
05 — acessos RACF fora do padrão
06 — datasets modificados inesperadamente
07 — tráfego TCP/IP anormal
08 — transferência incomum de dados
09 — alterações de configuração
10 — comportamento inesperado de aplicações
Mas atenção.
CPU alta não prova ataque.
Job desconhecido não prova malware.
Falha RACF não prova invasão.
Tráfego elevado não prova exfiltração.
Por isso precisamos de uma palavra fundamental:
BASELINE.
📊 CAPÍTULO 16 — BASELINE: COMO SABER QUE ALGO É ESTRANHO?
Dick Tracy encontra uma pegada tamanho 44.
Isso é suspeito?
Depende.
Se todas as pessoas da sala usam tamanho 44, talvez não.
Se somente uma pessoa possui esse tamanho e ela deveria estar a 500 quilômetros dali, temos algo interessante.
Mainframe funciona da mesma maneira.
Você precisa conhecer o normal.
CPU NORMAL
│
├───────────────
│
│ /\ ← anomalia
│ / \
│_____/ \________
Baseline pode incluir:
CPU
I/O
rede
jobs
horários
volume de transações
acessos
datasets
falhas RACF
origens de conexão
processos USS
Segurança sem contexto gera alertas.
Segurança com contexto produz investigação.
🔎 CAPÍTULO 17 — O PASSO A PASSO DE DICK TRACY
Imagine um incidente suspeito.
O iniciante quer imediatamente matar o job.
Dick Tracy segura sua mão.
— Primeiro preserve evidências.
Uma investigação conceitual pode seguir:
1. DETECTAR
↓
2. VALIDAR
↓
3. DELIMITAR
↓
4. PRESERVAR EVIDÊNCIAS
↓
5. IDENTIFICAR IDENTIDADES
↓
6. IDENTIFICAR RECURSOS
↓
7. RECONSTRUIR TIMELINE
↓
8. CONTER
↓
9. ERRADICAR
↓
10. RECUPERAR
↓
11. APRENDER
A ordem concreta dependerá da gravidade e dos procedimentos da organização. Um ataque em andamento pode exigir contenção urgente.
Mas existe uma regra preciosa:
Não destrua as pistas tentando resolver rapidamente o problema.
Logs importam.
SMF importa.
Horários importam.
IDs importam.
Mudanças importam.
🧬 CAPÍTULO 18 — DEFESA EM PROFUNDIDADE
Agora chegamos ao coração do artigo.
Não existe um botão:
[ PROTEGER MAINFRAME ]
Existe um conjunto de controles:
IDENTIDADE
│
RACF/SAF
│
menor privilégio
│
autenticação forte
│
REDE
│
TLS / AT-TLS / filtros
│
SISTEMA
│
z/OS + USS + hardening
│
APLICAÇÃO
│
CICS / Db2 / IMS / MQ
│
DADOS
│
criptografia
│
MONITORAMENTO
│
SMF / telemetria
│
RESILIÊNCIA
│
backup / recuperação
Isso é defesa em profundidade.
Se uma camada falhar, outra pode conter o ataque.
🧯 CAPÍTULO 19 — MENOR PRIVILÉGIO É UM EXTINTOR INVISÍVEL
Imagine dois usuários comprometidos.
Primeiro:
USERA
READ CUSTOMER.TEST
Segundo:
USERB
ALTER *
Qual comprometimento possui maior raio de impacto?
Óbvio.
O princípio do menor privilégio não existe porque administradores gostam de burocracia.
Existe para reduzir:
BLAST RADIUS
Se uma identidade for comprometida, o atacante herda aquilo que ela consegue fazer.
Logo:
cada privilégio desnecessário também pode tornar-se privilégio disponível ao invasor.
🔐 CAPÍTULO 20 — CRIPTOGRAFIA: A IRONIA DO RANSOMWARE
Existe uma ironia deliciosa.
Ransomware utiliza criptografia para prejudicar o proprietário.
Segurança utiliza criptografia para protegê-lo.
RANSOMWARE
dados
↓
chave controlada pelo atacante
↓
proprietário perde acesso
Contra:
CRIPTOGRAFIA CORPORATIVA
dados
↓
chave controlada adequadamente
↓
atacante não consegue interpretar dados
O algoritmo pode até compartilhar fundamentos criptográficos.
O que muda completamente é:
quem controla as chaves e com qual finalidade.
🧠 CAPÍTULO 21 — O ATAQUE MAIS PERIGOSO TALVEZ NÃO TENHA MALWARE
Voltamos à cena inicial.
Dick Tracy reuniu as evidências.
Nenhum vírus.
Nenhum worm.
Nenhum ransomware.
Nenhum executável misterioso.
O jovem programador perguntou:
— Então não houve ataque?
Dick Tracy respondeu:
— Houve.
— Cadê o malware?
— Não precisava.
Uma credencial válida havia sido comprometida.
O criminoso entrou utilizando mecanismos legítimos.
Consultou recursos para os quais aquela identidade possuía autorização.
Executou comandos permitidos.
Usou ferramentas administrativas existentes.
O sistema fez exatamente aquilo que havia sido configurado para fazer.
Esse cenário nos leva a uma conclusão extremamente importante:
O atacante não precisa necessariamente fazer o mainframe executar código malicioso. Às vezes basta conseguir autorização para executar operações legítimas com intenção maliciosa.
🧪 CAPÍTULO 22 — EXERCÍCIO PARA O PADAWAN COBOL
Pegue uma aplicação fictícia:
BANCO
│
├── CICS
│ └── COBOL
│
├── Db2
│
├── MQ
│
├── Batch/JCL
│
└── USS/API
Agora não pergunte:
"Onde instalaríamos antivírus?"
Faça estas perguntas:
Passo 1 — Identidade: quem consegue entrar?
Passo 2 — Autorização: depois de entrar, o que cada identidade consegue fazer?
Passo 3 — Aplicação: existe regra que contorna controles?
Passo 4 — Dados: quem consegue ler, alterar ou destruir?
Passo 5 — Rede: quem consegue conversar com quais serviços?
Passo 6 — Software: quem consegue alterar código e executáveis?
Passo 7 — Produção: quem consegue promover mudanças?
Passo 8 — Auditoria: conseguiríamos descobrir posteriormente quem fez determinada operação?
Passo 9 — Recuperação: conseguimos restaurar o ambiente se produção for destruída?
Passo 10 — Blast radius: se uma única credencial for comprometida, até onde o atacante chega?
Esse exercício vale mais do que decorar 30 nomes de malware.
🕵️ CAPÍTULO 23 — DICK TRACY ENSINA O PROGRAMADOR COBOL A PENSAR COMO INVESTIGADOR
O COBOL ensina:
IF condição
THEN ação
END-IF
Segurança ensina algo parecido:
IF evidência
THEN hipótese
ELSE continue investigando
END-IF
Mas existe uma diferença essencial.
Não faça:
CPU ALTA
=
HACKER
Faça:
CPU ALTA
↓
qual workload?
↓
qual horário?
↓
qual USERID?
↓
qual programa?
↓
qual origem?
↓
é comportamento normal?
↓
existem outras evidências?
Isso é investigação.
🎁 CURIOSIDADE — O MAINFRAME PODE AJUDAR A INVESTIGAR A PRÓPRIA CENA DO CRIME
Uma característica fascinante de ambientes corporativos maduros é a quantidade de telemetria disponível.
O mesmo ecossistema utilizado para:
performance
capacity
billing
auditoria
operação
pode ajudar na segurança.
SMF é um exemplo extraordinário dessa convergência.
Aquilo que para o analista de performance significa:
"Quem gastou CPU?"
para segurança pode significar:
"Quem executou essa atividade?"
Para Capacity Planning:
"Quando começou?"
Para investigação:
"Essa hora coincide com o acesso suspeito?"
Os mesmos dados podem contar histórias diferentes.
O segredo é saber fazer perguntas.
🏁 EPÍLOGO — O CRIMINOSO TINHA A CHAVE
05:42.
O incidente estava finalmente compreendido.
O jovem programador fechou o ISPF.
— Dick, então o que devo guardar dessa noite?
O detetive colocou o chapéu.
— Não procure apenas criminosos arrombando janelas.
— Por quê?
— Porque os melhores entram pela porta.
— E como impedimos isso?
Dick Tracy olhou novamente para o mainframe.
Na tela estavam:
RACF
SMF
CICS
Db2
MQ
USS
TCP/IP
JCL
COBOL
— Não existe uma única defesa. Identifique quem entra. Limite o que pode fazer. Proteja os dados. Observe o comportamento. Registre evidências. Separe responsabilidades. Proteja a recuperação. E nunca confunda uma credencial válida com uma intenção legítima.
O jovem programador pensou por alguns segundos.
Finalmente entendeu.
O mainframe não precisava estar "infectado".
O criminoso poderia estar simplesmente usando o sistema.
E essa talvez fosse a descoberta mais inquietante de toda a investigação.
☕ A LIÇÃO DO BELLACOSA MAINFRAME
Para quem está começando em COBOL, malware pode parecer assunto de outra equipe.
Não é.
Quando você escreve:
IF USER-AUTHORIZED
PERFORM TRANSACTION
END-IF
você está tomando uma decisão de segurança.
Quando lê um dataset, está acessando um ativo.
Quando executa JCL, está solicitando recursos.
Quando uma aplicação chama Db2, MQ ou CICS, existe uma relação de confiança.
Quando um programa vai para produção, existe uma cadeia de custódia do software.
Quando alguém recebe privilégio demais, aumenta-se o potencial raio de impacto de um comprometimento.
E quando ninguém observa os registros, as pistas podem existir sem que ninguém monte o quebra-cabeça.
Portanto, a evolução mental do padawan deveria ser:
"MAINFRAME NÃO PEGA VÍRUS"
↓
"MAINFRAME POSSUI SUPERFÍCIE DE ATAQUE"
↓
"PRECISO PROTEGER O SISTEMA"
↓
"PRECISO PROTEGER IDENTIDADES E DADOS"
↓
"PRECISO OBSERVAR COMPORTAMENTO"
↓
"PRECISO LIMITAR O IMPACTO
MESMO QUANDO UMA DEFESA FALHAR"
Essa última etapa é maturidade.
Porque segurança não consiste em acreditar que ninguém conseguirá atravessar a primeira porta.
Consiste também em garantir que, se alguém atravessar, não encontre todas as outras portas abertas.
E talvez seja esse o maior ensinamento de Dick Tracy para o jovem programador COBOL:
Em segurança, encontrar a arma é interessante. Descobrir quem tinha acesso, como entrou, o que fez, quais pistas deixou e por que conseguiu chegar tão longe é a verdadeira investigação.
No Bellacosa Mainframe, o mistério nunca termina no virus.exe.
Às vezes não existe vírus.
Às vezes não existe exploit.
Às vezes não existe sequer uma porta arrombada.
Existe apenas um USERID.
Uma autorização excessiva.
Uma atividade às 03:17.
E um detetive olhando para o SMF e perguntando:
— Muito bem... quem estava usando essa chave? ☕🕵️
