Cybersecurity Architecture

O que é este projeto

Este repositório reúne uma coleção de arquiteturas de segurança cibernética, modelos de ameaças (threat models), playbooks de resposta a incidentes e templates de compliance que usamos como base em projetos reais. Cada artefato foi construído a partir de experiências em ambientes de produção.

A segurança não pode ser uma reflexão tardia. Ela precisa estar embutida desde o design da arquitetura até o monitoramento em tempo real. Este projeto documenta exatamente como fazemos isso: desde a modelagem de ameaças antes de escrever a primeira linha de código até a automação de detecção e resposta quando algo dá errado.

Cada módulo segue uma estrutura consistente: contexto do cenário, modelo de ameaça aplicável, controles implementados, código funcional e métricas de validação. O objetivo é que qualquer equipe consiga pegar um playbook, adaptar ao seu contexto e aplicar em produção no mesmo dia.

Todos os playbooks seguem o formato NIST CSF (Identify, Protect, Detect, Respond, Recover) e incluem templates de comunicação para stakeholders durante incidentes.

Threat Modeling

Modelagem de ameaças é o exercício de pensar como um atacante antes que ele pense por você. Usamos dois frameworks complementares: STRIDE para identificar categorias de ameaças e DREAD para priorizar o risco de cada uma.

STRIDE — Categorias de ameaças

Spoofing (Falsificação) — um atacante se passa por outro usuário ou serviço. Exemplo: token JWT forjado sem validação de assinatura permite acesso administrativo
Tampering (Adulteração) — dados são modificados em trânsito ou em repouso. Exemplo: parâmetros de preço alterados no body de uma requisição de pagamento
Repudiation (Repúdio) — ações são executadas sem rastro auditável. Exemplo: exclusão de registros financeiros sem log imutável
Information Disclosure (Vazamento) — dados sensíveis expostos indevidamente. Exemplo: stack trace com credenciais de banco retornado em erro 500
Denial of Service (Negação de Serviço) — recurso tornado indisponível. Exemplo: endpoint sem rate limiting que permite 10 mil requests por segundo
Elevation of Privilege (Escalação) — acesso a funcionalidades além do permitido. Exemplo: IDOR que permite um usuário comum acessar dados de administrador

DREAD — Priorização de risco

Cada ameaça identificada pelo STRIDE recebe uma pontuação DREAD de 1 a 10 em cinco dimensões: Damage (impacto), Reproducibility (facilidade de reprodução), Exploitability (facilidade de exploração), Affected Users (usuários impactados) e Discoverability (facilidade de descoberta). A média define a prioridade de mitigação.

Na prática, aplicamos STRIDE em cada componente do diagrama de arquitetura e geramos uma matriz de risco DREAD. Isso nos dá um backlog de segurança priorizado que pode ser integrado ao sprint da equipe de desenvolvimento.

Zero Trust Architecture

O modelo Zero Trust parte de um princípio simples: nunca confie, sempre verifique. Independentemente de onde o request origina — rede interna, VPN, ou internet pública — cada acesso é tratado como potencialmente hostil e precisa ser autenticado, autorizado e criptografado.

Implementamos Zero Trust em três camadas:

Microssegmentação de rede — cada serviço vive em seu próprio segmento com regras de firewall específicas. Um banco de dados nunca é acessível diretamente pela internet, e mesmo serviços internos precisam de mTLS para se comunicar
Autenticação mútua (mTLS) — tanto o cliente quanto o servidor apresentam certificados. Isso impede que um serviço comprometido se passe por outro na rede interna
Least privilege dinâmico — permissões são concedidas just-in-time e com escopo mínimo. Um serviço de relatórios tem acesso read-only ao banco, e apenas durante a janela de execução
Continuous verification — sessões são reavaliadas continuamente. Mudança de IP, device fingerprint ou padrão de uso dispara re-autenticação

Arquitetura Zero Trust com microssegmentação, mTLS e verificação contínua

Resposta a incidentes

Um playbook de resposta a incidentes não é um documento que você lê durante a crise. É um procedimento que a equipe pratica antes da crise acontecer. Estruturamos cada playbook em seis fases baseadas no NIST:

Preparação — ferramentas configuradas, canais de comunicação definidos, runbooks acessíveis offline
Identificação — alertas do SIEM, triagem inicial, classificação de severidade (P1 a P4)
Contenção — isolamento do sistema afetado sem destruir evidências forenses
Erradicação — remoção da causa raiz, patching, rotação de credenciais comprometidas
Recuperação — restauração gradual com monitoramento intensificado
Lições aprendidas — post-mortem blameless, atualização de controles e playbooks

SLA de resposta a incidentes: P1 (crítico, dados vazados ou sistema fora do ar) exige resposta em 15 minutos, contenção em 1 hora e comunicação a stakeholders em 2 horas. P2 (alto impacto, funcionalidade degradada) exige resposta em 30 minutos. Esses SLAs devem estar documentados e testados com simulações trimestrais.

Exemplo: Script de análise de logs para detecção de brute force

# incident_detector.py
# Detecta tentativas de brute force analisando logs de autenticação

import re
from collections import defaultdict
from datetime import datetime, timedelta

