Prontidão de evidência e a primeira pergunta do caso

Semana 1, dia 1. Percorra o ensino e o marco resolvido antes de tentar o exercício indicado. Compare o seu artefato com a resolução final só depois.

1.1 A resposta faz parte da gestão de risco

Uma equipe de resposta a incidentes faz mais do que reagir a um alarme. Ela prepara contatos e autoridade, reconhece atividade potencialmente danosa, preserva fatos, toma decisões proporcionais, restaura serviços e aprende com o resultado. O NIST SP 800-61 Rev. 3 distribui recomendações de resposta a incidentes ao longo da gestão de risco de cibersegurança descrita pelo NIST Cybersecurity Framework 2.0. As funções Govern, Identify, Protect, Detect, Respond e Recover do framework — governar, identificar, proteger, detectar, responder e recuperar — são atividades concorrentes e contínuas. Uma equipe não deve esperar por “responder” para pensar em donos, cópias de segurança, comunicações ou evidência.

Há uma distinção importante entre uma função usada para preparar a resposta e uma ação tomada durante um caso particular. O modelo do NIST SP 800-61 Rev. 3, seção 2.1 coloca Govern, Identify e Protect na preparação ampla e na gestão de risco; Detect, Respond e Recover descrevem as atividades de resposta voltadas ao caso. A categoria de melhoria liga as lições de volta a todas elas. Isto é um modelo para organizar resultados, não uma exigência de que todo caso atravesse seis passos isolados. Na Harbor Library, nomear um responsável autorizado pelo serviço pertence à prontidão; conferir a edição de reserva de hoje pertence à investigação; decidir se uma conta deve ser restringida pertence à resposta. Um tíquete de melhoria depois do exercício pode alterar a lista de contato do responsável antes do próximo caso.

Quem começa pode testar a prontidão com quatro perguntas: Qual serviço pode ser prejudicado? Quais registros poderiam mostrar o que aconteceu? Quem pode aprovar uma ação disruptiva? Que resultado mostraria que o serviço normal pode ser retomado com segurança? Uma equipe que não consegue respondê-las tem trabalho a fazer mesmo que o sistema de alerta seja excelente. Por outro lado, respondê-las não estabelece que um alerta particular seja malicioso. A distinção impede que um inventário de controles seja confundido com um achado de incidente.

Considere uma biblioteca pequena que oferece reserva de salas pela internet. Um alerta pode dizer que uma conta de administrador entrou numa hora incomum. Isso é um sinal que vale examinar. Por si, não prova comprometimento da conta. Uma mudança na base de reservas pode ser um evento com efeito de negócio. A equipe precisa avaliar contexto, evidência e impacto antes de rotular a situação como incidente confirmado. Estas são definições de trabalho para este caso de ensino; uma organização deve usar a própria política aprovada de classificação.

A primeira pergunta útil é: Qual serviço e quais pessoas podem ser prejudicados, e o que se sabe agora? Uma equipe que registra a incerteza pode agir depressa sem fingir que conhece a causa-raiz. Uma equipe que rotula todo alerta como “violação” arrisca interrupção desnecessária; uma equipe que descarta todo alerta arrisca contenção tardia.

1.2 Um mapa fictício de serviço

O curso usa a Harbor Library, uma organização fictícia. Não há registros pessoais nem rede real. Moradores reservam salas de estudo por um site. A equipe da recepção pode editar reservas. Uma lista separada de boletim de eventos contém endereços de contato. O serviço de reserva depende de uma aplicação web, de um serviço de identidade, de uma base de dados, de uma cópia noturna e de uma central de atendimento da equipe.

Tabela da aula; deslize para ver todas as colunas →

Este mapa é incompleto de propósito. Não diz se a aplicação usa hospedagem de terceiros, como os relógios são sincronizados, nem quem pode aprovar uma interrupção de serviço. Uma equipe de resposta deve registrar isso como lacunas de prontidão antes de uma crise. Se uma dependência falhar, a equipe pode então pedir evidência e opções ao dono correto.

