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
ao estilo bellacosa mainframe, para o El Jefe Midnight Lunch
Meu quarto ano de volta ao Brasil foi 2017. Se 2016 tinha sido recovery mode, 2017 foi aquele estágio pior: o sistema sobe, os serviços respondem, mas o usuário já não confia no resultado. Tudo funciona “mais ou menos”. E em sistemas críticos — e em países — “mais ou menos” é sinônimo de risco permanente.
Depois de doze anos na Europa, eu já não era mais um recém-chegado. Em 2017, eu já estava totalmente reabsorvido pelo ambiente. Já entendia os atalhos, os silêncios, os códigos não escritos. E talvez por isso o descalabro tenha doído mais.
A economia de 2017 não era de retomada — era de rastros. Pequenos sinais aqui e ali, estatísticas otimistas demais para quem vivia o chão da fábrica, do comércio, do escritório esvaziado. Era como ver logs dizendo “process completed successfully” enquanto o arquivo final vinha corrompido.
Empregos voltavam? Sim — mas piores, mais precários, mais frágeis. O discurso oficial falava em modernização, eficiência, flexibilidade. Para quem viveu na Europa, o contraste era brutal: lá, flexibilidade vem acompanhada de proteção. Aqui, vinha acompanhada de silêncio.
Mudanças na lei laboral foram apresentadas como upgrade. Na prática, muita gente sentiu como downgrade. Menos direitos, mais insegurança, menos previsibilidade. O sistema ficou “mais leve” porque descarregou peso no usuário final.
As discussões sobre previdência em 2017 escancararam algo profundo: o futuro deixou de ser garantido. Para quem trabalhou anos fora, contribuindo religiosamente, aquilo soava como heresia sistêmica. Previdência, na Europa, é contrato de longo prazo. No Brasil, virou feature flag: pode existir hoje, pode não existir amanhã.
O cidadão comum entendeu rápido a mensagem implícita: cuide-se sozinho. O sistema não promete mais nada. Isso muda comportamento, cultura, mentalidade. Quando o futuro fica nebuloso, o presente vira campo de batalha.
Em 2017, o cansaço deixou de ser individual e virou coletivo. Não era mais indignação, era exaustão. As pessoas não estavam menos informadas — estavam saturadas. Escândalos sucessivos, crises sobrepostas, versões conflitantes da realidade.
Era como operar um sistema que dispara alertas o tempo todo. No começo você corre. Depois você silencia alarmes. E quando silencia demais, o desastre passa despercebido.
A confiança institucional estava abaixo do mínimo operacional. Ninguém acreditava totalmente em ninguém. A política virou ruído de fundo, como um fan barulhento que você aprende a ignorar — até o dia em que ele para e tudo esquenta de vez.
É nesse vácuo que extremos prosperam. Em 2017, vi com clareza o avanço da extrema direita no Brasil. Não como caricatura, mas como sintoma. Para quem viveu na Europa, o padrão era conhecido: medo, insegurança, ressentimento, nostalgia de um passado idealizado que nunca existiu.
Quando o sistema parece injusto, alguém sempre promete apertar RESET à força. Pouca gente pergunta o que se perde nesse processo.
A cultura do diálogo foi substituída pela cultura do confronto. Complexidade virou fraqueza. Dúvida virou traição. Tudo precisava ser rápido, simples, binário. True ou false. Sem maybe.
No plano local, a decepção foi concreta. A expectativa criada em torno do prefeito de Itatiba se dissolveu rápido. Promessas não cumpridas, gestão confusa, distância da população. Para quem tinha participado do processo político em 2016, aquilo foi especialmente frustrante.
Política municipal é onde o cidadão espera ver resultado rápido. Quando falha ali, a descrença se multiplica. O sentimento era claro: se nem no município as coisas funcionam, por que funcionariam em Brasília?
Foi mais uma lição dura de mainframe: problema sistêmico não se resolve trocando apenas o operador do turno.
O povo em 2017 seguia sobrevivendo — mas já não acreditava. A esperança virou cautela. O planejamento virou curto prazo. A pergunta deixou de ser “como melhorar?” e passou a ser “como aguentar?”.
Vi gente boa desistindo de participar, desistindo de discutir, desistindo de sonhar. E isso é talvez o dano mais grave que um sistema pode causar: quando o usuário perde o desejo de interagir.
Em 2017, eu já não romantizava mais nada. Nem o Brasil, nem a Europa. Entendi que tinha voltado para um país em transição permanente, preso entre um passado mal resolvido e um futuro mal explicado.
O sistema seguia ligado, sim. Mas com remendos, exceções, workarounds perigosos. E operadores cada vez mais ideológicos, menos técnicos.
2017 ensinou uma verdade incômoda de qualquer ambiente crítico:
quando o sistema falha por muito tempo, o problema deixa de ser técnico e passa a ser humano.
O Brasil de 2017 não estava só quebrado economicamente.
Estava cansado.
Desconfiado.
E perigosamente aberto a soluções simples para problemas complexos.
E todo veterano de mainframe sabe:
é exatamente nesse momento que mais se precisa de calma, método e responsabilidade —
porque qualquer comando errado, executado com raiva,
pode derrubar tudo de vez.
| Bellacosa Mainframe e a viagem sem visibilidade na SP 065 |
| Bellacosa Mainframe apresenta Houseki no Kuni |
"O maior bug não é um ABEND. É esquecer quem você era antes da última alteração."
宝石の国 (Houseki no Kuni)
Título internacional
Land of the Lustrous
Autora
Haruko Ichikawa (市川春子) (Houseki no Kuni)
Mangá
Publicação: 25 de outubro de 2012
Conclusão: 25 de abril de 2024
Revista: Monthly Afternoon
Editora: Kodansha
Total: 13 volumes
Demografia: Seinen (Wikipedia)
Anime
Diretor: Takahiko Kyōgoku
Roteiro: Toshiya Ōno
Estúdio: Orange
Exibição:
7 de outubro de 2017
23 de dezembro de 2017
Episódios: 12 (Houseki no Kuni)
Gêneros
Fantasia
Ação
Drama
Mistério
Pós-apocalíptico
Filosófico
Psicológico
Seinen (Houseki no Kuni)
Milhares de anos após o desaparecimento da humanidade, a Terra tornou-se um planeta silencioso.
Não existem cidades.
Não existem países.
Não existem computadores.
Não existem seres humanos.
Apenas uma pequena comunidade de seres cristalinos conhecidos como Gemas, liderados pelo misterioso Kongō Sensei.
Enquanto isso, criaturas vindas da Lua — os Lunarians — descem constantemente para capturar essas gemas e transformá-las em joias ornamentais.
No centro da história está Phosphophyllite (Phos), a gema mais frágil de todas.
Sua dureza é apenas 3,5 na escala de Mohs.
Ela não serve para lutar.
Não serve para patrulhar.
Não serve para mineração.
Não serve para praticamente nada.
E justamente por isso inicia uma jornada que mudará completamente aquele mundo.
Se existe um estúdio que mudou a opinião do público sobre CGI em anime, esse estúdio é o Orange.
Antes de Houseki no Kuni, CGI em anime normalmente era associado a:
movimentos robóticos;
personagens artificiais;
expressões limitadas.
Orange fez exatamente o contrário.
Criou:
cabelos translúcidos;
reflexos cristalinos;
iluminação física;
animação extremamente fluida.
Até hoje muitos consideram Houseki no Kuni um dos melhores exemplos de CGI para televisão. A recepção entre fãs frequentemente destaca justamente como o 3D foi usado para valorizar a obra, e não apenas reduzir custos. (Reddit)
Praticamente tudo.
Não existem humanos.
Não existe romance.
Não existe fanservice.
Não existe protagonista overpower.
Não existe "escolhido".
Não existe bem contra mal.
O conflito é muito mais profundo.
A guerra é psicológica.
Filosófica.
Existencial.
Imagine um registro VSAM.
Durante anos você altera alguns campos.
Depois substitui metade do registro.
Depois muda toda a chave.
Depois altera o layout.
Depois converte EBCDIC para Unicode.
Depois muda a plataforma.
Depois muda o banco.
Ainda é o mesmo programa?
Essa pergunta é exatamente o coração de Houseki no Kuni.
Toda a evolução de Phos gira em torno de uma questão filosófica clássica:
Se substituímos todas as partes de um objeto...
ele continua sendo o mesmo objeto?
Phos perde:
braços;
pernas;
cabeça;
memória;
personalidade;
lembranças.
Cada nova peça muda quem ela é.
No final o espectador começa a perguntar:
"Ainda é Phos?"
Inicialmente parece uma aventura simples.
As Gemas patrulham a ilha.
Os Lunarians aparecem.
Há batalhas.
Mas pouco a pouco tudo muda.
Phos começa a descobrir segredos.
Descobre que ninguém conhece realmente a origem daquele mundo.
Nem mesmo Kongō.
Cada revelação desmonta tudo aquilo que parecia verdade.
O anime termina justamente quando o mangá entra em sua fase mais transformadora, adaptando aproximadamente os 36 primeiros capítulos. (Houseki no Kuni)
A protagonista.
Frágil.
Ingênua.
Curiosa.
É provavelmente uma das maiores evoluções psicológicas já vistas em um mangá.
Uma gema isolada.
Seu corpo produz mercúrio venenoso.
É condenada à solidão.
Representa depressão.
Abandono.
Aceitação.
Bondosa.
Gentil.
Busca provar seu valor.
Vive constantemente à sombra da força de Bort.
A gema mais resistente.
Fria.
Precisa.
Quase perfeita.
Existe apenas durante o inverno.
Quando chega a primavera...
desaparece.
Uma das personagens mais marcantes da série.
Talvez o maior mistério da obra.
Professor.
Monge.
Pai.
Máquina?
Nenhuma definição parece suficiente.
Embora existam batalhas espetaculares, Houseki no Kuni não é um anime de combate.
Cada arco representa uma transformação de Phos.
Não se trata de derrotar um inimigo.
Trata-se de perder uma parte de si.
É uma aventura de autodescoberta.
Aqui está a verdadeira riqueza da obra.
Toda a estrutura do mundo remete ao budismo.
Os três grupos de seres representam diferentes estados da existência.
O sofrimento é inevitável.
O apego causa dor.
A libertação depende do desapego.
Quem somos?
Nosso corpo?
Nossa memória?
Nossas lembranças?
Nossa consciência?
Houseki no Kuni nunca entrega uma resposta definitiva.
Phos começa sendo considerada inútil.
Justamente sua fragilidade permite enxergar o mundo de uma forma diferente.
Toda evolução possui um preço.
Toda melhoria exige perdas.
Não existe upgrade gratuito.
Agora imagine que Phos seja um sistema legado.
Primeiro fazem um pequeno PATCH.
Depois trocam um módulo.
Depois convertem arquivos.
Depois trocam banco.
Depois fazem API REST.
Depois Docker.
Depois Cloud.
Depois IA.
Depois Microservices.
Depois Kubernetes.
Depois OpenShift.
Depois z/OS Connect.
Depois reescrevem metade.
A pergunta continua:
Ainda é o mesmo sistema COBOL?
Houseki no Kuni fala exatamente disso.
No Japão, a obra consolidou Haruko Ichikawa como uma das autoras mais originais de sua geração. Internacionalmente, o anime ganhou reputação por provar que CGI de alta qualidade pode servir à narrativa quando há direção artística consistente. Entre os fãs, é frequentemente lembrado como uma "joia escondida" e muitos ainda aguardam uma continuação animada. (Houseki no Kuni)
Não houve uma campanha de censura significativa.
Apesar de abordar:
identidade;
religião;
sofrimento;
violência psicológica;
o anime foi exibido normalmente.
O que ocorreu foi uma adaptação relativamente fiel do mangá, encerrando antes dos arcos mais sombrios e filosóficos.
A obra completa possui:
13 volumes
história totalmente concluída
muito mais profunda que o anime
O mangá desenvolve praticamente todos os grandes mistérios deixados em aberto na animação. (Houseki no Kuni)
Não existe uma light novel oficial.
Houseki no Kuni nasceu como mangá original de Haruko Ichikawa e sua principal adaptação é o anime. (Houseki no Kuni)
Também não existe um grande jogo oficial para consoles ou PC baseado na franquia. Há apenas colaborações, produtos promocionais e conteúdo criado por fãs ao longo dos anos, mas nenhum RPG ou jogo oficial de grande porte.
As características físicas das Gemas são inspiradas em propriedades mineralógicas reais.
A dureza de cada personagem influencia diretamente sua função em combate.
Os cabelos translúcidos se tornaram uma assinatura visual da série.
O anime foi um marco técnico para a animação 3D japonesa.
A transformação de Phos é frequentemente comparada ao Paradoxo do Navio de Teseu, discutindo se algo continua sendo o mesmo após todas as suas partes serem substituídas. (Houseki no Kuni)
Se The Promised Neverland faz você questionar a moralidade, Houseki no Kuni faz você questionar a própria identidade.
Não é uma história sobre pedras preciosas.
É uma história sobre memória.
Sobre evolução.
Sobre perda.
Sobre aceitar que crescer significa deixar versões antigas de nós para trás.
Para um programador COBOL, a metáfora é irresistível: um sistema corporativo pode atravessar décadas recebendo correções, novos módulos, APIs, bancos de dados, interfaces web e integrações com IA. Em algum momento, quase nada do código original permanece. Ainda assim, os negócios continuam chamando aquele sistema pelo mesmo nome. Houseki no Kuni transforma essa mesma pergunta — "o que ainda permanece igual?" — em uma obra-prima filosófica disfarçada de fantasia cristalina. É um anime raro, contemplativo e profundamente memorável.
| Bellacosa Mainframe e o final do red team |
Depois de onze artigos, alguma coisa mudou.
Começamos com Ferris Bueller olhando para regras e percebendo que regras também têm buracos.
Passamos por registros escolares.
Abe Froman.
Cameron.
Telefone.
Engenharia social.
Swiss Cheese.
Ferrari.
MFA.
PAM.
Rollback.
Backup.
Rooney enlouquecendo atrás de sua própria hipótese.
IA generativa.
Agentes.
Deepfake.
Mainframe.
RACF.
z/OS.
APIs.
Service accounts.
E, em algum ponto dessa bagunça maravilhosa, ficou claro que Red Team nunca foi apenas sobre invasão.
Nunca foi apenas sobre “entrar”.
Nunca foi sobre imprimir root na tela e comemorar como se tivéssemos acabado de derrotar a Estrela da Morte.
Red Team, quando bem feito, é outra coisa.
É uma forma organizada de criar desconforto antes que o mundo real crie algo muito pior.
É um espelho adversarial.
É colocar a organização diante de perguntas que ninguém quer ouvir.
E então observar.
Por isso este último episódio não termina com explosão.
Termina com silêncio.
O dia acabou.
Ferris voltou para casa.
Rooney perdeu a batalha.
Cameron ficou olhando para a Ferrari.
O sistema continuou rodando.
E agora precisamos responder:
Bem-vindo ao último episódio de:
Existe uma tentação.
Uma tentação enorme.
O Red Team consegue acesso.
Escala privilégio.
Atinge objetivo.
E alguém pensa:
Pronto.
Fim.
Não.
Esse é o começo.
Se o resultado de um Red Team é apenas demonstrar que alguém é inteligente, o exercício falhou.
Talvez tenha sido tecnicamente interessante.
Talvez tenha sido divertido.
Mas o valor organizacional é pequeno.
Porque o objetivo real não é provar que o atacante é esperto.
É descobrir:
o que a organização não sabia sobre si mesma.
Isso muda tudo.
O exploit é meio.
A evidência é meio.
A técnica é meio.
O conhecimento novo é o produto.
Imagine:
Ataque
↓
Descoberta
↓
Evidência
↓
Correção
↓
Detecção
↓
Aprendizado
Isso é Red Team maduro.
Se Ferris conseguiu entrar, excelente.
Agora pergunte:
como?
Por qual caminho?
Qual controle não funcionou?
Qual controle nem existia?
Qual suposição estava errada?
Quem deveria ter percebido?
Quem percebeu e ignorou?
Quanto tempo levou?
Que evidência ficou?
Que privilégio permitiu avançar?
Essa investigação é muito mais importante que a entrada.
Uma operação Red Team deveria produzir um momento desconfortável.
Aquele em que alguém olha para um diagrama e diz:
— Espera.
— Isso é possível?
E alguém responde:
— Sim.
Esse é o valor.
Não humilhar.
Iluminar.
“Essa rede é isolada.”
“Esse usuário não tem acesso.”
“Esse sistema não está exposto.”
“Esse backup funciona.”
“Esse alerta sempre dispara.”
“Essa conta só é usada por aplicação.”
“Esse fornecedor não consegue chegar lá.”
“Esse endpoint não fala com produção.”
Red Team pega cada frase e pergunta:
Esse talvez seja o tema central da série inteira.
Arquitetura desenha caixas.
Atacante segue setas.
A empresa vê:
USER
APP
DB
MAINFRAME
Ferris vê:
Pessoa
↓
Confiança
↓
Credencial
↓
API
↓
Service Account
↓
Mainframe
O risco não está apenas nos objetos.
Está nas relações.
Você já sabe que senha fraca é ruim.
Já sabe que MFA ajuda.
Já sabe que least privilege importa.
O Red Team fica valioso quando encontra algo que ninguém tinha modelado.
Por exemplo:
uma dependência esquecida.
Um usuário privilegiado por herança.
Uma API que transforma identidade humana em conta genérica.
Um fornecedor que ainda possui acesso.
Um processo de Help Desk que contorna MFA.
Esse é o ouro.
Queremos falhas sistêmicas.
Uma vulnerabilidade é:
“este componente tem problema.”
Uma falha sistêmica é:
“essas cinco coisas juntas criam um caminho.”
E isso é muito mais interessante.
Durante toda a série, o queijo suíço apareceu.
Não por acaso.
Red Team vive de alinhamento.
Uma falha pequena.
Outra pequena.
Mais uma.
E pronto.
OSINT
↓
Pretexto
↓
Reset
↓
Conta
↓
Privilégio
↓
Sistema
Nenhum buraco sozinho era suficiente.
Juntos, eram.
Isso também é importante.
Red Team não existe para derrotar Blue Team.
Essa rivalidade pode ser divertida em exercício.
Mas é pedagogicamente pobre quando vira cultura.
Se Red ganha e Blue aprende, organização ganhou.
Se Blue detecta Red cedo e Red aprende como foi detectado, organização ganhou.
O objetivo não é troféu.
É aprendizado.
Quando Red e Blue compartilham conhecimento, o valor sobe.
Red mostra:
“entrei por aqui.”
Blue responde:
“não vimos.”
Engineering corrige.
Depois repete.
Isso é evolução.
Corrigir sem retestar é esperança.
Você fecha vulnerabilidade.
Ótimo.
Red tenta de novo.
Funcionou?
Se sim, evidência.
Se não, continue.
Isso é perigoso.
Executar checklist.
Gerar relatório.
Arquivar PDF.
Nada muda.
Pronto.
Red Team virou teatro.
O exercício só tem valor se produzir mudança.
Relatório deveria responder:
o que aconteceu?
por que aconteceu?
qual impacto?
qual evidência?
como corrigir?
como detectar?
como evitar repetição?
Esse último ponto importa.
Não:
“poderia haver risco.”
Mas:
“este caminho permitiu chegar até aqui.”
Evidence-based.
Captura.
Logs.
Timeline.
Com clareza.
Uma falha pode existir e não ser explorável.
Pode ser explorável e ter baixo impacto.
Pode parecer pequena e abrir caminho gigantesco.
Red Team ajuda a contextualizar.
Por isso objetivo importa.
Não “escaneie portas”.
Mas:
“consiga acessar dado crítico.”
Agora o time precisa pensar como adversário.
Ferris não quer CVE.
Quer resultado.
Depois de todo caos:
Essa pergunta transforma ataque em engenharia.
Pode ser patch.
Configuração.
MFA.
Segmentation.
PAM.
Fine.
Help Desk.
Mudança.
Aprovação.
Offboarding.
Incident Response.
Também válido.
Autoridade excessiva.
Urgência.
Medo de questionar.
“Depois regularizamos.”
Talvez essa seja a raiz.
Esse é um ponto essencial.
Não apenas IT.
Segurança.
RH.
Fornecedores.
Gestores.
Processos.
Ferris explorou tudo isso.
Tinha:
diretor;
regras;
registro;
tecnologia;
pessoas;
processos.
Era perfeita para mostrar que superfície de ataque não é apenas digital.
E mais conectada.
E mais rápida.
E mais complexa.
Então risco cresce.
Quanto mais sistemas.
Mais integrações.
Mais contas.
Mais exceções.
Mais difícil compreender tudo.
Red Team encontra caminhos que ninguém desenhou.
Relações não documentadas.
Scripts antigos.
Contas herdadas.
Integrações temporárias.
Esses caminhos são perigosos.
Conhecer o que existe.
Inventário.
Exposição.
Relações.
Sem isso, você protege o que conhece.
E Ferris usa o que esqueceu.
Essa é uma verdade dolorosa.
Hoje arquitetura está certa.
Amanhã alguém cria uma API.
Depois um pipeline.
Depois uma integração.
Depois uma exceção.
Se Red Team roda uma vez por ano, pode testar fotografia antiga.
Threat modeling.
Testing.
Validation.
Monitoring.
Não precisa ser ataque completo toda semana.
Mas precisa existir loop.
Essa parte às vezes é ignorada.
O atacante simulado também pode errar.
Criar hipótese ruim.
Focar demais numa técnica.
Perder caminho.
Red Team precisa revisar suas próprias decisões.
Rooney pode existir do lado vermelho também.
“Esse sistema deve estar vulnerável.”
Talvez não.
Se você insiste só porque quer achar algo, perde credibilidade.
O objetivo é verdade.
Não vitória.
Se controle funcionou:
registre.
Respeite.
Não force artificialmente só para “ganhar”.
Porque exercício deve refletir risco real.
Tudo precisa de escopo.
Autorização.
Limites.
Horários.
Critérios.
Red Team sem governança é risco.
Ferris pode improvisar.
Profissional não.
Ferris quer sair da escola.
Red Team quer melhorar a escola.
Essa é uma boa síntese.
Precisamos:
documentar caminho;
corrigir;
criar detecção;
retirar privilégio;
melhorar processo.
Senão Ferris volta amanhã.
Você pode não impedir tudo.
Então precisa ver.
Se exploit funciona mas Blue detecta em 30 segundos, resposta é muito diferente.
Red Team deve testar detectabilidade.
Quanto tempo?
Segundos?
Minutos?
Horas?
Dias?
Esse número importa.
Depois de detectar, quanto tempo para conter?
Detectar sem agir também falha.
Transformar achado em regra.
Query.
Correlation.
Behavior.
Isso fecha ciclo.
Red executa novamente.
Blue vê?
Excelente.
Aprendizado virou capacidade.
E surpresa em produção raramente é divertida.
No artigo anterior, vimos que z/OS pode ser extremamente seguro e ainda estar ligado a dezenas de sistemas.
Essa é a síntese perfeita.
Red Team moderno não pode tratar mainframe como ilha.
Precisa testar caminho.
E ainda assim o contexto anterior estar comprometido.
Isso é o que aprendemos.
Essa frase também merece parede.
Componente seguro dentro de sistema inseguro continua exposto.
MQ é confiança.
Pipeline é confiança.
IAM é confiança.
Tudo precisa ser validado.
A Ferrari estava segura porque ninguém ousava tocar.
Até tocar.
O mesmo vale para produção.
“ninguém mexe nisso” não é controle.
MFA.
PAM.
Logs.
Segregação.
Approval.
Essas coisas não dependem apenas de boa vontade.
Também aprendemos:
você pode corrigir estado.
Não necessariamente consequência.
Por isso resposta importa.
É:
detectar;
conter;
recuperar;
aprender.
Talvez seja uma das maiores lições.
O defensor também pode ser vulnerabilidade.
Viés.
Ego.
Pressão.
Autoridade.
Security culture precisa proteger decisão.
Pessoas.
Processos.
Informações.
Decisões.
Tudo pode falhar.
Uma ideia poderosa.
Teste não apenas tecnologia.
Teste como equipe reage.
Ambiguidade.
Pressão.
Sinais conflitantes.
Isso aumenta maturidade.
IA trouxe escala.
Mas não mudou fundamentos.
Identity.
Authorization.
Privilege.
Trust.
Context.
Logs.
Mesma história.
Talvez essa seja a frase da temporada.
Mudamos interface.
Mantivemos vulnerabilidades humanas.
Mainframe continua.
Cloud cresce.
IA entra.
Tudo coexistindo.
Superfície de ataque vira camada sobre camada.
Aqui chegamos à frase final.
No filme, Ferris fala sobre vida.
Sobre parar.
Observar.
Porque passa rápido.
Em tecnologia, acontece algo parecido.
Sistema muda.
Versão muda.
Pessoas mudam.
Arquitetura muda.
Fornecedores mudam.
Privilégios acumulam.
APIs surgem.
Agentes entram.
Se você não parar para olhar...
pode perder o mapa.
Isso é simples.
Mas organizações continuam operando com threat model antigo.
“Esse sistema nunca foi exposto.”
Agora tem API.
“Esse usuário não acessa produção.”
Agora está em grupo novo.
“Essa aplicação não fala com cloud.”
Agora fala.
Mudança cria risco.
Inventário contínuo.
Mapeamento.
Revisão.
Porque o desconhecido cresce.
Esse é todo propósito.
Red Team compra aprendizado com risco controlado.
Melhor descobrir falha numa simulação do que num incidente.
Gostei dessa definição.
Você cria pressão controlada.
Dentro de regras.
Para revelar comportamento real.
É quase Chaos Engineering de segurança.
Se todos sabem exatamente o script, teste perde realismo.
Ainda assim precisa segurança.
Equilíbrio.
Sucesso é:
algo mudou.
Controle melhorou.
Alerta nasceu.
Privilégio caiu.
Processo foi corrigido.
Pessoas aprenderam.
Isso é sucesso.
Em vez de:
“Quantos sistemas comprometemos?”
Talvez:
quantos attack paths foram eliminados?
quanto caiu time to detect?
quantas contas privilegiadas foram removidas?
quantos controles foram validados?
Isso mostra maturidade.
Ele detecta fraqueza.
Não apenas software.
Cultura.
Processo.
Arquitetura.
Governança.
É quase um instrumento diagnóstico.
Relatório sem ação vira coleção de PDFs.
Ferris volta.
Cada achado precisa dono.
Prazo.
Prioridade.
Risco.
Reteste.
Caso contrário, desaparece em backlog.
Pode ser legítimo.
Nem tudo precisa corrigir.
Mas aceitação deve ser consciente.
Não esquecimento.
Se negócio aceita, documente.
Contexto.
Compensating control.
Prazo.
Ferris não deve ser surpresa.
Não consegue corrigir agora?
Monitore.
Limite.
Segmente.
Reduza blast radius.
Segurança prática.
Essa é a beleza.
Não acreditamos em controle perfeito.
Criamos vários.
Swiss Cheese invertido.
Defensor cria desalinhamento.
Isso resume metade da segurança.
Essa pergunta deveria ser feita periodicamente.
Não por paranoia.
Por maturidade.
Procurar comportamento sem esperar alerta.
Uma extensão natural.
Se Red Team mostrou caminho, Blue pode hunt.
Não significa derrotismo.
Significa perguntar:
se já entrou, como vemos?
Isso muda desenho.
Verifique.
Limite.
Monitore.
Não confie implicitamente.
Ferris não ganha passe vitalício.
Talvez essa seja melhor definição.
Confiamos.
Mas verificamos.
Limitamos.
Reavaliamos.
Pais.
Escola.
Restaurante.
Cameron.
Sistema.
Tudo dependia dela.
Por isso funcionou.
Não ataque a tecnologia.
Ataque as suposições.
Essa foi a primeira ideia.
E continua no final.
“Usuário não fará isso.”
“Fornecedor não será comprometido.”
“Token não vazará.”
“Agente seguirá prompt.”
“Admin não será enganado.”
Tudo hipótese.
Teste.
Essa frase continua maravilhosa.
Mainframe ensina uma coisa importante.
Confiabilidade vem de disciplina.
Processo.
Controle.
Auditoria.
Recovery.
Não de magia.
Red Team deve adicionar adversarial thinking a essa disciplina.
APIs.
IA.
Cloud.
Zowe.
z/OS Connect.
Tudo pode coexistir.
Mas segurança clássica continua:
Identity.
Authorization.
Audit.
Segregation.
Recovery.
Confiança.
Sempre confiança.
Depois do Red Team:
Se resposta for “nada”...
talvez o teste tenha sido ruim.
Ou o ambiente seja excelente.
Reteste para saber.
Também aprenda sucesso.
Porque aprendizado cria nova investigação.
Ataque.
Descoberta.
Correção.
Detecção.
Aprendizado.
Depois:
novo ataque.
Porque ambiente mudou.
Attack
↓
Learn
↓
Improve
↓
Detect
↓
Adapt
↓
Attack Again
Não é fracasso.
É evolução.
Agora imagine a escola vazia.
Corredores silenciosos.
Rooney foi para casa.
Cameron está pensando na vida.
Ferris terminou sua aventura.
O computador continua ligado.
Os registros continuam lá.
Nada parece diferente.
Mas nós sabemos.
Sabemos que:
o sistema confiou demais.
As pessoas confiaram demais.
Os controles tinham buracos.
O atacante viu caminhos invisíveis.
Essa é a transformação.
Depois de um bom Red Team, você não olha para ambiente da mesma maneira.
Uma porta.
Uma identidade.
Uma relação.
Uma exceção.
Uma API.
Tudo pode ser parte de algo maior.
Se a organização aprendeu, próxima vez será diferente.
Talvez Cameron diga não.
Talvez Help Desk verifique.
Talvez MFA bloqueie.
Talvez SOC correlacione.
Talvez RACF negue.
Talvez pipeline exija aprovação.
Aí Red Team cumpriu seu papel.
Esse é o troféu.
Não o shell.
Melhor ainda.
Pessoas começaram a perguntar:
“Como sabemos?”
Isso é maturidade.
Não paranoia.
Dúvida.
Como sabemos?
Autenticamos?
Ainda precisa?
Testamos?
Quem impede?
E o caminho até ele?
Perguntas.
Ferris sobrevive porque pergunta.
Defesa melhora quando aprende a perguntar também.
Por isso Red Team é valioso.
Ele injeta uma perspectiva que a organização naturalmente perde.
Quem constrói vê intenção.
Quem ataca vê abuso possível.
O desenvolvedor pergunta:
“Como isso deveria funcionar?”
O Red Team pergunta:
“Como isso pode funcionar de modo inesperado?”
Ambos são necessários.
Sem builder, nada existe.
Sem breaker, suposições permanecem invisíveis.
Não cinismo.
Não paranoia.
Disciplina.
Testar hipóteses.
Imaginar mau uso.
Validar.
É amigo inconveniente.
Aquele que aponta:
“Você deixou a Ferrari destrancada.”
Melhor ouvir dele.
Essa é talvez a frase mais importante.
O Red Team entrega relatório.
O atacante real entrega incidente.
Escolha qual prefere.
Última cena.
Ferris abre a porta.
Olha para nós.
Quase como se soubesse que passamos doze artigos transformando uma comédia adolescente numa tese sobre cybersecurity, RACF, AI e engenharia social.
E talvez diga:
— Vocês ainda estão aqui?
Sim.
Estamos.
Porque sistemas são complicados.
Confiança é complicada.
Pessoas são complicadas.
E segurança é a arte de impedir que toda essa complexidade vire desastre.
Ferris tinha razão sobre uma coisa.
A vida passa rápido.
Sistemas também.
Arquitetura muda.
Equipe muda.
Ameaça muda.
Tecnologia muda.
Aquilo que era seguro ontem pode não ser amanhã.
Então precisamos parar.
Olhar.
Observar.
Questionar.
Testar.
Porque segurança não é uma fotografia.
É um processo.
E talvez a melhor forma de resumir toda esta temporada seja assim:
Sistemas passam muito rápido. Se você não parar para observá-los de vez em quando, pode não perceber que alguém já encontrou um jeito de sair pela porta dos fundos.
Não precisamos transformar Ferris em vilão.
Nem Rooney em incompetente.
Nem Cameron em vulnerabilidade.
Eles são apenas personagens excelentes para lembrar que todo sistema é feito de componentes humanos e técnicos ligados por confiança.
E toda confiança deveria responder:
quem?
por quê?
por quanto tempo?
com qual evidência?
com qual limite?
Depois de doze cafés, esse é o verdadeiro Red Team.
Não:
Mas:
Então feche o terminal.
Salve os logs.
Atualize o ticket.
Revogue a credencial temporária.
Reteste a correção.
Sirva mais um café.
E olhe novamente para o ambiente.
Porque Ferris já foi embora.
Mas outro adversário talvez esteja chegando.
☕ SAVE FERRIS.
Fim da temporada.
☕ 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.