Bellacosa Mainframe e o mistério do mainframe que jurava estar seguro

☕ Um Café no Bellacosa Mainframe

🐶 Mumbly e o Mistério do Mainframe que Jurava Estar Seguro

Firewalls, criptografia, autenticação, RACF, Zero Trust, ameaças, insiders, Red Team e aquele acesso das 03:17 que estava perfeitamente autorizado — mas não deveria estar acontecendo.

Há personagens que chegam a uma investigação arrombando portas, apontando armas e gritando ordens.

Mumbly não.

Ele aparece de sobretudo, dirige uma lata-velha, resmunga alguma coisa incompreensível e fica olhando para o suspeito com aquela expressão de quem já percebeu algo que ninguém mais percebeu.

E então vem aquela risadinha.

Heh-heh-heh-heh-heh...

Perfeito para investigar cybersecurity.

Porque segurança de computadores tem uma característica curiosa: quando ocorre um grande incidente, frequentemente descobrimos que várias partes do sistema estavam funcionando exatamente como foram configuradas para funcionar.

O firewall permitiu a conexão.

O certificado era válido.

A criptografia funcionou.

A senha estava correta.

O MFA foi aprovado.

O RACF autorizou.

O CICS executou.

O COBOL retornou RETURN-CODE = 0.

E alguém acabou de fazer algo que jamais deveria ter acontecido.

Mumbly ergueria uma sobrancelha.

Heh-heh-heh...

Temos um caso.

Antes de entrar na LPAR, vale apresentar nosso investigador. The Mumbly Cartoon Show foi produzido pela Hanna-Barbera e estreou nos Estados Unidos em 11 de setembro de 1976. Foram produzidos 16 episódios, com Mumbly dublado originalmente por Don Messick e Chief Schnooker por John Stephenson. O cão detetive de sobretudo trabalhava solucionando crimes enquanto seu chefe humano nem sempre demonstrava a mesma competência. (Wikipedia)

No Brasil, ficou conhecido como Rabugento, o Cão Detetive, com Pietro Mário na voz do protagonista e Guálter de França como Chefe Sinuca na dublagem registrada pela Herbert Richers. (DB - Dublagem Brasileira)

E existe uma conexão especialmente divertida: Mumbly é frequentemente descrito como uma paródia canina do detetive Columbo — sobretudo, comportamento aparentemente desajeitado, insistência e aquela capacidade de incomodar o suspeito até a verdade aparecer.

Exatamente o método que usaremos.

🕵️ CAPÍTULO 1 — O sistema estava seguro

Nosso caso começa numa grande empresa fictícia.

Chamaremos de:

BELLACOSA BANK

O diretor pergunta ao responsável pela infraestrutura:

— Nosso sistema está protegido?

Resposta:

— Claro!

E começa o inventário:

Firewall .............. ✔
WAF ................... ✔
TLS ................... ✔
AES ................... ✔
MFA ................... ✔
RACF .................. ✔
SIEM .................. ✔
Antivírus ............. ✔
Backups ............... ✔

Mumbly olha para a lista.

Hmmmmmm...

E resmunga.

Porque o primeiro erro de cybersecurity está diante dele:

ter controles de segurança não significa necessariamente estar seguro.

Essa diferença parece filosófica, mas é engenharia.

Um firewall resolve determinados problemas.

Criptografia resolve outros.

MFA resolve outros.

RACF resolve outros.

Nenhum deles consegue responder sozinho à pergunta:

“O sistema está fazendo somente aquilo que deveria fazer?”

É aí que começa nossa investigação.

🔥 CAPÍTULO 2 — O primeiro suspeito: Firewall

Durante muito tempo aprendemos segurança usando a metáfora do castelo:

             INTERNET
                 |
                 |
          +-------------+
          |  FIREWALL   |
          +-------------+
                 |
       =====================
       REDE CORPORATIVA
       =====================
           |          |
        SERVER      SERVER

Do lado de fora estão os bárbaros.

Dentro das muralhas estão os cidadãos confiáveis.

É uma metáfora útil.

Mas perigosa.

Porque cria uma conclusão implícita:

