OpenCyber AcademyMapa da aula
Aula 08 publicada. Mapa, exemplo, EX036.
flowchart TD
N0["8.1 O caso"]
N1["8.2 Causas"]
N2["8.3 Recomendações"]
N3["Síntese"]
N0 --> N1 --> N2 --> N3
N3 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX036"]
Desenho lógico
flowchart LR
N0["8.1 O caso"]
N1["8.2 Causas"]
N2["8.3 Recomendações"]
N3["Síntese"]
N0 --> N1 --> N2 --> N3 --> Q["EX036"]
[8.1 O caso]
|
v
[8.2 Causas]
|
v
[8.3 Recomendações]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX036]
Objetivos de aprendizagem
Você vai (1) analisar um incidente sob supervisão; (2) separar causas de sintomas; (3) recomendar mudanças de projeto.
8.1 O caso
Ines dá a Owen um caso supervisionado do histórico da Thornbury, anonimizado. Um atendente da central alterou os dados bancários de um inquilino para reembolsos de aluguel depois que quem ligou passou nas perguntas básicas de identificação. O reembolso foi para a conta de um criminoso. O inquilino percebeu semanas depois. Owen lê as anotações da ligação, os logs do sistema e o relatório da investigação. Ele monta primeiro uma linha do tempo, depois lista os sintomas, como o reembolso extraviado, e os separa das causas. Ines revisa cada etapa e questiona as suposições iniciais dele sobre de quem foi a culpa.
8.2 Causas
Owen identifica causas em vários níveis. As perguntas de identificação usavam informações que criminosos conseguem encontrar, como a data de nascimento e o endereço. O sistema permitia alterar os dados bancários e emitir um reembolso no mesmo dia, sem nenhuma notificação ao inquilino. O atendente era medido pelo tempo de atendimento das ligações, o que desestimulava verificações extras. Nenhuma pessoa sozinha falhou; o projeto tornou a fraude fácil. Ele faz referência à separação de privilégio de Saltzer e Schroeder (1975), que sugere que mudanças sensíveis precisam de mais de uma condição independente.
8.3 Recomendações
Owen recomenda: confirmar as mudanças bancárias por um código enviado ao telefone ou e-mail cadastrado do inquilino; uma retenção de sete dias nos reembolsos depois de mudanças bancárias; notificação automática ao inquilino de qualquer mudança; e ajustar as métricas da central de atendimento para que o tempo de verificação não seja penalizado. Ele estima o custo e o efeito de cada uma. Kwame e a chefe do financeiro aceitam as quatro. Ines observa que a análise de casos é valiosa quando muda o projeto, e não quando simplesmente atribui a culpa ao atendente envolvido.
Exemplo resolvido
Owen analisa um caso anonimizado de fraude em reembolso, identifica as causas de projeto usando a separação de privilégio e recomenda quatro mudanças aceitas.
Caso sintético. O caso é sintético; Saltzer e Schroeder (1975) é real.
Erros e limites
Casos históricos têm evidências faltantes. As retenções podem atrasar reembolsos legítimos.
Exercícios
-
EX036 — Perguntas fracas. Por que as perguntas de identificação eram fracas?
Mostrar critérios de avaliação
Rubrica: 3 = criminosos conseguem encontrar a data de nascimento e o endereço;; 2 = dados públicos;; 1 = vago;; 0 = nenhuma. -
EX037 — Causa no sistema. Que característica do sistema permitiu a fraude?
Mostrar critérios de avaliação
Rubrica: 3 = mudança bancária e reembolso no mesmo dia sem notificação;; 2 = mesmo dia;; 1 = vago;; 0 = nenhuma. -
EX038 — Princípio. Que princípio Owen aplicou?
Mostrar critérios de avaliação
Rubrica: 3 = separação de privilégio;; 2 = separação;; 1 = menor privilégio;; 0 = nenhuma. -
EX039 — Mudança nas métricas. Por que ajustar as métricas da central de atendimento?
Mostrar critérios de avaliação
Rubrica: 3 = as metas de tempo de atendimento desestimulavam verificações extras;; 2 = incentivos;; 1 = vago;; 0 = nenhuma. -
EX040 — Retenção do reembolso. Por quanto tempo o reembolso fica retido após uma mudança bancária?
Mostrar critérios de avaliação
Rubrica: 3 = sete dias;; 2 = sete;; 1 = vago;; 0 = nenhuma.
Síntese
A análise de casos supervisionada encontra as causas de desenho por trás dos incidentes e as transforma em mudanças aceitas.