Comprar produtos de (centro de operações de segurança) é fácil e construir um SOC não é, porque a dificuldade não está em produto algum, e sim em saber qual pergunta cada um responde e como as respostas se combinam.
Para que serve cada camada
A arquitetura de SOC da Fortinet é mais fácil de guardar como um conjunto de perguntas que como uma lista de produtos.
| Pergunta | Onde é respondida |
|---|---|
| O que aconteceu neste endpoint? | FortiEDR |
| O que aconteceu na rede? | Logs do FortiGate, FortiNDR |
| O que aconteceu em tudo, correlacionado? | FortiSIEM, FortiAnalyzer |
| Quem está tratando isso, e o que já fez? | FortiSOAR |
| O que é normal para este usuário ou entidade? | UEBA |
O valor está nas costuras, e não nas caixas. Uma execução num endpoint é banal; uma conexão de saída é banal; um e-mail de phishing é banal. Os três juntos, nessa ordem, em minutos, são um incidente, e produto algum sozinho vê os três.
Esse é o argumento para correlação, e é também a razão de um SOC com ferramentas excelentes e nenhuma integração render menos que um com ferramentas modestas conectadas entre si.
Vetores de ataque
As rotas de entrada não mudaram muito, e saber a quais você está de fato exposto foca todo o resto.
Phishing e engenharia social seguem sendo o acesso inicial mais comum, porque miram a parte do sistema que não se corrige com atualização. A oportunidade de detecção raramente é o e-mail em si, e geralmente é o que acontece depois dele: um documento lançando um interpretador de scripts, um usuário autenticando de um local implausível.
Serviços expostos e vulnerabilidades vêm em segundo. Tudo que é alcançável da internet está sendo varrido continuamente, e a janela entre uma vulnerabilidade se tornar pública e ser explorada em escala é curta o bastante para que a cadência de correção seja preocupação de detecção, e não só de higiene.
Abuso de credenciais é o que torna os demais duradouros. Credenciais roubadas produzem atividade que é autorizada por definição, e é por isso que telemetria de identidade importa e por que "este login teve sucesso" não é o mesmo que "este login foi legítimo".
Cadeia de suprimentos e terceiros alarga o perímetro para incluir organizações que você não controla. A consequência prática é que conexões confiáveis merecem monitoramento, e não isenção.
Atividade interna, maliciosa ou descuidada, é o caso em que todo controle técnico está satisfeito e o comportamento ainda está errado. É o argumento mais forte a favor de linha de base comportamental.
Ler comportamento em vez de alertas
Um alerta diz que algo casou com uma regra. Comportamento é a sequência, e lê-la é o que separa triagem de investigação.
Os enquadramentos que ajudam:
Etapas. Ataques avançam por fases reconhecíveis: obter acesso, estabelecer persistência, escalar privilégio, mover-se lateralmente, coletar, e agir sobre objetivos. Situar uma observação numa etapa diz o que procurar em seguida: um alerta de execução deveria motivar uma checagem de persistência, porque é isso que costuma vir depois.
Técnicas acima de indicadores. Um indicador é um endereço ou hash específico e muda barato. Uma técnica — extrair credenciais da memória de um processo, agendar uma tarefa para persistência — é cara para o atacante mudar porque é como o objetivo é alcançado. Detecções escritas contra técnicas sobrevivem; contra indicadores, expiram.
Linhas de base. Boa parte da atividade maliciosa é atividade comum num lugar ou horário incomum. Uma ferramenta administrativa não é suspeita; aquela conta usando-a naquele servidor àquela hora pode ser. Isso só funciona se o normal tiver sido caracterizado, que é para o que serve a UEBA.
O que torna uma detecção boa
A falha recorrente em engenharia de detecção é volume sem discriminação. Uma regra que dispara o tempo todo é silenciada, e uma regra silenciada é pior que uma ausente, porque produz a aparência de cobertura.
As propriedades que vale exigir:
Uma resposta. Se ninguém sabe dizer o que fazer quando ela dispara, é telemetria, e não detecção, e pertence a um painel.
Falsos positivos toleráveis. Medidos no ambiente real, e não em princípio. Uma regra que produz quarenta alertas por dia no seu parque precisa de ajuste antes de ser habilitada, faça ela o que fizer em outro lugar.
Intenção documentada. O que ela procura e por quê. Quem faz a triagem às 3h frequentemente não é quem a escreveu, e uma regra que ninguém entende é uma regra que ninguém consegue ajustar.
Dados que ela consiga de fato ver. Uma detecção que depende de telemetria que sua coleta não retém nunca vai disparar, e a ausência parece idêntica a uma ausência de ataques.
O que quem vai prestar o exame precisa saber de cor
Cada produto de SOC responde uma pergunta diferente — endpoint, rede, correlacionado, fluxo de trabalho, linha de base comportamental — e o valor está em correlacionar entre eles, porque ataques relevantes são banais em qualquer visão isolada. Os principais vetores são phishing, serviços expostos, abuso de credenciais, cadeia de suprimentos e insiders, e o abuso de credenciais é o que torna a atividade autorizada por definição. Leia comportamento como sequências em etapas, prefira técnicas a indicadores porque indicadores mudam barato, e estabeleça uma linha de base para que atividade comum em contexto incomum fique visível. Uma detecção precisa de resposta definida, falsos positivos toleráveis medidos no seu próprio ambiente, intenção documentada, e telemetria que seja de fato coletada.
Esta série, em ordem
Este artigo abre a série Operações de segurança da Fortinet. Ele monta o quadro: qual pergunta cada produto responde, e como os atacantes de fato entram; as partes tratam então dos produtos na ordem em que a evidência flui por um centro de operações: logs coletados e relatados, correlacionados em incidentes, tratados por playbooks, enriquecidos pelo que os endpoints e a rede viram, atraídos por iscas e, por fim, a visão que um atacante tem de você antes de tudo isso começar.
- Ingestão de logs no FortiAnalyzer: normalização e a divisão analytics/arquivo. Logs analisados em campos estruturados e guardados duas vezes: o armazenamento de análise indexado e o arquivo comprimido.
- Relatórios do FortiAnalyzer: datasets, gráficos e por que um relatório volta vazio. Um dataset é uma consulta, um gráfico renderiza um, um relatório organiza os gráficos: e por que um relatório volta vazio.
- SOC no FortiAnalyzer: manipuladores de eventos, incidentes, indicadores e playbooks. Do log ao evento e ao incidente: os handlers que você escreve, os incidentes que as pessoas trabalham, os playbooks que agem.
- Regras, subpadrões e transformar incidentes em ação no FortiSIEM. Regras feitas de subpadrões, para que uma regra diga isto aconteceu e depois aquilo, dentro de uma janela.
- Analytics no FortiSIEM: montar consultas, agregação e o CMDB. Uma busca só é tão boa quanto aquilo com que consegue cruzar: consultas, agregação e a configuration management database.
- Aprendizado de máquina, UEBA e integração da plataforma no FortiSIEM. Aprendizado de máquina e análise de comportamento de usuários para o que nenhuma regra descreveu, e o resto da plataforma integrado.
- Arquitetura e modelo de dados do FortiSOAR: módulos, registros e relacionamentos. Um banco de dados com automação acoplada: módulos, registros, campos e as relações entre eles.
- Playbooks, Jinja e conectores no FortiSOAR. Um gatilho, passos e dados fluindo entre eles, e o Jinja que molda a saída de um passo para o seguinte.
- Fluxo de incidentes, filas, war rooms e depuração de playbooks no FortiSOAR. Fases, filas e war rooms para quem trabalha incidentes, e como depurar um playbook.
- Arquitetura do FortiEDR: componentes, implantação, multi-tenancy e o serviço de nuvem. O que o coletor vê no endpoint contra o que o serviço em nuvem sabe sobre o mundo.
- Políticas, controle de comunicação e playbooks no FortiEDR. As políticas de segurança decidem o que um processo pode fazer; o controle de comunicação decide quais aplicações podem conversar.
- Caça a ameaças, forense e investigação de alertas no FortiEDR. O que aconteceu antes do alerta, o que ele tocou e se ainda está acontecendo.
- FortiNDR Cloud: arquitetura, sensores, tipos de evento e detecções. Observar o tráfego em vez dos endpoints: sensores, tipos de evento e o que nenhum agente consegue ver.
- FortiNDR Cloud: consultas IQL, caça a ameaças e integração. Fazer perguntas aos metadados de rede retidos depois do fato, e ligar as respostas ao resto.
- FortiDeceptor: chamarizes, iscas, tokens e o desenho de uma estratégia de dissimulação. Uma isca não tem usuários legítimos, então qualquer interação com ela é suspeita por construção.
- Implantação do FortiDeceptor: redes, sites isolados, gerência central e análise de incidentes. Alcançar os segmentos que os atacantes usam, inclusive os isolados e sem conexão externa, e analisar o que as iscas pegaram.
- FortiRecon: gestão de superfície de ataque e o que a dark web de fato é. O que um atacante vê quando olha para você, e o que a dark web de fato é.