EXTERNO = NÃO CONFIÁVEL
INTERNO = CONFIÁVEL

Mumbly atravessa o firewall, olha para trás e resmunga:

Hmmmm...

O firewall nunca prometeu isso.

Ele controla comunicações segundo determinadas políticas.

Um packet filter poderia encontrar:

SOURCE      = 192.168.20.10
DESTINATION = 10.20.10.50
PROTOCOL    = TCP
PORT        = 443

e decidir:

ALLOW

Isso significa:

essa comunicação atende à política.

Não significa:

essa pessoa é honesta.

Nem:

essa operação é legítima.

Muito menos:

o que acontecer dentro dessa conexão será seguro.

🧱 CAPÍTULO 3 — Nem todo firewall é igual

O primeiro dos nossos infográficos apresentava diversos tipos de firewall.

A ideia geral está correta, mas precisamos separar tecnologias, arquiteturas e gerações.

Um packet-filtering firewall trabalha principalmente com características dos pacotes.

Um firewall stateful vai além.

Ele mantém contexto sobre conexões.

Simplificando:

SOURCE       PORT     DESTINATION    PORT     STATE

10.1.1.20    49152    10.2.1.30      443      ESTABLISHED
10.1.1.21    50233    10.2.1.31      22       ESTABLISHED

Agora o equipamento pode perguntar:

“Este pacote pertence a uma comunicação que já conheço?”

É uma enorme evolução sobre examinar pacotes isoladamente.

Mas ainda existe um problema.

Imagine:

HTTPS
TCP/443

Perfeitamente permitido.

Dentro dele:

POST /transfer

E dentro dessa requisição:

{
  "origem": "12345",
  "destino": "98765",
  "valor": 9800000
}

O firewall pode estar completamente satisfeito.

Mumbly não.

🌐 CAPÍTULO 4 — Então aparece o WAF

Agora acrescentamos outra camada:

INTERNET
   |
   v
FIREWALL
   |
   v
WAF
   |
   v
API GATEWAY
   |
   v
APPLICATION

O Web Application Firewall consegue observar aspectos específicos do tráfego HTTP/HTTPS e aplicar políticas relacionadas à aplicação.

Isso melhora enormemente nossa defesa.

Mas novamente:

WAF ALLOWED

não significa:

BUSINESS TRANSACTION IS LEGITIMATE

Essa diferença será fundamental quando chegarmos ao COBOL.

🔐 CAPÍTULO 5 — O segundo suspeito: criptografia

Mumbly encontra uma placa:

AES-256

O administrador sorri.

— Nossos dados são criptografados!

Mumbly responde:

Hmmmm...

Excelente.

Mas onde estão as chaves?

Silêncio.

Essa pergunta muda completamente a investigação.

Criptografia simétrica, como AES, utiliza segredo compartilhado para proteger dados.

Criptografia de chave pública trabalha com uma estrutura envolvendo chave pública e privada.

Na prática, sistemas modernos frequentemente combinam mecanismos.

Conceitualmente:

CRIPTOGRAFIA ASSIMÉTRICA
          |
          v
ESTABELECIMENTO DE CONFIANÇA/
SEGREDO DE SESSÃO
          |
          v
CRIPTOGRAFIA SIMÉTRICA
          |
          v
GRANDE VOLUME DE DADOS

Por quê?

Entre outros motivos, desempenho e características distintas dos algoritmos.

Mas nosso detetive não está interessado apenas no algoritmo.

Está procurando confiança.

🗝️ CAPÍTULO 6 — Quem guarda a chave da chave?

Imagine que CUSTOMER.DATA esteja perfeitamente criptografado.

Fantástico.

Agora alguém encontra no programa:

01  WS-CRYPTO-KEY PIC X(32)
    VALUE 'MINHA-SUPER-CHAVE-SECRETA'.

Mumbly começa a rir.

Heh-heh-heh-heh-heh...

A matemática continua funcionando.

A arquitetura de segurança, não.

O problema real passa a incluir:

Quem cria a chave?

Quem possui acesso?

Onde ela fica?

Pode ser exportada?

