Bellacosa Mainframe e o controle dos logs

☕ UM CAFÉ NO BELLACOSA MAINFRAME

🧬 MYNE E A BIBLIOTECA DOS LOGS ESQUECIDOS — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE UMA IA PODE INVESTIGAR UM ATAQUE DE CINCO ANOS ATRÁS

SMF, RACF, CICS, Db2, MQ, Threat Intelligence, Historical Threat Hunting, IOC, TTP, embeddings, grafos temporais, Inteligência Artificial, COBOL, arqueologia digital — e o dia em que Myne descobriu que alguns livros só podem ser compreendidos depois de escritos.

🎬 PRÓLOGO — MYNE ENCONTROU UMA BIBLIOTECA QUE NINGUÉM LIA

Myne entrou no CPD carregando três livros.

Isso por si só não deveria surpreender ninguém que conhecesse Honzuki no Gekokujou: Shisho ni Naru Tame ni wa Shudan wo Erandeiraremasen.

Se existisse uma biblioteca dentro de um IBM z17, provavelmente ela tentaria conseguir um cartão de acesso antes mesmo de perguntar onde ficava a saída de emergência.

O programador COBOL olhou para ela.

— Myne, aqui não temos livros.

Ela apontou para as fitas, discos, datasets e arquivos históricos.

— Claro que têm.

— Isso são logs.

— Então vocês têm livros que as máquinas escrevem.

O programador ficou alguns segundos olhando para o terminal 3270.

Droga.

A menina tinha razão.

Porque existe uma maneira curiosa de entender o System Management Facilities — SMF.

O SMF é uma espécie de cronista do z/OS.

Jobs começam.

Jobs terminam.

Usuários entram.

Programas executam.

Recursos são acessados.

Subsistemas trabalham.

Eventos acontecem.

E o mainframe escreve.

E escreve.

Durante anos.

O problema é que frequentemente fazemos algo bastante humano:

guardamos livros que nunca mais lemos.

Myne abriu um deles.

Na capa estava escrito:

SMF — 2021

— O que aconteceu aqui?

— Nada.

— Você leu?

— Na época.

— E o que vocês sabiam naquela época?

Silêncio.

Myne sorriu.

Ali começava nosso problema.

Porque:

O passado não muda. Nosso conhecimento sobre o passado muda.

🦖 CAPÍTULO 1 — PRIMEIRO: O QUE DIABOS É UM LOG?

Antes de colocar inteligência artificial, embeddings, grafos e outros nomes bonitos na história, precisamos começar pelo básico.

Um computador executa operações.

Algumas dessas operações produzem registros.

Chamamos genericamente esses registros de logs, embora no mainframe existam estruturas muito mais específicas.

Imagine:

10:01 USER01 LOGIN
10:03 USER01 SUBMIT JOB
10:04 JOB01 START
10:06 JOB01 READ DATASET
10:07 JOB01 END RC=0000
10:09 USER01 LOGOFF

Isso é uma narrativa extremamente simplificada daquilo que aconteceu.

Perceba uma coisa importante.

O log normalmente não escreve:

10:03 HACKER COMEÇOU ATAQUE

Ele registra um evento.

Quem precisa interpretar o significado daquele evento somos nós.

No universo z/OS temos uma fonte particularmente importante:

SMF — System Management Facilities.

O SMF registra inúmeros tipos de atividades do sistema.

Existem diferentes record types, cada um representando determinadas categorias de informação.

Um exemplo muito conhecido é o SMF Type 30, relacionado ao ciclo de vida de jobs, started tasks, sessões TSO e outras atividades.

No mundo da segurança RACF encontramos registros como o SMF Type 80, capazes de registrar eventos relacionados à segurança.

Nosso programador COBOL pode imaginar algo conceitualmente semelhante a:

01 SECURITY-EVENT.
   05 EVENT-DATE       PIC X(10).
   05 EVENT-TIME       PIC X(08).
   05 USER-ID          PIC X(08).
   05 RESOURCE-NAME    PIC X(44).
   05 ACCESS-TYPE      PIC X(08).
   05 RESULT-CODE      PIC X(04).