Do mapa de dependências ao contrato de prontidão de evidência

Um mapa de serviço nomeia componentes e donos; não mostra que um investigador conseguiria responder a uma pergunta específica a tempo. Um passo útil seguinte é um contrato de prontidão de evidência: um acordo curto e testável sobre qual fonte registraria um evento, o que os campos significam, quem pode recuperá-lo, por quanto tempo um registro útil pode permanecer disponível e como um segundo analista poderia reproduzir a seleção. Isto é um dispositivo de ensino da OpenCyber Academy, não um formulário exigido pelo NIST SP 800-61 Rev. 3. A orientação de resposta a incidentes do NIST coloca preparação, conhecimento do serviço e papéis de resposta dentro da gestão de risco mais ampla; o contrato abaixo transforma essa orientação geral num exercício pequeno de biblioteca fictícia.

Comece por uma pergunta de decisão, não pelo nome de um produto. Os registros de prática introduzidos na seção 1.7 incluirão uma reserva cancelada B18 e a conta desk-a; trate-os aqui como prévia. “Temos logs?” é amplo demais. “O cancelamento de B18 foi uma ação aprovada da equipe, e o estado atual da reserva o refletiu?” separa uma pergunta de atividade de uma pergunta de estado de negócio. Uma auditoria de reserva poderia registrar uma edição, mas uma comparação de estado autoritativo seria necessária para confirmar o que os usuários podem reservar agora. Do mesmo modo, um serviço de identidade poderia relatar que a conta desk-a entrou, enquanto nem o rótulo da conta nem um carimbo de tempo identificam a pessoa no teclado. O plano de evidência deve dizer o que uma fonte consegue discriminar e qual conclusão tentadora ela não pode carregar.

Para cada pergunta, escreva seis campos antes do incidente: (1) o produtor e o evento que ele deveria emitir; (2) identificadores que possam ligar registros sem fundir em silêncio pessoas ou ações diferentes; (3) hora do evento, hora da coleta e premissas de relógio ou fuso; (4) o custodiante, o caminho aprovado de coleta e o limite de acesso; (5) retenção esperada e indicadores de falha; e (6) um ensaio pequeno e autorizado que possa mostrar se a fonte de fato funciona. Campos em branco ou não testados permanecem desconhecidos. Um diagrama que mostra uma seta de log sem esses detalhes é uma hipótese de arquitetura, não prova de cobertura.

O que segue é um cartão de desenho D1 proposto, escrito para uma versão isolada de treinamento da Harbor Library. É um plano do que os donos testariam, não um registro novo da série R, nem uma descrição da configuração real de log da biblioteca, nem evidência disponível no marco das 09:05. Nomes de campo como request_id e session_id são campos candidatos de desenho; a existência e a semântica deles precisam ser conferidas antes de uma correlação real.

Tabela da aula; deslize para ver todas as colunas →

O cartão de quatro linhas é um resumo, não um contrato de seis campos concluído. Para a primeira linha, um registro de teste proposto plenamente especificado leria como segue. Os nomes de campo, os horários e as observações esperadas são inventados para um ensaio isolado futuro; nenhum é alegado como existente em R1–R8.

Tabela da aula; deslize para ver todas as colunas →

O cartão de decisão de quatro linhas é, de propósito, de dois lados. Nomeia uma fonte e, em seguida, nomeia o que ainda seria desconhecido depois de vê-la. Isso impede o salto familiar de “o log existe” para “a pergunta foi respondida”. A primeira linha também distingue um registro de atividade de um registro do estado do mundo. Se uma auditoria da aplicação diz que B18 foi cancelada, mas a cópia restrita do estado atual falta, o analista pode relatar o cancelamento registrado e pedir a comparação de estado. O analista não pode certificar a agenda ao vivo só pela auditoria. A segunda linha antecipa o exercício de correlação do módulo 2 da edição inglesa, que não está neste manuscrito: mesmo uma correspondência exata de chave de sessão, se fosse fornecida, estreitaria uma relação entre registros, não a identidade nem a autorização de uma pessoa.

