Ferris Bueller Tinha um Plano de Ataque — Red Team Antes de Existir Red Team
Reconhecimento, criatividade adversarial e a ideia de que o verdadeiro alvo nem sempre é a tecnologia: são as suposições de quem construiu o sistema.
✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
| Bellacosa Mainframe e o pedagio de igarata na sp 065 |
| Bellacosa Mainframe e a neblina na sp 065 |
| Bellacosa Mainframe e a neblina na sp 065 |
| Bellacosa Mainframe e o rollback e backup |
Existe uma cena em Curtindo a Vida Adoidado que deveria ser exibida em todo curso de operações, recuperação, banco de dados, continuidade e resposta a incidentes.
A Ferrari foi usada.
A quilometragem aumentou.
O problema precisa desaparecer.
Surge então uma ideia absolutamente maravilhosa em sua simplicidade:
Se andar para frente aumentou a quilometragem...
andar para trás deveria diminuir.
Lógica cristalina.
Elegante.
Quase matemática.
E completamente incapaz de apagar tudo o que já aconteceu.
É neste momento que Ferris Bueller encontra uma das verdades mais dolorosas de produção:
Você pode voltar um valor.
Pode restaurar um arquivo.
Pode carregar um backup.
Pode executar ROLLBACK.
Pode recuperar uma tabela.
Pode restaurar um dataset.
Pode voltar configuração.
Mas talvez não consiga desfazer:
a mensagem enviada;
o pagamento processado;
o cliente que recebeu informação errada;
o arquivo copiado;
a fraude executada;
o log gerado;
o segredo exposto;
o processo disparado;
a decisão humana tomada.
Em outras palavras:
Bem-vindo ao oitavo episódio de:
Hoje vamos falar da Ferrari.
Mas, na verdade, vamos falar de backup, restore, rollback, journaling, Db2, VSAM, recuperação de transações e daquela reunião pós-incidente em que alguém pergunta:
— Dá para voltar?
E toda a sala fica em silêncio.
Em tecnologia usamos várias palavras como se significassem a mesma coisa.
Backup.
Restore.
Rollback.
Recovery.
Undo.
Rebuild.
Reprocess.
Failback.
Mas não são a mesma coisa.
Cada uma atua em uma camada diferente.
Ferris descobriria isso rapidamente.
Backup é uma cópia de estado em algum momento.
Ele responde:
Isso é importante.
Mas não significa que você consegue voltar instantaneamente.
Exemplo:
00:00 BACKUP
02:00 INCIDENT
05:00 DETECTION
Se você restaurar o backup da meia-noite...
o que acontece com tudo que ocorreu entre 00:00 e 05:00?
Pedidos?
Pagamentos?
Cadastros?
Transações?
Logs?
Talvez você recupere consistência técnica destruindo realidade de negócio.
Ferrari voltou para garagem.
Mas a cidade inteira já viu o carro.
Rollback normalmente significa desfazer uma transação ou conjunto de mudanças antes da confirmação definitiva.
Em banco de dados, isso é natural.
Você inicia uma unidade de trabalho.
Faz alterações.
Algo dá errado.
Executa rollback.
O banco volta ao estado anterior daquela transação.
Perfeito.
Mas perceba:
isso funciona porque o sistema ainda possui contexto suficiente para desfazer.
Depois que uma mudança é confirmada, propagada e consumida por outros sistemas, a história complica.
Quem trabalha com transação entende.
Antes do COMMIT, o universo ainda pode ser negociado.
Depois do COMMIT...
a conversa muda.
UPDATE...
UPDATE...
UPDATE...
COMMIT
Pronto.
A transação foi assumida como válida.
Agora talvez existam:
logs;
replicações;
mensagens;
processos downstream;
auditoria;
integrações.
A quilometragem já saiu da Ferrari e entrou no ecossistema.
Essa é a essência.
Imagine:
um operador envia uma transferência errada.
Depois percebe.
Você pode corrigir o registro.
Mas o dinheiro talvez já tenha saído.
Pode restaurar a tabela.
Mas outro sistema já consumiu o evento.
Pode reverter status.
Mas cliente já recebeu e-mail.
Pode apagar arquivo.
Mas alguém já copiou.
Recuperação técnica não garante recuperação operacional.
Eles olharam apenas para o indicador:
quilometragem.
Queriam mudar um número.
Mas o evento foi maior.
O carro saiu.
Rodou.
Foi visto.
Foi usado.
Voltou.
A história existiu.
Esse é o erro clássico de sistemas:
confundir estado observável com totalidade do evento.
Um bom sistema não registra apenas o estado atual.
Registra também eventos.
Quem alterou.
Quando.
O que era antes.
O que ficou depois.
Isso é fundamental para auditoria e recuperação.
Se você só sabe o estado final, perde contexto.
Journaling existe exatamente porque operações importam.
Em vez de guardar apenas:
BALANCE = 1500
você também consegue reconstruir:
10:01 CREDIT +500
10:02 DEBIT -100
10:05 CREDIT +200
Isso muda tudo.
Você não tem apenas fotografia.
Tem filme.
No Db2, log é central para recuperação.
As alterações são registradas para permitir:
rollback;
rollforward;
recovery;
consistência.
A lógica é maravilhosa.
Banco de dados crítico não pode depender de memória humana.
Precisa saber o que aconteceu.
O princípio é simples:
registre intenção antes de assumir mudança.
Assim, em caso de falha, o sistema consegue entender o que estava acontecendo.
Isso é profundamente diferente de:
“Espero que dê tudo certo.”
Ferris aprovaria.
Imagine:
UPDATE A
UPDATE B
SYSTEM CRASH
Sem mecanismo transacional, talvez A mude e B não.
Estado inconsistente.
Com log e controle transacional, o banco pode decidir:
completar;
ou desfazer.
Atomicidade.
É o sistema dizendo:
ou tudo ou nada.
ACID é aquele conjunto de propriedades que muita gente aprende e depois esquece.
Atomicity.
Consistency.
Isolation.
Durability.
Mas na cena da Ferrari, ele ganha vida.
Ferris quer que o sistema pareça como antes.
Só que realidade já sofreu efeitos fora da transação.
ACID protege o banco.
Não protege o universo.
Nem sempre queremos voltar.
Às vezes queremos restaurar base antiga e reaplicar logs até um ponto específico.
Isso é rollforward.
Exemplo:
BACKUP 00:00
+
LOGS
+
RECOVERY UNTIL 02:14
Agora chegamos perto de um ponto anterior ao incidente.
Muito melhor que simplesmente restaurar tudo.
Mas ainda exige planejamento.
Essa é uma das ferramentas mais poderosas.
Voltar ao estado exato ou aproximado antes da corrupção.
Mas perguntas continuam:
qual momento?
Como sabemos?
Outros sistemas estavam sincronizados?
As mensagens externas foram revertidas?
A aplicação tem cache?
Existe replicação?
Recovery é ecossistema.
Imagine:
APP
↓
API
↓
DB
↓
MQ
↓
SERVICE A
↓
SERVICE B
Você restaura o banco.
Excelente.
Mas o MQ já entregou mensagens.
Service A já executou ação.
Service B já notificou outro sistema.
Agora seu estado interno voltou no tempo.
O resto do mundo não.
Parabéns.
Você acabou de inventar inconsistência distribuída.
Essa é uma bela metáfora.
Em mensageria, depois que algo é consumido, talvez você precise de evento compensatório.
Não apagar história.
Compensar.
Exemplo:
PAYMENT_SENT
Depois:
PAYMENT_REVERSAL
A primeira ação continua existindo.
A segunda corrige consequência.
Isso é muito diferente de fingir que a primeira nunca aconteceu.
Esse conceito é lindíssimo para Ferrari.
Você não consegue apagar o passeio.
Mas pode fazer uma operação posterior para reduzir impacto.
Em sistemas distribuídos, isso aparece muito.
Em vez de rollback perfeito:
compensação.
Porque o mundo real raramente é transacional ponta a ponta.
Em arquiteturas distribuídas, uma transação pode envolver várias etapas.
Se uma falha no meio, você executa ações compensatórias.
Reserve
↓
Charge
↓
Ship
↓
Notify
Se Ship falhar:
talvez precise estornar Charge.
Não “desfazer magicamente” o tempo.
Compensar.
A Ferrari volta para garagem.
Mas o pai ainda pode descobrir.
Outra verdade dolorosa.
Toda empresa diz:
“Temos backup.”
Pergunta:
Silêncio.
Backup não testado é hipótese.
Restore testado é capacidade.
Clássico.
Arquivo corrompido.
Permissão errada.
Retenção insuficiente.
Chave de criptografia perdida.
Dependência esquecida.
Versão incompatível.
Backup sem catálogo.
Você descobre no pior momento.
Ferris diria:
“Talvez devêssemos ter testado isso antes de sair com o carro.”
Organizações maduras testam recuperação.
Simulam perda.
Restauram.
Medem.
Validam.
Porque desastre real não é momento de aprender documentação.
Recovery precisa virar músculo.
Recovery Point Objective.
Pergunta:
5 minutos?
1 hora?
24 horas?
Isso define estratégia.
Ferrari:
quanto de quilometragem o pai perceberia?
Talvez RPO emocional de Cameron seja zero.
Recovery Time Objective.
Quanto tempo para voltar ao serviço?
Minutos?
Horas?
Dias?
Backup existe.
Mas restaurar demora 12 horas.
Talvez negócio não aceite.
Não de infraestrutura apenas.
TI implementa.
Negócio decide impacto aceitável.
Não adianta prometer:
RPO zero.
RTO zero.
Sem orçamento, arquitetura e testes.
Ferrari-level availability custa Ferrari-level money.
No mainframe, VSAM continua sendo parte crítica de muitos ambientes.
KSDS.
ESDS.
RRDS.
Arquivos usados em sistemas centrais.
Recuperação precisa considerar:
backup;
repro;
journaling;
CICS recovery;
logs.
Se um arquivo crítico sofre alteração indevida, simplesmente copiar backup anterior pode não ser suficiente.
CICS existe justamente para lidar com processamento transacional robusto.
Unidades de trabalho.
Syncpoint.
Recovery.
Rollback.
Quando algo falha antes da confirmação, CICS pode ajudar a manter consistência.
Isso é controle real.
Não esperança.
Até ali, ainda dá para desfazer.
Depois, a unidade de trabalho se torna permanente.
É o equivalente ao carro atravessar a porta da garagem.
Depois disso, consequências aparecem.
Outro erro clássico.
Durante incidente, alguém pensa:
“Vamos restaurar backup.”
Talvez.
Mas antes:
o atacante ainda está dentro?
a credencial ainda está válida?
o vetor foi fechado?
a persistência foi removida?
Se você restaura sem eliminar causa...
o atacante volta.
É como:
Ferrari volta para garagem.
Chave continua disponível.
Ferris continua na casa.
Excelente plano.
Quem entrou?
Quando?
O que fez?
Até onde chegou?
Quais sistemas tocou?
Quais credenciais usou?
Quais dados alterou?
Logs e journaling tornam isso possível.
Sem timeline, recovery vira chute.
Eles ajudam a reconstruir.
Mas também podem informar escopo.
Se você não sabe o que foi alterado, talvez restaure demais.
Ou de menos.
Ambos são perigosos.
Se invasor pode apagar logs, investigação fica difícil.
Por isso:
centralização;
imutabilidade;
retenção;
segregação.
A Ferrari precisava de câmera na garagem.
Imagine:
GARAGE DOOR OPEN
CAR STARTED
ODOMETER CHANGED
UNAUTHORIZED DRIVER
Alerta.
Cameron desmaia.
Filme acaba em 20 minutos.
Observabilidade reduz espaço para surpresa.
Mesmo que você restaure tudo:
SIEM guardou evento.
Sistema externo recebeu mensagem.
Banco parceiro registrou transação.
Cliente viu ação.
História distribuída permanece.
Isso é bom para investigação.
Ruim para quem queria “voltar no tempo”.
Vamos aprofundar essa frase.
Você pode desfazer tabela.
Não desfaz medo.
Pode restaurar sistema.
Não restaura confiança automaticamente.
Pode reverter acesso.
Não desaprende dado vazado.
Pode corrigir transação.
Não elimina impacto reputacional.
Essa é a diferença entre recovery técnico e recovery de negócio.
Algumas ações têm custo permanente.
Exfiltração.
Publicação.
Vazamento de chave.
Segredo exposto.
Depois que dado sai, não existe rollback real.
Você pode revogar.
Mitigar.
Trocar credencial.
Mas informação já foi vista.
Se certificado privado vaza:
rotacionar.
Revogar.
Reemitir.
Mas você precisa assumir que foi comprometido.
Não adianta apagar arquivo local e dizer:
“Pronto.”
O passado aconteceu.
Organizações restauram sistemas.
Mas também precisam lidar com:
exfiltração;
credenciais;
persistência;
pressão;
comunicação;
compliance.
Backup ajuda.
Mas não resolve tudo.
Backup combate indisponibilidade.
Não necessariamente confidencialidade ou integridade.
Muito importante.
Mas apenas uma fatia.
Você precisa também:
detecção;
segmentação;
MFA;
PAM;
logs;
resposta;
recovery.
Ferrari segurada apenas por marcha a ré é um plano fraco.
Backups críticos deveriam ser protegidos contra alteração e exclusão indevida.
Porque atacante moderno sabe que backup atrapalha.
Então tenta destruir.
Imutabilidade reduz isso.
Alguns ambientes mantêm cópias isoladas.
Físicas ou lógicas.
Objetivo:
se produção for comprometida, backup não cai junto.
É colocar uma Ferrari reserva em outro prédio.
Isso é frequentemente esquecido.
Quem controla backup controla recovery.
Se a mesma conta administrativa domina:
produção;
logs;
backup;
então comprometimento único pode destruir tudo.
Segregação novamente.
Mainframe ganhou reputação de confiabilidade não por magia.
Mas por décadas de disciplina operacional.
Journaling.
Logs.
Checkpoint.
Restart.
Backup.
Recovery.
Transação.
Tudo isso nasceu porque processamento crítico não tolera improviso.
Nem tudo é online.
Imagine batch longo.
Falha no passo 47.
Você vai reprocessar desde o início?
Talvez não.
Checkpoint/restart existe para reduzir isso.
Mas depende de desenho.
Aplicação batch deveria saber recomeçar de ponto consistente.
Caso contrário, reexecutar pode duplicar:
pagamentos;
registros;
mensagens.
Ferris daria marcha a ré e depois descobriria que rodou a quilometragem duas vezes.
Uma operação idempotente pode ser repetida sem mudar resultado além da primeira execução.
Isso é ouro em recovery.
Porque retries acontecem.
Se repetir pagamento gera outro pagamento, temos problema.
Outra confusão.
Retry tenta de novo.
Rollback desfaz.
Restore recupera estado.
Cada um tem papel.
Misturar esses conceitos cria incidentes novos durante recuperação.
Todo mundo sob pressão.
Diretor ligando.
Clientes afetados.
Equipe cansada.
Aí alguém sugere:
“Vamos executar esse script que achei.”
Ferris sorri.
Recovery precisa de runbook.
Passos definidos.
Critérios.
Dependências.
Quem aprova.
Como validar.
Como voltar.
Isso reduz improvisação.
Documentação pode estar errada.
Sistema mudou.
Pessoa saiu.
Senha expirou.
Ferramenta foi atualizada.
Drill encontra isso antes do desastre.
Numa War Room:
Não:
“tem procedimento.”
Pergunta:
“já funcionou?”
Sem isso, point-in-time recovery vira adivinhação.
Essa pergunta muda resposta.
Se sim, você só resetou o tabuleiro.
Camadas:
Backup
↓
Logs
↓
Recovery Procedure
↓
Validation
↓
Security Fix
↓
Monitoring
Uma falha não deve destruir tudo.
A beleza da cena é que o plano de marcha a ré não apenas falha conceitualmente.
A situação piora dramaticamente.
É quase uma alegoria perfeita de recovery improvisado.
Você tenta corrigir incidente.
Cria outro.
Quem nunca?
Clássico.
Script emergencial.
Configuração errada.
Restore incompleto.
Rollback impossível.
O remédio cria novo problema.
Isso é por que mudança durante incidente precisa de controle.
Urgência não elimina risco.
Pode simplificar processo.
Mas não significa:
faça qualquer coisa.
Mudanças emergenciais também precisam de:
registro;
aprovação;
plano de retorno;
validação.
Essa frase é fundamental.
Não depois.
Antes.
Toda mudança deveria perguntar:
se falhar, como voltamos?
Se resposta for:
“depois vemos”,
você acabou de criar dívida operacional.
Segurança detecta.
Operações recupera.
DBA restaura.
Aplicação valida.
Negócio confirma.
Incidente atravessa times.
Recovery é colaborativo.
Infra diz:
servidor está online.
DBA:
banco está consistente.
Aplicação:
serviço responde.
Negócio:
clientes ainda estão vendo saldo errado.
Então não recuperou.
Não basta “verde no dashboard”.
Precisamos validar:
integridade;
completude;
reconciliação;
transações;
acessos;
segurança.
Ferrari dentro da garagem não basta.
Precisamos saber se o pai percebeu.
Especialmente em sistemas financeiros.
Comparar:
origem;
destino;
totais;
contagens;
valores.
Isso encontra discrepâncias depois de recuperação.
Em sistemas empresariais, vários componentes interagem.
Db2 atualiza.
CICS coordena.
MQ envia.
Recuperação precisa respeitar consistência entre componentes.
Não adianta um voltar para 10h e outro ficar em 10h30.
Esse é um problema real.
Quando múltiplos sistemas têm backups em horários diferentes, restore pode criar mundos paralelos.
Sistema A pensa que evento aconteceu.
Sistema B não.
Agora nasce reconciliação dolorosa.
Hoje fala-se muito em cyber recovery.
Não apenas recuperar hardware.
Recuperar de ataque.
Isso exige:
ambiente limpo;
cópias confiáveis;
validação;
isolamento;
credenciais novas;
forense.
É muito mais amplo.
Em certos cenários, você recupera num ambiente isolado.
Valida antes de reconectar.
Porque não quer restaurar malware junto.
Ferrari passa por inspeção antes de voltar para garagem.
Se comprometimento aconteceu semanas antes e você não percebeu, backup pode conter persistência.
Então:
qual ponto é realmente limpo?
Logs ajudam.
Forense ajuda.
Não é trivial.
Quanto mais tempo atacante fica sem ser detectado, mais difícil saber onde voltar.
Incidente identificado em 5 minutos?
Ótimo.
Depois de 60 dias?
Boa sorte.
Mean Time To Detect interfere em recuperação.
Se você demora para detectar corrupção, pode ter backups já contaminados.
Detecção não é só segurança.
É recovery.
Se Cameron tivesse registro claro de:
quem tirou;
quando;
quanto rodou;
onde;
talvez não tentasse resolver com marcha a ré.
Informação reduz pânico.
Em incidente, a primeira vontade é voltar.
Mas recovery precipitado pode destruir evidência.
Antes de apagar:
preserve.
Colete.
Registre.
Depois recupere.
Forense e operação precisam equilibrar.
Imagem de disco.
Logs.
Memória quando necessário.
Eventos.
Artefatos.
Porque depois do restore talvez você perca pistas.
Ferrari lavada demais perde impressão digital.
Em incidentes graves, evidência pode ter valor jurídico.
Quem coletou?
Quando?
Como preservou?
Integridade.
Mais uma vez: história importa.
Sistemas podem voltar.
Pessoas lembram.
Clientes lembram.
Auditores lembram.
Reguladores lembram.
Diretores lembram.
É por isso que incidentes têm efeitos duradouros.
A quilometragem era um indicador.
O verdadeiro problema era:
Cameron havia quebrado confiança com o pai.
Não existe rollback técnico para isso.
A cena é genial justamente porque mostra limite da reversibilidade.
Depois de vazamento:
usuários mudam comportamento.
Clientes questionam.
Parceiros exigem garantias.
Você pode restaurar sistema em duas horas.
Reputação pode levar anos.
Esse é o Ctrl+Z emocional que não existe.
Essa é talvez a conclusão mais madura.
Recovery não é viagem temporal.
É construir um estado novo e confiável depois de algo ruim.
Você não apaga incidente.
Você aprende.
Corrige.
Recupera.
Monitora.
Segue.
Pense:
NORMAL
↓
INCIDENT
↓
CONTAINMENT
↓
RECOVERY
↓
NEW TRUSTED STATE
Não voltamos exatamente ao começo.
Voltamos melhores.
Ou deveríamos.
Quando alguém disser:
— Dá para dar rollback?
Pergunte:
Do banco?
Do arquivo?
Da aplicação?
Do pagamento?
Da mensagem?
Da confiança?
Do vazamento?
Essa pergunta salva reuniões.
A Ferrari anda para frente.
Depois anda para trás.
Mas a estrada continua existindo.
Esse é o ponto.
Sistemas guardam estado.
Negócios acumulam consequências.
Pessoas acumulam memória.
Red Team precisa pensar nisso porque ataque não termina no acesso inicial.
Importa também:
o que pode ser revertido;
o que pode ser restaurado;
o que pode ser compensado;
o que é irreversível.
Backup é essencial.
Restore é capacidade.
Rollback é mecanismo.
Journaling é memória.
Logs são história.
Recovery é processo.
E resposta a incidente é o momento em que tudo isso precisa funcionar junto.
Então, da próxima vez que alguém sugerir:
“É só voltar.”
Coloque a xícara na mesa.
Olhe para a equipe.
E responda:
Porque às vezes você consegue colocar a Ferrari em marcha a ré.
Mas não consegue fazer o mundo esquecer que ela saiu da garagem.
☕ SAVE FERRIS.
No próximo artigo:
Porque depois de errar o rollback...
nada melhor do que deixar o defensor destruir o ambiente tentando provar que estava certo.
☕ Um Café no Bellacosa Mainframe — Especial Red Team
Uma série de 12 artigos sobre Red Team, segurança ofensiva, engenharia social, OSINT, integridade de dados, MFA, PAM, rollback, Blue Team, inteligência artificial, RACF e z/OS, usando Ferris Bueller para explorar uma pergunta fundamental: o sistema está realmente seguro ou apenas acredita que está?
Reconhecimento, criatividade adversarial e a ideia de que o verdadeiro alvo nem sempre é a tecnologia: são as suposições de quem construiu o sistema.
Integridade de dados, alteração de registros, privilégio, auditoria e a perigosa diferença entre aquilo que aconteceu e aquilo que o banco de dados afirma ter acontecido.
Pretexting, autoridade inventada e confiança contextual: Identity, Authentication e Authorization não são a mesma coisa.
Como dados públicos sobre pessoas, tecnologias, hábitos, empresas e relacionamentos podem revelar uma superfície de ataque antes do primeiro scan.
Ferris → Cameron → telefone → escola → funcionário → sistema. Nenhuma peça precisa falhar sozinha quando a cadeia inteira possui uma combinação explorável de confiança.
Firewall, SIEM, EDR e Zero Trust podem funcionar perfeitamente enquanto engenharia social, Help Desk e processos humanos criam outro caminho até o objetivo.
Privilégio, acesso físico, MFA, PAM, least privilege e o risco de proteger um ativo crítico apenas com medo, confiança e a esperança de que ninguém ousará tocá-lo.
Rollback, restore, journaling, logs, Db2, VSAM e recuperação: voltar o estado de um sistema não significa apagar as consequências daquilo que aconteceu.
Confirmation Bias, tunnel vision, Sunk Cost, Authority Gradient e o risco de uma resposta defensiva criar mais impacto que o próprio atacante.
IA generativa, agentes, OSINT automatizado, deepfake, voice cloning e automação transformam o ataque artesanal em uma capacidade paralela e escalável.
RACF, SAF, ACEE, APF, USS, TSO, CICS, Db2, MQ, z/OS Connect, Zowe e service accounts vistos pela ótica dos caminhos de ataque até o mainframe.
Red Team não termina em “conseguimos entrar”. Ataque deve gerar descoberta, evidência, correção, detecção e aprendizado para deixar a organização mais resiliente.
Ferris Bueller’s Red Team: Como Hackear o Sistema Sem Precisar Roubar a Ferrari do Cameron reúne os doze episódios e conecta Red Team, engenharia social, IA, Blue Team e segurança de mainframe.
☕ Acessar o especial completo SAVE FERRISA série SAVE FERRIS, publicada no Bellacosa Mainframe, utiliza situações inspiradas em Ferris Bueller para explicar conceitos de Red Team, cybersecurity, segurança ofensiva, engenharia social, OSINT, Blue Team, Purple Team, Zero Trust, MFA, PAM, inteligência artificial, RACF, IBM z/OS, CICS, Db2, MQ e segurança de mainframe.
O fio condutor é simples: um atacante não precisa necessariamente quebrar a tecnologia. Ele pode explorar relações de confiança, processos, identidades, privilégios, integrações e suposições existentes entre pessoas e sistemas.
A temporada acompanha o ciclo completo: reconhecimento → engenharia social → acesso → privilégio → impacto → detecção → correção → aprendizado.
Para Red Teams e Blue Teams, o objetivo final não é provar quem é mais inteligente, mas encontrar caminhos invisíveis antes que um adversário real os descubra.
Gostou deste artigo? 💡💡💡 Conecte-se comigo no LinkedIn e acompanhe conteúdos exclusivos sobre IBM Z, COBOL, Arquitetura, IA, Modernização e Engenharia de Software.
👨💻 Perfil no LinkedIn 📚 Assinar "Aprenda mais no Bellacosa Mainframe" ☕ Acompanhar "Um Café no Bellacosa Mainframe"IBM Champion 2026 • Especialista em IBM Mainframe
Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.