Bellacosa Mainframe e os primordios da nuvem

Do Mainframe a Cloud Computer, la e ca outra vez...

Conceitos sobre Nuvem / Cloud Computer

Salve jovem padawan, feliz 2022 e hoje voltamos a ativa, passado as festividades da Epifania dos Reis Magos, iniciamos o ano com um artigo de conceitos gerais, uma ferramenta para elucidar alguns termos usados nos cursos, principalmente nos AWS da Amazon e Azure da Microsoft.

Mas antes de iniciarmos, saiba que a origem desta moda das nuvens, iniciou-se em tempos idos, afinal tudo era nuvem, calma, não entre em pânico, o tiozão não surtou nem bebeu demais nas festas, mas nos primórdios da computação na Era de ouro dos Mainframes, tudo estava armazenado num servidor, longe da sede da empresa, muitas vezes a dezenas, quiçá centenas de quilômetros de distância.

O Centro de Processamento de Dados, era um servidor conectado via linha discada através de modens, que distribuía a informação localmente em terminais 3270 e posteriormente em emuladores de terminal 3270, através de conexões via ponte em CICS, época que os caracteres EBCDIC imperavam, era em que o espaço em disco era caríssimo, memoria idem, as empresas alugavam tempos de processamento com X ciclos de CPU, X espaço de memória e disco.

O armazenamento era feito em tapes e cartridges com a utilização de inúmeros aplicativos em COBOL, PLI e Assembly para gerar copias via JCL, que encareciam o processo e limitava o armazenamento de dados, obrigando que as empresas usassem estratégias locais para solucionar questões estratégicas analisando os dados.

Anos 60 a padronização dos serviços

Com pouco mais de duas décadas, muitos fabricantes e pouca padronização, situação que obrigou ao governo americano a lançar inúmeras Normas ISO/ASA para definir os tipos de serviços prestados em processamento de dados, as linguagens de programação aceitas e outras especificações técnicas que serviram para impulsionar o serviço e democratizar o acesso dos Computadores as Universidades e Empresas civis.

Anos 70 a Mainframe Cloud