Não é a estrutura real do SMF.

É apenas nosso copybook didático.

Agora imagine:

USER-ID       = JOAO
RESOURCE-NAME = FINANCE.PAYROLL
ACCESS-TYPE   = READ
RESULT-CODE   = 0000

Tudo certo.

João estava autorizado.

RACF respondeu:

ACCESS ALLOWED

O erro começa quando transformamos isso mentalmente em:

ACCESS ALLOWED = ATIVIDADE LEGÍTIMA

Não.

RACF respondeu uma pergunta:

Essa identidade possui autorização para realizar essa operação?

Mas existe outra pergunta:

Essa operação faz sentido dentro do comportamento esperado dessa identidade?

E outra:

Por que essa identidade acessou esse recurso às 02:17?

E outra:

O que aconteceu cinco minutos antes?

E outra:

O que aconteceu depois?

E finalmente:

Outras identidades fizeram exatamente a mesma sequência?

Agora nossa investigação começa a ficar interessante.

📚 CAPÍTULO 2 — MYNE DESCOBRE QUE O MAINFRAME ESCREVE LIVROS HÁ DÉCADAS

Myne observou as pilhas de registros históricos.

— Quanto tempo vocês guardam isso?

O operador respondeu:

— Depende.

Essa talvez seja uma das respostas mais importantes de toda nossa história.

Porque nenhuma IA pode analisar aquilo que deixou de existir.

Imagine:

2021 → LOGS → RETENÇÃO → DELETE

Chegamos a 2026.

Descobrimos uma nova técnica de ataque.

Queremos investigar 2021.

Mas:

DATA NOT FOUND

Fim da investigação.

IA não é necromante de storage.

Se o dado foi destruído, não existe prompt capaz de ressuscitá-lo fielmente.

Por isso retenção é uma decisão de segurança.

Uma organização pode preservar diferentes tipos de telemetria:

SMF
RACF
CICS
Db2
IMS
MQ
Syslog
Firewall
Proxy
DNS
EDR
IAM
APIs
Aplicações
OpenTelemetry

E isso cria algo extraordinário:

uma memória operacional da organização.

Myne entendeu imediatamente.

— Então vocês possuem livros contando o que o computador fez?

— Sim.

— E podem relê-los?

— Sim.

— Então por que não fazem isso quando aprendem algo novo?

O programador COBOL congelou.

Boa pergunta.

🕰️ CAPÍTULO 3 — A MÁQUINA DO TEMPO NÃO É A IA

Existe uma distinção importante.

Quando dizemos:

"Uma IA poderia descobrir em 2026 um ataque ocorrido em 2021?"

parece que a IA está viajando no tempo.

Não está.

A verdadeira máquina do tempo é:

telemetria preservada.

Imagine:

2021
 │
 ├── SMF
 ├── RACF
 ├── CICS
 ├── Db2
 └── MQ
      │
      ↓
 HISTORICAL STORAGE
      │
      ↓
     2026

Agora podemos fazer perguntas novas sobre informações antigas.

Essa diferença é fundamental.

A equação não é:

IA = MÁQUINA DO TEMPO

É:

RETENÇÃO
   +
NOVO CONHECIMENTO
   +
NOVAS FERRAMENTAS
   =
REANÁLISE DO PASSADO

E isso nos leva à ideia central deste artigo:

Dados antigos podem produzir descobertas novas.

🔬 CAPÍTULO 4 — O ATAQUE QUE NÃO EXISTIA EM 2021

Calma.

O ataque existia.

O que talvez não existisse era nosso conhecimento sobre ele.

Imagine que encontramos isto em 2021:

REMOTE-IP = 198.51.100.77

Consultamos nossas fontes.

Resultado:

UNKNOWN

Nada especialmente interessante.

Cinco anos passam.

Outras organizações são atacadas.

Pesquisadores investigam.

