Runtime protection: RASP e detecção de anomalias

1. Introdução à Proteção em Tempo de Execução

Proteger uma aplicação apenas durante o desenvolvimento não é mais suficiente. Enquanto ferramentas de SAST (Static Application Security Testing) e SCA (Software Composition Analysis) analisam o código-fonte e dependências em busca de vulnerabilidades conhecidas, elas não conseguem detectar ataques que ocorrem durante a execução da aplicação. É aí que entra a proteção em tempo de execução (runtime protection).

O paradoxo da segurança em produção é claro: precisamos de baixa latência para oferecer boa experiência ao usuário, mas também precisamos detectar e bloquear ataques em milissegundos. Cenários como injeção de SQL, exploração de memória (buffer overflow) e abuso de lógica de negócios exigem mecanismos que observem o comportamento real da aplicação, não apenas o código estático.

2. RASP (Runtime Application Self-Protection): Conceitos Fundamentais

RASP é uma tecnologia que integra segurança diretamente no runtime da aplicação. Diferente de um WAF (Web Application Firewall) que opera na borda da rede analisando tráfego HTTP, o RASP executa dentro da aplicação, interceptando chamadas de função, fluxo de dados e tráfego interno.

Existem duas arquiteturas principais:

  • Agente embarcado: biblioteca ou módulo carregado junto com a aplicação (ex: agente Java, módulo Node.js)
  • Proxy reverso: camada intermediária que intercepta requisições antes de chegarem ao servidor

Enquanto o WAF analisa o payload HTTP, o RASP entende o contexto da aplicação — sabe se um parâmetro está sendo usado em uma consulta SQL, por exemplo. Já o EDR (Endpoint Detection and Response) foca no sistema operacional, não na aplicação.

3. Técnicas de Detecção de Anomalias em Aplicações

A detecção de anomalias em runtime se divide em duas abordagens principais:

  • Baseada em assinaturas: compara o comportamento atual com padrões conhecidos de ataques (SQL injection, XSS). Eficaz contra ameaças conhecidas, mas falha em ataques zero-day.
  • Baseada em heurísticas: estabelece um baseline do comportamento normal da aplicação e detecta desvios estatísticos. Exemplo: se uma API normalmente recebe 100 requisições/min e de repente recebe 10.000, algo anormal está ocorrendo.

Métricas importantes de runtime incluem latência de requisições, taxa de erro HTTP, alocação de memória e número de conexões simultâneas. Um pico repentino de alocação de heap pode indicar um ataque de negação de serviço ou exploração de memória.

4. Integração do RASP no Pipeline de Desenvolvimento

A integração do RASP deve acontecer desde os estágios iniciais do pipeline CI/CD. Ferramentas como Contrast Security, Hdiv e OpenRASP (código aberto) oferecem agentes para diversas linguagens.

Exemplo de configuração de agente OpenRASP em uma aplicação Java:

# Configuração do OpenRASP para Spring Boot
# Arquivo: openrasp.yml

rasp:
  enabled: true
  mode: monitor  # ou 'block' para bloquear ataques
  log_level: info
  security:
    sql_injection:
      enabled: true
      action: block
    command_injection:
      enabled: true
      action: log
    ssrf:
      enabled: true
      action: block

Em ambientes de homologação, recomenda-se usar o modo monitor (apenas log) para evitar falsos positivos que possam bloquear funcionalidades legítimas. Após validação, ativa-se o modo block em produção.

5. Detecção de Anomalias Específicas por Camada

Camada de Entrada

Aqui, o RASP analisa payloads de requisições HTTP. Exemplo de detecção de SQL injection:

# Log de detecção de SQL injection pelo RASP
[2025-01-15 14:32:01] ALERTA: SQL injection detectado
  Requisição: POST /api/users/login
  Parâmetro: username = "admin' OR '1'='1"
  Contexto: consulta SQL gerada: SELECT * FROM users WHERE username = 'admin' OR '1'='1'
  Ação: bloqueado

Camada de Lógica

Anomalias em chamadas de API, como traversal de IDs ou abuso de rate limit, são detectadas por análise comportamental:

# Detecção de IDOR (Insecure Direct Object Reference)
[2025-01-15 14:35:22] ALERTA: Acesso não autorizado a objeto
  Usuário: user123 (role: viewer)
  Recurso: /api/admin/config
  Contexto: usuário sem privilégios de admin tentou acessar endpoint restrito
  Ação: log + bloqueio

Camada de Dados

Vazamento de dados em responses ou acesso não autorizado a objetos são monitorados:

# Detecção de resposta com dados sensíveis
[2025-01-15 14:40:11] ALERTA: Possível vazamento de dados
  Endpoint: GET /api/users/profile/456
  Response inclui campo: "credit_card_number" (mascarado parcialmente)
  Ação: log (modo monitor)

6. Ferramentas e Implementação Prática

Exemplo com Node.js (Express) usando OpenRASP

// Instalação do agente OpenRASP
npm install openrasp-node

// Configuração no arquivo principal
const openrasp = require('openrasp-node');
const express = require('express');
const app = express();

// Inicializar RASP
openrasp.start({
  app_id: 'minha-app',
  mode: 'monitor',  // ou 'block' em produção
  server_url: 'http://localhost:8080'
});

// Middleware do RASP para interceptar requisições
app.use(openrasp.middleware());

// Endpoint vulnerável (protegido pelo RASP)
app.post('/api/search', (req, res) => {
  const query = req.body.query;
  // O RASP interceptará SQL injection aqui
  const result = db.execute(`SELECT * FROM products WHERE name = '${query}'`);
  res.json(result);
});

Integração com SIEM

Para enviar logs de anomalias para sistemas como ELK ou Splunk:

# Configuração de saída de logs do RASP
rasp:
  output:
    type: file
    path: /var/log/rasp/rasp.log
  siem:
    enabled: true
    format: json
    endpoint: http://siem-server:9200/rasp-logs

7. Desafios e Mitigações na Adoção de RASP

Desafio Mitigação
Overhead de CPU (5-10%) Testar em staging, dimensionar recursos
Falsos positivos Ajustar thresholds, usar modo monitor inicial
Latência adicional (1-5ms) Otimizar regras, usar cache de decisões

RASP não substitui práticas de codificação segura. É uma camada adicional de defesa (defense in depth), não uma bala de prata.

8. Casos de Uso e Melhores Práticas para Devs

Exemplo real: bloqueio de Log4Shell (CVE-2021-44228)

O RASP conseguiu bloquear a exploração da vulnerabilidade Log4Shell em tempo real, mesmo em aplicações que ainda não haviam sido patchadas. O agente detectava o padrão ${jndi:ldap://...} nas requisições e impedia a execução da função vulnerable.

Estratégia de rollout

  1. Fase 1 (Homologação): RASP em modo monitor, coletando logs e identificando falsos positivos
  2. Fase 2 (Produção - monitor): Ativar em produção, apenas observando
  3. Fase 3 (Produção - bloqueio gradual): Ativar bloqueio para ataques críticos (SQL injection, RCE)
  4. Fase 4 (Produção - bloqueio total): Bloquear todos os padrões de ataque conhecidos

Checklist para equipes de desenvolvimento

  • [ ] Realizar testes de penetração com RASP ativo
  • [ ] Revisar logs de anomalias semanalmente
  • [ ] Ajustar regras de detecção baseadas em falsos positivos
  • [ ] Documentar exceções de regras (whitelist)
  • [ ] Testar performance com RASP ativo antes de ir para produção

Referências