Trace onde uma observação pode se perder. Um resultado de busca ausente tem várias causas diferentes. O produtor pode nunca emitir o evento; um evento emitido pode falhar na coleta; um registro coletado pode chegar depois da consulta; um registro disponível pode já ter expirado; controles de acesso podem negar a visão selecionada; a consulta pode usar o identificador de reserva, o fuso ou a janela de tempo errados; ou um revisor pode ler mal uma linha real. A resposta a essas falhas difere. Repetir a mesma consulta não repara a não emissão, e pedir uma exportação ampla não substitui corrigir um filtro errado. Uma revisão de prontidão registra, portanto, o último ponto confirmado no caminho do produtor até quem estuda, e um dono nomeado para a próxima verificação. Não reduza todo resultado vazio a “o sistema não teve atividade”.

Torne um ensaio falseável. Numa cópia isolada de treinamento, explicitamente aprovada, um dono poderia pré-declarar uma mudança sintética de reserva e um evento de controle deliberadamente fora do intervalo. O custodiante da aplicação registraria o identificador do pedido de teste e a hora UTC do evento; o coletor registraria a hora de recebimento e a fonte; o analista executaria uma consulta limitada e guardaria o filtro exato e a hora de execução. O resultado esperado é a mudança dentro do intervalo e os campos combinados, com o controle fora do intervalo excluído pelo intervalo declarado. Se a linha esperada falta, a equipe investiga emissão, transporte, retenção, acesso e escopo da consulta, nessa ordem. Se a linha fora do intervalo aparece, o filtro ou a interpretação do tempo precisa de correção. Passar neste ensaio pequeno mostra apenas que o caminho e o intervalo testados se comportaram como declarado. Não prova que todos os eventos futuros serão coletados, nem que o evento prova por que uma pessoa agiu.

A evidência do ensaio deve incluir os casos negativos e de falha, não só uma captura de painel bem-sucedida. Uma cópia de um resultado de busca sem fonte, filtros e limite de coleta pode ser impossível de reproduzir. O carimbo da fonte e a hora em que o analista descobriu o registro devem ocupar campos separados; caso contrário, um registro atrasado pode parecer ter ocorrido mais tarde do que ocorreu. O plano também deve dizer como um erro de fonte é notado: por exemplo, um evento de teste esperado ausente, um recebimento de coleta atrasado, uma mudança de esquema ou uma janela de retenção expirada. O módulo 2 da edição inglesa, ausente deste arquivo, exercita essas distinções com registros sintéticos. Elas pertencem à prontidão porque quem responde não pode reconstruir um registro que nunca foi retido.

Escopo e privacidade seguem a pergunta. A pergunta sobre reservas não autoriza abrir a lista separada do boletim. O cartão D1 nomeia os campos mínimos de reserva e de sessão a pedir, os custodiantes que poderiam fornecê-los e a aprovação a buscar. Se uma observação posterior e sustentada levantar uma preocupação de exposição de dados, o líder do incidente e o contato de privacidade podem definir um propósito e um limite novos. Coletar um histórico inteiro de identidade ou a base de frequentadores só porque isso é tecnicamente acessível ampliaria o caso e o número de pessoas expostas a esses registros. Um bom plano de evidência torna a menor seleção útil reproduzível e registra o que ela excluiu. As regras exatas de retenção, acesso e privacidade de uma organização real devem vir da própria política e das obrigações aplicáveis; este cartão fictício não as fornece.

