Capítulo 1 — Governança, riscos e compliance de segurança: fundamentos e decisões

Capítulo 1 — Governança, riscos e compliance de segurança: fundamentos e decisões

Mapa da aula

Aula 01 publicada. Mapa, exemplo, EX001.

flowchart TD
  N0["1.1 O problema de decisão"]
  N1["1.2 Comece por um serviço, não por um produto"]
  N2["1.3 Traduza uma ameaça em um cenário de negócio"]
  N3["1.4 Escolha resultados que possam ser verificados"]
  N4["1.5 Defina prioridades sob um limite real"]
  N5["1.6 Um exemplo curto de trabalho"]
  N6["1.7 O teste da estratégia em uma página"]
  N7["EX001 — Atividade ou resultado"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX001"]

Desenho lógico

flowchart LR
  N0["1.1 O problema de decisão"]
  N1["1.2 Comece por um serviço, não por um produto"]
  N2["1.3 Traduza uma ameaça em um cenário de negócio"]
  N3["1.4 Escolha resultados que possam ser verificados"]
  N4["1.5 Defina prioridades sob um limite real"]
  N5["1.6 Um exemplo curto de trabalho"]
  N6["1.7 O teste da estratégia em uma página"]
  N7["EX001 — Atividade ou resultado"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX001"]

[1.1 O problema de decisão]
    |
    v
[1.2 Comece por um serviço, não por um produto]
    |
    v
[1.3 Traduza uma ameaça em um cenário de negócio]
    |
    v
[1.4 Escolha resultados que possam ser verificados]
    |
    v
[1.5 Defina prioridades sob um limite real]
    |
    v
[1.6 Um exemplo curto de trabalho]
    |
    v
[1.7 O teste da estratégia em uma página]
    |
    v
[EX001 — Atividade ou resultado]
    |
    v
[Exemplo resolvido] --> [Exercício EX001]

Objetivos de aprendizagem

Ao final deste capítulo, o leitor deve ser capaz de distinguir um objetivo de negócio de uma atividade de segurança, explicar como um cenário de risco afeta um serviço, identificar quem deve ser dono de uma decisão, escrever um resultado de segurança mensurável e testar se uma ação proposta pertence a uma estratégia.

1.1 O problema de decisão

Uma estratégia de segurança é um conjunto de escolhas sobre o que a organização vai proteger, por que isso importa, que nível de interrupção ou perda ela consegue tolerar, quem pode decidir e como o progresso será verificado. Ela tem um horizonte de tempo e um limite de recursos. Uma lista de controles, ferramentas ou normas é uma evidência útil para uma estratégia, mas a lista sozinha não explica qual resultado importa primeiro.

Considere duas propostas: “Comprar uma nova plataforma de segurança” e “Restaurar o serviço de agendamento de clientes em até quatro horas após um evento destrutivo”. A primeira é uma atividade possível. A segunda é um resultado de serviço. Para cumprir o resultado, a organização pode acabar precisando de uma plataforma, de backups, de runbooks, de treinamento ou de uma arquitetura diferente. O resultado oferece um motivo para comparar essas opções. Ele também cria um teste: um exercício cronometrado de restauração pode mostrar se a promessa é crível.

O NIST Cybersecurity Framework 2.0 oferece uma linguagem útil para esse trabalho. Suas seis funções são Govern, Identify, Protect, Detect, Respond e Recover. Uma estratégia usa as seis, mas é em Govern que a organização define expectativas, responsabilidades e a direção de risco. Os recursos de início rápido para pequenas empresas do NIST ilustram que uma organização modesta pode começar pelo próprio contexto e pelas próprias prioridades, em vez de copiar um programa grande de outra empresa.

1.2 Comece por um serviço, não por um produto

O trabalho de segurança tem valor porque protege um serviço, um dever, uma pessoa ou um ativo que importa para a missão. Comece nomeando os serviços em linguagem simples. Um processador de pagamentos pode depender de autorização de cartões, liquidação, acesso de lojistas e suporte. Uma clínica pode depender de agendamento de consultas, acesso a prontuários e resultados de laboratório. A mesma tecnologia pode sustentar vários serviços, e um único serviço pode atravessar vários fornecedores e sistemas.

Para cada serviço, registre cinco fatos: o dono, as pessoas afetadas, os sistemas e dados de suporte, a interrupção máxima tolerável e as consequências da falha. O dono é a pessoa responsável por escolher os tradeoffs aceitáveis; a equipe de segurança fornece evidências e opções. Um dono crível consegue dizer se uma indisponibilidade de quatro horas importa mais do que um lançamento atrasado e pode aprovar um exercício de recuperação que ocupe temporariamente o tempo da equipe.

Não tente tornar o primeiro inventário perfeito. Uma primeira passada que nomeie os serviços mais importantes e as dependências desconhecidas é mais útil do que uma planilha abrangente cujas linhas não têm dono. Registre a incerteza como incerteza. Se o tempo de recuperação for um palpite, marque-o como uma premissa a validar com o dono do serviço.

1.3 Traduza uma ameaça em um cenário de negócio

“Ransomware” é um rótulo de ameaça. “O serviço de agendamento fica indisponível por dois dias porque os administradores não conseguem restaurar seu banco de dados” é um cenário de risco. O cenário pode ser testado contra evidências: idade do backup, tempo de restauração, separação das contas de administrador e existência de um processo manual de agendamento. Ele também tem uma consequência de negócio: atraso no serviço, sobrecarga da equipe ou impacto contratual.

Um cenário compacto tem quatro partes:

1. Condição: o evento ou a fraqueza que pode ocorrer.
2. Serviço: o processo de negócio que seria afetado.
3. Consequência: o tipo de dano que se seguiria.
4. Lacuna de evidência: o que ainda não se sabe bem o bastante para decidir.

Por exemplo: “Se uma conta de administrador comprometida puder apagar tanto o banco de dados de agendamento em produção quanto seus backups, os agendamentos podem parar além da meta de quatro horas; a equipe não executou um teste completo de restauração neste trimestre.” A afirmação não diz que houve comprometimento. Ela liga uma condição plausível a um resultado de serviço mensurável e a uma lacuna testável.

Incidentes reais mostram por que essas distinções importam. Em seu relatório público sobre o evento de ransomware da Colonial Pipeline em 2021, o U.S. Government Accountability Office afirma que o ransomware foi implantado contra os sistemas de negócio da operadora e discute a resposta posterior em segurança de dutos. A lição estratégica aqui é uma inferência: dependências de sistemas de negócio podem afetar decisões operacionais, por isso o mapeamento de serviços e o planejamento de continuidade não devem parar no sistema técnico mais visível. Este livro não infere dessa fonte a causa raiz detalhada do incidente.

1.4 Escolha resultados que possam ser verificados

Um resultado de segurança descreve um estado que a organização quer alcançar. Ele deve ter um dono, uma data, uma fronteira e evidências. “Melhorar o monitoramento” não tem fronteira nem teste de sucesso. “Até o fim do trimestre, todo provedor de identidade de produção e toda aplicação exposta externamente enviam eventos de segurança ao repositório de logs monitorado, e um relatório semanal de cobertura identifica as fontes ausentes” pode ser verificado.

Um resultado não precisa garantir que nenhum incidente ocorrerá. Equipes de segurança não podem prometer zero ataques ou zero perdas. Elas podem estabelecer expectativas claras sobre capacidade: detectar uma classe de evento dentro de um tempo definido, restaurar um serviço dentro de uma janela testada, revisar acessos privilegiados em uma cadência definida ou resolver exposições críticas segundo uma regra de risco acordada. A medição deve usar evidências coletadas no trabalho cotidiano, e não números inventados para uma apresentação.

Medidas úteis combinam cobertura, qualidade e efeito. Cobertura pergunta se a população-alvo está incluída. Qualidade pergunta se um controle funciona sob teste. Efeito pergunta se o resultado do serviço melhorou. Para backups, essas medidas podem ser: percentual de serviços críticos com cópias protegidas; percentual de restaurações amostradas que dão certo; e tempo medido para restaurar um serviço. Um número alto de cobertura de backup não substitui um teste de restauração.

1.5 Defina prioridades sob um limite real

A maioria das equipes não consegue fazer tudo ao mesmo tempo. Por isso uma estratégia precisa de uma regra explícita de priorização. Comece pela criticidade e pela exposição do serviço e depois considere as evidências que sustentam o cenário, o tempo necessário para reduzir o risco, as dependências e o custo. Use rótulos consistentes como “agir neste mês”, “planejar neste trimestre” e “aceitar por ora, com um dono e uma data de revisão”. Evite a falsa precisão: uma nota 8,7 não é útil se ninguém consegue explicar como ela foi calculada ou que decisão muda em 8,7.

Uma ação pode ser valiosa mesmo quando é pequena. Testar se os backups podem ser restaurados pode custar menos do que comprar uma ferramenta nova e revelar a lacuna de maior consequência. Inversamente, um dashboard de segurança vistoso pode ser um mau investimento inicial se ninguém for dono dos alertas por trás dele. Priorizar é decidir sobre a redução esperada de danos relevantes, não uma competição para implantar o maior número de controles.

A estratégia deve nomear o que fica adiado e por quê. Um adiamento aprovado não é evidência de que o risco desapareceu. Ele registra o tradeoff, o dono, as medidas compensatórias e a data em que a decisão será revista. O NIST Privacy Framework, separado, pode ajudar quando o cenário envolve danos decorrentes do tratamento de dados pessoais; o risco de privacidade é mais amplo do que a prevenção de vazamentos.

1.6 Um exemplo curto de trabalho

A fictícia Northstar Community Services opera um portal público de agendamento, um serviço interno de gestão de casos e uma escala de voluntários. Sua equipe executiva tem um engenheiro de segurança e orçamento limitado para os próximos três meses. A organização não tem um inventário confirmado de integrações com terceiros. Seu resultado de serviço mais importante é que os agendamentos possam continuar durante uma indisponibilidade de sistema, mesmo que o portal fique temporariamente fora do ar.

Uma primeira conversa sobre estratégia pode produzir o seguinte registro:

Isto é deliberadamente incompleto. A meta de quatro horas é uma premissa de trabalho até que o diretor de operações a valide. O mapa de dependências pode mudar a prioridade. O exercício pode revelar que o processo manual é mais importante do que a restauração técnica. Uma estratégia pode mudar quando as evidências melhoram; a mudança deve ser registrada para que as pessoas entendam por que a decisão mudou.

1.7 O teste da estratégia em uma página

Antes de comprar ou construir qualquer coisa, tente escrever seis frases:

1. Precisamos manter este serviço disponível ou recuperável para estas pessoas.
2. O dono do serviço aceita este limite de impacto.
3. Nossos principais cenários sustentados por evidências são estes.
4. Neste trimestre entregaremos estes resultados mensuráveis.
5. Estes donos tomarão as decisões de tradeoff e executarão o trabalho.
6. Revisaremos estes sinais nesta cadência e revisaremos o plano quando as evidências mudarem.

Se alguma frase for impossível de completar, o fato que falta é a próxima tarefa de pesquisa. O objetivo do teste de uma página não é esconder a complexidade. Ele obriga a equipe a mostrar a relação entre missão, risco, ação e evidência antes de se expandir em um plano longo.

Exercícios do capítulo 1

Estes cinco exercícios são os primeiros do mínimo exigido de cinquenta. Suas resoluções aparecem no fim deste rascunho. Use apenas o caso fictício da Northstar Community Services apresentado acima.

EX001 — Atividade ou resultado

Classifique cada afirmação como atividade ou como resultado de serviço mensurável e depois reescreva uma atividade como resultado: (a) comprar uma ferramenta de segurança de endpoint; (b) restaurar o agendamento de consultas a partir do backup em até quatro horas em um exercício cronometrado; (c) escrever uma política sobre phishing; (d) enviar um alerta a um revisor designado em até quinze minutos após uma mudança em conta privilegiada.

EX002 — Construção de cenário

Escreva um cenário de risco em quatro partes para a escala de voluntários, usando condição, serviço, consequência e lacuna de evidência. Declare uma premissa que precise de confirmação. Não afirme que tenha ocorrido qualquer violação.

EX003 — Seleção de evidências

A Northstar informa que “todos os serviços críticos têm backups”. Cite três evidências que testariam se isso sustenta seu objetivo de continuidade dos agendamentos. Explique por que uma captura de tela da configuração, sozinha, é insuficiente.

EX004 — Decisão de prioridade

A equipe tem uma semana. Ela pode (a) comprar um dashboard sem dono designado para os alertas ou (b) executar um exercício cronometrado de restauração com o diretor de operações. Escolha a primeira ação e dê dois motivos. Indique uma condição sob a qual a outra ação poderia se tornar adequada mais tarde.

EX005 — Estratégia em uma página

Complete o teste da estratégia em seis frases para a Northstar. Marque pelo menos duas afirmações como premissas ou como pendentes de aprovação do dono. Inclua um resultado com dono, data e evidência.

Conceitos — três perguntas que uma nota não responde

Cobertura, qualidade e efeito são ofícios diferentes. Cobertura conta se uma população está dentro do conjunto administrado. Qualidade pergunta se um controle sobreviveu a um teste deliberado. Efeito pergunta se o resultado do serviço se moveu para as pessoas que dependem dele. Um único decimal não assume os três ofícios, e não cabe em Govern, porque Govern nomeia expectativas, responsabilidades e uma direção para o risco.

Dados — onde as seis frases param

Fluxo de decisão — recuse a nota e depois teste a frase em branco

flowchart TD
  A["Uma figura de fornecedor ou uma oferta de plataforma"] --> B{"Alguém nomeia a escolha que muda nessa figura?"}
  B -->|Não| C["Recuse a figura como falsa precisão"]
  B -->|Sim| D{"A frase 2 está completa?"}
  C --> D
  D -->|Não| E["A frase em branco é a próxima tarefa de pesquisa"]
  E --> F["Não trate a compra como a escolha de estratégia"]
  D -->|Sim| G{"Que ofício a ação cumpre?"}
  G -->|População contada| H["Cobertura"]
  G -->|Controle sobreviveu a um teste| I["Qualidade"]
  G -->|Resultado do serviço mudou| J["Efeito"]
  I --> K["Uma restauração cronometrada pode falar de qualidade e, com o relógio guardado, de efeito"]
  H --> L["Cobertura não responde ao resultado de quatro horas"]

Exemplo resolvido — o cartaz de terça da Calder

O cartaz de terça-feira da Calder Systems mostra um escudo verde e uma figura de prontidão igual a 9,1. A engenheira deixa essa figura fora da tabela de decisão, porque nenhum colega aponta uma escolha que seria outra se a figura impressa andasse um décimo. Ela rascunha as seis frases na mesma folha. A frase 1 consegue nomear o agendamento de consultas para clientes e para a equipe da recepção, ainda que o portal possa ficar fora. A frase 2 para em branco: falta a aceitação do diretor de operações, então a linha inacabada é a tarefa de pesquisa, e uma encomenda de catálogo da plataforma Calder é recusada. A restauração cronometrada continua sendo o primeiro resultado verificável. Ela só fala de um teste e do relógio do serviço depois que alguém a executa. Integrações com firmas externas seguem sem contagem, e isso é uma lacuna separada.

Caso sintético. Essa marca de fornecedora é uma ilustração de sala de aula, não uma medição que a Northstar tenha coletado no próprio portal.

Aplicar

• EX051 — Um decimal num cartaz. A Calder Systems apresenta uma nota de prontidão de 9,1. Por que a regra de falsa precisão a recusa, e de quais dois tipos de medida uma restauração cronometrada pode falar? Rubrica: 3 = ninguém diz que decisão muda em 9,1; a restauração cronometrada pode mostrar qualidade e, se o relógio for guardado, efeito; cobertura é outra pergunta;; 2 = recusa a nota;; 1 = aceita 9,1;; 0 = nenhuma.
• EX052 — A segunda frase em branco. A frase 2 do teste de uma página não pode ser completada. Que fato falta, e a equipe pode tratar a compra de uma plataforma como a escolha de estratégia? Rubrica: 3 = o diretor de operações não aceitou o limite de quatro horas; o fato que falta é a próxima tarefa de pesquisa; uma frase em branco impede a compra;; 2 = o limite não foi aceito;; 1 = comprar a plataforma;; 0 = nenhuma.

Fontes deste capítulo

• NIST Cybersecurity Framework 2.0 — funções do framework e finalidade de gestão de riscos.
• NIST CSF 2.0 Small Business Quick Start — como iniciar um programa modesto no contexto da organização.
• NIST Privacy Framework — risco de privacidade além dos eventos de segurança.
• U.S. GAO, Critical Infrastructure Protection: TSA Is Taking Steps to Address Some Pipeline Security Program Weaknesses — fatos públicos sobre o incidente da Colonial Pipeline em 2021.

Caso sintético. Todos os detalhes do caso da Northstar Community Services são fictícios. A lição estratégica extraída do relatório do GAO está explicitamente identificada como inferência.

Continue estudando — aula 01 (capítulo 01 de 04)

← Início do curso · Índice das aulas · Capítulo 02 →

Continue para a próxima aula já escrita.