A importância dos playbooks no SOC

Passei boa parte, ou senão a maior parte da minha trajetória profissional trabalhando com, ou em SOCs. Seja como cliente, como prestador do serviço, como contribuidor individual, ou como líder. Mas certa vez tive uma das experiências mais interessantes e de maior aprendizado.

Eu era líder de um time de segurança e cliente de um SOC 100% remoto. Por uma questão estratégica da companhia, internalizamos parte da operação, transformando-o em um SOC híbrido. Em resumo, meu desafio foi:

• Desenhar e dimensionar o que seria o novo SOC, e preparar uma RFP para migração do serviço remoto para híbrido, baseado nesta nova arquitetura.
• O N1 viria deste novo contrato, e o N2 seria de interno. Foi necessário, então, um hiring significativo de especialistas.
• Um novo (e muito bonito) espaço acolheria o SOC, o que trouxe questões de logística. Todos iriam ocupar o SOC em turnos de 24x7 e precisavam ter todas as facilidades prontas.
• Ajustes pontuais e rearquitetura das soluções.

Cronograma super apertado, mas concluído no prazo, e ao final de tudo isso, tínhamos um SOC híbrido operando. Quando de-repente, o inesperado aconteceu (na verdade eu deveria esperar).

Todos, ou a maioria, estavam chegando praticamente juntos. O time de N1, que chegou neste novo contrato, estava treinado nas ferramentas, mas não conhecia os processos, e muito menos o que fazer com os eventos que não paravam de aparecer, além dos pedidos dos clientes internos. Com isso, os casos subiam para o N2. O N2, que também era formado por novos colaboradores, por sua vez, queriam dedicar tempo à engenharia do SOC, e não queriam ter o trabalho operacional de triagem do que estava chegando.

Foi então que identifiquei que precisávamos definir a governança, a começar pela criação dos playbooks, o que ajudaria o N1 a saber o que fazer na triagem.

Isso parece trivial em uma operação de SOC hoje em dia, mas na época não se falava em automação de SOC. SOAR era coisa do futuro, e XDR praticamente não existia. Automação, quando existia, era feita via scripting. Então nos reunimos como time, e após algum tempo na sala rabiscando no whiteboard, chegamos à uma solução.

A solução

Todo evento que gerasse um caso de uso novo, ou não documentado, seria analisado pelo N2, responsável pela engenharia do SOC. O playbook seria definido, documentado na knowledge base, e, quando acontecesse novamente, o N1 saberia o que fazer. E, quando possível, o caso de uso seria automatizado.

O resultado

Tivemos alguns resultados muito interessantes e valiosos, que abrangeram desde a satisfação do time até uma eficiência operacional bem melhor.

Primeiramente, construímos em pouquíssimo tempo, uma KB recheada de casos de uso, pois o N2 estava focado em modelar e documentar cada novo caso para não ter que triá-lo novamente. O N1 se sentiu ouvido e ganhou autonomia para atuar de forma mais técnica, resolvendo problemas mais desafiadores. O N2 ganhou tempo para trabalhar em melhorias e na engenharia interna do SOC, além de atuarem como arquitetos em projetos matriciais com outros times.

A conclusão

Não subestime duas coisas. Primeiro, a importância dos processos e da governança como fundação para qualquer tecnologia ou nova organização. Tínhamos um excelente parceiro de SOC, excelentes profissionais, tecnologia de ponta para a época, mas a governança ficou para depois, e a lição foi aprendida. Segundo, mas não menos importante: escutar o time e captar os sinais. No final do dia, o tempo que tiramos debruçados no whiteboard para desenhar o que seria um novo processo, resolveu de maneira simples, um grande problema de governança.