Infraestruturas são relacionadas.

Malwares são analisados.

Técnicas são documentadas.

Surge nova threat intelligence.

Agora descobrimos:

198.51.100.77
      ↓
Infrastructure associated with Campaign X

Imediatamente surge uma pergunta:

Esse endereço apareceu alguma vez em nossa infraestrutura?

Consultamos os registros históricos.

SELECT *
FROM HISTORICAL_EVENTS
WHERE REMOTE_IP = '198.51.100.77';

E encontramos:

O endereço que parecia irrelevante ganhou significado.

O passado mudou?

Não.

Mudou nosso conhecimento.

🧬 CAPÍTULO 5 — IOC: AS PEGADAS MAIS ÓBVIAS

Aqui nosso programador COBOL precisa conhecer uma sigla:

IOC — Indicator of Compromise.

Pode envolver coisas como:

IP
domínio
hash
arquivo
URL
certificado

Imagine que conhecemos o hash de um malware.

Podemos pesquisar registros históricos procurando aquele valor.

Isso é útil.

Mas existe um problema.

Atacantes podem trocar infraestrutura.

Mudam IP.

Mudam domínio.

Recompilam malware.

Alteram hashes.

Então:

HASH-A

vira:

HASH-B

Uma detecção baseada exclusivamente em igualdade pode falhar.

IF HASH = KNOWN-BAD-HASH
    PERFORM SECURITY-ALERT
END-IF.

Se mudou um byte:

NO MATCH

Por isso precisamos subir um degrau.

🥷 CAPÍTULO 6 — TTP: NÃO PROCURE APENAS O SAPATO, PROCURE O JEITO DE ANDAR

Agora encontramos:

TTP — Tactics, Techniques and Procedures.

Em vez de perguntar apenas:

Qual IP o atacante utilizou?

podemos perguntar:

Como ele trabalha?

Talvez uma campanha costume realizar algo parecido com:

obter credencial
      ↓
autenticar
      ↓
enumerar recursos
      ↓
executar programa legítimo
      ↓
acessar dados
      ↓
movimentar informações

IPs podem mudar.

Usuários podem mudar.

Hosts podem mudar.

Mas certas características comportamentais podem permanecer.

É como reconhecer alguém não pelo sapato, mas pelo jeito de andar.

E agora nosso histórico fica muito mais valioso.

Porque podemos perguntar:

Existe no passado alguma sequência parecida com esse comportamento?

Essa pergunta seria extremamente difícil usando apenas pesquisas exatas.

É aqui que entram técnicas mais modernas.

🕸️ CAPÍTULO 7 — MYNE DESENHA UM GRAFO NA MESA DO CPD

Myne pegou uma folha.

Escreveu:

USER01

Depois:

JOB17

Ligou os dois:

USER01 ──SUBMITTED──> JOB17

Acrescentou:

JOB17 ──EXECUTED──> PROG01

Depois:

PROG01 ──READ──> PAYROLL.DATA

Finalmente:

PROG01 ──PUT──> MQ.EXTERNAL

O programador COBOL olhou.

— Você fez um grafo.

— Fiz uma história.

Exatamente.

Grafos são extraordinariamente úteis porque permitem representar:

entidades

como:

USER
JOB
PROGRAM
DATASET
TRANSACTION
IP
DATABASE
QUEUE
CERTIFICATE
HOST
API

relações

como:

submitted
executed
read
connected
authenticated
called
sent
received

Assim:

USER01
   │
submitted
   ↓
 JOB17
   │
executed
   ↓
 PROG01
   │
  read
   ↓
CUSTOMER.DATA

O que antes eram quatro linhas espalhadas em bilhões de registros torna-se uma relação visual e computável.

⏱️ CAPÍTULO 8 — O GRAFO PRECISA DE UM RELÓGIO

Segurança possui uma característica essencial:

tempo.

Não basta saber:

USER01 → DATASET

Precisamos saber quando.

Imagine:

