O FortiSOAR costuma ser descrito como uma plataforma de automação, e essa descrição deixa de lado justamente a parte que decide se uma implantação vai dar certo. Ele é um repositório estruturado de dados para o trabalho de segurança, com uma automação que age sobre esses dados. Acerte o modelo de dados e os playbooks se combinam; erre, e cada playbook vira um caso especial.
Modelos de implantação
O nó único (single node) roda tudo num único appliance. Serve para a maioria das implantações, e a disponibilidade dele passa a ser a sua disponibilidade.
A alta disponibilidade (HA) junta os nós em cluster para que a perda de um deles não pare o tratamento de incidentes, o que aqui importa mais do que o normal, porque a plataforma é justamente o que as pessoas usam durante um incidente.
As implantações distribuídas ou multi-tenant (vários ambientes isolados na mesma plataforma) colocam nós de tenant ligados a um master central. É o formato de um provedor de serviços gerenciados, e também o de uma organização com regiões que precisam manter os dados no local e, ainda assim, reportar de forma centralizada. A pergunta que define o desenho é se os dados podem sair do tenant, porque é isso que decide quanto cada nó resolve sozinho.
O modelo de dados
São quatro conceitos, e um se apoia no outro.
Um módulo é um tipo de coisa: alertas, incidentes, indicadores, ativos, tarefas. Os módulos são o que aparece na navegação, e é a eles que os registros pertencem.
Um registro é uma instância: um alerta, um incidente.
Os campos guardam os valores de um registro. Eles têm tipo, e o tipo importa mais do que parece: um campo picklist (lista de seleção) restringe a entrada a valores conhecidos, e é isso que permite usá-lo em condições de playbook e no agrupamento dos dashboards (os painéis). Um campo de texto guardando o que deveria ser uma picklist é o motivo mais comum para um dashboard não conseguir resumir alguma coisa.
Os relacionamentos ligam registros de módulos diferentes. Um incidente se relaciona com os alertas que o originaram, com os ativos envolvidos, com os indicadores observados e com as tarefas atribuídas. É isso que diferencia uma plataforma (orquestração, automação e resposta de segurança) de uma fila de chamados: o relacionamento pode ser consultado, então "mostre todo incidente que envolveu este ativo no último trimestre" é uma pergunta que o sistema sabe responder.
Correlação entre módulos
Os relacionamentos existem para permitir a correlação. Quando chega um alerta com um indicador que já está ligado a um incidente aberto, o sistema pode anexar o alerta a esse incidente em vez de abrir um duplicado.
A consequência prática é a deduplicação. Um (centro de operações de segurança) afogado em alertas muitas vezes é um SOC vendo o mesmo evento reportado cinco vezes por cinco produtos, e a correlação por um indicador em comum junta tudo isso num só incidente, com cinco fontes.
Isso só funciona se os dados forem consistentes. Um indicador guardado como texto num lugar e como registro relacionado em outro não pode ser correlacionado, e é por isso que o modelo de dados merece atenção antes da automação.
Controle de acesso
O controle de acesso do FortiSOAR é baseado em papéis e funciona em dois eixos que vale manter separados:
O que você pode fazer: criar, ler, atualizar e apagar, definido por módulo. Um analista pode atualizar incidentes, mas não apagá-los; um administrador pode as duas coisas.
O que você pode ver: quais registros ficam visíveis, normalmente delimitados por equipe ou por dono. Numa implantação multi-tenant, essa é a fronteira que mantém os tenants separados, e ela é um controle de segurança, não uma conveniência.
O erro de projeto a evitar é dar permissões amplas durante o rollout com a intenção de restringi-las depois. Uma automação escrita em cima de permissões que ninguém restringiu é uma automação que quebra no dia em que alguém restringir.
Templates, dashboards e widgets
Os templates padronizam a aparência de um registro e o que é obrigatório nele, para que incidentes de um mesmo tipo tenham os mesmos campos e ninguém precise lembrar o que preencher.
Os dashboards são montados com widgets, e cada widget mostra uma fatia dos dados. A disciplina que funciona é montar dashboards para responder a uma pergunta, e não para atender a um cargo: "o que está sem responsável há mais de uma hora" leva a uma ação, enquanto "tudo sobre incidentes" é uma tela que as pessoas param de olhar.
Os widgets consultam o mesmo modelo de dados, e isso fecha o ciclo: um campo picklist pode ser agrupado e contado; um campo de texto livre, não.
O que o candidato à prova precisa saber de cor
A implantação pode ser em nó único, em HA ou distribuída e multi-tenant, e, no último caso, a pergunta decisiva é se os dados podem sair do tenant. Módulos guardam registros, registros têm campos com tipo, e relacionamentos ligam registros de módulos diferentes; os relacionamentos podem ser consultados e são eles que permitem a correlação e a deduplicação. O tipo do campo importa, porque picklists podem ser agrupadas em condições de playbook e em dashboards, e texto livre não. O controle de acesso define tanto o que você pode fazer em cada módulo quanto quais registros você pode ver, e esse segundo eixo é a fronteira entre tenants.