Como ocorre a rotação?

Quem consegue substituí-la?

Existe auditoria?

Existe separação de funções?

Existe hardware dedicado para protegê-la?

É aí que o mundo IBM Z fica fascinante.

Entram elementos como ICSF, hardware criptográfico, certificados, key rings e políticas de acesso.

Segurança criptográfica empresarial não é:

AES = ON

É um ecossistema.

🚚 CAPÍTULO 7 — Data at rest, data in transit e data in use

Mumbly encontra três salas.

Na primeira:

DATA AT REST

São datasets, bancos, arquivos, volumes e backups.

Na segunda:

DATA IN TRANSIT

São dados atravessando redes.

Na terceira:

DATA IN USE

Agora a coisa fica interessante.

Porque podemos possuir:

DISK
  ↓
ENCRYPTED DATA
  ↓
APPLICATION
  ↓
DECRYPT
  ↓
PROCESSING

Em algum momento uma aplicação autorizada precisa utilizar os dados.

Consequentemente:

criptografia não substitui controle de acesso.

E controle de acesso não substitui criptografia.

Essa é a essência de defense in depth.

🪪 CAPÍTULO 8 — Mumbly pergunta: “Quem é você?”

Chegamos à autenticação.

Temos senha.

PIN.

OTP.

Biometria.

Certificados.

Tokens.

Security keys.

Passwordless.

MFA.

Mas antes de decorar tecnologias precisamos aprender uma separação fundamental:

IDENTIFICATION
      ↓
Quem você afirma ser?

AUTHENTICATION
      ↓
Você consegue provar?

AUTHORIZATION
      ↓
O que você pode fazer?

Um usuário pode autenticar corretamente e continuar sem autoridade para determinado recurso.

Essa distinção é essencial no mainframe.

🏦 CAPÍTULO 9 — RACF entra na delegacia

Imagine:

USERID ABC123
PASSWORD ********

Autenticação concluída.

Mas ABC123 tenta acessar:

BANK.PROD.CUSTOMER.MASTER

Agora precisamos perguntar:

ABC123 possui READ?

Talvez sim.

Depois:

Possui UPDATE?

Talvez não.

ALTER?

Definitivamente esperamos que isso tenha sido pensado cuidadosamente.

Esse é o princípio de least privilege:

conceder somente os privilégios necessários para executar determinada função.

Um desenvolvedor COBOL iniciante precisa compreender isso muito cedo.

Seu programa não vive sozinho.

Ele executa dentro de uma arquitetura de identidade e autorização.

🧑‍💻 CAPÍTULO 10 — Então Mumbly encontra o COBOL

Aqui nossa investigação muda.

O sistema é:

Mobile App
    |
   TLS
    |
   WAF
    |
API Gateway
    |
z/OS Connect
    |
   CICS
    |
   RACF
    |
PGMPAY01
    |
   Db2

Uma requisição chegou.

Firewall:

OK

WAF:

OK

TLS:

OK

Identidade:

OK

RACF:

OK

CICS:

OK

E agora o programa recebe:

TRANSFER-AMOUNT = 9.800.000

Quem decide se aquela transferência faz sentido?

Talvez seja justamente o sistema de negócio.

💰 CAPÍTULO 11 — Uma linha COBOL também pode ser cybersecurity

Considere:

IF TRANSFER-AMOUNT > DAILY-LIMIT
    MOVE 'Y' TO ADDITIONAL-REVIEW
END-IF.

Isso parece uma regra bancária.

E é.

Mas também constitui controle de risco.

Podemos adicionar:

IF DESTINATION-COUNTRY NOT = CUSTOMER-USUAL-COUNTRY
   AND TRANSFER-AMOUNT > HIGH-RISK-LIMIT
       PERFORM REQUEST-ADDITIONAL-VALIDATION
END-IF.

Então descobrimos três níveis diferentes:

NETWORK AUTHORIZATION
        |
        | Posso estabelecer comunicação?
        v

SYSTEM AUTHORIZATION
        |
        | Posso acessar o recurso?
        v

BUSINESS AUTHORIZATION
        |
        | Posso executar ESTA operação?
        v