Depois de ler o conjunto de dados na seção 1.7, aplique o contrato ao instantâneo real do módulo 1 sem importar D1 como evidência. R1 relata uma entrada de desk-a, mas não há dispositivo, semântica de chave de sessão nem pessoa. R3 e R4 registram edições de reserva, mas a tabela fornecida não contém um alvo aprovado pelo responsável nem uma comparação fresca de estado autoritativo. R5 registra o relato de um frequentador, não uma contagem de todos os usuários afetados. R6 agenda treinamento, mas não lista as tarefas de reserva aprovadas. R7 relata um trabalho de cópia concluído, não uma restauração isolada. R8 carece explicitamente de detalhe de destino, portanto não pode estabelecer ausência de transferência de dados. Às 09:05 o analista pode abrir um caso limitado, preservar os ponteiros fornecidos e pedir aos donos nomeados os discriminadores que faltam. O analista não pode alegar que os campos de log ou os ensaios propostos em D1 já estavam implementados.

Um contrato de prontidão de evidência só é útil se alguém for dono da sua manutenção. Uma mudança de serviço pode renomear um campo de reserva, dividir um caminho de escrita, mover um produtor de log ou encurtar a retenção. O dono então repetiria o teste autorizado e atualizaria a fonte, o significado e a rota de coleta do contrato. O documento deve mostrar o último escopo testado e o próximo gatilho de revisão; um estado antigo “verde” sem esses detalhes é mais fraco do que um desconhecido atual e explícito. Isto liga o mapa de serviço do módulo 1 ao tratamento de evidência do módulo 2, às verificações de controle e recuperação do módulo 3 e às melhorias pós-ação do módulo 4, todos da edição inglesa e fora deste manuscrito. Continua a ser um artefato de preparação, não um substituto da evidência do caso nem de uma investigação concluída.

Testar se a prontidão é utilizável

Uma equipe de resposta pode possuir uma política, uma lista de contatos, software de monitoramento e cópias noturnas e ainda assim ser incapaz de tomar uma decisão segura sob pressão. A existência de um componente diz pouco sobre se a equipe consegue usá-lo corretamente quando um serviço particular está ameaçado.

Uma alegação prática de prontidão deve ter cinco partes: capacidade, dono, permissão, teste e resposta à falha. Por exemplo, “temos logs de reserva” é uma frase de inventário. Uma frase verificável de prontidão é: “o custodiante da aplicação pode, com a aprovação do líder do incidente, recuperar mudanças de reserva para um identificador e um intervalo de tempo especificados; outro revisor pode conferir a fonte, os filtros e a saída; se a linha de teste esperada estiver ausente, o custodiante investiga coleta e retenção em vez de alegar que não houve atividade.”

Esta distinção importa porque um sucesso técnico aparente pode esconder resultados de negócio fracassados. Um indicador verde de saúde da web pode representar uma página inicial que responde enquanto uma escrita de reserva falha. Um estado bem-sucedido de trabalho de cópia não demonstra que uma base restaurada contém a agenda correta. Um registro de entrada estabelece que o sistema produtor relatou um evento de conta; não estabelece uma identidade humana.

O NIST Cybersecurity Framework 2.0 descreve resultados de cibersegurança em Govern, Identify, Protect, Detect, Respond e Recover. O NIST SP 800-61 Revision 3 integra recomendações de resposta a incidentes com a gestão de risco organizacional. Nenhuma das fontes autentica as observações fictícias da Harbor Library nem especifica os cartões deste exercício. A implicação de ensino é examinar se os resultados desejados pela organização podem de fato ser demonstrados.

Considere os resultados contrastantes de ensaio a seguir:

Tabela da aula; deslize para ver todas as colunas →

Os testes de prontidão devem expor as próprias limitações. Passar num ensaio de recuperação valida o caminho e o intervalo testados, não todo coletor, conta ou dia futuro. Uma aprovação assinada para uma mudança simulada não estabelece autoridade para fazer qualquer outra mudança.

Unidade de revisão da semana 1, número 1 — Conferir o contrato de entrada antes de interpretar o resultado

Objetivo e distinção

Estas cinco unidades suplementares de revisão estendem as aulas 01–05 já existentes; não criam aulas diárias novas nem substituem EX001–EX050. Todos os casos e programas usam peças fictícias ou em memória. Para cada extensão executável, rode primeiro o laboratório nomeado completo numa sessão nova de Python. Para AR1, rode também a listagem de aprovação presa ao pedido antes do portão de tipo. Não se conecte a sistemas de produção nem trate resultados de peça como autorização.

