Capítulo 7 — Arquitetura e engenharia de segurança: controles e verificação | Profissionalizante Arquitetura e engenharia de segurança

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

Capítulo 7 — Arquitetura e engenharia de segurança: controles e verificação

Mapa da aula

Aula 07 publicada. Mapa, exemplo, EX031.

flowchart TD
  N0["7.1 Selecionar os controles"]
  N1["7.2 Requisitos verificáveis"]
  N2["Laboratório — Rastreamento dos requisitos até os res"]
  N3["7.3 Conferir se funcionam"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX031"]

Desenho lógico

flowchart LR
  N0["7.1 Selecionar os controles"]
  N1["7.2 Requisitos verificáveis"]
  N2["Laboratório — Rastreamento dos requisitos até os res"]
  N3["7.3 Conferir se funcionam"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX031"]

[7.1 Selecionar os controles]
    |
    v
[7.2 Requisitos verificáveis]
    |
    v
[Laboratório — Rastreamento dos requisitos até os res]
    |
    v
[7.3 Conferir se funcionam]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX031]

Objetivos de aprendizagem

Você vai (1) selecionar controles para as principais ameaças; (2) escrever requisitos verificáveis; (3) conferir se os controles funcionam.

7.1 Selecionar os controles

Para as principais ameaças dos reparos, Owen seleciona controles com a equipe de imóveis e a TI. Exposição dos códigos dos cofres de chaves: mostrar os códigos apenas ao contratado designado no dia da visita, como feito no capítulo 6, e registrar cada visualização. Contas de ex-funcionários dos contratados: o fluxo de acesso com expiração. Visibilidade entre contratados: restringir cada conta de contratado às suas próprias ordens. Anotações alteradas: manter um histórico de mudanças que os contratados não conseguem editar. Ele confere as escolhas contra as famílias de controles do NIST SP 800-53 Rev. 5, o que confirma que cobriu controle de acesso, auditoria e responsabilização.

7.2 Requisitos verificáveis

Owen transforma os controles em enunciados que podem ser conferidos: uma conta de contratado só consegue ver as ordens atribuídas à sua empresa; um código de cofre de chaves só fica visível na data da visita; toda visualização de código é registrada com usuário e horário; as edições das anotações das ordens preservam a versão anterior. Requisitos vagos, como "o acesso dos contratados deve ser seguro", não podem ser testados. Escrevê-los com precisão também ajuda o fornecedor, que pode confirmar quais deles o produto suporta e fazer orçamento dos que exigem configuração.

Laboratório — Rastreamento dos requisitos até os resultados da verificação

# Trace requirements to verification results, before and after the vendor fix (synthetic).
reqs = {"R1 contractor sees own company's jobs only": "pass",
        "R2 key safe code visible only on visit date": "fail (visible until end of next day)",
        "R3 every code view logged with user and time": "pass",
        "R4 job note edits keep previous version": "pass"}
for r, res in reqs.items(): print(f"{r}: {res}")
print(f"round 1: {sum(v == 'pass' for v in reqs.values())}/{len(reqs)} passed")
reqs["R2 key safe code visible only on visit date"] = "pass (after vendor cutoff change)"
print(f"round 2: {sum(v.startswith('pass') for v in reqs.values())}/{len(reqs)} passed")

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

R1 contractor sees own company's jobs only: pass
R2 key safe code visible only on visit date: fail (visible until end of next day)
R3 every code view logged with user and time: pass
R4 job note edits keep previous version: pass
round 1: 3/4 passed
round 2: 4/4 passed

7.3 Conferir se funcionam

Owen e um testador usam duas contas de contratado de teste para conferir cada requisito. O laboratório rastreia cada requisito até o resultado do teste. Três passam. O teste de visibilidade do código falha: os códigos continuam visíveis por um dia depois da visita, porque o fornecedor usa o fim do dia seguinte como corte. O fornecedor muda a configuração e o novo teste passa. Owen registra os resultados numa tabela ligada às ameaças, para que qualquer pessoa veja quais ameaças são tratadas por controles verificados e quais ainda dependem de promessas não verificadas.

Exemplo resolvido

Owen seleciona controles para quatro ameaças, escreve quatro requisitos testáveis e os verifica, pegando um erro no corte de visibilidade dos códigos.

Caso sintético. Os controles e os testes são sintéticos; o SP 800-53 Rev. 5 é real.

Erros e limites

As contas de teste podem não refletir o volume real de dados. As configurações do fornecedor podem voltar ao padrão após atualizações.

Exercícios

EX031 — Controle contra adulteração. Que controle trata as anotações alteradas? Rubrica: 3 = um histórico de mudanças que os contratados não conseguem editar;; 2 = histórico;; 1 = vago;; 0 = nenhuma.
EX032 — Requisito vago. Por que "o acesso dos contratados deve ser seguro" é um requisito ruim? Rubrica: 3 = não pode ser testado;; 2 = não testável;; 1 = vago;; 0 = nenhuma.
EX033 — Cobertura no laboratório. O que a primeira rodada de testes mostrou no laboratório? Rubrica: 3 = 3 de 4 requisitos passaram; a visibilidade do código falhou;; 2 = 3 de 4;; 1 = vago;; 0 = nenhuma.
EX034 — Causa da falha. Por que o teste de visibilidade do código falhou? Rubrica: 3 = o fornecedor cortava no fim do dia seguinte;; 2 = corte;; 1 = vago;; 0 = nenhuma.
EX035 — Resultado do novo teste. O que a segunda rodada mostrou no laboratório? Rubrica: 3 = os 4 requisitos passaram depois da correção do fornecedor;; 2 = 4 de 4;; 1 = vago;; 0 = nenhuma.

Síntese

Os controles se tornam confiáveis quando são escritos como requisitos testáveis e verificados com resultados registrados.

Continue estudando — aula 07 (capítulo 07 de 12)

← Capítulo 06 · Índice das aulas · Capítulo 08 →

Continue para a próxima aula já escrita.