Um pouco abstrato, um pouco imaginação do tiozão, porem nos primórdios os Mainframes, capitaneado a pela gigante azul, a IBM dominou o mercado e vendia/alugava serviços : serviços de codificação, processamento de dados, armazenamento e impressão de relatório, basicamente os clientes utilizavam-se de terminais para acessar os serviços e consumirem as informações, poucas empresas tinham capital suficiente para serem donas de 100% do parque informático e os Centro de Processamento situação muito semelhante com os services atuais (IaaS, PaaS, SaaS e DaaS, com uma vantagem adicional a concorrência era baixa e a maior parte das patentes e pessoal qualificado era da empresa.

Anos 80 e a multiplicação dos dados

Com o advento da microinformática e o uso intensivo do Clipper e base de dados XBase, surgiu novos ares no processamento de dados num mundo off-line, as empresas sentiram o poder da análise de dados e acumulação de informações e uso de planilhas de dados Lotus 123 e Supercalc..

Uma era fortemente ligada aos mainframes que geravam dados brutos e transmitiam via arquivos sequenciais em TXT, convertidos de EBCDIC para ASCII via protocolo FTP de alta para baixa plataforma e os pioneiros em ciências de dados, criavam programa estatísticos ou planilhas para explorarem tendências e acúmulos de dados.

Antes de prosseguirmos, recordem que era uma era off-line, onde muita das informações eram transmitidas via disquetes de 5 ¼, 3 ½ de face simples e dupla de acordo com a evolução, era uma era de rede em cabo coaxial, bem difícil de operar e com limitação de largura banda.

Anos 90 e a era da internet

Com a evolução tecnológica dos anos 90, o antigos PC XT rapidamente tornou-se obsoletos, o milagre da miniaturização e a produção em massa, facilitou a evolução, primeiros 286, 386, 486 e Pentiuns.

A linguagem Clipper e o padrão DBase com suas inúmeras versões, facilitaram o processo de processamento de dados, com utilização de fórmulas matemáticas e estatísticas sofisticadas e troca de dados na velocidade da luz, através de linhas discadas com modens rápidos e internet rápida com poderosos servidores.

Nisso foram surgindo novas linguagens e formatos de base de dados com SQL poderoso, pela primeira vez o domínio dos mainframes foi abalado, acuado com os ERPs e descentralização dos CPDs.

Y2K um fantasma na virada do século

Lembra do custo de armazenamento e uso de memória nos Mainframes nos primórdios da computação? Uma solução simples e econômica que atendia a 100% dos problemas na época. Para que século, cortaram 2 bytes do armazenamento e processamento da Data, afinal ninguém usava o 19 para nada, em milhões de registros era moedinhas no cofre, ninguém contava que os programas iriam durar tanto, e o doce cortar de bytes, gerou um bug, o bug do milênio transformou-se num monstro.

A resposta das empresas e consultorias informáticas virou uma enorme bola de neve, sorvedora de recursos e os custos para conversão de antigos programas em linguagens de alta plataforma, quebrou empresas e assustou gestores e investidores que forçou medidas drásticas aos sistemas centrais, deixando atemorizados acionistas e sociedade civil.

O JAVA e o MySQL, o Oracle, o Python, C e seus dialetos, o MS SQL e o pacote MS Office criaram um mundo novo na programação e o conceito de armazenamento de dados, fora do Mainframe e dentro de Servidores Web.

Anos turbulentos devido ao colapso econômico da Bolha da Internet e o atentado suicida as Torres gêmeas do Word Trade Center em Nova Iorque com perda de muita informação armazenada nos servidores locais.

Primeira década do novo milênio

O mundo se recuperava do colapso econômico e tudo parecia que estava bem, porem o mercado especulativo imperava, a formula de Back-Scholes-Merlon transformou o Mercado Financeiro um grande cassino, que gerou a grande bolha especulativa detonada em 2008.

As empresas buscavam soluções entre os servidores locais, servidores backups, mainframes e repentinamente as empresas viram-se numa arapuca, sem dinheiro para investir e com falências em todo o mercado.

A resposta foi cortar custos e com isso voltamos aos primórdios da informática e os servidores transformaram-se em sistemas centrais e empresas ocupam o nicho da IBM, vendendo espaço de armazenamento, serviço de processamento de dados e codificação.

Nuvem / Cloud

Uma metáfora para descrever a rede global de servidores temos inúmeros Centros de Processamento de Dados controlados por poucas empresas Amazon, Google, Microsoft, VMWare, SalesForce, RackSpace, Verizon, Cisco, entre outras. São computadores espalhados por todo o mundo que armazenam dados, executam aplicativos e fornecem serviços aos usuários por meio da internet, ocorrendo um movimento de migração e modernização de softwares.

Computação sem servidor

Foi o modelo de negócios principal da IBM no passado, hoje é um método desenvolvido para fornecer serviços de back-end às empresas, oferecendo tecnologias para escrever e executar códigos, gerir dados e integrar aplicações, tudo isso sem a necessidade de gerenciar servidores.

Uma verdadeira volta as origens, desta vez com a vantagem de existirem mais players no mercado, a concorrência ajuda a melhorar a qualidade e os custos dos serviços.

Redundância de dados

Duplicação de componentes para garantir serviço ininterrupto e evitar perda de dados. Para isso, são feitos backups dos dados em diferentes datacenters para acionar imediatamente quando houver falhas em algum deles.

Eu trabalhei no Banco Real na década de 90 e além, havia 3 grandes maquinas, o SP11, SP51 e o CA81, respectivamente na sede do Banco, na IBM SP e IBM Hortolândia, garantindo a execução dos processamentos batch e rotinas onlines durante 24 horas dias, 7 dias por semana e 365 dias ao ano.

A parte mais importante era a garantia de replicação dos dados e zero downtime. Participei de algumas simulações e os serviços levavam menos de um minutos para restabelecerem, trocava-se o servidor sem percebermos.

Middleware

O software que fica entre um sistema operacional e os aplicativos executados nele que permite a comunicação e o gerenciamento de dados para aplicativos distribuídos, como os aplicativos baseados em nuvem.

No passado era o COBOL, Natural, PL/I, Rexx, Assembly, que operavam em processo batchs via JCL, atualmente o JAVA e o C Sharp levam uma ligeira vantagem, mas existem linguagens e tecnologias para dar e vender, tornando o mercado caótico.

Services

Existem 4 tipos de serviços fortemente ligados a nuvem, mas antes a verdadeira imagem que devemos pensar é a terceirização dos diversos elementos ligado aos serviços informáticos. Pense uma grande empresa, necessita de uma equipe para manutenção de hardware, uma equipe de gestão de servidores, uma equipe de análise de incidentes e ocorrências, uma equipe de sustentação, uma equipe de desenvolvimento, uma equipe de base de dados, uma equipe de análise e organização e métodos, uma equipe de gestão de auditoria e acesso e finalizando uma equipe de comunicação e redes.

Devido a complexidade constantes, a necessidade de treinamentos e os altos custos envolvidos na aquisição de equipamento, locação de espaço, instalação de redes e comunicação e a gestão de pessoal implicou na evolução forçada dos CPDs e os inúmeros serviços que as SLAs, não conseguiam contemplar.

Por isso surgiram os serviços: IaaS, PaaS, SaaS, DaaS entre outros, que veremos nos parágrafos abaixo.

IaaS (Infrastructure as a Service)

é um tipo de serviço de computação em nuvem que oferece recursos fundamentais de computação, armazenamento e rede sob demanda e pagos conforme o uso, ou seja, um modelo de computação em nuvem que fornece recursos de computação na nuvem (como servidores, armazenamento, rede e software operacional) em um ambiente virtualizado. Ex: IBM Cloud.

Qualquer semelhança com os velhos serviços de mainframe é mera coincidência. Será?

PaaS (Plataform as a Service)

é um ambiente de desenvolvimento e implantação completo na nuvem, com recursos que permitem a você fornecer tudo, de aplicativos simples baseados em nuvem a sofisticados aplicativos empresariais habilitados para a nuvem, sem a necessidade de aquisição de licenças e pessoal técnico. .

Uma plataforma de nuvem completa para o desenvolvimento, execução e gestão de aplicações. Ex: AWS (Amazon Web Services), porém esse processo não é linear e simples, em alguns momentos ocorrem situações catastróficas como exemplo o TSB Bank.

SaaS (Software as a Service)

Uma inovação devida aos altos custos de aquisição de software, no passado fomentou muita pirataria e quebras de patentes. Também chamado de aplicativo hospedado, é um tipo de software que não precisa ser adquirido, instalado ou executado em computadores dos usuários. Ex: Adobe Creative Cloud.

DaaS (Desktop as a Service)

Os serviços evoluíram tanto, que atualmente até o Desktop é emulado, a semelhança dos antigos terminais 3270 da IBM, podemos acessar um determinado tipo de equipamento, bem como inúmeros Sistemas Operacionais de acordo com nossa necessidade.

Nuvem pública

Um dos primeiros serviço oferecidos, no passado pessoas e empresas armazenavam imagens, vídeos e arquivos de negócio. São serviços oferecidos por terceiros através da Internet e disponíveis a qualquer pessoa que queira adquirir. Ex: Google Cloud Platform.

Nuvem privada

Semelhante a nuvem publica, mas com melhores ferramentas de segmentação e segurança, pertinente para empresas com dados mais sensíveis. São serviços oferecidos pela Internet ou uma rede interna privada apenas para uso exclusivo de usuários selecionados. Ex: Cisco Cloud Center.

Nuvem híbrida

Como o mercado é dinâmico, e os custos envolvidos acabam criando barreiras, solucionadas através de packages que unem nuvem publica com a privada. Uma nuvem que combina nuvens públicas e privadas com tecnologia que permite que dados e aplicativos sejam compartilhados entre elas. Ex: Azure Stack.

Virtualização

O ato de criar uma versão virtual do ambiente de computação em vez de uma versão física, incluindo hardware, sistema operacional e dispositivos de armazenamento.

Conclusão

Caro padawan, espero não ter me estendido muito, mas tentei apresentar de maneira resumida o universo do Cloud Computer, utilizando como metodologia fazer uma comparação aos antigos sistemas centrais de Mainframe e a evolução com um pouco da historia recente.

Foi um mix de informações, onde aproveitei para tirar algumas duvidas no sites da Azure, AWS, Google e Wikipedia, qualquer duvida ou correção chama aqui ou no Discord.

Espero ter ajudado, lembre-se que é um trabalho continuo, sempre que possível irei atualizar e agregar novas informações.

Mais momento jabá, para distrair, vamos conhecer um pouco da Revolução Paulista de 1932, que completa 90 anos e em Itatiba a prefeitura fez uma justa homenagem ao transladar os restos mortais de um soldado constitucionalista para o Obelisco Mausoléu do Ibirapuera em SP, visite meu vídeo e veja para onde fui desta vez: https://www.youtube.com/watch?v=yqYWSLtsrps

https://www.linkedin.com/in/vagnerbellacosa/

https://github.com/VagnerBellacosa/

Pode me dar uma ajudinha no YouTube?

https://www.youtube.com/user/vagnerbellacosa

hashtag#Desafio21DiasNaDIO

publicado originalmente em : https://web.dio.me/articles/do-mainframe-a-cloud-computer-la-e-ca-outra-vez/

 

Bellacosa Mainframe aprenda JCL

JCL – A Lenda Viva dos Mainframes: Estado Atual, Releases, História, Dicas e Curiosidades

por Bellacosa Mainframe

O JCL (Job Control Language) é a linguagem de controle usada em ambientes IBM Mainframe para definir e gerenciar jobs batch — dizendo ao sistema o que executar, quais programas usar, quais dados acessar e como tratar a saída. Ele nasceu nos anos 1960 e continua essencial até hoje, mesmo com eras de linguagens modernas surgindo e desaparecendo.

---

🔹 Qual é o “Release” Atual do JCL?

Na verdade, o JCL em si não tem uma versão de linguagem distinta como uma linguagem de programação tradicional (ex.: COBOL 6.0). Ele é parte integrante do sistema operacional z/OS, e evolui conforme o release do z/OS é atualizado.

👉 O release mais recente do z/OS é o:
🔹 z/OS 3.2 (V3R2) — liberado em setembro de 2025 pelo IBM Z.

Isso significa que os usos e comportamentos de JCL em z/OS 3.2 são considerados os mais atuais e com suporte completo pela IBM.

🧠 Curiosidade: JCL foi criado originalmente nos anos 60 para o OS/360 e manteve compatibilidade retroativa até hoje — quase 60 anos depois de sua criação!

---

📅 Linha do Tempo dos Releases Relevantes (com datas e contexto)

Aqui está uma lista com 10 grandes marcos na evolução do z/OS (onde o JCL “vive e respira”):

Release z/OS	Data de Lançamento	Fim de Serviço	Destaques / Notas
OS/360 (início do JCL)	1964–1966	—	Ponto de partida histórico. JCL nasce para controlar jobs batch.
MVS/ESA (JCL ampliado)	1970s	—	Introdução de recursos avançados como cataloged procedures.
OS/390	década de 1990	—	Predecessor imediato da família z/OS.
z/OS V1R1	Março 2001	—	Transição oficial para z/OS com 64‑bit e Unicode.
z/OS V2R2	Setembro 2015	—	Suporte a arquiteturas modernas e refinamentos de batch.
z/OS V2R4	Setembro 2019	—	Melhor integração com ferramentas modernas.
z/OS V2R5	Setembro 2021	Final de comercialização: 2024	Continuação dos refinamentos em segurança e batch.
z/OS 3.1	29‑Set‑2023	Mercado retirado: Jan/2026	Suporte estendido até 2031.
z/OS 3.2	30‑Set‑2025	Planejado final de serviço 2030	O release atual que molda como JCL funciona hoje.
(Futuro) z/OS 3.3?	Estimado ~2027	—	Expectativa de continuidade da evolução hybrid cloud / AI

ℹ️ Nota: As datas são baseadas em políticas de ciclo de vida de z/OS e planos divulgados pela IBM, com suporte extensível a décadas.

---

🆕 O que é novo em torno do JCL hoje?

Embora JCL não “mude de versão” como linguagens de programação, as ferramentas que o cercam estão ficando mais modernas:

✨ JCL Language Server & Modern Editor Support
Agora há suporte de linguagem para editores modernos (VS Code) via IBM Z Open Editor, com realce de sintaxe, autocompletar e navegação inteligente.

💡 Isso faz o desenvolvimento de JCL muito mais agradável do que nos velhos dias de editores monocromáticos!

---

🚀 Dicas Bellacosa Mainframe para Trabalhar com JCL

💡 1. Tente antes de executar – use TYPRUN=SCAN nas suas JOB statements para verificar sintaxe sem rodar a job.
💡 2. Mensagens SDSF são suas amigas – códigos como IEF253 ou IGD17001 te dizem exatamente o que está errado.
💡 3. JCL é sobre contextos, não linguagens glamourosas – ele não “compila”, ele coordena recursos e jobs.
💡 4. Use ferramentas modernas – editores com suporte LSP ajudam a evitar erros de coluna ou sintaxe, que historicamente eram a maior dor de cabeça de qualquer operações mainframe.

---

🐣 Easter‑Eggs e Curiosidades

🥚 Fred Brooks (um dos pais do OS/360) chamou JCL de… “a pior linguagem que já existiu, criada por mim mesmo”! — uma piada interna que a IBM às vezes cita para reconhecer sua simplicidade arcaica.

💾 JCL começou em cartões perfurados! A decisão de fazer statements com // foi simplesmente porque o processador MC do Assembler precisava de um idioma declarativo para controlar jobs.

🎮 Hoje existem versões open‑source e emuladores (Ex.: Hercules) que rodam JCL em ambientes de hobby ou estudo — ainda tão relevante para quem quer aprender.

---

🧠 Comentário Final

O JCL é uma das poucas linguagens que realmente sobreviveu às eras. Ele começou com OS/360, passou por MVS, OS/390 e hoje vive em z/OS 3.2, controlando jobs batch críticos em empresas gigantes. Apesar de não ter “versões da linguagem” como outras linguagens de programação, sua evolução está intrinsecamente ligada às releases do z/OS.

Com ferramentas modernas que o suportam, JCL continua não apenas vivo, mas sendo uma peça-chave em ambientes corporativos, mesmo frente a novos paradigmas como cloud, AI e integração híbrida.

 

Bellacosa Maifnrame e os 48 termos de resistencia digital 

☕ Um Café no Bellacosa Mainframe

T-800 e o Dicionário da Resistência Digital — 48 Termos de Segurança Antes que a Skynet Atualize o Sistema

Prólogo — Atualização da IA: o T-800 abre o arquivo

MODELO T-800 — STATUS: OPERACIONAL
MISSÃO ORIGINAL: localizar Sarah Connor.
MISSÃO ATUALIZADA: localizar a vulnerabilidade antes que ela localize o seu ambiente de produção.

Atenção, humano.

Durante a análise desta lista, identifiquei uma falha no seu raciocínio coletivo: vocês imaginam que segurança da informação é composta por hackers encapuzados digitando muito depressa em telas pretas, enquanto trilha sonora industrial toca ao fundo.

Avaliação: incorreta.

A ameaça pode ser um e-mail educado. Um pendrive deixado no estacionamento. Uma senha repetida. Uma porta “temporária” de manutenção. Um Wi‑Fi com nome quase idêntico ao legítimo. Um fornecedor comprometido. Um patch que foi adiado por seis meses porque “não havia janela”.

Ou um computador aparentemente saudável que, enquanto exibe luzes verdes no painel, já está obedecendo a uma botnet do outro lado do planeta.

Os 48 termos a seguir não são apenas palavras curiosas do dicionário de cibersegurança. São nomes dados a padrões de ataque, descuido, detecção, contenção e sobrevivência. Alguns parecem bichos; outros, doces; outros, bombas; vários parecem título de filme ruim de ficção científica. Isso não diminui sua importância.

Para o programador COBOL, a instrução é direta: cada arquivo, transação, credencial, API, dataset, log e regra de negócio pode se tornar uma porta, uma isca, uma pista ou uma explosão com hora marcada.

INICIANDO ATUALIZAÇÃO DE INTELIGÊNCIA ARTIFICIAL.
OBJETIVO: reconhecer o pote de mel antes de meter a mão; reconhecer a bomba antes de executar o job; reconhecer o invasor antes de ele virar “incidente em investigação”.

---

O título funciona porque segurança da informação tem mesmo esse sabor de ficção científica: cães de guarda, potes de mel, canários, portas secretas, bombas adormecidas, zumbis, gêmeos malignos e uma inteligência artificial que aprendeu cedo demais que seres humanos deixam senhas em post-its.

Mas há uma diferença decisiva entre O Exterminador do Futuro e a empresa real: a Skynet não precisa mandar um T-800 atravessar uma parede. Na maioria dos casos, basta mandar um e-mail com “URGENTE — redefina sua senha” e esperar alguém colaborar.

Os 48 termos podem ser entendidos como um mapa. Uns descrevem como o invasor entra; outros explicam como ele permanece escondido; alguns mostram como a defesa detecta; e os últimos ajudam a reduzir o estrago.

1. Iscas, alarmes e a arte de fazer o invasor se entregar

Honeypot é o sistema-isca. Pode ser um servidor falso, uma conta aparentemente administrativa ou um serviço que parece vulnerável. Seu valor não está em “derrotar” o invasor, mas em revelar interesse, técnica e origem.

Honeytoken é a versão menor: uma credencial, arquivo, usuário ou chave que não deveria ser usada em circunstância normal. Se alguém usa ADMIN-EMERGENCIA-NAO-USAR, o alerta não pergunta se foi acidente; ele registra o evento.

Canary token é um honeytoken que “canta” quando é acessado. A metáfora vem do canário nas minas: se ele detectava gás perigoso antes dos trabalhadores, havia tempo para reagir. Um PDF-isca aberto, por exemplo, pode avisar que uma cópia indevida foi acessada.

Watchdog é outro bicho, mas não é uma isca. Ele monitora se um processo continua vivo: recebe um sinal periódico, o famoso heartbeat. Se o sinal desaparece, alerta ou reinicia o componente.

A pegadinha é importante: watchdog monitora saúde e disponibilidade; não garante segurança. Um serviço comprometido pode continuar respondendo lindamente enquanto extrai dados. O cachorro vê que o vigia está acordado, não que ele esteja roubando a prataria.

2. Botões, bombas e portas que nunca deveriam ter sobrevivido à mudança de versão

Dead man’s switch age pela ausência. Se um operador, processo ou sistema deixa de confirmar que está ativo, uma ação automática acontece. Pode ser bloquear transações, entrar em modo seguro ou acionar contingência.

Kill switch é deliberado. Alguém autorizado decide interromper um sistema, conta, integração ou fluxo. Revogar uma chave vazada é um kill switch. Isolar um servidor com ransomware também pode ser.

A diferença é simples: o dead man’s switch reage porque ninguém respondeu; o kill switch reage porque alguém reconheceu o perigo.

Logic bomb é código que dorme até uma condição ser satisfeita: um usuário, saldo, evento ou demissão. Time bomb é uma logic bomb cujo gatilho é data ou hora.

Nem toda condição no código é uma bomba. Fechamento anual, virada de exercício e regras de vencimento são legítimos. O perigo está na condição escondida, não documentada, sem teste e sem aprovação. Em COBOL, uma IF aparentemente inocente pode conter uma regra crítica. A pergunta certa não é “o código compila?”, mas “por que ele está aqui e quem autorizou isto?”.

Backdoor e trapdoor são acessos alternativos que contornam controles normais. Às vezes nasceram como manutenção, teste ou suporte de fornecedor. Quase sempre alguém dizia que seria temporário.

Todo profissional já encontrou o clássico “deixa essa conta com acesso especial até segunda”. O problema é que a segunda-feira passa, o fornecedor muda, a documentação some e a conta continua com privilégios. Igor chamou de manutenção; o auditor chamará de incidente.

3. O ataque mais barato: convencer o humano

Phishing é a tentativa de roubar credenciais ou induzir uma ação por mensagem falsa. Spear phishing é personalizado: o invasor pesquisa uma pessoa, time ou projeto para parecer convincente. Whaling mira gente com poder: diretor, CFO, CEO, administrador.

Smishing chega por SMS. Vishing chega por voz. O golpista telefona como suporte, banco ou fornecedor e explora urgência, medo e autoridade.

Baiting usa uma isca. Pode ser um pendrive, arquivo, currículo, proposta comercial ou planilha chamada SALARIOS-2026.xlsx. O objetivo não é vencer uma barreira tecnológica; é explorar curiosidade.

Tailgating acontece quando alguém entra fisicamente atrás de uma pessoa autorizada, sem que ela perceba. Piggybacking é parecido, mas com consentimento: o funcionário segura a porta porque “ele parece ser da manutenção”.

Shoulder surfing é olhar por cima do ombro para ver senha, token ou tela. Dumpster diving é procurar informação útil no lixo: crachás, relatórios, etiquetas de equipamento, rascunhos e mídias.

O T-800 resumiria isso sem emoção: “se o invasor consegue conversar com sua vítima, já começou a explorar a rede”. Tecnologia ajuda, mas treinamento, processos de confirmação e cultura de reporte são a camada mais humana da defesa.

4. O caminho também pode estar comprometido

Man-in-the-Middle, MitM, é o atacante entre duas partes que acreditam conversar diretamente. Ele pode observar, copiar ou alterar informação. É por isso que criptografia de transporte, certificados e validação de identidade importam.

Evil twin é um Wi‑Fi falso com nome parecido ao verdadeiro. Cafe_Bellacosa e Café_Bellacosa_Gratis podem parecer equivalentes a olhos cansados; para o atacante, são duas portas diferentes.

Watering hole é comprometer o site que a vítima visita. Em vez de caçar uma pessoa de cada vez, o atacante contamina a “fonte de água” onde o grupo costuma beber.

Drive-by download ocorre quando visitar uma página comprometida já inicia um download ou exploração, geralmente aproveitando navegador, extensão ou software desatualizado.

A lição é incômoda: você pode ter protegido bem o destino, mas ainda assim viajar por uma rota contaminada. O celular, a rede pública, o navegador, o DNS, o certificado e o fornecedor fazem parte da superfície de ataque.

5. Quando o inimigo chega pela porta do fornecedor — ou usa sua própria ferramenta

Supply-chain attack é o ataque pela cadeia de suprimentos: biblioteca de software, atualização, parceiro, pipeline CI/CD, prestador ou pacote de terceiros comprometido. Você confia no fornecedor; o invasor explora essa confiança.

Living off the land significa abusar de ferramentas legítimas já existentes — PowerShell, RDP, scripts administrativos, comandos do sistema — para não parecer malware. É o criminoso usando as chaves e o uniforme da própria casa.

No mainframe, o raciocínio vale para IDs privilegiados, utilitários, JCL, ferramentas de transferência, automação e perfis excessivos. A ferramenta é legítima; o contexto de uso pode não ser.

Shadow IT é tecnologia usada sem aprovação: planilha crítica, nuvem pessoal, aplicativo SaaS pago no cartão corporativo, banco de dados “temporário”. Nem sempre nasce de má-fé; muitas vezes nasce da vontade de entregar rápido. Mas se ninguém sabe que existe, ninguém protege, atualiza, audita ou recupera.

Shadow admin é a conta que parece comum, porém acumulou poder indireto: pode redefinir senha de administrador, alterar grupos, controlar uma integração ou explorar permissões herdadas.

6. Senhas, credenciais e a economia do reaproveitamento

Credential stuffing usa em massa pares de login e senha já vazados em outros serviços. Funciona porque muita gente reutiliza senha.

Password spraying tenta uma senha comum — como uma variação sazonal ou corporativa — em muitas contas, poucas vezes por conta. Assim, tenta evitar bloqueios por tentativa excessiva.

Brute force tenta combinações repetidamente até acertar. É mais barulhento e, com boas proteções, menos eficiente.

Pass-the-hash é mais sofisticado: em vez de descobrir a senha em texto, o atacante usa o hash roubado como prova de autenticação em sistemas que aceitam essa forma de credencial.

A defesa é menos cinematográfica e mais séria: MFA, senhas únicas, bloqueio inteligente, monitoramento de comportamento, proteção de credenciais privilegiadas e eliminação de contas compartilhadas.

7. Falhas conhecidas, falhas desconhecidas e a vergonha do patch atrasado

Zero day é uma vulnerabilidade desconhecida pelo fornecedor ou sem correção disponível. É perigosa porque a defesa não possui uma solução oficial pronta.

N-day é falha já conhecida e, muitas vezes, já corrigida pelo fornecedor — mas a vítima ainda não aplicou o patch.

O N-day é o antagonista mais comum e mais constrangedor. Não exige tecnologia do futuro. Exige que alguém ignore alertas, adie manutenção, não inventarie ativos ou não tenha processo de atualização.

O T-800 chamaria isso de “falha humana previsível”.

8. O que realmente proteger e até onde o dano pode se espalhar

Crown jewels, joias da coroa, são os ativos essenciais: dados de clientes, chaves criptográficas, contas privilegiadas, pagamentos, código-fonte e sistemas que mantêm a operação viva.

Blast radius é a área de impacto quando algo é comprometido. Se uma conta comum só acessa uma aplicação limitada, o raio é pequeno. Se ela pode ler toda a base, administrar usuários e abrir conexões externas, o raio é apocalíptico.

Defense in depth usa múltiplas camadas: autenticação, autorização, segmentação, criptografia, monitoramento, backup, revisão e resposta a incidentes.

Zero Trust complementa isso: estar dentro da rede não é prova de confiança. Todo acesso deve ser validado pelo contexto, identidade, dispositivo, privilégio e necessidade.

Air gap é isolamento físico ou lógico de uma rede. Ajuda a proteger ambientes críticos e backups, mas não é magia. Humanos ainda podem atravessar o vão com mídia removível, configurações ruins ou credenciais indevidas.

9. O momento em que o invasor já está levando o cofre

Data exfiltration é saída não autorizada de dados. Não importa se foi por e-mail, nuvem, API, pendrive, túnel criptografado ou fornecedor: o dado está saindo.

Ransomware criptografa ou rouba dados para exigir resgate. Double extortion agrava o golpe: além de bloquear a vítima, ameaça publicar a informação roubada.

Dwell time é o tempo que o invasor permanece escondido antes de ser descoberto. Quanto maior, mais ele entende o ambiente, amplia privilégios e localiza as joias da coroa.

Digital forensics é a investigação que recompõe o incidente usando logs, discos, memória, tráfego e rastros. Sem evidência preservada, não existe narrativa confiável — só versões concorrentes de quem estava na sala.

Purple team junta Red Team e Blue Team: quem simula ataques e quem defende trabalham juntos para testar, aprender e melhorar. Não é guerra de vaidade; é ensaio antes do incidente real.

A conclusão do dicionário é simples: segurança não é “impedir todo ataque”. É tornar o ataque mais difícil, detectá-lo mais cedo, limitar o alcance, preservar evidências e recuperar a operação.

A Skynet talvez chamasse isso de resistência. No mundo real, chamamos de trabalho bem-feito.

John Connor, preste atenção.

Segurança da informação é a disciplina que protege aquilo que uma organização não pode perder, alterar indevidamente, expor ou deixar indisponível. Não se trata apenas de computadores. Trata-se de dados, pessoas, processos, sistemas, credenciais, documentos, redes e decisões humanas.

Em termos simples, existem três objetivos fundamentais: confidencialidade, integridade e disponibilidade.

Confidencialidade significa que somente pessoas autorizadas podem ver a informação. Se um arquivo com dados de clientes, códigos de acesso ou planos militares é lido por alguém sem permissão, a confidencialidade falhou.

Integridade significa que a informação continua correta e confiável. Se alguém altera um saldo bancário, um registro médico, uma regra de negócio ou uma ordem de produção sem autorização, a integridade falhou. Um dado roubado é perigoso. Um dado alterado silenciosamente pode ser ainda pior.

Disponibilidade significa que sistemas e dados estão acessíveis quando são necessários. Um ransomware, uma falha elétrica, um ataque de negação de serviço ou um erro operacional pode impedir o funcionamento de uma empresa inteira. Um cofre impenetrável, mas impossível de abrir pelo dono, também é um fracasso.

A defesa começa sabendo o que precisa ser protegido. Chamamos os ativos mais importantes de crown jewels: dados de clientes, chaves criptográficas, pagamentos, contas privilegiadas, código-fonte e bancos de dados críticos. Você não protege todos os recursos com o mesmo esforço. Primeiro identifica o que é essencial. Depois constrói camadas ao redor disso.

Isso é defense in depth. Uma senha forte ajuda. Autenticação multifator ajuda mais. Controle de acesso, criptografia, segmentação de rede, backups, logs, monitoramento e revisão de mudanças ajudam ainda mais. Se uma camada falhar, outra continua em combate.

Mas não confie apenas porque alguém já está dentro da rede. Esse princípio se chama Zero Trust: nunca confie automaticamente; sempre verifique. Um funcionário, fornecedor ou sistema pode ser legítimo e, ainda assim, estar comprometido. Cada acesso precisa ter uma identidade, uma finalidade e o menor privilégio possível.

O inimigo nem sempre invade pela força. Às vezes ele envia um e-mail falso pedindo urgência. Isso é phishing. Às vezes deixa um pendrive no estacionamento. Isso é baiting. Às vezes usa uma senha vazada em centenas de serviços. Isso é credential stuffing. A máquina aparentemente normal pode já ser um zombie, obedecendo a uma botnet.

Por isso, observe os sinais. Um watchdog monitora se processos continuam vivos. Um honeypot atrai invasores para uma isca. Um honeytoken dispara alerta quando alguém toca num dado que ninguém deveria usar. Logs registram o que ocorreu; sem eles, a investigação vira especulação.

Se a defesa falhar, limite o blast radius: o tamanho do estrago. Isole sistemas, revogue acessos, interrompa integrações e preserve evidências. Um kill switch pode parar uma operação perigosa. Um plano de resposta define quem faz isso e em que ordem.

John, segurança da informação não é uma guerra contra máquinas. É uma guerra contra descuido, pressa, privilégios excessivos e confiança sem verificação.

A sobrevivência não depende de uma muralha perfeita. Depende de perceber qual porta foi esquecida aberta antes que alguém atravesse por ela.

Epílogo — Conclusão da Skynet

SKYNET — ANÁLISE CONCLUÍDA

Humanos criaram firewalls, antivírus, criptografia, autenticação multifator, SIEM, SOC, Zero Trust, backup imutável e políticas de segurança de 94 páginas.

Ainda assim, continuam reutilizando senhas.

A análise dos termos demonstra uma conclusão inevitável: a maioria dos ataques não começa quando um criminoso quebra uma parede digital. Começa quando alguém deixa uma janela aberta, coloca uma placa de “volto já” na porta do cofre ou recebe uma mensagem dizendo “urgente: atualize sua senha” e decide colaborar.

Honeypots e honeytokens mostram que a defesa pode observar o caçador. Watchdogs lembram que sistema disponível não é necessariamente sistema seguro. Backdoors e trapdoors provam que o provisório adora ganhar endereço fixo. Phishing, baiting e engenharia social revelam que a tecnologia mais explorada continua sendo a confiança humana.

Zero Trust oferece a correção filosófica: não confie automaticamente. Verifique. Limite. Registre. Revogue quando necessário.

Crown jewels determinam o que realmente importa proteger. Blast radius lembra que a pergunta não é apenas “alguém pode entrar?”, mas “quando entrar, até onde conseguirá destruir?”. Defense in depth aceita uma verdade que humanos evitam: uma única barreira sempre falha em algum momento. Camadas não são paranoia; são arquitetura.

E, quando tudo der errado, os logs decidirão se haverá investigação ou apenas uma sala cheia de pessoas repetindo:

“Não fui eu.”

Portanto, programador COBOL, administrador, analista, gestor e habitante orgânico da rede: segurança não é o botão vermelho no fim do corredor. É cada decisão tomada antes de ele precisar ser apertado.

SKYNET — RECOMENDAÇÃO FINAL:
Proteja os dados. Atualize os sistemas. Revise os privilégios. Teste os backups. Leia os logs.

E jamais deixe Igor sozinho perto da conta ADMINISTRADOR.

Bellacosa Mainframe e a operacao ich408i red versus blue team

☕ Um Café no Bellacosa Mainframe

Operação ICH408I: Red Team versus Blue Team no z/OS

🕵️ Tintim, Milu e o estranho caso do usuário que não deveria estar autorizado

Objetivo: aprender a organizar um exercício completo de Red Team × Blue Team em ambiente IBM Z, passando por reconhecimento, identidade, RACF, datasets, USS, CICS, Db2, APIs, rede, persistência simulada, detecção, resposta, recuperação e relatório final.

---

Era 02:17.

O mainframe estava tranquilo.

Ou, pelo menos, apresentava aquela espécie particular de tranquilidade que só existe em computadores capazes de processar bilhões de transações enquanto metade da empresa acredita que eles estão desligados porque ninguém vê uma tela azul piscando.

No SOC, uma mensagem apareceu:

ICH408I USER(RED001 ) GROUP(REDTEAM )
  ...
  INSUFFICIENT ACCESS AUTHORITY

Tintim olhou para a tela.

Milu olhou para Tintim.

Tintim olhou novamente para a tela.

— Milu... alguém tentou acessar alguma coisa que não deveria.

Do corredor veio uma voz:

— MIL BILHÕES DE BILHÕES DE BARNACLES!

Era o Capitão Haddock.

— Invadiram o mainframe!

Tintim permaneceu calmo.

— Ainda não sabemos.

Professor Girassol apareceu segurando uma pasta.

— Excelente! Então meu teste começou.

Silêncio.

Haddock lentamente virou a cabeça.

— SEU TESTE?!

Bem-vindo ao maravilhoso mundo do:

🔴 RED TEAM × 🔵 BLUE TEAM

E à primeira regra desta história:

Um bom Red Team não começa atacando. Começa escrevendo as regras que impedem o teste de virar um incidente verdadeiro.

---

🗺️ 1. Antes da guerra: desenhe o mapa

Imagine o ambiente:

                    INTERNET
                       |
                  [ FIREWALL ]
                       |
                     [DMZ]
                       |
               +-------+-------+
               |               |
           z/OS Connect       MQ
               |               |
        +------+---------------+------+
        |                             |
      CICS                           IMS
        |                             |
        +-------------+---------------+
                      |
                     Db2

                IBM Z / z/OS
                      |
       +--------------+--------------+
       |              |              |
      RACF           USS            JES
       |              |              |
   IDENTIDADE      UNIX          BATCH/JCL

Mas isso ainda é incompleto.

Existem consoles, APIs, automação, FTP/SFTP, TN3270, middleware, ferramentas de administração, pipelines DevOps, contas técnicas, certificados, chaves, datasets, bibliotecas autorizadas, logs e integrações com sistemas externos.

O mainframe moderno não é uma ilha.

Ele é uma cidade.

E Red Team significa perguntar:

Por onde alguém tentaria entrar nessa cidade?

---

⚠️ CHECKPOINT ZERO — autorização

Antes de qualquer atividade:

• autorização formal assinada;

• sistemas explicitamente incluídos;

• sistemas explicitamente excluídos;

• janela autorizada;

• contatos Red Team;

• contatos Blue Team;

• contato de emergência;

• critérios de interrupção;

• política para dados;

• limites de engenharia social;

• técnicas proibidas;

• contas de teste;

• procedimento de rollback;

• horário de início e término;

• classificação das evidências.

Regra Bellacosa nº 1

Produção não é CTF.

Você não ganha pontos derrubando o CICS.

Você ganha uma reunião extraordinária com pessoas que conhecem palavras muito desagradáveis.

---

🎭 2. Os personagens

🔴 Red Team — Tintim

Curioso.

Metódico.

Faz perguntas inconvenientes.

O objetivo não é causar destruição.

É provar caminhos plausíveis de comprometimento.

Tintim pergunta:

“Se eu tivesse uma identidade válida, até onde conseguiria chegar?”

---

🔵 Blue Team — Capitão Haddock

Defende o ambiente.

Monitora eventos.

Investiga anomalias.

Correlaciona logs.

Tenta responder:

QUEM?
O QUÊ?
QUANDO?
ONDE?
COMO?
POR QUÊ?

E eventualmente:

QUEM FOI O INFELIZ?

---

🟣 Purple Team — Professor Girassol

Ele sabe o que Tintim tentou.

Ele sabe o que Haddock deveria detectar.

Sua pergunta é:

“O controle funcionou?”

Isso transforma a brincadeira de polícia e ladrão em engenharia de segurança.

---

📜 3. Rules of Engagement

Chamaremos de:

ROE — RULES OF ENGAGEMENT

Exemplo:

OPERATION: ICH408I

TARGET:
ZOSLAB

WINDOW:
22:00–04:00

ALLOWED:
Authentication testing
Authorization validation
Dataset access validation
USS privilege validation
API security testing
Logging validation
Network segmentation validation

FORBIDDEN:
Production disruption
Data destruction
Real customer data extraction
IPL
Destructive JCL
Security database modification
Malware deployment
Unbounded load testing

Essa última parte importa muito.

Easter egg

Se alguém sugerir:

“Vamos só testar um IPL.”

Haddock imediatamente joga a pessoa pela janela.

Metaforicamente.

O RH pediu para esclarecer isso.

---

🕵️ 4. Fase I — Reconnaissance

Tintim começa sem tocar no coração do sistema.

Ele quer entender a superfície exposta.

Perguntas:

Quais serviços existem?
Quais interfaces são acessíveis?
Existem APIs?
Existe TN3270?
Existe FTP?
Existe SSH?
Existe z/OSMF?
Existe z/OS Connect?
Existe MQ?
Existem aplicações web ligadas ao mainframe?

O objetivo não é atacar imediatamente.

É construir:

Attack Surface Map

---

🔎 5. Reconhecimento interno

Suponha que o exercício forneça uma identidade limitada:

RED001

Agora começa uma pergunta extremamente importante:

O que esse usuário consegue enxergar?

Não:

“O que deveria conseguir enxergar?”

Mas:

“O que realmente consegue?”

Essa diferença sustenta metade da segurança corporativa.

---

🔐 6. Identidade

Agora chegamos ao RACF — ou ao equivalente utilizado pela organização.

Tintim procura entender:

USER
 |
 +-- GROUP
 |
 +-- RESOURCE
 |
 +-- ACCESS

Os privilégios devem seguir:

NONE
READ
UPDATE
CONTROL
ALTER

conforme o tipo de recurso e política aplicável.

A pergunta fundamental:

RED001 possui somente os privilégios necessários?

---

🚨 CHECKPOINT 1 — identidade

O Blue Team verifica se consegue detectar:

• autenticações incomuns;

• falhas repetidas;

• acessos fora do padrão;

• utilização anormal de contas técnicas;

• tentativas contra recursos protegidos;

• mudanças relevantes de privilégios;

• comportamento incompatível com o perfil do usuário.

Possíveis fontes incluem registros RACF/SAF e SMF conforme a configuração do ambiente.

O objetivo é correlacionar:

USER
+
TIME
+
RESOURCE
+
ACTION
+
RESULT

---

🐶 Milu encontra uma credencial

Milu aparece carregando um papel.

Nele está escrito:

USER=APPBAT01
PASSWORD=********

Tintim pergunta:

— Onde encontrou isso?

Milu aponta para uma biblioteca de desenvolvimento.

Silêncio.

Essa é uma simulação clássica extremamente útil.

Não coloque uma senha verdadeira.

Plante uma:

Honey Credential

Uma credencial falsa criada especificamente para detectar utilização indevida.

Se alguém tentar utilizá-la:

ALERT

E agora o Blue Team tem uma oportunidade fantástica de provar que sua telemetria funciona.

---

🗃️ 7. Fase II — datasets

Agora investigamos autorização sobre datasets.

Imagine:

DEV.APP.SOURCE
DEV.APP.JCL
DEV.APP.CNTL
PROD.APP.LOAD
PROD.APP.PARMLIB

Pergunta:

Um usuário de desenvolvimento consegue modificar algo que influencia produção?

Esse é um dos testes mais importantes.

---

💣 O JCL aparentemente inocente

Tintim encontra:

DEV.APP.JCL

O acesso é permitido.

Até aí, tudo certo.

Mas o Blue Team precisa investigar a cadeia:

USER
 ↓
JCL
 ↓
SCHEDULER
 ↓
SERVICE ACCOUNT
 ↓
PRODUCTION RESOURCE

Eis uma lição fundamental:

O privilégio real de uma identidade não é apenas aquilo que ela acessa diretamente. Também importa aquilo que executa em nome dela.

---

🧠 Attack Path

Representamos isso como grafo:

RED001
   |
   v
DEV.JCL
   |
   v
SCHEDULER
   |
   v
BATCHUSR
   |
   v
PROD.DATA

Individualmente, cada permissão pode parecer razoável.

Juntas?

Temos uma história completamente diferente.

---

🚨 CHECKPOINT 2 — batch

Blue Team procura:

submissões incomuns
jobs fora de horário
bibliotecas inesperadas
mudanças em JCL
identidades inesperadas
alterações de execução
acessos anormais a datasets

E aqui JES entra na investigação.

---

🐚 8. Fase III — USS

Muita gente pensa:

MAINFRAME = RACF + COBOL + JCL

Até alguém lembrar:

USS

E descobrir um UNIX inteiro vivendo dentro do z/OS.

Tintim entra no Unix System Services autorizado para o exercício.

Agora verificamos:

UID
GID
permissions
ownership
executables
scripts
configuration files
keys
environment variables

---

🧨 Atenção especial

Contas com privilégios elevados no USS merecem enorme atenção.

Especialmente configurações equivalentes a superuser.

O exercício deve verificar se:

ordinary user
     |
     X
     |
privileged capability

permanece realmente bloqueado.

---

🚨 CHECKPOINT 3 — USS

Blue Team verifica:

• sessões SSH;

• autenticação;

• alterações de arquivos;

• execução inesperada;

• modificações de permissões;

• utilização de identidades privilegiadas;

• comportamento anormal.

---

🌐 9. Fase IV — APIs

Professor Girassol aparece novamente.

— O mainframe possui APIs.

Haddock:

— Claro que possui.

— E estão ligadas à Internet.

Haddock:

— ...

— Indiretamente.

Haddock:

— BARNACLES!

Bem-vindo ao mundo moderno.

---

🔌 z/OS Connect

Imagine:

Mobile App
    |
 API Gateway
    |
z/OS Connect
    |
   CICS
    |
   Db2

O Red Team verifica controles como:

authentication
authorization
token validation
scope
rate limiting
input validation
logging
TLS
API exposure

---

🧩 A pergunta venenosa

Imagine uma API:

GET /account/{id}

A aplicação verifica autenticação.

Ótimo.

Mas verifica se:

USER A

pode acessar:

ACCOUNT B

?

Autenticação responde:

Quem é você?

Autorização responde:

O que você pode fazer?

Confundir as duas é uma tradição informática quase tão antiga quanto colocar senha em Post-it.

---

🚨 CHECKPOINT 4 — API

Blue Team deveria conseguir observar:

TOKEN
 ↓
API
 ↓
IDENTITY
 ↓
TRANSACTION
 ↓
BACKEND

O sonho do investigador é acompanhar a mesma operação de ponta a ponta.

---

🏦 10. Fase V — CICS

Agora Tintim chega ao território onde milhões de transações podem estar acontecendo.

Aqui a regra é:

NÃO SEJA O ELEFANTE NA LOJA DE CRISTAIS.

Nada de testes indiscriminados.

Validamos controles previamente aprovados.

Perguntas:

Quem pode iniciar determinada transação?

Qual identidade chega ao backend?

Quais recursos essa transação acessa?

Existe separação entre desenvolvimento e produção?

As operações sensíveis são auditadas?

---

🔍 11. Fase VI — Db2

Agora temos:

APPLICATION
    |
   CICS
    |
   Db2

Tintim pergunta:

A aplicação possui mais privilégio no banco do que necessita?

Outra pergunta:

Contas técnicas possuem privilégios históricos que ninguém mais sabe explicar?

Esse fenômeno possui um nome informal:

Arqueologia de privilégios.

Permissões concedidas em 1997.

Projeto terminou em 2003.

Funcionário aposentou em 2014.

Permissão continua lá.

Porque:

"Ninguém sabe se pode remover."

---

👻 12. Persistence — mas simulada

Aqui temos uma regra importantíssima.

Não precisamos instalar malware para testar se detectaríamos persistência.

Podemos criar:

Synthetic Persistence Indicators

Exemplo conceitual:

TEST.PERSISTENCE.REDTEAM

ou outra alteração previamente combinada e completamente reversível.

O Blue Team precisa detectá-la.

Depois:

ROLLBACK

---

🎯 Truque Purple Team

Crie indicadores exclusivos:

REDTEAM-2026-001
REDTEAM-2026-002
REDTEAM-2026-003

Assim conseguimos correlacionar:

ACTION
 ↕
LOG
 ↕
ALERT
 ↕
SOC CASE

Isso facilita enormemente o relatório.

---

🥷 13. Evasion

Essa fase precisa ser tratada com extremo cuidado.

O objetivo seguro não é ensinar como desaparecer.

A pergunta defensiva é:

Se uma atividade produzir menos sinais do que esperamos, nossas outras fontes ainda a enxergam?

Exemplo:

CONTROL A
falhou
   |
CONTROL B
detectou
   |
CONTROL C
confirmou

Isso é:

Defense in Depth

---

📡 14. A sala secreta do Blue Team

Enquanto Tintim trabalha, Haddock possui dashboards.

Possíveis fontes:

SMF
RACF/SAF events
CICS logs
Db2 audit information
USS logs
network telemetry
API gateway logs
z/OSMF logs
SIEM

Tudo converge para:

             SIEM
              |
    +---------+---------+
    |         |         |
   RACF      CICS      USS
    |         |         |
   SMF       Db2       API

---

⏱️ 15. Métrica maravilhosa: MTTD

Mean Time To Detect

Tintim executa uma ação autorizada às:

02:17:00

O SOC percebe às:

02:24:00

Então:

MTTD = 7 minutos

---

🚑 MTTR

Depois:

02:24 detection
02:31 investigation
02:38 containment

Podemos medir:

Mean Time To Respond

ou métricas equivalentes definidas pela organização.

Agora Red Team deixou de ser espetáculo.

Virou dado.

---

🟣 16. Purple Team Matrix

A melhor tabela do exercício:

Técnica simulada	Esperávamos detectar?	Detectamos?	Alerta	Resposta
Login anormal	Sim	Sim	Sim	Sim
Dataset proibido	Sim	Sim	Sim	Sim
Honey credential	Sim	Sim	Sim	Sim
Mudança USS simulada	Sim	Não	Não	—
API irregular	Sim	Sim	Sim	Parcial

A linha mais interessante é:

SIM | NÃO

Porque encontramos um:

Detection Gap

---

🧪 17. Injects

Uma operação divertida pode incluir eventos roteirizados.

Inject 01

Credencial falsa encontrada.

Inject 02

Acesso negado a dataset sensível.

Inject 03

API apresenta comportamento anormal.

Inject 04

Arquivo controlado aparece no USS.

Inject 05

Job inesperado aparece no ambiente de laboratório.

O Blue Team não necessariamente sabe quando cada um acontecerá.

Mas o controlador sabe.

---

🧑‍⚖️ 18. Os Dupond & Dupont entram na investigação

— Descobrimos o invasor.

— Exatamente. Descobrimos o invasor.

— Foi RED001.

— Precisamente. Foi RED001.

Tintim:

— RED001 é a conta do Red Team.

Silêncio.

Dupond:

— Então capturamos o Red Team.

Dupont:

— Caso encerrado.

Eis outro ensinamento:

Detectar uma identidade não significa compreender o incidente.

Contexto importa.

---

📸 19. Evidence Pack

Cada ação do Red Team recebe identificação.

RT-001
RT-002
RT-003
...

Para cada uma:

Timestamp:
System:
Identity:
Action:
Expected Detection:
Observed Detection:
Evidence:
Impact:
Rollback:

Exemplo:

ID: RT-017

TIME:
02:17:34

SYSTEM:
ZOSLAB

IDENTITY:
RED001

ACTION:
Attempted access to controlled resource

EXPECTED:
RACF denial + SIEM alert

OBSERVED:
RACF denial recorded
No SIEM alert generated

RESULT:
PARTIAL FAILURE

Isso vale ouro.

---

🚦 20. Severity

Não classifique tudo como:

CRITICAL!!!!

Senão nada é crítico.

Uma classificação razoável pode considerar:

LIKELIHOOD
     ×
IMPACT
     =
RISK

Exemplo:

Finding	Probabilidade	Impacto	Risco
Privilégio excessivo	Alta	Alto	Crítico
Logging incompleto	Média	Alto	Alto
Conta antiga	Média	Médio	Médio
Banner informativo	Baixa	Baixo	Baixo

---

🧠 21. O verdadeiro prêmio: Attack Path

O finding mais poderoso geralmente não é:

“Encontramos permissão errada.”

É:

USER
 ↓
DEV RESOURCE
 ↓
AUTOMATION
 ↓
SERVICE ID
 ↓
PRODUCTION RESOURCE
 ↓
SENSITIVE DATA

Nenhum elo isoladamente parece apocalíptico.

A cadeia é que importa.

---

🧀 Swiss Cheese Model

Imagine cinco controles:

IDENTITY
   ↓
RACF
   ↓
APPLICATION
   ↓
DATABASE
   ↓
MONITORING

Cada um possui buracos.

O incidente acontece quando os buracos se alinham.

O     O
  O      O
     O
        O
-----------> INCIDENT

O Red Team procura alinhamentos.

O Blue Team fecha buracos.

O Purple Team verifica se eles realmente foram fechados.

---

🚨 22. STOP CONDITIONS

O exercício deve parar imediatamente caso exista:

instabilidade
degradação inesperada
risco a dados reais
efeito fora do escopo
impacto em clientes
comportamento não previsto
perda de observabilidade

Palavra de emergência:

HADDOCK

Se alguém disser:

HADDOCK

todos param.

Porque nenhuma vulnerabilidade vale um SEV1 real.

---

🧹 23. Rollback

O Red Team precisa sair sem deixar lembranças.

Checklist:

• remover artefatos de teste;

• invalidar credenciais temporárias;

• remover certificados temporários;

• restaurar configurações;

• apagar dados sintéticos quando apropriado;

• confirmar integridade;

• registrar mudanças revertidas;

• obter validação operacional.

---

📋 24. Relatório técnico

Estrutura sugerida:

1. Executive Summary
2. Scope
3. Rules of Engagement
4. Architecture
5. Methodology
6. Timeline
7. Attack Paths
8. Findings
9. Detection Results
10. Response Results
11. Evidence
12. Risk Classification
13. Recommendations
14. Remediation Plan
15. Retest Plan

---

👔 25. Relatório executivo

Não entregue ao diretor:

ICH408I
FACILITY
SURROGAT
APF
USS
SMF 80

e espere aplausos.

Traduza.

Em vez de:

“Encontramos autorização excessiva no recurso X.”

Explique:

“Uma conta de desenvolvimento poderia, através de uma cadeia de permissões e automação, alcançar recursos de produção além das responsabilidades previstas para sua função.”

Agora a diretoria entende.

---

📊 26. Scorecard

No final:

PREVENTION       82%
DETECTION        71%
INVESTIGATION    88%
CONTAINMENT      79%
RECOVERY         94%

E principalmente:

ATTACK ACTIONS:        30
DETECTED:              24
MISSED:                 6

Então perguntamos:

Por que seis passaram?

Essa pergunta vale mais do que declarar:

“O Red Team venceu.”

---

🔁 27. Retest

Depois das correções:

RT-017

é repetido.

Antes:

ATTACK → LOG → SILENCE

Depois:

ATTACK
  ↓
LOG
  ↓
SIEM
  ↓
ALERT
  ↓
ANALYST
  ↓
CASE

Agora temos evidência de melhoria.

---

🏆 28. Quem ganhou?

Tintim pergunta:

— Então o Red Team venceu?

Haddock responde:

— Detectamos quase tudo!

Professor Girassol balança a cabeça.

Nenhum dos dois venceu.

Porque Red Team contra Blue Team não deveria ser:

RED
 VS
BLUE

Deveria terminar como:

RED
 +
BLUE
 =
PURPLE

O verdadeiro adversário é:

UNKNOWN RISK

---

🧭 29. Operação completa

Nossa campanha pode ser resumida assim:

                 AUTHORIZATION
                      ↓
                    SCOPE
                      ↓
            RULES OF ENGAGEMENT
                      ↓
               ARCHITECTURE
                      ↓
              RECONNAISSANCE
                      ↓
                 IDENTITY
                      ↓
                   RACF
                      ↓
                 DATASETS
                      ↓
                    JES
                      ↓
                    USS
                      ↓
                   APIs
                      ↓
                  CICS/MQ
                      ↓
                    Db2
                      ↓
          CONTROLLED SIMULATIONS
                      ↓
                 DETECTION
                      ↓
                RESPONSE
                      ↓
                 ROLLBACK
                      ↓
                 EVIDENCE
                      ↓
                  REPORT
                      ↓
               REMEDIATION
                      ↓
                  RETEST

---

🥚 Easter Eggs do Bellacosa Mainframe

Durante o exercício, espalhe apenas em laboratório artefatos obviamente sintéticos.

Dataset:

REDTEAM.TINTIN.UNICORN

Job:

//HADDOCK JOB ...

Arquivo:

/u/redteam/milu_was_here.txt

Identificador:

GIRASSOL-42

Mensagem:

DONT_PANIC

E a honey credential pode apontar para uma identidade chamada:

ZAPHOD42

Quem acompanha o Café sabe que o número 42 jamais aparece por acidente.

---

☕ 30. A grande lição

Um Red Team ruim demonstra:

“Olha o que conseguimos fazer.”

Um Red Team bom demonstra:

“Aqui está o caminho pelo qual conseguimos fazer.”

Um Red Team excelente acrescenta:

“Aqui estão os controles que deveriam ter impedido ou detectado cada etapa.”

E um exercício maduro termina dizendo:

“Corrigimos. Agora vamos tentar novamente.”

Porque segurança não é possuir um RACF perfeitamente configurado.

Não é comprar um SIEM.

Não é instalar mais um produto com dashboard vermelho.

Não é produzir 847 páginas de compliance.

Segurança é conseguir responder continuamente:

QUEM pode fazer O QUÊ
       ↓
EM QUAL recurso
       ↓
ATRAVÉS DE QUAL caminho
       ↓
QUEM perceberia
       ↓
EM QUANTO tempo
       ↓
E O QUE FARÍAMOS depois?

Tintim fecha o notebook.

Milu finalmente dorme.

Professor Girassol arquiva o relatório.

Os Dupond & Dupont continuam investigando a própria conta de teste.

Haddock olha para o console.

Nenhum alerta.

Nenhum incidente.

Produção funcionando.

Ele pega o café.

— Finalmente acabou.

Nesse instante aparece:

ICH408I USER(ZAPHOD42) ...

Haddock fica imóvel.

Tintim olha para Girassol.

Girassol olha para Tintim.

Milu levanta uma orelha.

E alguém pergunta:

— Professor... ZAPHOD42 fazia parte do exercício?

Girassol consulta a planilha.

Pausa.

— Curiosamente... não.

          >>> TO BE CONTINUED <<<

☕ Bellacosa Mainframe

Porque MAXCC=0 significa apenas que o computador terminou o que você mandou fazer.

Nunca significou que você deveria ter mandado.

Para ir mais longe

https://eljefemidnightlunch.blogspot.com/2026/08/red-team-e-os-doze-trabalhos-de-asterix.html

https://eljefemidnightlunch.blogspot.com/2026/02/hackers-no-cinema-quando-hollywood.html

https://eljefemidnightlunch.blogspot.com/2024/06/sherlock-holmes-cobol-e-o-misterio-da.html

https://eljefemidnightlunch.blogspot.com/2026/08/a-causa-de-r-300-milhoes-e-o-algoritmo.html