Depois desta unidade, explique por que um cálculo correto de um programa pode ainda ser irrelevante para a pergunta de incidente pretendida. Identifique três coisas separadas: a versão de fonte selecionada, o quadro de entrada declarado e a proposição exata em teste.

A aula 01 já ensina um contrato de prontidão de evidência: nomear uma pergunta útil, uma fonte, um custodiante, condições de coleta e um ensaio. O passo adicional aqui é testar a fronteira entre esse contrato e a entrada de fato entregue a um verificador. Uma tabela pode ser internamente bem formada e ainda pertencer a outra versão ou omitir um objeto exigido pela decisão.

Um ponteiro de fonte identifica onde o leitor deve olhar. Por si, não estabelece a verdade, a completude nem a aplicabilidade do que se encontra. Um quadro de entrada declarado afirma quais objetos a comparação atual deve cobrir. Não é evidência de que o quadro inclui todo objeto relevante de produção. Uma proposição de teste afirma a condição estreita que o programa pode avaliar depois que essas entradas são aceitas.

Por exemplo, o programa original BSL1 pode inspecionar intervalos de reserva fornecidos. Não pode determinar sozinho se um exportador omitiu uma reserva, se a política foi aprovada para o serviço relevante, ou se as linhas descrevem o incidente atual. Essas perguntas não se tornam verdadeiras porque a função de sobreposição executa corretamente.

Uma revisão em três estágios

Aceitar o contrato de entrada declarado?
    não -> rejeitar ou pedir esclarecimento; sem aprovação de negócio
    sim
     |
     v
Avaliar o modelo declarado sobre essas entradas
     |
     v
Relatar o resultado dentro desse escopo
    + nomear o que a fonte e o modelo não podem estabelecer

Explicação do texto: o primeiro estágio confere se a entrada pode ser usada sob este contrato particular. O segundo aplica a regra declarada. O terceiro impede que um cálculo estreito se torne um achado de incidente sem suporte. Nenhuma das setas autentica um produtor, estabelece autorização ou fornece um registro ausente.

Comece por congelar o quadro esperado antes de olhar o resultado. Suponha que um revisor receba um quadro BSL1 declarado de seis objetos, S01–S06. Um segundo arquivo contém só S01 e relata ausência de conflito. Esse resultado pode estar correto para S01 sozinho. Não pode responder à pergunta de seis objetos, a menos que os cinco objetos ausentes sejam contabilizados. Redefinir em silêncio o quadro esperado para coincidir com o arquivo devolvido mudaria a pergunta depois de ver a resposta.

Em seguida, inspecione o significado do campo, não só a presença do campo. Um campo chamado confirmed pode conter um booleano, texto, um inteiro ou nenhum valor. Um valor que uma linguagem de programação trata como verdadeiro não é necessariamente uma afirmação afirmativa sob o esquema do exercício. A unidade 4 torna essa diferença executável.

Por fim, inspecione a frase que o analista escreve. Mesmo um ponteiro autêntico de R4 sustenta o fato de que um cancelamento foi registrado; não fornece aprovação, o ator humano nem uma comparação fresca de estado de reserva aprovada pelo responsável. Verificação de tipo não é prova semântica. Por outro lado, uma entrada malformada não é evidência de que ocorreu uma mudança maliciosa. É um motivo para interromper essa comparação e buscar uma fonte utilizável.

Exemplo resolvido

Uma nota de revisão proposta diz: “O verificador não devolveu achados, portanto as seis reservas estão seguras.” A entrada anexa contém só S01. O primeiro erro é um descompasso de quadro, antes de qualquer pergunta sobre se o cálculo de sobreposição está correto. O segundo erro é promover um resultado de peça a segurança do serviço. Uma substituição defensável é: “Não se encontrou sobreposição na comparação declarada de uma linha; esta entrada não responde à pergunta de ensaio de seis linhas nem estabelece um estado real de serviço.”

