 |
| Bellacosa Mainframe e a invasao do mainframe |
☕ Um Café no Bellacosa Mainframe
Agente 86 Entra no CPD — O Dia em que o Kaos Descobriu que Não Precisava Explodir o Mainframe, Bastava Convencer Alguém a Digitar a Senha
Ou: como DDoS, phishing, malware, credential stuffing, MITM, ransomware, RACF, Zero Trust e um programador COBOL iniciante terminaram presos na mesma operação de segurança — enquanto Maxwell Smart insistia que tudo estava “sob controle”
Existe um erro recorrente quando alguém começa a estudar cybersecurity: imaginar que cada ataque pertence a uma gaveta perfeitamente separada.
De um lado ficam os vírus.
Em outra gaveta ficam os hackers.
Em outra, as senhas.
Em outra, a rede.
Em outra, o ransomware.
E em algum lugar escuro do datacenter existe um sujeito de capuz digitando coisas verdes em uma tela preta enquanto uma caveira pisca dramaticamente.
É uma imagem maravilhosa para cinema.
Para segurança da informação, porém, é quase tão útil quanto Maxwell Smart tentando abrir a porta secreta da CONTROL e sendo esmagado por ela.
Porque ataques reais raramente acontecem de forma isolada.
Eles são cadeias.
Um criminoso pode começar com reconhecimento, descobrir nomes e endereços, enviar phishing, roubar uma credencial, entrar numa VPN, mapear a rede, comprometer outro equipamento, instalar malware, coletar novas credenciais, movimentar-se lateralmente, exfiltrar dados e, finalmente, disparar ransomware.
Quando você olha apenas para o ransomware, está olhando para o último episódio da série.
O ataque começou muitos capítulos antes.
Portanto, programador COBOL, pegue seu café, sente-se ao lado do console e esconda o telefone-sapato do Agente 86 antes que ele tente discar para o RACF.
Hoje vamos transformar aquelas famosas listas de “tipos de ataques” em algo que realmente faça sentido.
1. Missão número 1: entender o que realmente está sendo atacado
Antes de decorar nomes, precisamos fazer uma pergunta simples:
Qual parte do sistema o atacante está tentando comprometer?
Podemos dividir o problema em quatro grandes famílias:
| Família | Objetivo |
|---|
| Ataques de rede | Interferir, observar ou manipular comunicações |
| Ataques de identidade/senha | Conseguir se passar por usuário autorizado |
| Malware | Executar código malicioso dentro do ambiente |
| Ataques cibernéticos combinados | Encadear técnicas até atingir um objetivo |
Essa divisão já ajuda enormemente.
Imagine um banco.
O mainframe pode estar funcionando perfeitamente.
O COBOL também.
O Db2 também.
O CICS também.
Mas alguém compromete a estação Windows de um administrador com acesso privilegiado.
A pergunta então deixa de ser:
“O mainframe foi hackeado?”
e passa a ser:
“O caminho até o mainframe foi comprometido?”
Essa diferença é gigantesca.
2. Os três pilares da segurança
Antes de continuarmos, precisamos conversar com três velhos conhecidos:
Confidencialidade, Integridade e Disponibilidade.
O famoso modelo CIA:
Confidentiality
Integrity
Availability
Confidencialidade significa:
somente quem deve ver os dados consegue vê-los.
Integridade:
os dados não podem ser modificados indevidamente.
Disponibilidade:
o serviço precisa continuar funcionando.
Um ataque DDoS, por exemplo, normalmente não precisa roubar informação nenhuma.
Ele pode simplesmente impedir que o serviço funcione.
Está atacando Availability.
Já um MITM pode ameaçar confidencialidade e integridade.
Um ransomware pode atingir disponibilidade, integridade e confidencialidade ao mesmo tempo.
Agente 86 olha para a tela:
— Chefe, temos três suspeitos!
O Chefe responde:
— Smart, isso não são suspeitos. São os pilares da segurança.
— Eu sabia disso.
Não sabia.
3. DoS: ninguém entra no prédio
Denial of Service significa negar serviço.
Imagine uma aplicação capaz de atender dez mil requisições por segundo.
Alguém produz tráfego ou trabalho suficiente para consumir recursos.
Podem acabar:
CPU;
memória;
conexões;
threads;
filas;
largura de banda;
sockets;
recursos da aplicação.
O sistema continua existindo.
Mas deixou de responder adequadamente.
É como um restaurante que possui cem mesas e recebe dez mil pessoas de uma vez.
A cozinha não foi destruída.
O prédio não caiu.
Simplesmente não consegue atender.
4. DDoS: agora o Kaos alugou um exército
Distributed Denial of Service é o mesmo conceito multiplicado.
Em vez de um atacante:
Atacante → Servidor
temos:
Computador infectado ─┐
Câmera IoT ───────────┤
Servidor infectado ───┤
Roteador comprometido ├──► ALVO
PC doméstico ─────────┤
Outro equipamento ────┘
Isso normalmente envolve uma botnet.
E veja a primeira conexão importante:
MALWARE
↓
BOTNET
↓
DDoS
Já ficou claro que as categorias não vivem isoladas.
Um malware pode criar uma botnet.
A botnet pode realizar DDoS.
Um ataque alimenta outro.
5. Reconnaissance: o Agente 86 olha a planta do prédio
Antes de invadir qualquer coisa, um atacante inteligente tenta entender o terreno.
Isso é reconnaissance.
Reconhecimento pode envolver descobrir:
Um port scan, por exemplo, tenta descobrir quais serviços parecem estar acessíveis.
Host
├── 22
├── 80
├── 443
├── 8080
└── ...
Importante:
port scanning não é automaticamente ataque.
Administradores fazem isso.
Pentesters fazem isso.
Equipes de segurança fazem isso.
O contexto importa.
Um martelo pode construir uma casa ou quebrar uma janela.
A ferramenta sozinha não define a intenção.
6. Packet Sniffing: escutando o telefone da CONTROL
Sniffing significa observar tráfego de rede.
Administradores utilizam análise de pacotes para diagnosticar problemas.
Por exemplo:
origem
destino
protocolo
porta
latência
retransmissões
flags
erros
Um atacante pode tentar observar informações expostas.
Mas existe uma grande diferença entre:
HTTP
e:
HTTPS/TLS
Capturar pacotes criptografados não significa automaticamente conseguir ler o conteúdo.
TLS existe justamente para proteger comunicações.
E aqui aparece um conceito muito mais profundo:
criptografia não serve apenas para esconder dados.
Ela também pode participar da autenticação do outro lado da comunicação.
7. MITM: “desculpe, mas você está falando comigo”
Man-in-the-Middle ocorre quando um terceiro consegue posicionar-se entre duas partes.
Alice pensa estar falando com Bob:
Alice ───────── Bob
Mas Mallory está no caminho:
Alice ←→ Mallory ←→ Bob
Mallory pode tentar observar, retransmitir ou modificar comunicações.
É aqui que TLS, certificados e validação correta tornam-se importantíssimos.
Imagine a conversa:
— Aqui é o servidor do banco.
— Tem certeza?
Essa é uma das perguntas criptográficas mais importantes da Internet.
8. ARP Spoofing: “o gateway sou eu”
Em redes locais, ARP ajuda a relacionar endereços IP e MAC.
Simplificando:
Quem possui 192.168.1.1?
E alguém responde:
Eu, neste endereço MAC.
Num cenário de spoofing ou poisoning, um atacante tenta introduzir informações falsas.
Conceitualmente:
Vítima:
Onde está o gateway?
Atacante:
EU SOU O GATEWAY!
O resultado pode permitir manipular caminhos de tráfego.
E novamente:
ARP spoofing
↓
MITM
↓
sniffing
Observe a cadeia.
Segurança é frequentemente isto:
uma técnica preparando a próxima.
9. DNS: a lista telefônica do mundo digital
Você digita:
banco.com
Mas computadores trabalham com endereços.
DNS resolve nomes para endereços.
Se essa resolução for manipulada, você pode digitar o nome correto e acabar no lugar errado.
banco.com
↓
DNS legítimo
↓
servidor verdadeiro
versus:
banco.com
↓
resolução comprometida
↓
servidor malicioso
DNS spoofing enfatiza respostas falsas.
DNS cache poisoning enfatiza contaminar informações armazenadas em cache.
É quase como alterar o número de telefone de uma empresa na lista telefônica.
Você disca corretamente.
Mas chega ao criminoso.
10. Evil Twin: o Wi-Fi gratuito que custou caro
Imagine um aeroporto.
Você encontra:
Airport_Free_WiFi
Ao lado:
Airport_Free_WiFi_5G
Qual é legítimo?
Um Evil Twin é um ponto de acesso configurado para parecer legítimo.
O detalhe brilhante do ataque:
a vítima conecta-se voluntariamente.
Ninguém precisou invadir fisicamente o notebook.
A pessoa entrou na rede errada.
É um encontro perfeito entre rede e engenharia social.
11. Password attacks: atacar o segredo ou atacar quem conhece o segredo?
Agora mudamos de andar no prédio da CONTROL.
Em vez de atacar a rede, atacamos identidade.
Temos:
brute force;
dictionary attack;
credential stuffing;
password spraying;
rainbow tables;
keylogging;
phishing;
shoulder surfing;
social engineering;
hash cracking;
pass-the-hash;
default passwords.
O objetivo é conseguir algo que permita autenticação.
12. Brute force: a marreta matemática
Brute force tenta possibilidades.
aaaa
aaab
aaac
...
O problema para o atacante é que espaços de senha podem crescer absurdamente.
Por isso sistemas modernos usam:
rate limiting;
lockout adaptativo;
MFA;
monitoramento;
detecção de anomalias.
Uma coisa importante para o programador iniciante:
não tente inventar sua própria política de autenticação dentro do programa COBOL.
Deixe identidade para sistemas especializados.
No z/OS, isso significa respeitar mecanismos de segurança da plataforma.
13. Dictionary attack: humanos são previsíveis
Em vez de testar tudo, o atacante usa palavras comuns e padrões humanos.
Pessoas gostam de:
nomes;
datas;
times;
animais;
nomes de empresas;
sequências;
variações previsíveis.
Em vez de procurar qualquer senha possível, o atacante procura aquilo que seres humanos provavelmente escolheriam.
O algoritmo não ficou mais inteligente.
Ele simplesmente passou a explorar psicologia.
14. Credential stuffing: quando um vazamento vira dez invasões
Imagine:
usuario@email.com
SenhaSuperForte123!
Excelente senha.
Mas o usuário repete a mesma em quinze serviços.
Um deles sofre vazamento.
O criminoso pega usuário e senha vazados e testa em outros serviços.
Isso é credential stuffing.
A senha não foi quebrada.
Foi reutilizada.
Por isso uma regra moderna extremamente importante é:
credenciais diferentes em serviços diferentes.
Password managers ajudam justamente nisso.
15. Password spraying: uma senha para muitas pessoas
Brute force:
uma conta
muitas senhas
Password spraying:
muitas contas
poucas senhas
O objetivo pode ser evitar mecanismos simples de bloqueio.
O atacante tenta algumas senhas comuns contra vários usuários.
Isso mostra outra verdade da segurança:
defesas previsíveis também podem ser estudadas.
16. Hashing: senha não deveria ficar guardada como texto
Um sistema bem projetado não deveria armazenar:
senha = "abc123"
em texto puro.
O modelo moderno envolve funções apropriadas para armazenamento de senha:
password
+
salt
↓
password hashing/KDF
↓
valor armazenado
O salt ajuda a impedir que valores iguais produzam o mesmo resultado reutilizável em massa.
Rainbow tables historicamente exploram pré-computações de hashes.
Com salts únicos e algoritmos modernos apropriados, essa técnica perde muito da vantagem.
17. Pass-the-Hash: “não preciso da senha, obrigado”
Em alguns ambientes e mecanismos, um atacante pode utilizar material derivado da autenticação sem conhecer a senha original.
Esse conceito ensina algo enorme:
não protegemos apenas:
password
Protegemos também:
token
cookie
ticket
hash
session
certificate
key
Identidade virou ecossistema.
18. Default Password: a porta blindada com a chave pendurada
Existem vulnerabilidades sofisticadas.
E existem:
admin / admin
Dispositivos e sistemas configurados com credenciais padrão esquecidas representam risco histórico.
É uma das lições mais cruéis da segurança:
tecnologias sofisticadas podem ser derrotadas por configuração preguiçosa.
19. Phishing: por que quebrar criptografia se posso telefonar para o usuário?
Phishing explora confiança.
O atacante tenta convencer alguém a:
clicar;
autenticar;
fornecer informação;
aprovar acesso;
executar alguma ação.
Ele não precisa derrotar AES.
Não precisa quebrar TLS.
Precisa convencer Carlos do financeiro.
Isso muda a filosofia defensiva.
Treinamento é importante.
Mas sistemas devem ser projetados para que um erro humano isolado não destrua tudo.
20. Spear Phishing e Whaling
Phishing pode ser genérico.
Spear phishing é direcionado.
Whaling mira executivos ou pessoas de alto valor.
Quanto mais informações o atacante possui, mais convincente pode ser.
É por isso que reconnaissance não significa apenas escanear portas.
Pode significar descobrir:
quem trabalha onde
quem aprova pagamentos
quem administra sistemas
quem possui acesso privilegiado
LinkedIn, redes sociais, páginas corporativas e documentos públicos também podem alimentar reconhecimento.
21. Shoulder Surfing: o ataque zero megabytes
Às vezes segurança não precisa de software.
A pessoa simplesmente olha:
PIN
senha
tela
código
documento
Isso é shoulder surfing.
Nenhum malware.
Nenhum exploit.
Nenhum zero-day.
Somente:
👀
Segurança da informação inclui segurança física.
22. Malware: quando o inimigo atravessou o portão
Agora entramos na família:
vírus;
worm;
trojan;
ransomware;
spyware;
adware;
rootkit;
keylogger;
botnet;
backdoor;
fileless malware;
cryptojacking;
logic bomb;
loader.
Aqui perguntamos:
que comportamento o código malicioso executa?
23. Virus versus Worm
Vírus tradicionalmente associa-se a outros arquivos ou programas.
Worm possui capacidade de propagação automática.
VÍRUS
arquivo → execução → infecção
WORM
máquina A
↓
máquina B
↓
máquina C
↓
máquina D
Worms podem crescer muito rapidamente.
Por isso segmentação de rede é tão importante.
Se tudo consegue falar livremente com tudo:
um problema local pode virar problema corporativo.
24. Trojan: o presente do Kaos
Trojan aparenta ser algo legítimo.
Programa.
Documento.
Jogo.
Instalador.
Update.
Mas contém comportamento malicioso.
O usuário abre o portão.
O Cavalo de Troia atravessa.
A metáfora atravessou milhares de anos e continua perfeita.
25. Ransomware: o último episódio, não necessariamente o primeiro
O desenho popular é:
arquivos criptografados
↓
pague resgate
Mas operações modernas podem envolver:
phishing
↓
acesso inicial
↓
roubo de credenciais
↓
reconhecimento
↓
movimento lateral
↓
exfiltração
↓
sabotagem de recuperação
↓
criptografia
↓
extorsão
Por isso backup é indispensável.
Mas backup sozinho não resolve tudo.
Se dados forem exfiltrados, a vítima pode recuperar arquivos e ainda enfrentar extorsão.
26. Spyware e Keylogger
Spyware coleta informações.
Keylogger captura entrada de teclado.
Mas hoje credenciais podem ser obtidas também por:
cookies;
tokens;
sessões;
navegador;
clipboard;
credenciais armazenadas.
Esse detalhe explica por que MFA, apesar de excelente, não significa invulnerabilidade.
Se a sessão autenticada for comprometida, o atacante talvez não precise pedir um segundo fator novamente naquele momento.
27. Rootkit: “não encontrei nada suspeito”
Rootkits tentam ocultar presença e manter persistência em níveis profundos.
O conceito assustador:
o próprio sistema usado para verificar segurança pode estar comprometido.
É como pedir ao suspeito:
— Há criminosos na sala?
— Nenhum.
— Ótimo.
Agente 86 fecha o relatório.
O Chefe começa a chorar.
28. Backdoor: a porta dos fundos
O fluxo normal:
login
↓
MFA
↓
autorização
↓
recurso
Uma backdoor tenta criar outro caminho.
atalho oculto
↓
acesso indevido
Daí o nome.
29. Fileless Malware e Living off the Land
Fileless não significa necessariamente zero arquivos em absolutamente todas as etapas.
A ideia geral é minimizar o uso de arquivos executáveis tradicionais gravados no disco e abusar de mecanismos existentes no sistema.
Daí o conceito:
Living off the Land.
O atacante pensa:
“Por que carregar todas as ferramentas se a vítima já possui ferramentas que posso abusar?”
Esse conceito é extremamente importante em ambientes modernos.
30. Cryptojacking: roubar eletricidade em vez de dados
Cryptojacking usa recursos computacionais sem autorização.
O objetivo pode ser mineração ou outro trabalho computacional.
Rouba:
CPU
GPU
energia
capacidade
cloud budget
A vítima percebe:
CPU alta;
máquinas lentas;
custos inesperados;
consumo anormal.
É roubo de recurso.
31. Logic Bomb
Uma logic bomb espera uma condição.
IF condição
THEN executar ação maliciosa
Ela pode ficar dormente.
Um gatilho acontece.
A ação dispara.
O nome é quase literal.
32. Loader: “eu só trouxe o próximo vilão”
Loader carrega ou introduz outro malware.
Isso mostra outra característica atual:
malware pode ser modular.
loader
↓
payload
↓
credential stealer
↓
backdoor
↓
ransomware
Não pense num único vírus fazendo tudo.
Pense numa equipe.
Até o Kaos entendeu microserviços.
33. SQL Injection: agora o programador COBOL precisa prestar muita atenção
SQL Injection acontece quando entrada controlada externamente acaba sendo interpretada como parte da instrução SQL.
A grande regra:
DADO ≠ CÓDIGO
Esse princípio vale em qualquer plataforma.
Em aplicações COBOL com Db2, especialmente envolvendo SQL dinâmico, nunca devemos tratar entrada não confiável como parte livre de uma instrução construída sem controles apropriados.
Use os recursos corretos da plataforma.
Variáveis host.
Parâmetros.
Prepared statements onde aplicável.
Validação.
Privilégio mínimo.
O problema não é “Db2 ser inseguro”.
O problema é a aplicação misturar comando com dado de forma insegura.
34. XSS: quando dado vira script
Cross-Site Scripting é conceitualmente semelhante em outro domínio.
Conteúdo controlado pelo usuário acaba sendo interpretado pelo navegador como código ativo.
Novamente:
DADO NÃO CONFIÁVEL
≠
CÓDIGO CONFIÁVEL
A defesa envolve técnicas como output encoding adequado ao contexto, validação e políticas de segurança.
Esse princípio aparece repetidamente na cybersecurity.
Talvez devesse estar escrito em letras gigantes na parede de toda equipe de desenvolvimento:
Nunca permita que um dado seja promovido a comando sem controle.
35. Zero-Day: não é um vírus de filme
Zero-day refere-se a vulnerabilidade para a qual os defensores ainda não tiveram oportunidade efetiva de corrigir ou para a qual ainda não existe correção disponível no momento relevante.
O nome remete a:
dias para corrigir = 0
Por isso segurança não pode depender apenas de patch.
Precisamos de defesa em profundidade:
segmentação;
least privilege;
monitoramento;
EDR;
allowlisting;
hardening;
detecção comportamental;
Zero Trust.
36. Agora vamos montar o ataque completo
Pegue todas as técnicas e coloque numa história.
1. Reconnaissance
↓
2. Spear phishing
↓
3. Roubo de credencial
↓
4. Initial Access
↓
5. Loader
↓
6. Malware
↓
7. Backdoor
↓
8. Credential Access
↓
9. Network Discovery
↓
10. Lateral Movement
↓
11. Data Collection
↓
12. Exfiltration
↓
13. Ransomware
Pronto.
As listas deixaram de ser listas.
Viraram uma operação.
Esse é exatamente o tipo de pensamento usado em frameworks como MITRE ATT&CK.
37. MITRE ATT&CK: pare de decorar nomes, acompanhe comportamento
MITRE ATT&CK organiza técnicas conforme objetivos do adversário.
Em vez de perguntar:
“Que vírus é esse?”
perguntamos:
Como entrou?
Como executou?
Como persistiu?
Como elevou privilégios?
Como obteve credenciais?
Como descobriu sistemas?
Como se movimentou?
Como coletou dados?
Como exfiltrou?
Como causou impacto?
Essa mudança é enorme.
Você deixa de colecionar nomes de ameaças.
Passa a estudar comportamento adversário.
38. E o IBM Z no meio disso tudo?
Aqui aparece nosso mainframe.
Muitos iniciantes imaginam:
“Mainframe não está na Internet, então problema resolvido.”
Não necessariamente.
Uma arquitetura moderna pode ser:
Internet
↓
WAF
↓
API Gateway
↓
OpenShift
↓
z/OS Connect
↓
CICS
↓
COBOL
↓
Db2
O atacante não precisa começar no COBOL.
Pode atacar:
O mainframe é uma fortaleza.
Mas uma fortaleza conectada a pontes.
E pontes também precisam ser protegidas.
39. RACF: “Quem é você?”
RACF nos traz uma maneira elegantíssima de pensar segurança.
Primeira pergunta:
QUEM É VOCÊ?
Autenticação.
Segunda:
O QUE VOCÊ PODE FAZER?
Autorização.
Terceira:
O QUE VOCÊ FEZ?
Auditoria.
Essa tríade explica boa parte da segurança corporativa moderna.
Um usuário pode autenticar corretamente.
Isso não significa que deva acessar tudo.
É aí que entra authorization.
40. Least Privilege: Agente 86 não deveria ter acesso ao botão vermelho
Imagine Maxwell Smart entrando no CPD.
Ele recebe acesso:
READ
UPDATE
ALTER
CONTROL
SPECIAL
OPERATIONS
AUDITOR
Tudo.
Porque “fica mais fácil”.
É exatamente assim que incidentes horríveis começam.
Least Privilege diz:
conceda apenas o necessário.
Se um programador precisa ler determinado dataset, talvez não precise ALTER.
Se uma aplicação precisa consultar tabela, talvez não precise DROP.
Se um usuário precisa executar transação CICS, não significa que precisa acessar tudo no sistema.
Privilégio mínimo reduz o estrago possível.
41. Defense in Depth: a porta secreta da CONTROL tem muitas portas
Nunca dependa de uma única defesa.
Se sua segurança é:
firewall
então:
firewall falhou → acabou
Defense in Depth:
Firewall
↓
segmentação
↓
identidade
↓
MFA
↓
least privilege
↓
hardening
↓
endpoint security
↓
application security
↓
monitoramento
↓
backup
↓
incident response
O atacante precisa vencer várias barreiras.
É como a sequência de portas da abertura de Get Smart.
Só que sem prender Maxwell Smart no elevador.
42. Zero Trust: “não confie só porque está dentro”
O modelo antigo era frequentemente:
fora da rede = perigoso
dentro da rede = confiável
Zero Trust questiona isso.
Estar dentro não é prova suficiente.
Pergunte constantemente:
quem é?
qual dispositivo?
qual contexto?
qual recurso?
qual risco?
qual autorização?
comportamento esperado?
Isso combina muito bem com a mentalidade RACF.
O velho mainframe já sabia há décadas que:
“estar conectado” não é igual a “estar autorizado”.
43. MFA: excelente, mas não é escudo mágico
MFA aumenta bastante a segurança.
Mas ainda existem riscos:
phishing;
roubo de sessão;
engenharia social;
aprovação indevida;
recuperação de conta;
endpoint comprometido.
Métodos resistentes a phishing, como FIDO2/passkeys corretamente implementados, ajudam especialmente nesse cenário.
A evolução parece:
senha
↓
senha forte
↓
password manager
↓
MFA
↓
phishing-resistant MFA
↓
passkeys/FIDO2
44. SOC: o verdadeiro Agente 86 da segurança corporativa
Um SOC observa eventos.
Imagine:
08:01 login anormal
08:05 DNS estranho
08:08 scan interno
08:12 autenticação em novo servidor
08:17 acesso privilegiado
08:25 transferência anormal
08:40 alterações massivas
Isoladamente, cada evento pode parecer pouco importante.
Juntos:
evento
+
evento
+
evento
+
contexto
=
incidente
Essa correlação é um dos grandes trabalhos de defesa.
No z/OS, entram elementos como:
SMF;
RACF auditing;
logs;
eventos CICS;
Db2;
USS;
JES;
integração com SIEM.
45. SMF: o diário que o criminoso gostaria que você não tivesse
System Management Facilities registra enorme quantidade de informação operacional.
Para segurança, logs são fundamentais.
A pergunta não é apenas:
“O atacante entrou?”
Mas:
quando?
com qual identidade?
em qual sistema?
qual recurso?
qual operação?
de onde?
quanto tempo?
o que aconteceu depois?
Sem logs, investigar incidentes vira arqueologia paranormal.
Com logs, você consegue reconstruir a história.
46. O elemento mais perigoso não aparece bem nos infográficos
É o ser humano.
Temos:
usuário
administrador
desenvolvedor
fornecedor
help desk
executivo
operador
Criminosos sabem disso.
Às vezes o caminho mais barato não é quebrar uma criptografia moderna.
É convencer alguém com autoridade.
Isso explica o crescimento da engenharia social.
47. IA entra na sala
E aqui temos a atualização moderna.
IA generativa pode ser usada para:
produzir phishing convincente;
traduzir mensagens perfeitamente;
personalizar ataques;
automatizar pesquisa;
criar conteúdo fraudulento;
melhorar engenharia social.
Mas também pode ajudar defensores:
A IA não substitui as técnicas antigas.
Ela acelera o tabuleiro.
48. Passo a passo para o programador COBOL iniciante
Se você está começando, não tente estudar cybersecurity como se estivesse decorando Pokémons.
Faça assim.
Primeiro, aprenda redes:
IP
TCP
UDP
DNS
ARP
HTTP
TLS
firewall
Depois entenda identidade:
authentication
authorization
password
MFA
token
session
certificate
Depois malware:
trojan
worm
ransomware
backdoor
loader
rootkit
Depois aplicação:
SQL Injection
XSS
input validation
session security
APIs
Depois mainframe:
RACF
SMF
CICS security
Db2 privileges
USS security
JES
z/OSMF
TLS
certificates
Depois frameworks:
MITRE ATT&CK
Zero Trust
Defense in Depth
Least Privilege
Incident Response
A ordem importa.
Você constrói o mapa antes de estudar a guerra.
49. Easter Egg — o cone do silêncio da cybersecurity
Quem conhece Agente 86 sabe do maravilhoso Cone of Silence.
Ele deveria permitir uma conversa secreta.
Naturalmente nunca funciona direito.
Em cybersecurity existe uma analogia maravilhosa:
criptografia mal implementada é o Cone of Silence.
A organização diz:
— Está criptografado.
Pergunta:
— Como?
Silêncio.
— Onde estão as chaves?
Silêncio.
— Quem tem acesso?
Silêncio.
— Validamos certificados?
Silêncio.
— Rotacionamos segredos?
Silêncio.
— Está em produção desde 2009?
— Sim.
Agente 86 sorri:
— Chefe, acho que temos um problema.
50. Curiosidade: mainframe e Zero Trust são parentes distantes
Zero Trust parece moderníssimo.
Mas várias ideias combinam perfeitamente com práticas antigas de mainframe:
identidade forte
autorização granular
segregação
auditoria
privilégio mínimo
controle de recursos
Não significa que RACF “é Zero Trust”.
São coisas diferentes.
Mas existe uma continuidade filosófica.
Mainframe sempre tratou recurso como algo que deveria ser explicitamente protegido.
51. Curiosidade: segurança não é impedir tudo
Essa é uma das maiores mudanças de mentalidade.
Você nunca consegue garantir:
0 ataques
0 vulnerabilidades
0 erros humanos
O objetivo real inclui:
prevenir
detectar
conter
responder
recuperar
aprender
Resiliência importa tanto quanto prevenção.
Uma organização madura pergunta:
“O que acontece quando alguma barreira falhar?”
Porque alguma barreira eventualmente falhará.
52. O grande diagrama final
Se eu pudesse condensar tudo num quadro ao lado do terminal 3270:
RECONNAISSANCE
↓
INITIAL ACCESS
↓
EXECUTION
↓
PERSISTENCE
↓
CREDENTIAL ACCESS
↓
PRIVILEGE ESCALATION
↓
DISCOVERY
↓
LATERAL MOVEMENT
↓
COLLECTION
↓
EXFILTRATION
↓
IMPACT
E ao lado:
IDENTITY
↓
RACF
↓
LEAST PRIVILEGE
↓
SEGMENTATION
↓
MONITORING
↓
SMF
↓
SIEM
↓
RESPONSE
↓
RECOVERY
Um é o caminho do atacante.
O outro é o caminho da defesa.
Epílogo — “Sentimos muito, Chefe”
No final da investigação, o Agente 86 entra no CPD carregando três relatórios, um crachá errado e um telefone-sapato conectado acidentalmente ao modem.
O Chefe pergunta:
— Smart, descobriu como o Kaos invadiu o sistema?
Maxwell responde:
— Sim. Um zero-day ultrassofisticado combinado com criptografia pós-quântica reversa.
O analista RACF olha o log.
— Na verdade, alguém usou admin/admin.
Silêncio.
Maxwell ajeita o terno.
— Eu estava chegando nessa hipótese.
E talvez essa seja a melhor lição de cybersecurity.
Gostamos de falar de zero-days, ransomware, botnets, inteligência artificial, exploit chains e hackers patrocinados por Estados.
Tudo isso existe e é importante.
Mas muita segurança ainda depende de fundamentos aparentemente simples:
senhas únicas
MFA
patching
least privilege
segmentação
logs
backups
RACF
monitoramento
treinamento
procedimentos
Cybersecurity não é uma coleção de truques mágicos.
É disciplina.
É arquitetura.
É entender identidade, rede, aplicações e comportamento.
Para quem vem do COBOL e do mainframe, existe até uma vantagem cultural: o mundo IBM Z sempre nos ensinou que acesso não deveria ser baseado em “confio nesse cara”.
Deveria ser baseado em:
Quem é você?
A qual recurso quer acessar?
Qual nível de acesso precisa?
Quem autorizou?
O acesso foi registrado?
E se amanhã, às três da manhã, alguém tentar abrir um dataset crítico usando uma credencial válida de um funcionário que normalmente trabalha às duas da tarde em outro país?
Não basta perguntar:
“A senha estava correta?”
A pergunta moderna será:
“Essa operação faz sentido?”
Essa mudança separa autenticação de segurança.
E separa decorar ameaças de realmente compreender cybersecurity.
No Bellacosa Mainframe, portanto, a próxima vez que alguém disser:
“Não se preocupe, temos firewall.”
Você pode responder como o Chefe responderia ao Agente 86:
“Ótimo, Smart. Agora me diga quem protege a identidade, quem protege a sessão, quem monitora o acesso e quem lê os logs depois.”
Porque um firewall sozinho não salva o CPD.
Uma senha sozinha não salva o CPD.
Um antivírus sozinho não salva o CPD.
A verdadeira segurança está nas camadas.
E, se possível, mantenha Maxwell Smart longe do comando:
PERMIT * ACCESS(ALTER)
Certos riscos nem o Kaos merece.
