Capítulo 16 — Engenharia de sistemas
Mapa da aula
Aula 16 publicada. Mapa, exemplo, EX046.
flowchart TD
N0["16.1 O SOC como sistema"]
N1["16.2 Interfaces"]
N2["16.3 Desdobramento dos requisitos"]
N3["16.4 Trocas"]
N4["16.5 Ciclo de vida"]
N5["16.6 Verificação"]
N6["16.7 Caso"]
N7["Modos de falha do sistema"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX046"]
Desenho lógico
flowchart LR
N0["16.1 O SOC como sistema"]
N1["16.2 Interfaces"]
N2["16.3 Desdobramento dos requisitos"]
N3["16.4 Trocas"]
N4["16.5 Ciclo de vida"]
N5["16.6 Verificação"]
N6["16.7 Caso"]
N7["Modos de falha do sistema"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]
[16.1 O SOC como sistema]
|
v
[16.2 Interfaces]
|
v
[16.3 Desdobramento dos requisitos]
|
v
[16.4 Trocas]
|
v
[16.5 Ciclo de vida]
|
v
[16.6 Verificação]
|
v
[16.7 Caso]
|
v
[Modos de falha do sistema]
|
v
[Exemplo resolvido] --> [Exercício EX046]
Objetivos de aprendizagem
Você vai (1) ver o SOC como um sistema de pessoas, processos e tecnologia; (2) definir interfaces e requisitos entre componentes; (3) gerenciar trocas com critérios explícitos; (4) planejar o ciclo de vida, da concepção à aposentadoria.
16.1 O SOC como sistema
Um SOC combina pessoas (analistas, engenheiros), processos (triagem, escalonamento) e tecnologia (sensores, SIEM, gestão de casos). Zimmerman (2014) argumentou que muitos SOCs investem demais em ferramentas e de menos em pessoas e processos; o pensamento sistêmico os mantém em equilíbrio. Um novo SIEM comprado sem analistas treinados para usá-lo, ou sem um processo de triagem para receber seus alertas, acrescenta custo, mas pouca proteção. O pensamento sistêmico pergunta como uma mudança numa parte afeta as outras: uma nova detecção acrescenta alertas, o que acrescenta carga aos analistas, o que pode exigir uma mudança de processo. Amara aprende a fazer essa cadeia de perguntas antes de propor qualquer ferramenta.
16.2 Interfaces
Cada componente troca alguma coisa: os sensores enviam eventos ao SIEM, o SIEM envia alertas ao sistema de casos, os analistas enviam escalonamentos aos responsáveis pela resposta a incidentes. Cada interface precisa de formato, prazo e responsável definidos. A maioria das falhas entre equipes acontece em interfaces que ninguém possui. Se o SIEM muda o formato de seus alertas e ninguém avisa o administrador do sistema de casos, os alertas podem chegar com campos faltando, ou nem chegar. Registrar formato, prazo e responsável de cada interface transforma uma suposição num acordo que pode ser conferido e dá a alguém o dever de notar quando ele se rompe.
16.3 Desdobramento dos requisitos
Necessidades de alto nível ("detectar a tomada de conta em até 15 minutos") se desdobram em requisitos de componentes: logs do portal entregues em até 2 minutos, latência da regra abaixo de 5 minutos, reconhecimento pelo analista em até 8 minutos. As partes se somam: dois minutos de entrega, cinco da regra e oito de reconhecimento dão exatamente quinze, o que não deixa folga. Se a entrega dos logs escorregar para quatro minutos, a meta inteira falha, mesmo com a regra e os analistas dentro do prazo. Paolo sugere apertar os orçamentos dos componentes para que o total deixe uma margem, e monitorar cada um separadamente.
16.4 Trocas
Mais dados melhoram a visibilidade, mas custam armazenamento e atenção dos analistas. Os engenheiros de sistemas declaram critérios (tempo de detecção, custo, carga dos analistas) e comparam as opções com eles. Declarar os critérios antes de comparar as opções impede que as pessoas escolham a opção de que já gostavam e depois procurem motivos. Os pesos tornam as prioridades explícitas: se o tempo de detecção é o que mais importa, uma opção mais cara que o reduz à metade pode vencer. Amara monta uma pequena tabela para o acréscimo de sensores de rede nos depósitos, pontuando cada opção nos critérios acordados, com a evidência por trás de cada nota.
16.5 Ciclo de vida
Os componentes são planejados, construídos, operados, mantidos e aposentados. Aposentar um sensor antigo exige um substituto primeiro, ou a cobertura desaparece em silêncio. A aposentadoria é a fase mais negligenciada. Um sensor desligado durante uma renovação de hardware pode deixar uma lacuna que ninguém nota até que um incidente precise de seus dados. Planejar a aposentadoria significa verificar quais regras dependem do componente, confirmar que o substituto produz dados equivalentes e rodar os dois em paralelo por um curto período antes de desligar o antigo. Os responsáveis aprovam cada aposentadoria.
16.6 Verificação
Cada requisito tem um teste: um evento sintético cronometrado verifica se a meta de 15 minutos é cumprida de ponta a ponta. O evento sintético é injetado no portal, como se viesse de uma rajada real de logins, e os carimbos de tempo são registrados em cada etapa: chegada do log, disparo da regra, criação do alerta e reconhecimento pelo analista. Comparar os tempos das etapas com os orçamentos dos componentes mostra exatamente onde ocorre o atraso. O teste roda regularmente, e não uma única vez, porque o desempenho deriva à medida que os volumes e a equipe mudam. Metas não cumpridas abrem um chamado.
16.7 Caso
Amara desenha o SOC da Lindqvist como um diagrama de blocos e rotula cada interface com formato, latência e responsável. Desenhar o diagrama revela duas interfaces sem responsável nomeado: a alimentação vinda do balanceador de carga e o elo entre o sistema de casos e o serviço de acionamento do plantão. Ele também mostra que os logs do portal passam por um coletor intermediário que ninguém havia listado. Cada lacuna vira uma tarefa, e o diagrama é guardado com os documentos de arquitetura do SOC. Paolo o revisa com ela.
Modos de falha do sistema
As falhas no nível do sistema muitas vezes ficam nas interfaces: uma mudança de formato a montante quebra em silêncio a análise a jusante. Amara acrescenta um alerta de erro de análise em cada interface.
Exemplo resolvido
O teste cronometrado dela injeta uma rajada sintética e inofensiva de logins no portal às 14:00:00. O SIEM a recebe às 14:01:40, a regra dispara às 14:05:10 e um analista reconhece às 14:11:30 — 11,5 minutos de ponta a ponta, dentro do requisito de 15 minutos. A etapa mais lenta é o reconhecimento pelo analista.
Caso sintético. O projeto do SOC e o teste são inventados.
Erros e limites
Testes de ponta a ponta em horários tranquilos podem subestimar os atrasos em períodos movimentados; repita-os sob carga.
Exercícios
- EX046 — Equilíbrio. Contra que desequilíbrio Zimmerman (2014) alertou? Rubrica: 3 = investir demais em ferramentas vs pessoas e processos; 2 = parcial; 1 = vago; 0 = nada.
- EX047 — Desdobramento do requisito. Desdobre "detectar em até 15 minutos" em requisitos de componentes. Rubrica: 3 = entrega dos logs, latência da regra, reconhecimento, com os tempos; 2 = dois; 1 = um; 0 = nada.
- EX048 — Teste cronometrado. O que o teste de ponta a ponta mostrou? Rubrica: 3 = 11,5 min no total; dentro da meta; reconhecimento mais lento; 2 = parcial; 1 = errado; 0 = nada.
Síntese
A engenharia de sistemas liga as pessoas, os processos e a tecnologia do SOC por meio de interfaces, requisitos e testes definidos.
Continue estudando — capítulo 16 de 50
← Capítulo 15 (rascunho) · Índice de capítulos do curso · Capítulo 17 (rascunho) →