TRANSACTION

E é nesse terceiro nível que milhões de linhas COBOL sustentam controles críticos de negócio.

💣 CAPÍTULO 12 — Mumbly encontra um usuário perfeitamente legítimo

Às 03:17...

Sim, exatamente 03:17.

Um registro aparece:

USER ABC123
LOGIN SUCCESSFUL

Nada estranho.

Depois:

03:17:03 CUSTOMER READ
03:17:04 ACCOUNT READ
03:17:05 ACCOUNT READ
03:17:06 ACCOUNT READ
03:17:07 ACCOUNT READ

Alguns minutos depois:

38.421 RECORDS ACCESSED

RACF diz:

AUTHORIZED

Mumbly:

Hmmmmmmmmmm...

Normalmente ABC123 consulta 30 registros por dia.

Agora consultou 38 mil.

Essa é uma descoberta extraordinariamente importante:

acesso autorizado pode produzir comportamento malicioso.

👤 CAPÍTULO 13 — O insider não precisa derrubar a porta

O atacante externo pode precisar superar:

Firewall
WAF
MFA
RACF
Segmentation
Application Security

O insider talvez possua:

USERID válido
equipamento válido
VPN válida
acesso válido
conhecimento interno
autorizações legítimas

Seu caminho começa vários quilômetros depois da muralha.

Por isso:

AUTHENTICATED

não significa:

TRUSTED FOREVER

AUTHORIZED

não significa:

BEHAVIOR IS LEGITIMATE

Mumbly encontrou uma pista importante.

🎬 CAPÍTULO 14 — Uma fotografia não resolve o caso

Veja:

ABC123 READ CUSTOMER

Parece normal.

📸 Temos uma fotografia.

Agora:

03:17 Login incomum
03:18 Dataset sensível
03:19 Volume anormal
03:20 Nova aplicação
03:21 Consulta em massa
03:22 Transferência externa

Temos um filme.

🎬

Esse princípio ajuda a compreender SIEM, correlação, analytics e detecção comportamental.

Podemos coletar informações de várias fontes:

RACF ──────┐
SMF ───────┤
CICS ──────┤
Db2 ───────┤
MQ ────────┼──> CORRELATION
TCP/IP ────┤          |
WAF ───────┤          v
API ───────┤       ANALYTICS
Cloud ─────┘          |
                      v
                    ALERT

Uma ocorrência talvez não diga nada.

A sequência conta uma história.

Mumbly sempre soube disso.

Um detetive não resolve crimes olhando apenas para uma pegada.

Ele procura relações entre pistas.

🧮 CAPÍTULO 15 — Risk Scoring entra na investigação

Agora podemos transformar contexto em risco.

Não existe uma fórmula universal como esta, mas podemos imaginar pedagogicamente:

RISK SCORE =
    IDENTITY
  + DEVICE
  + NETWORK
  + BEHAVIOR
  + TRANSACTION
  + RESOURCE
  + THREAT CONTEXT

ABC123:

Known user ..................  0
Known workstation ...........  0
Unusual hour ................ 15
Sensitive resource .......... 20
Abnormal volume ............. 30
New destination ............. 20
Privilege anomaly ........... 30
                              ---
                              115

Em vez de simplesmente:

ALLOW
DENY

podemos pensar em respostas graduais:

ALLOW

ALLOW + MONITOR

STEP-UP AUTHENTICATION

LIMIT

REQUIRE APPROVAL

ISOLATE

DENY

OPEN INCIDENT

Isso representa uma evolução enorme da segurança binária.

🏰 CAPÍTULO 16 — Mumbly derruba o castelo

Finalmente chegamos ao Zero Trust.

O modelo antigo poderia implicitamente favorecer:

OUTSIDE
   ↓
UNTRUSTED

INSIDE
   ↓
TRUSTED

Zero Trust questiona essa confiança implícita.

Uma arquitetura mais madura pensa:

IDENTITY
    +
DEVICE
    +
RESOURCE
    +
CONTEXT
    +
POLICY
    +
RISK
    ↓
ACCESS DECISION

E mesmo depois de permitir:

CONTINUE OBSERVING

Esse último detalhe é fundamental.

Autorização não precisa representar um cheque em branco eterno.

🕸️ CAPÍTULO 17 — O Red Team pergunta algo diferente

Chegou a hora de Mumbly vestir o chapéu de Red Team.

Um teste superficial pergunta:

Como atravesso o firewall?

Um raciocínio muito mais interessante pergunta:

Onde esta organização deposita confiança?

Veja:

                    PRODUCTION
                  /      |      \
               CICS     DB2      MQ
                |        |        |
              COBOL     DBA    SERVICE
                |        |        |
               DEV     ADMIN    VENDOR
                 \       |       /
                    IDENTITY
                       |
                    HELPDESK

Isso é um grafo de confiança.

Agora existe uma pergunta deliciosamente Mumbly:

Qual caminho até produção possui menos resistência?

Talvez atacar:

Internet
→ Firewall
→ WAF
→ API
→ z/OS

seja difícil.

Mas existe:

Usuário
→ Helpdesk
→ Reset
→ Credencial
→ VPN
→ Ambiente interno

Ou:

Fornecedor
→ Service Account
→ Integração
→ MQ
→ Aplicação

Ou ainda:

Developer
→ Repository
→ Pipeline
→ Build
→ Load Library
→ Production

O Red Team não precisa necessariamente destruir a muralha.

Ele procura uma porta que alguém já deixou aberta.

📦 CAPÍTULO 18 — O assassino pode estar no pipeline

Mumbly encontra:

PGMPAY01.cbl

O fonte está perfeito.

Code review:

PASS

Testes:

PASS

Análise:

PASS

Mas existe uma cadeia:

SOURCE
  ↓
COPYBOOK
  ↓
REPOSITORY
  ↓
BUILD
  ↓
COMPILER
  ↓
LINK
  ↓
LOADLIB
  ↓
DEPLOY
  ↓
PRODUCTION

Comprometa uma etapa da cadeia e talvez você não precise alterar diretamente o fonte analisado.

Esse é o motivo pelo qual supply-chain security se tornou tão importante.

A pergunta deixa de ser:

O código está correto?

e vira:

Conseguimos provar que aquilo executando em produção corresponde ao artefato que acreditamos ter construído?

Essa é outra investigação inteira.

👻 CAPÍTULO 19 — O suspeito que ninguém interrogou: Service Account

Mumbly consulta a lista de usuários.

Humanos:

VAGNER01
MARIA02
JOAO03

E depois:

SVCMQ001
SVCBATCH
SVCAPI
CICSPROD

Hmmmmm...

Máquinas também possuem identidades.

Aplicações precisam conversar:

CICS
 ↓
MQ
 ↓
SERVICE
 ↓
API
 ↓
DATABASE

Um service account criado dez anos atrás pode ter acumulado privilégios porque, a cada problema, alguém decidiu:

“Libera mais um acesso para o batch funcionar.”

Depois de quinze anos:

SVCBATCH
    |
    +-- CUSTOMER.*
    +-- ACCOUNT.*
    +-- PAYMENT.*
    +-- CLAIMS.*
    +-- REPORT.*
    +-- ADMIN.*

Ele virou um fantasma com as chaves do prédio inteiro.

Essa é security debt.

🧑‍🔧 CAPÍTULO 20 — E o erro humano?

Um dos infográficos inclui corretamente erro humano entre ameaças.

Isso merece atenção.

Nem todo incidente nasce de:

EVIL HACKER

Pode nascer de:

PERMIT *

quando deveria ser:

PERMIT RESOURCE.X

Pode ser um certificado expirado.

Uma ACL errada.

Uma configuração esquecida.

Um dataset copiado para homologação contendo dados reais.

Um log com informação sensível.

Um backup sem a proteção esperada.

Um usuário que recebeu privilégio temporário e nunca o perdeu.

Ou simplesmente:

“Deixa assim porque está funcionando.”

Mumbly odeia essa frase.

Heh-heh-heh-heh...

🎩 CAPÍTULO 21 — White Hat, Black Hat e a confusão dos chapéus

