Capítulo 32 — Inteligência de ameaças e OSINT: confiabilidade | Engenharia Inteligência de ameaças e OSINT

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 32 publicada. Mapa, exemplo, EX094.

flowchart TD
  N0["32.1 Disponibilidade em série"]
  N1["Laboratório 7 — disponibilidade"]
  N2["32.2 Lendo o laboratório"]
  N3["32.3 Hipótese de independência"]
  N4["32.4 SLOs e orçamentos de erro"]
  N5["32.5 Degradação controlada"]
  N6["Medindo o que os usuários sentem"]
  N7["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX094"]

Desenho lógico

flowchart LR
  N0["32.1 Disponibilidade em série"]
  N1["Laboratório 7 — disponibilidade"]
  N2["32.2 Lendo o laboratório"]
  N3["32.3 Hipótese de independência"]
  N4["32.4 SLOs e orçamentos de erro"]
  N5["32.5 Degradação controlada"]
  N6["Medindo o que os usuários sentem"]
  N7["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX094"]

[32.1 Disponibilidade em série]
    |
    v
[Laboratório 7 — disponibilidade]
    |
    v
[32.2 Lendo o laboratório]
    |
    v
[32.3 Hipótese de independência]
    |
    v
[32.4 SLOs e orçamentos de erro]
    |
    v
[32.5 Degradação controlada]
    |
    v
[Medindo o que os usuários sentem]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX094]

Objetivos de aprendizagem

Você vai (1) calcular a disponibilidade de pipelines em série; (2) quantificar o efeito da redundância; (3) definir objetivos de nível de serviço com orçamentos de erro; (4) decidir onde o investimento em confiabilidade compensa.

32.1 Disponibilidade em série

Uma requisição que precisa passar por todas as etapas só tem sucesso se todas estiverem no ar, então as disponibilidades se multiplicam. Quatro etapas que parecem boas uma a uma podem resultar em algo medíocre. Uma etapa que fica no ar a maior parte do tempo ainda falha de vez em quando, e o pipeline falha sempre que qualquer etapa falha. O laboratório põe números nesse efeito com quatro valores plausíveis. Kofi usa o cálculo cedo no projeto para ver qual etapa limita o todo, antes de gastar dinheiro em etapas que já são confiáveis.

Laboratório 7 — disponibilidade

"""Lab 7 (ch 32): availability of a synthetic CTI pipeline - serial stages and a redundant pair."""
stages = {"taxii-poll": 0.995, "parser": 0.999, "enrich": 0.98, "store": 0.999}
serial = 1.0
for a in stages.values():
    serial *= a
print(f"serial availability={serial:.4f} (~{(1-serial)*8760:.0f} h/yr down)")
enrich_pair = 1 - (1 - stages["enrich"]) ** 2
improved = serial / stages["enrich"] * enrich_pair
print(f"with redundant enrich: {improved:.4f} (~{(1-improved)*8760:.0f} h/yr down)")

Execute com python3 lab_avail.py. Saída verificada:

serial availability=0.9732 (~235 h/yr down)
with redundant enrich: 0.9926 (~65 h/yr down)

32.2 Lendo o laboratório

O pipeline em série chega a 0,9732, cerca de 235 horas de indisponibilidade por ano — dominadas pelo enriquecimento, com 0,98. Duplicar o enriquecimento (duas instâncias independentes, qualquer uma pode atender) eleva o pipeline a 0,9926, cerca de 65 horas por ano. Investir na etapa mais fraca dá o maior ganho. Kofi apresentou o resultado em horas, e não em razões, porque os gestores achavam mais fácil julgar duzentas horas por ano do que quatro casas decimais. O mesmo raciocínio orienta os gastos seguintes: antes de comprar um armazenamento mais confiável, que já está perto da perfeição, a equipe pergunta qual etapa ainda responde pela maior parte das horas perdidas.

32.3 Hipótese de independência