02:01 LOGIN
02:04 SUBMIT JOB
02:06 READ DATASET
02:08 DB2 QUERY
02:10 MQ PUT
02:12 LOGOFF

Agora encontramos outra identidade:

03:01 LOGIN
03:04 SUBMIT JOB
03:06 READ DATASET
03:08 DB2 QUERY
03:10 MQ PUT
03:12 LOGOFF

E outra:

01:31 LOGIN
01:34 SUBMIT JOB
01:36 READ DATASET
01:38 DB2 QUERY
01:40 MQ PUT
01:42 LOGOFF

Individualmente:

NORMAL
NORMAL
NORMAL

Mas a sequência diz:

🤨

Por que três usuários diferentes executaram praticamente a mesma cadeia?

Criamos então um:

grafo temporal.

Não queremos apenas relações.

Queremos relações ordenadas no tempo.

🧠 CAPÍTULO 9 — ENTRAM OS EMBEDDINGS

Aqui precisamos evitar transformar IA em magia.

Um embedding é uma representação numérica de alguma informação.

De maneira extremamente simplificada:

evento/sequência
       ↓
representação
       ↓
embedding
       ↓
[0.18, -0.42, 0.71, 0.09 ...]

Dependendo de como o sistema foi construído, podemos comparar representações buscando similaridade.

Isso muda nossa pesquisa.

O velho modelo perguntava:

IS A = B?

Agora podemos perguntar:

HOW SIMILAR IS A TO B?

Imagine um ataque conhecido:

LOGIN
 ↓
PRIVILEGE CHANGE
 ↓
JOB SUBMISSION
 ↓
UNUSUAL READ
 ↓
TRANSFER

No passado encontramos:

LOGIN
 ↓
PRIVILEGE CHANGE
 ↓
JOB SUBMISSION
 ↓
DB2 READ
 ↓
TRANSFER

Não é idêntico.

Mas estruturalmente talvez seja interessante.

O mecanismo pode dizer:

HIGH SIMILARITY

Isso não significa:

ATTACK CONFIRMED

Significa:

INVESTIGATE THIS

Essa diferença é gigantesca.

🔗 CAPÍTULO 10 — CINCO EVENTOS INOCENTES PODEM FORMAR UM ATAQUE

Agora chegamos ao coração da investigação.

Imagine:

RACF

USER01 accessed DATASET.X
SUCCESS

Normal.

JES/SMF

USER01 submitted JOB77
SUCCESS

Normal.

Db2

APP17 queried CUSTOMER
SUCCESS

Normal.

MQ

APP17 PUT QUEUE.EXTERNAL
SUCCESS

Normal.

Rede

HOST17 contacted external destination
SUCCESS

Normal.

Separadamente:

NORMAL
NORMAL
NORMAL
NORMAL
NORMAL

Agora ligamos tudo:

USER01
   ↓
JOB77
   ↓
APP17
   ↓
CUSTOMER
   ↓
MQ.EXTERNAL
   ↓
HOST17
   ↓
EXTERNAL DESTINATION

Oops.

Esse é um princípio extraordinariamente importante:

um ataque pode ser construído inteiramente com operações que, isoladamente, são legítimas.

O atacante não precisa necessariamente quebrar a porta.

Talvez possua uma chave válida.

👻 CAPÍTULO 11 — O FANTASMA QUE NUNCA RECEBEU ACCESS DENIED

Nosso invasor hipotético é cuidadoso.

Durante meses:

ACCESS ALLOWED
RC=0000
SUCCESS
SUCCESS
SUCCESS

Nenhuma senha inválida.

Nenhum acesso negado.

Nenhum programa obviamente malicioso.

Nenhum:

HACKER.EXE

Ele utiliza:

credencial válida
programa válido
job válido
dataset permitido
transação legítima

Uma defesa baseada exclusivamente em:

IF ACCESS-DENIED
    PERFORM ALERT
END-IF

pode não perceber nada.

Precisamos perguntar também:

É comum?

É esperado?

Esse horário é normal?

Esse usuário costuma acessar esse dataset?

