A Apollo consegue triar seus alertas de segurança? O único sinal real estava enterrado em dez mil
Trabalho de segurança tier-one não é pegar atacantes, é se afogar em alertas que não são eles. Um agent que faz dedup, enriquece, e suprime o ruído conhecido te devolve o único sinal que um humano cansado perdeu.
Apollo Space Research
Apollo Space
Um console de segurança acende dez mil vezes antes do almoço. Um humano deveria olhar cada um e decidir: este é o atacante, ou isto é nada? Na terceira hora, todo alerta parece nada, porque nove mil e novecentos deles eram. Então o analista começa a clicar em “acknowledge” no instinto, e em algum lugar daquele fluxo, o que importava recebe o mesmo clique reflexo que os demais.
É assim que breaches acontecem com o alerta bem ali, já disparado, já ignorado.
O trabalho de segurança tier-one nunca foi ser brilhante. Era sobreviver ao volume. O agent restaura o sinal-ruído que um humano cansado perdeu, não achando mais alertas, mas matando os que nunca foram a história. Este post é sobre como, e por que a parte difícil não é detecção de jeito nenhum.
A versão ingênua: um humano como a fila
A montagem padrão parece razoável num slide. Suas ferramentas observam tudo, os endpoints, a rede, as contas de cloud, o provedor de identidade, e quando qualquer uma delas vê algo de que não gosta, levanta um alerta. Os alertas fluem para uma fila. Uma pessoa trabalha a fila, de cima a baixo, decidindo o que escalar.
Funciona para os primeiros cem. Aí o volume chega e o modelo quebra de um jeito que ninguém projetou.
A primeira falha é duplicação. Um evento, um único laptop mal configurado, digamos, dispara a ferramenta de endpoint, a de rede, e a de cloud-audit ao mesmo tempo. Agora são três alertas. Um login de um local incomum dispara a cada quinze minutos por uma hora porque o usuário está numa conexão instável. Agora são mais quatro. A fila não é dez mil eventos. É talvez algumas centenas de coisas reais, cada uma vestindo vinte fantasias, e o humano tem que reconhecer a fantasia antes de poder dispensá-la.
A segunda falha é pior, e é a que termina carreiras. O alerta de ruído conhecido, o backup job que sempre dispara a regra de exfiltração de dados às 2h, o scanner que você mesmo roda toda terça, é indistinguível de um real à primeira vista. Você aprende a deixar passar. E no dia em que uma exfiltração real por acaso se parece com o backup job, você deixa esse passar também. Supressão-por-fadiga não é uma política. É a ausência de uma, executada por uma pessoa exausta em alta velocidade.
O gargalo nunca foi detecção. As ferramentas detectam bem, esse é o problema, elas detectam tudo. O gargalo é um humano sendo pedido para ser um motor de deduplicação, um serviço de lookup, e uma decisão de julgamento, tudo ao mesmo tempo, o dia todo, ficando mais lento e menos preciso a cada hora. À tarde a decisão de segurança mais importante do prédio está sendo tomada pela pessoa mais esgotada nele.
O formato da correção: faça o trabalho chato antes de o humano ver
Aqui está a ideia-chave, e é mais simples do que a indústria de tooling faz parecer. A maior parte do que um analista tier-one faz não é julgamento. É escrituração. E escrituração é exatamente o que você nunca deveria pedir a um humano cansado para fazer em volume.
Três dos quatro trabalhos naquela fila são mecânicos. Deduplicação é mecânica: mesma fonte, mesma assinatura, mesma janela, isso é um evento, não vinte. Enriquecimento é mecânico: este IP, este usuário, este ativo, vá procurar e anexe o que se sabe antes de alguém ter que perguntar. Supressão é mecânica também, desde que a regra esteja escrita em vez de carregada na cabeça de alguém: o scanner de terça é o scanner de terça, toda terça, para sempre.
Só o quarto trabalho é julgamento: este é diferente, e aqui está por que você deveria se importar. Esse é o trabalho que você quer um humano fazendo em atenção plena. Tudo a montante dele é trabalho que já deveria estar feito quando uma pessoa olhar.
Então o agent faz os três trabalhos mecânicos primeiro, no escuro, antes de a fila jamais chegar a um humano. O agent restaura o sinal-ruído que um humano cansado perdeu, não achando mais alertas, mas matando os que nunca foram a história. Deixe-me percorrer os três.
Trabalho um: colapse as duplicatas no evento
A fila ingênua trata cada alerta como um fato. O agent trata alertas como evidência sobre um evento, que é uma unidade inteiramente diferente.
Quando três ferramentas disparam num laptop mal configurado, aqueles não são três problemas. São três testemunhas de um problema. O agent agrupa pelo que têm em comum, o mesmo host, a mesma janela de tempo, a mesma assinatura subjacente, e dobra vinte alertas num incidente com vinte peças de evidência de suporte anexadas. O login de conexão instável que disparou a cada quinze minutos vira uma única linha: sete alertas, mesmo usuário, mesmo padrão, ao longo de uma hora.
O humano agora lê incidentes, não alertas. Digamos que uma manhã típica traga quatrocentos alertas brutos; colapse as duplicatas e você pode estar olhando para quarenta eventos reais. Isso não é uma vitória pequena. Essa é a diferença entre uma fila que você passa os olhos em pânico e uma fila que você de fato lê. E a leitura é onde o julgamento pelo qual você é pago de fato acontece.
O ponto do colapso não é arrumação. É que um analista encarando um incidente bem-formado com sua evidência anexada toma uma decisão melhor que o mesmo analista encarando os vinte fragmentos de que veio, porque os fragmentos escondem o formato e o incidente o mostra.
Trabalho dois: enriqueça antes de alguém perguntar
Esta é a parte que parece mágica e é a mais mecânica de todas.
Na versão ingênua, um único alerta ambíguo dá início a uma caça ao tesouro. O analista vê um IP desconhecido e começa a abrir abas, lookup de reputação, geolocalização, isto-é-um-dos-nossos, já-disparou-antes. Ele vê um nome de usuário desconhecido e começa outra caça, qual o papel desta pessoa, no que ela normalmente toca, ela ainda está aqui. Cada lookup são trinta segundos. Multiplique por cada alerta ambíguo na fila e a caça ao tesouro é o trabalho.
O contexto já existe. Está espalhado, pelo inventário de ativos, o diretório de identidade, o histórico de incidentes passados, os feeds de ameaça, mas espalhado não é o mesmo que disponível. Funcionalmente, se ninguém o montou, ele não está lá.
O agent o monta com antecedência. Quando um humano vê o incidente, o IP já está rotulado com sua reputação e se pertence à empresa. O usuário já está rotulado com seu papel e se este comportamento é normal para ele. O ativo já está rotulado com quão sensível é. O analista não abre uma única aba. Ele lê um incidente enriquecido e gasta sua atenção na única pergunta que de fato é difícil: dado tudo isso, é real?
Esse é o motor silencioso sob a triagem rápida, não um analista mais esperto, mas um brain que fez os lookups enquanto o prédio estava escuro e os entregou como contexto em vez de dever de casa.
Trabalho três: suprima o ruído conhecido, em voz alta, não na cabeça de alguém
Este é o trabalho que silenciosamente decide se a coisa toda é segura.
Supressão é necessária; o backup job de fato dispara a regra toda noite e de fato é nada. O perigo não é suprimi-lo. O perigo é como um humano o suprime, aprendendo a ignorar um formato, o que significa que ele também ignora a coisa real que por acaso compartilha aquele formato. O conhecimento “isto está ok” mora em lugar nenhum a não ser nos reflexos do analista, e reflexos não conseguem distinguir um backup de uma exfiltração quando finalmente diferem.
O agent suprime o mesmo ruído, mas suprime uma regra escrita, não um sentimento. O scanner de terça é suprimido porque há uma regra explícita que diz: esta fonte, esta assinatura, esta janela, esperado. Quando algo bate com a regra, é arquivado, não revelado, mas arquivado, não deletado, então está lá se a imagem mudar. E aqui está a parte que o reflexo humano não consegue: quando um alerta quase bate com a regra de supressão mas difere de um jeito revelador, o backup job, mas de um IP que o backup nunca usou, o agent não o deixa passar. O quase-acerto é exatamente o que deveria escalar. Um reflexo suprime o quase-acerto. Uma regra o pega.
Essa é a inversão. O humano cansado suprime por similaridade e perde a exceção perigosa. O agent suprime por uma regra explícita e a exceção é a única coisa que sobrevive à supressão. Mesmo ruído removido. Segurança oposta.
O que sobra é o que você escala
Depois dos três trabalhos mecânicos, o que chega a um humano é pequeno, deduplicado, enriquecido, e sem ruído. A escalação não é “aqui está um alerta”. É “aqui está o único incidente desta manhã que não bate com um padrão conhecido, aqui está tudo que já sabemos sobre o ativo e o ator, e aqui está por que ele passou por toda regra de supressão”.
Essa é uma escalação em que um humano consegue agir em um minuto em vez de reconstruir ao longo de uma hora. E criticamente, o humano agora está lendo em atenção plena, porque está lendo uma coisa, não a décima-milésima coisa. O sinal não ficou mais alto. O ruído foi removido da frente dele.
Há uma proteção que vale nomear, porque o modo de falha de qualquer filtro agressivo é que ele filtra bem demais. Supressão ansiosa demais vira a mesma fadiga, só que automatizada, o agent deixando coisas passar do jeito que o humano cansado deixava. Então a versão segura mantém os eventos suprimidos arquivados e revisáveis, escala cada quase-acerto em vez de cada acerto, e trata “não tenho certeza” como uma razão para revelar, não para esconder. O trabalho do agent é remover os alertas que comprovadamente nunca foram a história, não adivinhar sobre os que poderiam ser.
A virada: o volume nunca foi o inimigo
Tire os consoles e os feeds e aqui está o que de fato é verdade. Ninguém num time de segurança é ruim em julgamento. Eles são ruins em julgamento na hora seis de lutar contra a fila, que é uma coisa completamente diferente, e não uma falha pessoal. Você pode contratar o analista mais afiado do mundo e a fila ainda vai esmagá-lo até virar um reflexo à tarde, porque é isso que dez mil alertas fazem com um sistema nervoso humano.
O trabalho de triagem parecia vigilância. Era principalmente imposto. Cada duplicata colapsada na mão, cada IP procurado numa aba, cada backup job deixado passar no instinto, esse era tempo e atenção gastos não na coisa que só um humano consegue: olhar o único evento genuinamente estranho com a mente fresca e decidir se a empresa está sob ataque. A pessoa mais valiosa na sala estava gastando suas melhores horas sendo um motor de deduplicação.
Então a pergunta não é se um agent pode substituir seu time de segurança. Não pode, e você não quer que ele substitua, a escalação ainda termina num humano que decide. A pergunta é se suas pessoas mais afiadas deveriam gastar suas manhãs como a fila ou como o julgamento. Triagem sempre foi dois trabalhos vestindo uma cabeça cansada: a escrituração que te desgasta, e a única decisão que vale a pena estar afiado para tomar. A máquina é muito boa na primeira. Ela existe para que o humano possa finalmente ser bom na segunda.
É isso que estamos construindo na Apollo, não um alarme mais alto, mas o colega de trabalho que lê a enxurrada inteira enquanto você dorme e te acorda para a única coisa que de fato é diferente. Se você já clicou em “acknowledge” no alerta que acabou importando, você já sabe que não foi descuido. Foi o volume. Alguém deveria estar pagando esse imposto por você.
A Apollo cuida da operação repetitiva da sua empresa pro seu time não precisar.
Entre na lista de espera: acesso antecipado, preço de usuário fundador e um lugar na primeira fila enquanto a gente constrói.
Entrar na lista de esperaA Apollo consegue escrever seu investor update?
Sim, porque a parte difícil do update mensal nunca foi a escrita. Era lembrar o que de fato aconteceu. A Apollo lê a empresa e rascunha; você mantém o julgamento e o tom.
Casos de UsoA Apollo consegue rodar seu partnerships desk? Sim, porque BD é um problema de memória
Business development não é outreach de alto volume. É pesquisa, uma intro quente, um pipeline conjunto, e um nudge para o deal que silenciosamente travou, guiado pela relação, não pela meta.
Casos de UsoA Apollo consegue rodar seu customer onboarding?
Onboarding é um checklist observado com prazos e riscos, a janela de maior churn que você tem, e um agent proativo persegue cada passo até o cliente chegar ao primeiro valor.