Para responder à pergunta original, o revisor deve reter a entrada de uma linha e o seu resultado, pedir o quadro ausente ou uma revisão explícita de escopo aprovada pelo responsável, e executar de novo a comparação relevante. Não invente as linhas ausentes, não infira que foram apagadas e não sobrescreva o primeiro resultado.

Prática suplementar W1-R1

Objetivo: separar a admissibilidade da entrada do significado de um resultado calculado. Entradas: os três relatórios abaixo, a limitação original de R4 e o quadro BSL1 de seis objetos descrito acima. Artefato exigido: três linhas contendo a decisão de admissibilidade, a afirmação estreita sustentada, a evidência ausente e o próximo pedido limitado. Restrições: nenhum fato novo da série R; nenhuma coleta de produção; reter tanto a entrada submetida quanto o escopo declarado.

Tabela da aula; deslize para ver todas as colunas →

Avaliação: um ponto por cada linha raciocinada corretamente, um por distinguir um quadro ausente de um achado negativo, e um por preservar a fronteira do caso canônico. Cinco pontos avaliam só esta tarefa suplementar. Uma alegação de aprovação real, de atribuição humana ou de estado seguro de produção exige correção, qualquer que seja o total. Resolução.

Rubrica: 3 = cinco pontos da fonte: três linhas corretas, distinção entre quadro ausente e achado negativo, e fronteira canônica preservada;; 2 = a maior parte desses pontos, com uma omissão de limite;; 1 = responde, mas omite fonte, limite ou a fronteira do caso;; 0 = nenhum.

Síntese da revisão

Uma entrada utilizável, um cálculo correto e uma conclusão operacional justificada são conquistas diferentes. Preserve a fronteira entre elas.

Marco resolvido

R1 registra uma entrada bem-sucedida de conta; R3 e R4 registram mudanças de reserva. Os registros estabelecem a sequência, enquanto a identidade da pessoa e a aprovação das mudanças permanecem desconhecidas. A primeira decisão é uma pergunta limitada ao responsável, não um veredito de comprometimento.

Prática — Aula 01

EX001 — Observação ou inferência

Objetivo: separar o conteúdo de um registro de uma explicação desse conteúdo. Entradas: R1, R3, R4, R5 e R7, todas dentro da liberação R1–R8 da Rodada A às 09:05. Estes são os ponteiros exatos de fonte para as quatro afirmações; não use R9 nem qualquer resultado posterior do caso. Saída: uma tabela de quatro linhas com afirmação, classificação, registro de suporte e uma frase que descreva o limite do registro. Classifique: (a) “R4 registra um cancelamento de B18”; (b) “desk-a foi comprometida”; (c) “R5 relata que B18 desapareceu”; (d) “R7 prova que o serviço pode ser restaurado em dez minutos.” Use as categorias observação direta, hipótese que exige confirmação e conclusão sem suporte. Uma nota 2 exige distinguir o fato de um relato de frequentador de uma prova independente da experiência completa do frequentador.

Extensão: Para cada afirmação original, reescreva qualquer conclusão sem suporte na formulação defensável mais estreita. Acrescente uma fonte que seria necessária para elevar a alegação.

Para crédito completo: Uma resposta de 2 pontos deve distinguir “R5 registra um relato de frequentador” de “a interface de reserva foi provada incorreta de forma independente”, e “R7 relata a conclusão da cópia” de “a recuperação foi testada”. Selecionar apenas um rótulo, sem uma frase de limite, obtém no máximo 1.

Resolução: EX001 no apêndice final.

Rubrica: 3 = nota 2 da fonte: quatro linhas com classificação, registro e limite; distingue o relato de R5 de prova independente da experiência, e a conclusão da cópia em R7 de recuperação testada;; 2 = as quatro linhas existem, mas falta um limite exigido para a nota 2;; 1 = responde à pergunta, mas omite fonte, limite ou a frase que restringe a alegação;; 0 = nenhum.