O último infográfico tenta classificar hackers.

Serve como introdução, mas é perigoso transformar todos os “chapéus” em taxonomia rígida.

É melhor classificar atores em dimensões.

Autorização

AUTHORIZED
UNAUTHORIZED

Motivação

Financial
Espionage
Ideological
Revenge
Curiosity
Sabotage

Relação

External
Internal
Partner
Supplier

Capacidade

Low
Medium
High
Advanced

Recursos

Individual
Criminal organization
Corporate
State-supported

Assim conseguimos construir modelos de ameaça muito melhores.

Um adolescente usando ferramentas prontas e uma equipe altamente financiada podem explorar a mesma vulnerabilidade.

Mas representam riscos completamente diferentes.

🛡️ CAPÍTULO 22 — Prevent não basta

Mumbly olha novamente nossa arquitetura.

Encontramos:

Firewall
MFA
RACF
TLS
Encryption
WAF

Tudo isso é importantíssimo.

Mas segurança precisa pensar em todo o ciclo:

Essa visão é muito próxima da estrutura do NIST Cybersecurity Framework 2.0, que organiza os resultados de cybersecurity nas funções Govern, Identify, Protect, Detect, Respond e Recover. (Wikipedia)

O ponto pedagógico permanece: prevenção é somente parte do trabalho.

🚨 CAPÍTULO 23 — Assume Breach

Existe uma pergunta desconfortável que Mumbly faria:

E se o atacante já estiver dentro?

Essa pergunta muda completamente o projeto.

Em vez de:

COMO IMPEDIMOS A ENTRADA?

também perguntamos:

COMO LIMITAMOS O MOVIMENTO?

COMO DETECTAMOS?

COMO CONTEMOS?

COMO PRESERVAMOS EVIDÊNCIAS?

COMO RECUPERAMOS?

COMO SABEMOS O QUE FOI AFETADO?

A arquitetura precisa sobreviver à falha de um controle.

Essa é uma maneira poderosa de compreender defense in depth.

🔬 CAPÍTULO 24 — O programador COBOL também faz parte da defesa

Essa talvez seja a descoberta mais importante deste artigo.

O programador iniciante frequentemente imagina:

SEGURANÇA
   =
EQUIPE DE SEGURANÇA

Não.

Quem escreve:

IF USER-ROLE = 'ADMIN'

está implementando uma decisão de segurança.

Quem escreve:

DISPLAY CUSTOMER-CARD-NUMBER

pode estar criando exposição de dados.

Quem decide registrar:

PASSWORD=XXXXXXXX

em log está tomando uma decisão de segurança.

Quem cria:

IF AMOUNT > LIMIT
   PERFORM VALIDATE
END-IF

pode estar implementando controle antifraude.

Quem ignora:

RETURN-CODE

pode transformar uma falha de segurança em comportamento inesperado.

Cybersecurity não começa no firewall.

Nem termina no RACF.

Ela atravessa o software.

🧠 CAPÍTULO 25 — Mumbly finalmente monta o quadro

Na parede da delegacia temos todas as pistas:

                   CYBERSECURITY
                         |
         +---------------+---------------+
         |               |               |
       PEOPLE          PROCESS        TECHNOLOGY
         |               |               |
         +---------------+---------------+
                         |
                       ASSET
                         |
                      THREATS
                         |
                  ATTACK SURFACE
                         |
                      CONTROLS
                         |
         +---------------+---------------+
         |               |               |
      PREVENT          DETECT          RESPOND
         |               |               |
      Firewall          SMF             SOC
      RACF              Logs            IR
      MFA               SIEM            Isolate
      TLS               UEBA            Recover
      Crypto            Alerts          Forensics
         \               |               /
          +--------------+--------------+
                         |
                      EVIDENCE
                         |
                       RISK
                         |
                    GOVERNANCE

E no centro disso tudo:

                     BUSINESS
                        |
                        v
                      COBOL
                        |
             +----------+----------+
             |          |          |
            CICS       Db2         MQ
             \          |          /
              +---------+---------+
                        |
                       z/OS
                        |
                       IBM Z

