Definir o resultado que precisa de mudar
Num banco fictício, uma auditoria identifica que o batch noturno pode avançar sem reconciliação completa. A equipa instala um novo script e fecha o ticket de alteração. Isso demonstra uma ação administrativa e pode documentar uma implementação, mas ainda não responde à constatação original. Começa por ligar requisito, condição observada, consequência, causa investigada e ação proposta. Define o que deve passar a acontecer: quando a reconciliação falhar, o processamento deve parar ou seguir uma exceção autorizada, com registo e escalada. Identifica o responsável pela implementação e quem avaliará o resultado. Evita critérios como “script entregue”, quando o risco resulta do comportamento do processamento. Os critérios devem permitir concluir tanto sucesso como falha ou evidência insuficiente.
Escolher âmbito, ambiente e período do reteste
Uma correção pode funcionar num nó e falhar no segundo, ou resultar no ciclo diurno mas não no noturno. O plano de reteste identifica ativos, configurações, versão implementada, ambiente, condições de execução e período relevante. Um teste em homologação pode apoiar a conclusão sobre desenho ou preparação, mas não demonstra automaticamente o comportamento em produção. Da mesma forma, evidência recolhida antes da implementação não verifica a alteração posterior. A duração e a seleção de observações dependem do objetivo, frequência do controlo, risco e método de avaliação. Não existe neste exercício uma regra universal de dois ciclos. Regista as limitações de acesso ou de tempo, o seu efeito na conclusão e a evidência adicional necessária.
Trabalhar com uma matriz de critérios
O laboratório fornece onze constatações, todas com ticket fechado, e uma matriz fictícia de dois ativos por dois ciclos. A query parte dos critérios exigidos e associa a evidência disponível; assim, um critério sem observação não desaparece do relatório. Em A, as quatro observações atuais satisfazem as condições modeladas. D só cobre um ativo e I só cobre o ciclo diurno. E usa ambiente de teste, H contém observações anteriores à implementação e J refere uma versão antiga. Cada resultado aponta uma lacuna diferente e exige uma resposta específica. A matriz foi definida pelo autor do exercício: uma query correta não demonstra que essa matriz representa todos os ativos ou condições de um serviço real.
Conservar histórico e interpretar observações posteriores
B tinha evidência favorável, seguida de uma falha no mesmo ativo e ciclo. No modelo, a observação posterior determina o estado atual, mas os registos anteriores permanecem disponíveis. Isto permite explicar a evolução em vez de apagar o que deixou de sustentar o encerramento. A query usa ROW_NUMBER para selecionar uma observação por critério após filtrar ambiente, versão e instante de corte. Em empate temporal usa o identificador de inserção, uma convenção explícita dos dados fictícios. Numa auditoria real, fontes contraditórias com a mesma hora exigem investigação; o maior identificador não prova maior fiabilidade. Também não se deve escolher o último sucesso e ignorar falhas posteriores. Um resultado inconclusivo precisa de investigação, não de conversão automática em aprovação.
Transformar a saída em uma conclusão delimitada
Executa o programa e compara os onze tickets fechados com os estados derivados. A é apenas elegível para revisão de encerramento, não uma opinião de auditoria emitida por software. O avaliador continua a precisar de confirmar autenticidade, pertinência, suficiência e âmbito da evidência, bem como os requisitos de independência aplicáveis. Os nomes de revisores no laboratório são dados, não pessoas autenticadas. Experimenta os probes de matriz vazia, evidência não revista e novo ativo. Cada alteração é revertida por savepoint para permitir comparação. Redige uma nota para D indicando o ativo por testar, quem deve fornecer evidência e o efeito da lacuna na conclusão. A nota deve distinguir a correção declarada do resultado efetivamente observado.
python3 content/labs/cisa-remediation-followup/run.py
# Compare findings A, B, D, E, H, I and J.
# eligible-for-closure-review is a review candidate, not an audit opinion.
# Production coverage and period sufficiency still require assessment.O ticket de instalação está fechado, mas só node-a tem testes válidos. A nota de follow-up regista implementação declarada e cobertura incompleta de node-b; não apresenta o serviço inteiro como corrigido.
Armadilhas comuns
Contar tickets em vez de resultados; testar a versão errada; remover critérios sem evidência; escolher só observações favoráveis; interpretar uma flag de revisão como independência demonstrada.
Tópicos relacionados: Evidência de auditoria · Controlo de alterações · Revisão pós-implementação
O encerramento precisa de uma conclusão sustentada no âmbito relevante. Uma implementação ou um ticket fechado são partes da evidência, não a conclusão inteira.
Referência: Assessing Security and Privacy Controls · CISA outline effective August 1, 2024