def detect_brute_force(log_path, threshold=10, window_minutes=5):
    """Analisa logs de autenticação e detecta IPs com
    tentativas de login acima do threshold na janela."""

    failed_attempts = defaultdict(list)
    pattern = re.compile(
        r'(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}).*'
        r'Failed login.*from (\d+\.\d+\.\d+\.\d+)'
    )

    with open(log_path, 'r') as f:
        for line in f:
            match = pattern.search(line)
            if match:
                timestamp = datetime.strptime(
                    match.group(1), '%Y-%m-%d %H:%M:%S'
                )
                ip = match.group(2)
                failed_attempts[ip].append(timestamp)

    alerts = []
    window = timedelta(minutes=window_minutes)

    for ip, timestamps in failed_attempts.items():
        timestamps.sort()
        for i, ts in enumerate(timestamps):
            count = sum(
                1 for t in timestamps[i:]
                if t - ts <= window
            )
            if count >= threshold:
                alerts.append({
                    'ip': ip,
                    'attempts': count,
                    'first_seen': ts.isoformat(),
                    'severity': 'P1' if count > 50 else 'P2'
                })
                break

    return alerts

# Uso
alerts = detect_brute_force('/var/log/auth/access.log')
for alert in alerts:
    print(f"[{alert['severity']}] {alert['ip']} "
          f"- {alert['attempts']} tentativas")
                

SIEM e monitoramento

Um SIEM (Security Information and Event Management) é o centro nervoso da operação de segurança. Ele coleta, correlaciona e analisa eventos de múltiplas fontes para detectar ameaças que nenhum log individual revelaria sozinho.

Documentamos configurações para ELK Stack e Splunk, incluindo:

Regras de detecção — queries que disparam alertas quando padrões suspeitos são identificados (login fora do horário, acesso a dados sensíveis em volume anormal, movimentação lateral)
Correlação de eventos — combinar logs de firewall, WAF, aplicação e banco de dados para reconstruir a cadeia de um ataque (kill chain)
Dashboards operacionais — visão em tempo real de tentativas de intrusão, top IPs bloqueados, anomalias de tráfego e status de compliance
Retenção e forense — políticas de retenção de logs por 12 meses (mínimo LGPD) com integridade garantida por hash encadeado

Exemplo: Regra YARA para detecção de webshell

# webshell_detection.yar
# Detecta webshells PHP comuns em uploads de arquivos

rule PHP_Webshell_Generic {
    meta:
        description = "Detecta webshells PHP genéricas"
        severity    = "critical"
        author      = "Sakaguchi IA Security"

    strings:
        $eval    = "eval($_" ascii
        $base64  = "base64_decode($_" ascii
        $system  = "system($_" ascii
        $exec    = "exec($_" ascii
        $shell   = "shell_exec($_" ascii
        $passthru= "passthru($_" ascii
        $assert  = "assert($_" ascii

    condition:
        filesize < 500KB and 2 of them
}
                

Compliance

Compliance não é checklist — é a tradução de requisitos regulatórios em controles técnicos mensuráveis. Mapeamos os frameworks mais relevantes para o mercado brasileiro e internacional:

LGPD (Lei Geral de Proteção de Dados) — mapeamento de bases legais por tipo de dado, registro de operações de tratamento (ROPA), mecanismos de consentimento granular, direito ao esquecimento com auditoria, e relatório de impacto (RIPD) para tratamentos de alto risco
SOC 2 Type II — controles de segurança, disponibilidade, integridade de processamento, confidencialidade e privacidade. Documentamos evidências automatizadas para cada Trust Service Criteria com scripts que coletam provas de controle continuamente
ISO 27001 — sistema de gestão de segurança da informação com 93 controles do Anexo A. Incluímos templates de declaração de aplicabilidade (SoA) e procedimentos operacionais para cada controle aplicável

Cada módulo de compliance inclui um mapeamento cruzado: para cada artigo da LGPD, indicamos o controle SOC 2 e ISO 27001 correspondente. Isso evita duplicação de esforço quando a organização precisa atender múltiplos frameworks simultaneamente.

Como usar

Clone o repositório, identifique o módulo que mais se aproxima do seu cenário e adapte. Cada pasta contém:

README.md — contexto, modelo de ameaça e decisões de segurança
playbook/ — procedimentos de resposta com checklists executáveis
detection/ — regras YARA, queries SIEM e scripts de detecção
compliance/ — mapeamento de controles e templates de evidência
scripts/ — ferramentas Python para automação de segurança
diagrams/ — diagramas SVG de arquitetura e fluxos de ataque

# Clone e comece
$ git clone https://github.com/Richardmsbr/cybersecurity-architecture
$ cd cybersecurity-architecture
$ pip install -r requirements.txt

# Execute o detector de brute force
$ python scripts/incident_detector.py --log /var/log/auth.log

# Escaneie uploads com regras YARA
$ yara detection/webshell_detection.yar /var/www/uploads/
                

Arquiteturas de segurança cibernética para produção

O que é este projeto

Threat Modeling

STRIDE — Categorias de ameaças

DREAD — Priorização de risco

Zero Trust Architecture

Resposta a incidentes

Exemplo: Script de análise de logs para detecção de brute force

SIEM e monitoramento

Exemplo: Regra YARA para detecção de webshell

Compliance

Como usar

Tecnologias

Detalhes

Índice

Quer algo parecido?

Quer implementar algo parecido?