 |
| Bellacosa Mainframe e a auditoria do T800 |
☕ Um Café no Bellacosa Mainframe
Do Z3R0 ao HERO — Quando o T-800 Auditou o Datacenter, Desconfiou de Igor e Descobriu que Red Team Não É Só Uma Caveira no Terminal
Ou: o programador COBOL queria saber se era Blue ou Red, o Exterminador respondeu que primeiro ele precisava descobrir quem tinha UPDATE na tabela de pagamentos — e Igor, naturalmente, sugeriu colocar a senha no nome do dataset para não esquecê-la.
MODELO T-800 — STATUS: OPERACIONAL
MISSÃO ORIGINAL: localizar Sarah Connor.
MISSÃO ATUALIZADA: localizar o proprietário da conta técnica com privilégio excessivo.
AVISO: “HASTA LA VISTA, SEGREGAÇÃO DE FUNÇÕES INEXISTENTE.”
O universo da segurança da informação adora cores. Há o Red Team, que pensa como um adversário; o Blue Team, que protege, monitora e responde; e o Purple Team, que tenta impedir que os dois passem a reunião inteira discutindo quem ganhou a bandeirinha do CTF.
Mas, antes que alguém instale uma distribuição cheia de ferramentas, abra três terminais pretos e declare-se “hacker ético” no LinkedIn, convém uma pequena verdade digna de uma sala de máquinas: segurança não começa pelo ataque. Começa por compreender o sistema que se pretende proteger ou avaliar.
Para o programador COBOL iniciante, isso é quase uma boa notícia. Você já está entrando por uma porta que muita gente só encontra depois de anos: a porta dos processos críticos, dos dados que realmente importam, dos controles de acesso, dos jobs que não podem falhar e das mudanças que precisam deixar rastro. No mundo em que uma API moderna conversa com uma fila, que conversa com CICS, que conversa com Db2, que conversa com um batch de quarenta anos ainda pagando salário, ninguém pode tratar segurança como detalhe de rodapé.
1. O primeiro diagnóstico do T-800: Pentest, Red Team e Blue Team não são a mesma coisa
Um pentest é uma avaliação autorizada, normalmente com escopo definido, para encontrar e validar vulnerabilidades. Pode ser um portal, uma API, uma rede, um aplicativo móvel ou um ambiente cloud. A pergunta é direta: “que falhas existem aqui, qual o impacto e como corrigir?”
O Red Team vai além: simula, de forma controlada, um adversário tentando atingir um objetivo relevante para o negócio. Não está interessado em colecionar cinquenta alertas coloridos. Está interessado em testar uma hipótese: seria possível alguém alcançar um ativo crítico? Os controles perceberiam? A organização conteria a atividade a tempo?
Já o Blue Team vive no mundo real. Ele administra ou acompanha controles, investiga alertas, endurece configurações, gerencia vulnerabilidades, melhora logs, responde a incidentes e tenta impedir que o mês da empresa acabe em reunião de crise com jurídico, diretoria e café frio.
| Time | Pergunta principal | Entrega útil |
|---|---|---|
| Pentest | “Que vulnerabilidades existem no escopo?” | Achados priorizados, evidências e recomendações |
| Red Team | “Um adversário plausível atingiria o objetivo?” | Cadeia de risco simulada e avaliação de controles |
| Blue Team | “Como prevenimos, detectamos e respondemos?” | Controles, telemetria, investigação e recuperação |
| Purple Team | “O que aprendemos juntos?” | Correções testadas e detecções melhores |
O Red não existe para humilhar o Blue. Se a operação termina com “entramos e vocês não viram”, mas ninguém melhora log, regra, privilégio ou processo, a empresa acabou de pagar por um trailer de filme, não por segurança.
2. O erro que termina em ABEND: ferramenta antes de fundamento
Ferramenta é multiplicador. Multiplica velocidade quando há conhecimento; multiplica confusão quando não há.
Um scanner pode apontar uma versão vulnerável. Isso ainda não responde se o serviço está exposto, se a função vulnerável está ativa, se há rota de rede, se o controle compensatório existe ou se o impacto é relevante. O profissional precisa validar a hipótese sem provocar dano.
É igual ao COBOL. Decorar READ, WRITE e PERFORM não torna ninguém dono do processamento. É preciso entender arquivo, chave, status, commit, lock, dados de entrada, regra de negócio e consequência de uma atualização. Segurança é a mesma conversa, apenas com o T-800 olhando por cima do ombro.
Os fundamentos indispensáveis são:
Redes: DNS, TCP/IP, HTTP/S, TLS, proxy, VPN, roteamento, portas e segmentação.
Sistemas operacionais: usuários, grupos, permissões, processos, serviços, logs, atualizações e administração.
Programação: lógica, variáveis, validação, tratamento de erro, bibliotecas, APIs e leitura de código.
Dados: modelagem, autenticação no banco, permissões, cópias, backups, trilhas de auditoria e mascaramento.
Identidade: autenticação não é autorização; saber quem entrou não responde ao que essa pessoa pode fazer.
Negócio: um ativo crítico não é necessariamente o servidor mais caro; pode ser uma tabela, uma interface, uma conta técnica ou uma etapa invisível do processo.
Curiosidade de sala de máquinas
O mainframe ensinou há décadas uma lição que a nuvem redescobre quase todo ano: controle de acesso é uma política, não uma tela de login. Um ID autenticado pode continuar perigosíssimo se tiver autoridade excessiva, grupos herdados, permissões antigas ou uso compartilhado. RACF não lê pensamentos, mas obriga a fazer a pergunta certa: quem tem acesso a quê, por qual motivo, e com qual registro?
3. A tríade CIA: não é agência secreta, embora Igor tivesse gostado da ideia
Segurança protege, no mínimo, três propriedades:
Confidencialidade: somente pessoas e processos autorizados veem a informação.
Integridade: dados e transações não são alterados indevidamente.
Disponibilidade: serviços e informações permanecem acessíveis quando necessários.
Pense num pagamento. Se alguém vê o dado de outro cliente, há quebra de confidencialidade. Se consegue alterar a conta favorecida, há quebra de integridade. Se o sistema de pagamentos fica indisponível no fechamento, há quebra de disponibilidade.
E o caso real quase sempre mistura tudo. Uma credencial comprometida pode permitir leitura indevida; a mesma conta, com privilégio demais, pode alterar uma regra; a tentativa de conter o problema pode derrubar um serviço. Segurança não é uma caixinha isolada. É o conjunto inteiro do processo sob pressão.
4. Red Team profissional: o atacante autorizado que sabe a hora de parar
O Red Team avalia caminhos, não apenas máquinas. Dependendo do escopo formal, pode testar exposição externa, aplicações, APIs, configurações, identidade, segmentação, processos, fornecedores e aspectos físicos. A palavra que mantém tudo do lado certo é autorização.
Antes de qualquer exercício sério devem existir regras de engajamento: objetivo, período, ativos permitidos, sistemas proibidos, limites de impacto, contatos de emergência, tratamento de evidências, dados que não podem ser acessados e critério de parada.
“Try harder” é excelente para o laboratório. Em produção, a tradução profissional é: pare quando a evidência já prova o risco. Não se demonstra que um backup está vulnerável apagando-o. Não se demonstra que dados pessoais podem ser acessados copiando uma base inteira. Não se demonstra indisponibilidade derrubando a folha de pagamento.
O objetivo é obter evidência mínima, confiável e reproduzível. O T-800 chama isso de eficiência. O jurídico chama de sobrevivência.
5. Blue Team: o turno da madrugada, os logs e a pergunta que ninguém queria receber
Blue Team não é um analista hipnotizado por um painel cheio de alertas. É uma combinação de capacidades: monitoramento, engenharia de detecção, resposta a incidentes, gestão de vulnerabilidades, hardening, segurança de endpoints, cloud, aplicações, identidade, backups e continuidade.
Uma defesa madura distingue quatro coisas:
Evento: algo aconteceu; um login, uma alteração, uma conexão.
Alerta: uma regra considerou o evento suspeito.
Incidente: a investigação confirmou atividade indevida ou dano.
Crise: o impacto ultrapassou a capacidade normal de resposta e exige coordenação executiva, legal ou operacional.
Confundir tudo gera dois desastres clássicos: pânico por qualquer alerta ou silêncio até a manchete chegar. Logs são fundamentais porque sem eles a organização fica discutindo memória e impressão. Com registros adequados, ela reconstrói fatos.
Para quem trabalha em z/OS, isso tem sabor familiar. SMF, RACF, logs de CICS, Db2 e auditorias não são burocracia arqueológica: são peças da história que você precisará contar quando algo parecer estranho.
6. Purple Team: quando o treinamento deixa de ser guerra civil
Purple Team é colaboração deliberada. O Red apresenta uma simulação autorizada ou um comportamento relevante; o Blue observa a telemetria, avalia se houve alerta, investiga e propõe melhoria. Depois ocorre reteste.
Exemplo: um exercício mostra que uma alteração sensível em uma conta técnica não gerou alerta útil. A correção pode envolver revisão de privilégio, registro adicional, regra de correlação, aprovação de mudança e um playbook para investigação. O reteste comprova se a defesa agora enxerga o comportamento.
Não importa qual ferramenta foi usada. Importa se a empresa consegue detectar o comportamento. É por isso que o MITRE ATT&CK é tão útil: ele fornece uma linguagem para falar de objetivos e técnicas adversárias sem reduzir a discussão a uma marca de ferramenta ou a um comando da moda.
7. O mapa de carreira: do Z3R0 ao profissional confiável
Não existe atalho, mas há sequência melhor que sair colecionando cursos.
Passo 1 — Aprenda o caminho dos dados
Entenda uma transação de ponta a ponta. Um navegador chama uma API; a API autentica o usuário, consulta uma base ou um serviço corporativo, grava um log e devolve uma resposta. Pergunte em cada etapa: onde há identidade? Onde há autorização? Onde há dado sensível? O que é registrado? Quem administra?
Passo 2 — Construa um laboratório isolado
Use apenas ambientes feitos para estudo ou sistemas próprios. Não precisa de um datacenter da Skynet. Uma máquina virtual, uma aplicação de treinamento, um serviço de logs e controles simples já permitem exercitar observação, documentação, correção e reteste.
Monte sempre os dois lados: uma aplicação ou serviço intencionalmente frágil e a visibilidade defensiva correspondente. A grande lição não é “como entrar”; é “que evidência isso deixou e como eu deveria ter percebido?”
Passo 3 — Aprenda aplicações e APIs
Aplicações modernas concentram falhas que scanners podem não compreender: autorização inadequada, regra de negócio frágil, exposição excessiva de dados, integração confusa e validação só no navegador.
Exemplo seguro: se uma pessoa autenticada consegue acessar uma fatura que não lhe pertence trocando apenas um identificador, o defeito é de autorização. O sistema confirmou “quem é você?”, mas esqueceu de confirmar “você pode ver isto?”. O remédio não é apenas esconder o campo na tela; é validar a permissão no servidor, registrar tentativas e revisar o modelo de acesso.
Passo 4 — Estude identidade, cloud e DevSecOps
Hoje o perímetro é móvel. Usuários acessam SaaS, APIs usam tokens, pipelines implantam infraestrutura e contas de serviço conversam com múltiplos sistemas. Um segredo exposto, uma permissão IAM excessiva ou uma conta técnica sem dono podem ser mais graves que uma porta aberta.
O bom profissional pergunta: qual identidade executa isso? Qual privilégio ela possui? O que aconteceria se fosse usada indevidamente? Onde está o log? Há rotação de segredo? Existe menor privilégio?
Passo 5 — Escolha uma profundidade, mantenha a largura
Você pode especializar-se em segurança ofensiva, SOC, resposta a incidentes, AppSec, GRC, cloud ou mainframe. O formato ideal é o “T”: profundidade em uma área, entendimento amplo das demais.
Um programador COBOL pode construir uma especialidade particularmente rara: segurança de aplicações e integrações híbridas. Quando a frente moderna conversa com CICS, Db2, MQ, IMS, batch e arquivos críticos, entender os dois lados é uma vantagem enorme. A porta de entrada pode ser uma API; o cofre pode estar no backend legado.
8. CVE não é automaticamente risco — e scanner não é oráculo
Uma CVE é identificação pública de uma vulnerabilidade. Ela pode ser importante, mas não substitui análise. Para priorizar, considere exposição, pré-requisitos, valor do ativo, controles existentes e impacto.
Uma falha moderada em um portal público que expõe dados pessoais pode ser mais urgente que uma falha crítica em ambiente isolado, sem rota de rede e sem uso da função vulnerável. Risco é a combinação de probabilidade e impacto, não um número piscando em vermelho.
O relatório útil traduz isso. Em vez de “corrigir vulnerabilidade”, ele diz que ativo foi afetado, por que importa, como o controle falhou, qual equipe pode corrigir, que medida temporária reduz risco e como retestar.
9. O artefato mais subestimado: o relatório
Um relatório ruim é uma coleção de prints com caveira. Um relatório bom é uma ponte entre segurança e mudança real.
Ele deve explicar o cenário, evidência, impacto plausível, controles esperados, lacuna observada, recomendação prática e prioridade. Deve falar para executivos sem esconder a parte técnica e falar para técnicos sem transformar a conclusão em poesia corporativa.
Por exemplo: “Revisar a autorização de alterações de favorecido, separar criação de aprovação, limitar privilégios da conta técnica, registrar mudanças críticas e retestar o fluxo.” Isso dá à empresa um caminho. “Melhorar a segurança” só dá vontade de pedir mais café.
Epílogo — O T-800 fecha o ISPF
Ao final da auditoria, Igor pergunta se Red Team significa usar vermelho no terminal. O T-800 olha para a tela, identifica uma conta compartilhada, três permissões herdadas e um backup nunca restaurado em teste. Depois responde, com a ternura de uma prensa hidráulica:
“A COR É IRRELEVANTE. A AUSÊNCIA DE EVIDÊNCIA, NÃO.”
Ser Blue, Red ou Purple não é escolher uma fantasia. É escolher uma responsabilidade. O Red testa se a defesa resiste; o Blue constrói e opera essa defesa; o Purple garante que o aprendizado não morra no relatório. E o profissional que começa em COBOL traz algo precioso para todos eles: a noção de que sistemas importam porque processos e pessoas dependem deles.
Estude fundamentos. Pratique somente em ambientes autorizados. Aprenda a ler código, logs, permissões e fluxos de negócio. Respeite escopo. Documente bem. E desconfie de toda conta técnica cujo responsável seja descrito como “sempre foi assim”.
Porque, como o T-800 aprendeu naquele turno no datacenter, o futuro não é uma guerra entre máquinas e humanos. É uma planilha de acessos sem dono, uma API sem autorização e Igor dizendo: “Doutor, eu deixei a senha em comentários para facilitar a manutenção.”