A fórmula da redundância supõe que as falhas são independentes. Dois trabalhadores de enriquecimento no mesmo host, ou chamando o mesmo provedor externo, falham juntos. Redundância real exige hosts diversos e, quando possível, provedores alternativos. Kofi conferiu o primeiro projeto de redundância e descobriu que as duas instâncias de enriquecimento chamavam o mesmo provedor externo. Se esse provedor caísse, as duas falhariam juntas e a melhoria do laboratório desapareceria. O projeto revisado acrescenta um modo de contingência que marca os indicadores como não enriquecidos em vez de esperar, o que tira a dependência comum do caminho crítico. Ele declara a hipótese de independência ao lado de cada número de disponibilidade que relata.

32.4 SLOs e orçamentos de erro

Um SLO como "99,5% das consultas têm sucesso a cada mês" define um orçamento de erro de 0,5%. Quando o orçamento se esgota, o trabalho em funcionalidades pausa e o trabalho de confiabilidade ganha prioridade. A equipe de Kofi acompanha o orçamento toda semana no mesmo painel das outras métricas. Quando uma interrupção de um parceiro consumiu a maior parte do orçamento de um mês, a equipe passou a sprint seguinte acrescentando novas tentativas e alertas em vez da funcionalidade de relatórios planejada. A regra foi acordada de antemão com o líder de CTI, então a pausa não precisou de uma nova discussão a cada vez.

32.5 Degradação controlada

Se o enriquecimento falha, o Lantern ainda deve armazenar e casar os indicadores, marcando-os como "não enriquecidos", em vez de parar a ingestão. Num SOC, serviço degradado é melhor que nenhum serviço. O modo de contingência de Kofi foi testado parando o serviço de enriquecimento durante uma reprodução de tráfego sintético. A ingestão continuou, a correspondência continuou e os indicadores levaram a marcação de não enriquecidos. Quando o enriquecimento voltou, uma tarefa em segundo plano preencheu o contexto ausente. Os analistas relataram que a marcação era útil, porque lhes dizia para buscar o contexto à mão nos casos urgentes durante a interrupção.

Medindo o que os usuários sentem

O tempo no ar de cada processo não é o que os analistas experimentam. Kofi acrescenta uma sonda sintética que injeta um indicador de teste a cada quinze minutos e confere se ele chega à política de DNS. A taxa de sucesso da sonda é a disponibilidade que os usuários de fato sentem, e ela pega falhas entre componentes que as verificações de saúde por processo deixam passar.

Exemplo resolvido

Kofi propõe uma segunda instância de enriquecimento em outro host e um modo de contingência que pula o enriquecimento externo quando o provedor está fora. A disponibilidade mensal medida sobe de 97,4% para 99,2% no trimestre seguinte; são números medidos, por isso diferem um pouco dos 0,9732 e 0,9926 previstos pelo Laboratório 7.

Caso sintético. Os números são ilustrativos.

Erros e limites

Números de disponibilidade escondem falhas parciais, como respostas lentas. Meça também SLOs de latência.

Exercícios

EX094 — Resultado em série. Cite a disponibilidade em série do laboratório e a indisponibilidade anual aproximada.
Mostrar critérios de avaliação
Rubrica: 3 = 0,9732, ~235 h; 2 = um; 1 = errado; 0 = nenhuma.
EX095 — Dependência oculta. Por que dois trabalhadores de enriquecimento podem não ser independentes?
Mostrar critérios de avaliação
Rubrica: 3 = host/provedor/rede compartilhados → falha de modo comum; 2 = vago; 1 = sempre independentes; 0 = nenhuma.
EX096 — Modo degradado. O que o Lantern deve fazer quando o enriquecimento externo está indisponível?
Mostrar critérios de avaliação
Rubrica: 3 = continuar a ingestão/correspondência; marcar como não enriquecido; tentar de novo depois; 2 = continuar; 1 = parar o pipeline; 0 = nenhuma.

Síntese

Multiplique as disponibilidades em série, corrija a etapa mais fraca com redundância de fato independente, administre os orçamentos de erro e degrade de forma controlada.

Continue estudando — capítulo 32 de 50

← Capítulo 31 (rascunho) · Índice de capítulos do curso · Capítulo 33 (rascunho) →