Esse job normalmente executa esse programa?

Por que isso aconteceu depois daquele outro evento?

Quem mais apresentou a mesma sequência?

Saímos de:

EVENT SECURITY

para:

BEHAVIOR SECURITY

🧮 CAPÍTULO 12 — O PERFORM UNTIL DA SEGURANÇA

Nosso COBOLzeiro finalmente percebe algo familiar.

Antigamente ele poderia imaginar:

IF RESULT-CODE NOT = ZERO
    PERFORM WRITE-ALERT
END-IF.

Agora nosso sistema conceitualmente executa:

PERFORM ANALYZE-RELATIONSHIP
   UNTIL NO-MORE-RELATIONSHIPS.

Pergunta:

quem chamou isso?

Depois:

o que essa entidade chamou?

Depois:

quem mais fez isso?

Depois:

o que aconteceu antes?

Depois:

o que aconteceu depois?

Depois:

isso aconteceu em outro LPAR?

Depois:

há comportamento semelhante em 2021?

É quase um gigantesco PERFORM UNTIL investigativo.

E, sim, nosso velho COBOL acabou de encontrar graph analytics.

🦴 CAPÍTULO 13 — LOGS SÃO FÓSSEIS DIGITAIS

Myne fechou o livro de 2021.

— Então vocês são arqueólogos.

— Analistas de segurança.

— Arqueólogos.

Pensando bem...

Ela novamente tinha razão.

Um fóssil não muda quando descobrimos uma nova teoria.

Uma amostra biológica antiga não muda quando inventamos um novo sequenciador.

Uma fotografia antiga não muda quando desenvolvemos melhor processamento de imagem.

O que muda é nossa capacidade de extrair conhecimento do artefato.

Logs podem funcionar da mesma maneira.

São:

fósseis digitais.

Em 2021:

DATA2021
+
KNOWLEDGE2021
=
INTERPRETATION2021

Em 2026:

DATA2021
+
KNOWLEDGE2026
=
INTERPRETATION2026

O primeiro termo permanece.

O segundo mudou.

Consequentemente, o terceiro também pode mudar.

🕳️ CAPÍTULO 14 — O EVENTO QUE NÃO EXISTE

Existe uma possibilidade ainda mais fascinante.

Imagine:

02:01 EVENT
02:02 EVENT
02:03 EVENT

      ...

02:17 EVENT
02:18 EVENT

Existe um buraco.

Na época alguém escreveu:

Collector failure.

Cinco anos depois aprendemos que determinada técnica pode provocar justamente perda ou degradação da telemetria.

Agora:

NO EVENT

torna-se potencialmente:

EVENT OF INTEREST

Isso parece paradoxal.

Mas segurança frequentemente trabalha com expectativas.

Se sabemos que determinado sistema deveria produzir:

A
B
C
D
E

e encontramos:

A
B
C

E

a ausência de D merece explicação.

Em lógica:

EXPECTED(EVENT-D)
AND
NOT(EVENT-D)

pode ser informação.

Myne sorriu.

— Até páginas arrancadas contam uma história.

Exatamente.

🔎 CAPÍTULO 15 — ENCONTRANDO O "PACIENTE ZERO"

Suponhamos que detectamos uma intrusão em 2026.

Começamos a reconstruir o grafo para trás.

Finalmente encontramos:

17/03/2021
USERX
JOBY
HOSTZ

Antes disso, nada relacionado aparece.

Podemos chamar isso de primeiro evento observado relacionado à investigação.

Mas cuidado.

Não devemos automaticamente afirmar:

"O ataque começou exatamente aqui."

Talvez registros anteriores tenham sido destruídos.

Talvez o atacante estivesse em uma área sem telemetria.

Talvez nossa correlação esteja incompleta.

A formulação tecnicamente responsável é:

Esse é o ponto mais antigo que conseguimos associar à atividade usando a telemetria atualmente disponível.

Segurança também é saber onde termina nossa evidência.