Agora finalmente enxergamos o sistema inteiro.

🐶 CAPÍTULO 26 — Mumbly resolve o caso

Chefe Sinuca entra correndo.

— Mumbly! Descobri! O firewall estava funcionando!

Mumbly:

Hmmmm.

— O MFA também!

Hmmmm.

— O certificado era válido!

Hmmmm.

— RACF autorizou!

Hmmmm.

— O programa COBOL terminou com CC 0000!

Mumbly sorri.

Heh-heh-heh-heh-heh...

Porque essa era justamente a pista.

Nada havia “quebrado”.

O usuário possuía uma identidade legítima.

A comunicação era permitida.

O canal estava criptografado.

O recurso estava autorizado.

A transação tecnicamente funcionou.

Mas às 03:17, aquela identidade começou a executar uma sequência de operações incompatível com seu comportamento normal, em volume incomum, sobre recursos sensíveis.

O sistema tradicional perguntava:

WHO ARE YOU?

Depois evoluiu para:

WHO ARE YOU?
ARE YOU AUTHORIZED?

A segurança moderna precisa continuar:

WHO ARE YOU?

WHAT DEVICE?

FROM WHERE?

WHAT RESOURCE?

WHAT OPERATION?

WHEN?

HOW MUCH?

HOW OFTEN?

IS THIS NORMAL?

WHAT CHANGED?

WHAT IS THE CURRENT RISK?

SHOULD WE CONTINUE TRUSTING THIS SESSION?

Mumbly não encontrou uma porta arrombada.

Encontrou algo muito mais interessante:

uma cadeia de confiança que continuou confiando quando já deveria ter começado a desconfiar.

☕ EPÍLOGO — O firewall não era o culpado

É tentador terminar uma aula de cybersecurity dizendo:

“Precisamos de firewalls melhores.”

Mas Mumbly provavelmente resmungaria.

O firewall fez seu trabalho.

O RACF fez seu trabalho.

A criptografia fez seu trabalho.

O CICS fez seu trabalho.

O COBOL fez exatamente aquilo que alguém havia programado.

Esse é precisamente o problema.

Segurança madura não pode ser reduzida à existência de ferramentas.

Precisamos perguntar continuamente:

QUEM
   ↓
FAZ O QUÊ
   ↓
SOBRE QUAL RECURSO
   ↓
EM QUAL CONTEXTO
   ↓
COM QUAL PRIVILÉGIO
   ↓
PRODUZINDO QUAL COMPORTAMENTO
   ↓
GERANDO QUAL RISCO

Por isso aqueles cinco infográficos aparentemente simples — Firewall, Criptografia, Autenticação, Ameaças e Hackers — acabam nos levando a uma discussão muito maior sobre IAM, RACF, least privilege, defesa em profundidade, Zero Trust, SIEM, UEBA, Risk Scoring, supply chain, insider threat, Red Team, observabilidade, resposta a incidentes e segurança de aplicações COBOL.

E talvez exista uma lição ainda mais bonita para quem está começando no mainframe.

Não olhe para um programa COBOL simplesmente como:

INPUT
  ↓
PROCESS
  ↓
OUTPUT

Olhe assim:

IDENTITY
    ↓
AUTHORIZATION
    ↓
INPUT
    ↓
BUSINESS RULES
    ↓
RISK CONTROLS
    ↓
TRANSACTION
    ↓
DATA
    ↓
AUDIT TRAIL

Porque aquele velho programa de quarenta anos pode não ser apenas um sistema que calcula juros, liquida pagamentos ou atualiza uma conta.

Ele pode ser uma das últimas linhas de defesa do negócio.

E quando alguém disser:

“Mas o usuário estava autenticado...”

talvez seja hora de vestir o sobretudo, olhar novamente os SMF records, correlacionar CICS, Db2, RACF, MQ e logs da aplicação e perguntar:

“Autenticado, sim. Mas deveria estar fazendo isso?”

Do fundo do Data Center ouvimos:

Heh-heh-heh-heh-heh...

Mumbly encontrou outra pista. 🐶🔎

Translate

quarta-feira, 8 de maio de 2019