 |
| Bellacosa Mainframe e a cybersegurança parte II |
☕ Um Café no Bellacosa Mainframe
Capítulo II — Operação, Detecção, Resposta e Recuperação
Ou: o Agente 86 recebeu um alerta às 03h17, entrou no SOC pelo Cone do Silêncio, descobriu que a KAOS estava usando uma conta perfeitamente válida — e Igor restaurou o backup errado porque a fita estava etiquetada como “FINAL-FINAL-AGORA-VAI”
Prólogo — O telefone-sapato tocou às 03h17
O telefone-sapato tocou às 03h17 da madrugada.
O Agente 86 levou alguns segundos para encontrá-lo. Primeiro atendeu o abajur, depois tentou conversar com uma torradeira e finalmente percebeu que estava usando o aparelho no pé direito.
— 86, temos um incidente — disse o Chefe.
— A KAOS invadiu o datacenter?
— Ainda não sabemos.
— Roubaram dados?
— Ainda não sabemos.
— Derrubaram o CICS?
— Ainda não sabemos.
— Então o que sabemos?
— Um alerta apareceu no SIEM. Depois apareceram outros 4.732. Igor clicou em “reconhecer todos” para limpar a tela.
— Chefe... acreditaria se eu dissesse que isso fazia parte da estratégia?
— Não.
— Eu também não.
No Capítulo I aprendemos o vocabulário: ativo, ameaça, vulnerabilidade, risco, confidencialidade, integridade, disponibilidade, autenticação, autorização, malware, criptografia e programação segura.
Agora começa a parte que separa a segurança decorativa da segurança operacional.
Porque nenhum ambiente consegue impedir todos os erros, ataques e falhas. Em algum momento uma senha será reutilizada, uma biblioteca apresentará vulnerabilidade, um funcionário clicará, um fornecedor será comprometido, um certificado vencerá, um job executará fora de sequência ou um atacante usará uma credencial válida.
A pergunta profissional não é apenas:
“Como impedir que algo aconteça?”
Também precisamos perguntar:
Como perceberemos rapidamente?
Como distinguiremos ruído de incidente real?
Quem terá autoridade para agir?
Como conteremos sem destruir o negócio?
Que evidências serão preservadas?
Como recuperaremos dados e serviços confiáveis?
Como evitaremos repetir a mesma história?
Pegue o café. O sistema está online, mas isso não significa que esteja saudável — e uma luz verde sozinha nunca absolveu ninguém.
1. Prevenção é apenas o primeiro turno da operação
Existe uma fantasia confortável segundo a qual segurança funciona como uma muralha medieval: instalamos firewall, antivírus, RACF, MFA e criptografia; depois trancamos a porta e voltamos para casa.
O atacante moderno prefere justamente não parecer atacante. Ele pode entrar com:
conta legítima comprometida;
token de sessão roubado;
API autorizada usada de forma abusiva;
ferramenta administrativa existente;
job scheduler corporativo;
acesso remoto de fornecedor;
credencial de serviço esquecida;
dependência comprometida no pipeline.
Quando uma operação maliciosa utiliza mecanismo legítimo, a simples pergunta “o acesso foi autorizado pelo sistema?” não basta. Precisamos perguntar se o comportamento é coerente com a identidade, a função, o horário, o ativo, o volume e o contexto.
Um usuário autorizado a consultar cem clientes por dia pode estar tecnicamente autorizado e comportamentalmente suspeito ao consultar dois milhões durante a madrugada.
No mainframe, uma transação pode apresentar:
RACF RC=0;CICS funcionando;
Db2 respondendo;
conexão TLS válida;
programa corretamente autorizado;
e ainda assim representar fraude, abuso interno ou credencial comprometida.
Segurança operacional vive nessa diferença entre permitido e esperado.
2. Antes do alerta: conheça o que existe
Não existe detecção séria sem inventário. Se ninguém conhece os ativos, ninguém sabe quais eventos importam.
2.1 Inventário não é apenas lista de servidores
Um inventário útil inclui:
sistemas e aplicações;
LPARs e subsistemas;
started tasks;
regiões CICS e IMS;
bancos Db2 e arquivos VSAM;
datasets críticos;
filas e canais MQ;
APIs e endpoints;
servidores USS;
certificados e chaves;
usuários privilegiados;
contas técnicas;
agendamentos;
pipelines e repositórios;
fornecedores e conexões externas;
responsáveis técnicos e de negócio.
O ativo precisa ter proprietário. “A aplicação é da TI” não é propriedade; é abandono coletivo com crachá.
Pergunte:
Quem responde pelo serviço?
Qual processo de negócio depende dele?
Quais dados são tratados?
Qual a criticidade?
Qual o RTO e o RPO?
Quem pode interrompê-lo numa emergência?
Onde estão os contatos fora do expediente?
Quais sistemas precisam voltar antes dele?
2.2 Classificação
Nem todo dado merece o mesmo controle. Classifique conforme sensibilidade, impacto e obrigação legal:
público;
interno;
confidencial;
restrito;
regulado;
crítico para continuidade.
O objetivo não é criar etiquetas bonitas. A classificação deve alterar comportamento: acesso, criptografia, retenção, mascaramento, backup, logging, transmissão e descarte.
2.3 Dependências invisíveis
Um sistema aparentemente simples pode depender de DNS, identidade, certificados, MQ, banco, storage, scheduler, rede, fornecedor e relógio sincronizado.
O Agente 86 pode restaurar o CICS em dez minutos e continuar parado porque o certificado do API gateway venceu três semanas antes e ninguém o colocou no inventário.
Dica Bellacosa: desenhe a cadeia mínima da transação crítica, da entrada até o registro final. Marque cada identidade, protocolo, fila, arquivo, banco, log e fornecedor atravessado. Esse mapa vale ouro durante um incidente.
3. Gestão de vulnerabilidades — scanner não é oráculo
O scanner encontra sinais de fraqueza. Ele não conhece sozinho todo o contexto do negócio.
3.1 CVE, CWE e CVSS
CVE identifica uma vulnerabilidade conhecida específica.
CWE descreve uma classe de fraqueza, como validação inadequada ou controle de acesso incorreto.
CVSS ajuda a expressar severidade técnica.
Severidade não é igual a risco empresarial.
Uma vulnerabilidade crítica pode estar em componente não executado, isolado e sem dados relevantes. Outra de severidade média pode estar numa API exposta que controla pagamentos.
Priorize considerando:
exploração conhecida;
exposição à Internet;
privilégio necessário;
facilidade de exploração;
criticidade do ativo;
dados alcançáveis;
controles compensatórios;
impacto operacional;
movimento lateral possível.
3.2 O ciclo correto
Descobrir os ativos.
Identificar vulnerabilidades.
Validar o achado.
Avaliar exposição e impacto.
Priorizar.
Corrigir ou mitigar.
Testar novamente.
Registrar exceções e prazos.
Medir recorrência.
“Aceitar risco” não significa ignorar. Significa que uma autoridade informada aceitou determinado risco por período definido, com justificativa, controles compensatórios e data de revisão.
3.3 Patch sem ensaio também derruba produção
Atualizar é essencial, mas mudança insegura pode criar indisponibilidade. O processo precisa de:
avaliação;
ambiente de teste;
plano de implementação;
rollback;
janela;
validação técnica e funcional;
monitoração pós-mudança.
No mainframe, SMP/E, HOLDDATA, manutenção de middleware, compatibilidade de compiladores, DBRM, packages, exits e integrações precisam ser entendidos. Segurança e disponibilidade não são inimigas; são requisitos que precisam conversar.
4. Evento, alerta, incidente e crise — não são sinônimos
Essa distinção evita que toda luz vermelha convoque o presidente da empresa.
Evento
Algo observável aconteceu:
login;
job iniciado;
dataset aberto;
regra de firewall acionada;
falha de autenticação;
transação concluída.
A maioria dos eventos é normal.
Alerta
Uma regra, modelo ou analista marcou determinado evento ou conjunto como digno de atenção.
Exemplo:
Dez falhas de login para a mesma conta em cinco minutos.
Alerta não prova ataque. Pode ser usuário esquecendo senha, script mal configurado ou tentativa hostil.
Incidente
Ocorrência que compromete ou ameaça confidencialidade, integridade, disponibilidade, autenticidade ou operação.
Exemplos:
conta comprometida;
acesso indevido;
malware confirmado;
exfiltração;
alteração não autorizada;
indisponibilidade causada por ataque.
Crise
Quando o impacto ultrapassa a resposta técnica e exige coordenação executiva, jurídica, regulatória, comunicacional e de continuidade.
Um incidente pode ser tecnicamente pequeno e reputacionalmente enorme. Outro pode ser tecnicamente complexo, mas bem contido e quase invisível ao cliente.
5. Logging — a caixa-preta do datacenter
Log é memória operacional. Sem ele, a investigação depende de palpites, lembranças e do testemunho de Igor, que afirma ter apertado “o botão verde — ou talvez o vermelho”.
5.1 O que registrar
Um registro útil responde:
quando aconteceu;
qual identidade agiu;
de onde veio;
qual recurso foi usado;
qual ação foi tentada;
qual foi o resultado;
qual regra autorizou ou negou;
qual identificador correlaciona a transação;
qual foi o código de retorno;
quanto tempo levou.
5.2 O que não registrar
Evite colocar em log:
senha;
chave privada;
token completo;
código MFA;
número integral de cartão;
dado pessoal sem necessidade;
conteúdo confidencial indiscriminado.
Log também é dado sensível. Ele pode revelar identidades, arquitetura, horários, endereços, comandos e regras internas.
5.3 O identificador de correlação
Uma transação moderna atravessa várias camadas. Sem um identificador consistente, cada sistema conta uma história separada.
Imagine:
CORRELATION-ID: TX-20260825-031700-0086Esse identificador pode acompanhar API gateway, z/OS Connect, CICS, programa COBOL, Db2, MQ e resposta ao cliente.
5.4 Exemplo COBOL didático
DISPLAY 'SECLOG|'
'CORR=' WS-CORRELATION-ID '|'
'USER=' WS-USER-ID '|'
'ACTION=TRANSFERENCIA|'
'RESULT=' WS-RESULTADO '|'
'RC=' WS-RETURN-CODEEm produção, o formato deve ser padronizado, protegido e integrado à plataforma de logging. O importante é não escrever mensagens vagas como:
DEU ERRO“Deu erro” é a versão digital de encontrar um cadáver com um bilhete dizendo “alguma coisa aconteceu”.
5.5 Tempo confiável
Sem sincronização de horário, a timeline vira ficção científica. Um servidor afirma que a credencial foi usada antes de ser roubada; outro registra a resposta antes da requisição.
Mantenha fontes de tempo confiáveis, timezone conhecido e tratamento consistente.
6. SIEM, SOC e o perigo da árvore de Natal
SIEM
Security Information and Event Management coleta, normaliza, correlaciona e pesquisa dados de segurança.
Ele pode reunir:
autenticação;
endpoints;
firewall;
cloud;
aplicações;
banco;
mainframe;
identidade;
vulnerabilidades;
threat intelligence.
Mas SIEM não é um detetive autônomo infalível. Sem fontes corretas, regras, contexto e operação, ele vira uma árvore de Natal: milhares de luzes piscando, ninguém sabendo qual representa incêndio.
SOC
Security Operations Center é a capacidade humana e processual de monitorar, analisar e coordenar resposta.
Pode ser interno, terceirizado ou híbrido. O importante é possuir:
cobertura definida;
responsabilidades;
níveis de escalonamento;
playbooks;
acesso a especialistas;
métricas;
autoridade para agir.
Falso positivo e falso negativo
Falso positivo: o alerta aponta ameaça inexistente.
Falso negativo: a ameaça existe, mas não é detectada.
Reduzir falsos positivos demais pode aumentar falsos negativos. Tornar a regra sensível demais pode afogar os analistas.
Detecção é equilíbrio, contexto e melhoria contínua.
Métricas que importam
tempo para detectar;
tempo para qualificar;
tempo para conter;
tempo para recuperar;
recorrência;
percentual de ativos cobertos;
qualidade das fontes;
alertas sem proprietário;
incidentes descobertos externamente.
Não comemore apenas “um milhão de eventos processados”. Isso mede volume, não proteção.
7. Mainframe também precisa falar com o SOC
O estereótipo do mainframe isolado morreu quando conectamos TCP/IP, web, APIs, DevOps, fornecedores e estações distribuídas.
No IBM Z, fontes relevantes podem incluir:
SMF;
registros RACF;
zSecure ou ferramentas equivalentes;
CICS monitoring e journaling;
Db2 audit e traces;
MQ events;
IMS logs;
JES e SDSF;
z/OSMF;
Communications Server;
USS syslog e audit;
FTP, SSH, TN3270 e APIs;
alterações em datasets e bibliotecas sensíveis.
Exemplos de sinais importantes
sucessivas falhas de autenticação;
uso incomum de usuário privilegiado;
alteração em perfil RACF;
concessão de
SPECIAL,OPERATIONSou acesso excessivo;acesso fora do padrão a dataset sensível;
job submetido por identidade incomum;
mudança em biblioteca APF;
novo UID(0) no USS;
certificado alterado;
volume incomum de leitura ou transferência;
canal MQ criado ou modificado;
API chamada em velocidade incompatível com uso humano.
O desafio não é apenas extrair SMF. É transformar registros em contexto compreensível para o SOC.
Um alerta “ICH408I” sem explicação pode não ajudar um analista distribuído. Enriqueça com:
ativo;
proprietário;
criticidade;
identidade;
perfil envolvido;
histórico;
ação recomendada.
8. MITRE ATT&CK — o catálogo de comportamento da KAOS
O MITRE ATT&CK é uma base de conhecimento sobre táticas e técnicas observadas em adversários reais. Não é uma lista de produtos, nem uma sequência obrigatória.
Entre as táticas empresariais estão:
Reconhecimento;
Desenvolvimento de Recursos;
Acesso Inicial;
Execução;
Persistência;
Escalada de Privilégio;
Evasão;
Acesso a Credenciais;
Descoberta;
Movimento Lateral;
Coleta;
Comando e Controle;
Exfiltração;
Impacto.
O valor operacional está em perguntar:
“Se alguém executar esta técnica em nosso ambiente, quais sinais veremos?”
Exemplo
O atacante obtém senha de fornecedor.
Acesso Inicial: usa serviço remoto legítimo.
Descoberta: enumera sistemas e permissões.
Acesso a Credenciais: encontra segredo num script.
Movimento Lateral: alcança servidor intermediário.
Coleta: reúne relatórios.
Exfiltração: envia pequenos volumes.
Impacto: executa ransomware para distrair.
Se a empresa possui regra apenas para o ransomware, detecta o último ato e perde a investigação inteira.
O ATT&CK ajuda a construir cobertura, exercícios de Red Team, hipóteses de hunting e linguagem comum. A matriz é um mapa do comportamento, não um bingo de checkboxes. MITRE ATT&CK
9. Threat hunting — procurar antes que o alarme toque
Monitoramento tradicional responde a regras conhecidas. Threat hunting começa com hipótese.
Exemplo:
“Se uma credencial privilegiada fosse comprometida, o atacante poderia consultar datasets fora de seu padrão sem gerar falha de autorização.”
O hunter procura:
horários incomuns;
ativos nunca usados por aquela identidade;
sequência atípica de comandos;
crescimento de volume;
combinação rara de eventos;
acessos legítimos com finalidade suspeita.
O processo:
Formular hipótese.
Identificar fontes de dados.
Pesquisar comportamento.
Validar contexto.
Investigar anomalias.
Criar nova detecção.
Melhorar a telemetria.
Threat hunting não é sair procurando “qualquer coisa estranha”. É investigação orientada por hipótese e conhecimento do ambiente.
10. Resposta a incidentes — o plano antes do incêndio
O NIST finalizou em 2025 a SP 800-61 Rev. 3, integrando resposta a incidentes ao gerenciamento de risco e às funções do CSF 2.0. A mensagem central é poderosa: resposta não começa quando o ataque é confirmado; preparação, governança, identificação, proteção e detecção fazem parte da capacidade de responder. NIST SP 800-61 Rev. 3
Para fins operacionais, podemos organizar a missão em:
Preparação.
Detecção e análise.
Contenção.
Erradicação.
Recuperação.
Lições aprendidas.
10.1 Preparação
Defina antes:
equipe;
contatos;
autoridade;
canais alternativos;
ferramentas;
acesso emergencial;
playbooks;
critérios de severidade;
obrigações legais;
fornecedores;
procedimentos de evidência;
ambientes de recuperação.
Se o diretório corporativo estiver indisponível, como a equipe encontrará os telefones? Se o e-mail estiver comprometido, por onde conversará? Se o cofre de senhas depender do ambiente atacado, quem abrirá a porta?
O Cone do Silêncio do Agente 86 é um ótimo exemplo de canal alternativo, exceto pelo pequeno detalhe de nunca funcionar.
10.2 Detecção e análise
Pergunte:
o que aconteceu?
quando começou?
quais ativos?
quais identidades?
qual escopo?
há persistência?
houve exfiltração?
o ataque continua?
qual impacto?
quais evidências sustentam a conclusão?
Não confunda ausência de evidência com evidência de ausência. Talvez o log não exista, esteja incompleto ou tenha sido apagado.
10.3 Contenção
Objetivo: limitar dano sem destruir capacidade de investigar ou operar.
Ações possíveis:
bloquear credencial;
revogar token;
isolar endpoint;
segmentar rede;
suspender integração;
limitar funcionalidade;
bloquear indicador;
preservar imagem e memória;
colocar regra temporária.
Desligar tudo pode conter o ataque e também apagar memória volátil, interromper negócio e alertar o adversário.
A contenção precisa considerar risco, evidência e missão.
10.4 Erradicação
Remova causa e presença:
malware;
conta criada;
persistência;
segredo exposto;
configuração insegura;
vulnerabilidade explorada;
acesso do fornecedor comprometido.
Trocar uma senha não resolve se o atacante possui token válido, outra conta ou chave de API.
10.5 Recuperação
Retorne de forma controlada:
restaure de fonte confiável;
aplique correções;
rotacione segredos;
valide integridade;
monitore intensamente;
reative em etapas;
confirme função de negócio;
comunique interessados.
10.6 Lições aprendidas
Pergunte sem caça às bruxas:
o que permitiu o incidente?
o que funcionou?
o que atrasou?
quais dados faltaram?
quais decisões foram confusas?
que controle precisa mudar?
como testar a melhoria?
Lição aprendida sem ação, responsável e prazo é apenas literatura pós-apocalíptica.
11. Classificação de severidade e playbooks
Nem todo incidente exige a mesma mobilização.
Uma matriz pode considerar:
criticidade do ativo;
sensibilidade do dado;
abrangência;
persistência;
impacto ao cliente;
indisponibilidade;
obrigação regulatória;
risco à vida ou segurança física;
exposição pública.
Playbook
Playbook é roteiro para tipo de ocorrência:
phishing;
conta comprometida;
ransomware;
vazamento;
DDoS;
segredo exposto;
fornecedor comprometido;
alteração privilegiada.
Ele deve informar:
Gatilhos.
Dados necessários.
Passos iniciais.
Decisões e autoridades.
Contenção.
Evidências.
Comunicações.
Critério de encerramento.
Playbook não substitui julgamento. Serve para que o julgamento comece vários degraus acima do pânico.
12. Forense digital — não pise nas pegadas da KAOS
Forense busca preservar, examinar e interpretar evidências digitais.
Princípios básicos
preservar o original;
documentar cada ação;
controlar acesso;
registrar horário e responsável;
calcular hashes quando apropriado;
trabalhar sobre cópias;
manter cadeia de custódia;
usar ferramentas e procedimentos defensáveis.
Ordem de volatilidade
Algumas evidências desaparecem rapidamente:
memória;
conexões;
processos;
sessões;
arquivos temporários;
disco;
backups e arquivos históricos.
Por isso, “desligue imediatamente” nem sempre é a primeira resposta correta.
Timeline
A investigação procura montar sequência:
03:12 — login remoto do fornecedor
03:14 — consulta a inventário
03:17 — falhas RACF em recurso crítico
03:19 — novo job submetido
03:23 — volume anormal em fila MQ
03:28 — transferência externa iniciada
03:31 — primeiro alerta qualificadoUma timeline liga identidades, ativos e técnicas. Sem tempo sincronizado e correlação, ela vira um quebra-cabeça produzido por Kafka depois de três expressos.
Cadeia de custódia
Documenta quem coletou, quando, onde, como, quem recebeu e quais transformações ocorreram. É essencial quando a evidência pode sustentar processo disciplinar, regulatório ou judicial.
13. Ransomware — o incêndio pode ser cortina de fumaça
Ransomware moderno pode envolver:
acesso inicial;
roubo de credenciais;
movimento lateral;
desativação de defesa;
exfiltração;
destruição de backup;
criptografia;
extorsão.
O arquivo criptografado é o sintoma visível. O incidente começou antes.
Primeiras perguntas
Quais sistemas foram atingidos?
O ataque continua?
Há exfiltração?
Quais credenciais foram usadas?
Backups foram alcançados?
Há cópia offline?
Quais dados e clientes estão envolvidos?
Existe obrigação de notificação?
Backups
A CISA recomenda backups offline, criptografados e testados regularmente. Backup conectado permanentemente ao mesmo domínio e acessível pelas mesmas credenciais pode ser destruído junto com produção. CISA StopRansomware
Uma regra prática conhecida é 3-2-1-1-0:
3 cópias dos dados;
2 tipos de mídia ou plataformas;
1 cópia fora do local;
1 cópia offline ou imutável;
0 erros após testes de verificação.
Não trate a fórmula como religião. Ajuste ao risco, à arquitetura e ao negócio.
Restaurar não encerra o incidente
Restaurar recupera disponibilidade. Ainda é necessário:
eliminar persistência;
corrigir entrada;
rotacionar credenciais;
validar integridade;
investigar vazamento;
monitorar retorno;
cumprir obrigações.
14. RTO, RPO e a fita “FINAL-FINAL”
RTO — Recovery Time Objective
Quanto tempo o serviço pode ficar indisponível.
RPO — Recovery Point Objective
Quanto dado pode ser perdido, expresso como ponto no tempo.
Exemplo:
RTO: duas horas;
RPO: quinze minutos.
Isso significa que a solução deve restaurar em até duas horas e perder no máximo quinze minutos de dados, conforme o cenário planejado.
Dependência e ordem de recuperação
Não adianta recuperar aplicação antes de identidade, rede, storage, banco ou mensageria.
Monte uma ordem:
infraestrutura fundamental;
identidade e segurança;
dados e mensageria;
serviços centrais;
canais;
integrações;
relatórios e funções secundárias.
Backup não testado é esperança magnética
Teste:
leitura;
integridade;
tempo de restauração;
procedimentos;
permissões;
dependências;
capacidade da equipe;
recuperação em ambiente isolado.
Igor possuir vinte fitas não significa possuir vinte backups. Pode possuir dezenove cópias ilegíveis e uma gravação do almoço de confraternização de 1998.
15. Continuidade de negócio e recuperação de desastre
Continuidade de negócio
Como manter funções essenciais durante interrupção.
Disaster Recovery
Como restaurar tecnologia e dados após desastre.
São relacionados, mas não idênticos.
Uma empresa pode continuar aceitando operações com limites reduzidos enquanto o ambiente completo é recuperado. Essa operação degradada precisa ser desenhada, autorizada e testada.
Pergunte:
Qual é o serviço mínimo viável?
Que operações podem esperar?
Que controles não podem ser removidos?
Como evitar duplicidade no reprocessamento?
Como reconciliar dados depois?
Como comunicar clientes e reguladores?
Nunca resolva disponibilidade removendo segurança de forma permanente. “Modo emergência” precisa ter escopo, prazo, auditoria e retorno controlado.
16. O programador COBOL dentro da resposta
O desenvolvedor não é figurante. Ele conhece regras, arquivos, commits, códigos de retorno e comportamentos que as ferramentas não compreendem.
Durante um incidente, pode ajudar a responder:
esta sequência é possível?
que arquivos são atualizados?
existe reprocessamento?
a operação é idempotente?
o rollback cobre tudo?
quais mensagens indicam fraude?
que campos correlacionam transações?
qual job gera este resultado?
qual versão estava em produção?
Exemplo: tratamento de retorno
EVALUATE TRUE
WHEN WS-DB2-SQLCODE = 0
MOVE 'SUCESSO' TO WS-RESULTADO
WHEN WS-DB2-SQLCODE = 100
MOVE 'NAO-ENCONTRADO' TO WS-RESULTADO
WHEN OTHER
MOVE 'FALHA-TECNICA' TO WS-RESULTADO
PERFORM REGISTRAR-EVENTO-SEGURANCA
PERFORM EXECUTAR-ROLLBACK
END-EVALUATEO objetivo não é registrar todo erro como ataque. É produzir sinal confiável e impedir estado inconsistente.
Idempotência
Se uma mensagem for processada novamente, o resultado deve ser controlado. Uma transferência não pode dobrar porque o consumidor caiu depois do débito e antes do acknowledgement.
Use:
identificador único;
controle de estado;
deduplicação;
transação adequada;
reconciliação.
Segurança no erro
Evite:
continuar com dados incompletos;
conceder acesso porque o autorizador não respondeu;
ocultar falha crítica;
expor SQL, dataset ou stack ao usuário;
gravar segredo no dump;
repetir operação destrutiva sem controle.
17. Exercício completo — Operação Telefone-Sapato
Cenário
Às 03h17, o SIEM detecta:
login válido de fornecedor;
origem incomum;
acesso a documentação interna;
falhas RACF em dataset crítico;
job submetido fora da janela;
aumento de volume numa fila MQ.
Passo 1 — Qualificar
Confirme fontes, horários, identidade, ativo e criticidade. Contate o fornecedor por canal confiável.
Passo 2 — Declarar incidente
Há combinação suficiente para investigação coordenada. Defina severidade, líder e canal seguro.
Passo 3 — Preservar
Guarde logs, eventos, comandos, metadados, configurações e evidências voláteis relevantes.
Passo 4 — Conter
revogue sessão;
suspenda a credencial;
limite conexão do fornecedor;
isole o ponto intermediário;
monitore contas relacionadas.
Passo 5 — Determinar escopo
Pesquise:
onde a credencial foi usada;
que recursos foram lidos;
que comandos foram executados;
se houve persistência;
se dados saíram;
se outras identidades foram obtidas.
Passo 6 — Erradicar
remova persistência;
corrija vulnerabilidade;
rotacione segredos;
revise acessos;
valide sistemas envolvidos.
Passo 7 — Recuperar
Reative conexões em etapas, com monitoramento reforçado e aprovação dos responsáveis.
Passo 8 — Aprender
Talvez a causa não tenha sido “fornecedor malicioso”, mas:
ausência de MFA resistente a phishing;
acesso excessivo;
segmentação inadequada;
falta de alerta sobre origem;
segredo em documentação;
resposta lenta fora do expediente.
A solução precisa atingir causas e não apenas trocar a senha.
18. Checklist da madrugada
Quando o alerta chegar, respire e confirme:
Quem lidera?
Qual canal será usado?
O que sabemos como fato?
O que é hipótese?
Quais ativos e identidades estão envolvidos?
O ataque continua?
Que evidências precisam ser preservadas?
Qual contenção reduz dano sem destruir a investigação?
Quem pode autorizar indisponibilidade?
Há impacto legal, regulatório ou ao cliente?
Os backups são confiáveis e isolados?
Qual a ordem de recuperação?
Como validar integridade antes de voltar?
Que monitoração permanecerá reforçada?
Quem será responsável pelas melhorias?
Não execute comandos copiados às pressas sem compreender o efeito. Não publique detalhes em grupos amplos. Não negocie atribuição antes de confirmar fatos. Não confunda velocidade com correria.
Epílogo — O alarme que finalmente significava alguma coisa
Às 08h42, o Agente 86 voltou ao escritório do Chefe.
— Incidente contido. A credencial foi revogada, o acesso do fornecedor isolado, as evidências preservadas e os serviços críticos validados.
— Excelente, 86. E o backup?
— Igor restaurou a fita FINAL-FINAL-AGORA-VAI.
— Funcionou?
— Tecnicamente, sim.
— Tecnicamente?
— Recuperamos o sistema de folha de pagamento de 1997. Segundo os dados, eu ainda sou solteiro, o café custa cinquenta centavos e ninguém ouviu falar de ransomware.
— 86...
— Desculpe por isso, Chefe.
O Capítulo II termina com uma verdade que não cabe numa caixa de ferramenta: resiliência é uma capacidade organizacional.
Ela nasce quando inventário, vulnerabilidade, logging, detecção, resposta, forense, backup e recuperação funcionam juntos.
Prevenção reduz a probabilidade. Detecção reduz o tempo de permanência. Contenção reduz o alcance. Erradicação remove a causa. Recuperação devolve a missão. Aprendizado reduz a chance de repetição.
O melhor SOC não é o que possui a maior parede de monitores. É aquele que sabe quais sinais importam, possui autoridade para agir, preserva evidências, mantém o negócio informado e transforma cada incidente em melhoria verificável.
Para o programador COBOL iniciante, a lição é direta: seu código participa da defesa. Cada validação, return code, log, commit, rollback, identificador de correlação e regra de reprocessamento pode acelerar ou destruir uma investigação.
Quando o telefone-sapato tocar às 03h17, ninguém desejará uma mensagem dizendo apenas DEU ERRO.
Queremos saber o que ocorreu, com quem, onde, quando, em qual transação, com qual resultado — e como voltar para casa sem deixar a KAOS escondida dentro do próximo batch.
Referências para continuar a missão
☕ Um Café no Bellacosa Mainframe
Cibersegurança: dos fundamentos à recuperação
Uma jornada em dois capítulos para entender a linguagem da segurança, reconhecer riscos e organizar a operação antes, durante e depois de um incidente.
Vocabulário e Fundamentos da Cibersegurança
Tríade CIA, ativos, ameaças, vulnerabilidades, risco, malware, autenticação, criptografia, redes, aplicações web e codificação segura.
Ler o Capítulo I no artigo original →Operação, Detecção, Resposta e Recuperação
Inventário, vulnerabilidades, eventos, alertas, incidentes, crise, monitoramento, contenção, evidências, continuidade e recuperação.
Ler o Capítulo II no artigo original →Mapa da missão: o primeiro capítulo explica o que precisa ser protegido e por quê; o segundo mostra como observar, decidir, responder e restaurar a operação quando a prevenção não for suficiente.
Sem comentários:
Enviar um comentário