⚠️ CAPÍTULO 16 — IA TAMBÉM ENXERGA FANTASMAS

Agora precisamos destruir uma ilusão.

Se pesquisarmos:

10.000.000.000 eventos

vamos encontrar coincidências.

Muitas.

Algumas parecerão assustadoras.

Isso não significa que sejam ataques.

Portanto:

ANOMALIA ≠ ATAQUE

CORRELAÇÃO ≠ CAUSALIDADE

SIMILARIDADE ≠ IDENTIDADE

EMBEDDING PRÓXIMO ≠ MESMO ATACANTE

MESMO IP ≠ MESMA PESSOA

Um modelo pode encontrar uma sequência extremamente semelhante à de uma campanha conhecida.

Excelente.

Mas o próximo passo deveria ser:

HYPOTHESIS
     ↓
RAW EVIDENCE
     ↓
TIMELINE
     ↓
CORROBORATION
     ↓
ANALYST
     ↓
CONCLUSION

Não:

AI
 ↓
GUILTY

A IA é extraordinária para reduzir um oceano de eventos a um conjunto investigável.

A conclusão continua dependendo das evidências.

🏗️ CAPÍTULO 17 — CONSTRUINDO A BIBLIOTECA DE MYNE

Se quiséssemos construir nosso Bellacosa Historical Threat Hunting Lab, poderíamos imaginar:

          HISTORICAL TELEMETRY
                  │
      ┌───────────┼───────────┐
      ↓           ↓           ↓
     SMF         RACF       CICS
      │           │           │
      ├───────────┼───────────┤
      ↓           ↓           ↓
     Db2          MQ        NETWORK
      └───────────┼───────────┘
                  ↓
            NORMALIZATION
                  ↓
             ENTITY MODEL
                  ↓
            TEMPORAL GRAPH
                  ↓
       ┌──────────┴──────────┐
       ↓                     ↓
   EMBEDDINGS          THREAT INTEL
       └──────────┬──────────┘
                  ↓
            AI ANALYSIS
                  ↓
             HYPOTHESES
                  ↓
          HUMAN INVESTIGATION

Observe algo importante.

IA está perto do final.

Porque antes dela existe muito trabalho pouco glamouroso:

coleta
qualidade
retenção
normalização
identidade
timestamp
integridade
contextualização

Garbage in, garbage out continua valendo em 2026.

🧹 CAPÍTULO 18 — NORMALIZAÇÃO: O TRABALHO QUE NINGUÉM COLOCA NA DEMO

SMF fala sua língua.

CICS possui seus eventos.

Db2 possui os seus.

MQ possui os seus.

Linux possui outros.

Cloud tem outros.

Aplicações têm outros.

Precisamos transformar:

SMF EVENT
CICS EVENT
DB2 EVENT
MQ EVENT
LINUX EVENT
CLOUD EVENT

em alguma representação comparável:

CANONICAL SECURITY EVENT

Conceitualmente:

{
  "timestamp": "...",
  "identity": "...",
  "source": "...",
  "action": "...",
  "resource": "...",
  "result": "...",
  "system": "..."
}

Agora podemos perguntar:

WHO
DID WHAT
TO WHAT
FROM WHERE
WHEN
WITH WHAT RESULT

Parece simples.

Na prática, essa pode ser uma das partes mais difíceis do projeto.

🔄 CAPÍTULO 19 — O PULO DO GATO: REPROCESSAR AUTOMATICAMENTE O PASSADO

Agora chegamos à ideia que Myne realmente gostou.

Um novo livro chega à biblioteca:

NEW THREAT INTELLIGENCE

Em vez de utilizá-lo apenas para detectar ataques futuros, o sistema pergunta:

Isso aconteceu conosco antes?

Automaticamente:

NEW IOC
   ↓
SEARCH HISTORY

ou:

NEW TTP
   ↓
SEARCH HISTORY

ou:

NEW BEHAVIORAL MODEL
   ↓
SEARCH HISTORY

Resultado:

2026 → NO MATCH
2025 → WEAK
2024 → WEAK
2023 → STRONG
2022 → STRONG
2021 → POSSIBLE FIRST OBSERVATION

Acabamos de criar algo fascinante:

Threat Intelligence Time Machine.

Não estamos somente protegendo o futuro.

Estamos continuamente reinterpretando o passado.

💾 CAPÍTULO 20 — ENTÃO GUARDEMOS TUDO PARA SEMPRE!

O programador COBOL levantou a mão.

— Resolvido. Guardamos tudo.

Do fundo do CPD vieram quatro vozes.

Storage:

— Quem paga?

Jurídico:

— Precisamos conversar.

Privacidade:

— Nem pense nisso.

Segurança:

— E quem protege esse gigantesco arquivo?

Excelente.

Retenção infinita não é automaticamente uma boa estratégia.

Logs podem conter informações sensíveis.

Um repositório histórico gigantesco também pode virar alvo.

Então precisamos pensar em:

retenção
criptografia
controle de acesso
imutabilidade
integridade
minimização
tokenização
compressão
classificação
requisitos legais
chain of custody

Talvez:

HOT  → meses
WARM → anos
COLD → período maior

Dependendo do valor e das obrigações associadas aos dados.

🧪 CAPÍTULO 21 — UM EXPERIMENTO PARA O PROGRAMADOR COBOL

Quer entender isso praticamente?

Crie um pequeno laboratório conceitual.

PASSO 1 — Crie eventos históricos

2021 USER01 LOGIN
2021 USER01 JOB01
2021 JOB01 READ CUSTOMER
2021 JOB01 MQPUT EXTERNAL

2021 USER02 LOGIN
2021 USER02 JOB09
2021 JOB09 READ INVENTORY

PASSO 2 — Finja que você está em 2021

Nenhum indicador conhecido.

Classifique tudo:

NORMAL

PASSO 3 — Avance para 2026

Agora surge inteligência:

Known suspicious sequence:

LOGIN
→ JOB
→ CUSTOMER READ
→ EXTERNAL MQ PUT

PASSO 4 — Reprocesse 2021

Resultado:

USER01
  ↓
JOB01
  ↓
CUSTOMER
  ↓
EXTERNAL

MATCH

PASSO 5 — Investigue

Não declare ataque automaticamente.

Pergunte:

USER01 deveria fazer isso?

JOB01 era legítimo?

Esse fluxo era documentado?

Qual volume foi transferido?

Existem outros eventos relacionados?

Quem criou JOB01?

Isso aconteceu novamente?

Pronto.

Você acabou de construir uma versão minúscula de historical threat hunting.

🧬 CAPÍTULO 22 — O QUE DEVEMOS PRESERVAR HOJE PARA DESCOBRIR AMANHÃ?

Essa talvez seja a pergunta mais profunda de todo o artigo.

Não é:

Quanto storage precisamos?

Nem:

Quantos anos de SMF devemos guardar?

A pergunta arquitetural é:

Quais evidências do presente precisamos preservar para permitir investigações que ainda não sabemos que serão necessárias?

Porque talvez em 2031 exista uma técnica analítica que hoje nem imaginamos.

E ela possa olhar para:

SMF de 2026

e descobrir algo que passou despercebido.

Isso transforma retenção.

De:

BACKUP

para:

INVESTIGATIVE MEMORY

📖 CAPÍTULO 23 — MYNE FINALMENTE ENTENDE O SMF

Myne colocou o último volume na estante.

Na lombada:

SMF — SEPTEMBER 2026

O programador perguntou:

— Então você acha que deveríamos guardar tudo?

— Não.

— Achei que você adorasse livros.

— Justamente por isso. Uma biblioteca não é um depósito de papel.

Silêncio novamente.

— Precisamos saber o que preservar, como catalogar e como encontrar.

Ela apontou para as estantes.

— Um livro impossível de encontrar quase não existe.

O programador olhou para seus bilhões de registros SMF sem normalização adequada.

Aquilo doeu.

🥚 EASTER EGG — O JOB QUE ESPEROU CINCO ANOS PARA SER LIDO

Em 2021:

//MYNE01  JOB ...
//STEP01  EXEC PGM=BOOKWORM

Executou.

RC=0000

Ninguém ligou.

O SMF registrou.

O dataset foi arquivado.

Os anos passaram.

Em 2026 chegou nova threat intelligence.

O sistema começou a reprocessar o passado.

2026...
2025...
2024...
2023...
2022...
2021...

Então:

MATCH FOUND

O analista abriu o registro.

Data:

17/03/2021 02:17:43

Ele chamou Myne.

— Encontramos o ataque.

Ela corrigiu:

— Não.

— Como não?

— O ataque já estava lá.

Myne apontou para o registro.

— Vocês encontraram a capacidade de lê-lo.

☕ EPÍLOGO — A BIBLIOTECA DO FUTURO JÁ ESTÁ SENDO ESCRITA

Existe uma tentação enorme quando falamos de inteligência artificial em cybersecurity de imaginar máquinas mágicas detectando hackers instantaneamente.

Mas talvez uma das aplicações mais fascinantes da IA seja muito menos cinematográfica.

Ela pode ajudar a reler.

Reinterpretar.

Correlacionar.

Comparar.

Encontrar relações.

Transformar bilhões de eventos isolados em histórias investigáveis.

O mainframe registrou:

USER
JOB
PROGRAM
DATASET
TRANSACTION
MESSAGE
DATABASE
TIMESTAMP

O RACF registrou.

O CICS registrou.

O Db2 registrou.

O MQ registrou.

A rede registrou.

Talvez ninguém tenha entendido a história naquele momento.

Cinco anos depois temos:

novos IOCs
+
novas TTPs
+
threat intelligence
+
grafos temporais
+
embeddings
+
modelos comportamentais
+
IA

e fazemos novamente a pergunta.

De repente:

EVENT
+
EVENT
+
EVENT
+
EVENT

deixa de parecer ruído.

Transforma-se em:

STORY

Essa talvez seja uma das grandes mudanças que IA, graph analytics e threat intelligence podem trazer para investigação digital.

Não apenas perguntar:

O que está acontecendo agora?

Mas:

O que aconteceu conosco quando ainda não sabíamos reconhecer aquilo que estava acontecendo?

E isso nos leva à frase que Myne deixou escrita em uma pequena etiqueta na entrada da biblioteca:

O passado não muda. O conhecimento capaz de interrogá-lo muda.

Em mainframe, isso significa que um SMF aparentemente insignificante produzido hoje pode ser a peça fundamental de uma investigação em 2031.

Por isso logs não são simplesmente lixo operacional.

Nem apenas instrumentos de troubleshooting.

Nem apenas accounting.

Nem apenas auditoria.

Quando preservados com propósito, integridade, contexto e governança, tornam-se:

MEMÓRIA INVESTIGATIVA.

E talvez o SOC do futuro tenha uma função que hoje ainda tratamos como excepcional:

NEW KNOWLEDGE
      ↓
REPROCESS HISTORY
      ↓
DISCOVER RELATIONSHIPS
      ↓
GENERATE HYPOTHESIS
      ↓
HUMAN INVESTIGATION

Uma espécie de:

PERFORM INVESTIGATE-PAST
   UNTIL NO-MORE-QUESTIONS.

Só existe um pequeno problema.

Como qualquer COBOLzeiro experiente percebeu imediatamente:

NO-MORE-QUESTIONS

provavelmente nunca será TRUE.

Myne abriu outro volume.

O programador colocou café na caneca.

E em algum dataset esquecido do mainframe havia um registro de cinco anos atrás esperando pacientemente que alguém inventasse a pergunta certa.

Porque algumas histórias são registradas muito antes de existir alguém capaz de entendê-las.

☕ Bellacosa Mainframe — onde até o SMF antigo merece uma segunda leitura.

Translate

segunda-feira, 6 de julho de 2020