OpenCyber Academy
Graduação · Capítulo 14 · Português
Código do curso: OCA-111Capítulo 14: OCA-111-C014

Capítulo 14 — Fundamentos de privacidade

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

Mapa da aula

Aula 14 publicada. Mapa, exemplo, EX040.

flowchart TD
  N0["14.1 Minimização"]
  N1["14.2 Redação"]
  N2["14.3 Limitação de finalidade"]
  N3["14.4 Acesso"]
  N4["14.5 Transferências internacionais"]
  N5["14.6 Risco de violação"]
  N6["14.7 Exercícios de reidentificação"]
  N7["14.8 Uma biblioteca de evidências sintéticas"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX040"]

Desenho lógico

flowchart LR
  N0["14.1 Minimização"]
  N1["14.2 Redação"]
  N2["14.3 Limitação de finalidade"]
  N3["14.4 Acesso"]
  N4["14.5 Transferências internacionais"]
  N5["14.6 Risco de violação"]
  N6["14.7 Exercícios de reidentificação"]
  N7["14.8 Uma biblioteca de evidências sintéticas"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX040"]

[14.1 Minimização]
    |
    v
[14.2 Redação]
    |
    v
[14.3 Limitação de finalidade]
    |
    v
[14.4 Acesso]
    |
    v
[14.5 Transferências internacionais]
    |
    v
[14.6 Risco de violação]
    |
    v
[14.7 Exercícios de reidentificação]
    |
    v
[14.8 Uma biblioteca de evidências sintéticas]
    |
    v
[Exemplo resolvido] --> [Exercício EX040]

Objetivos de aprendizagem

Você vai (1) minimizar os dados de clientes nas evidências; (2) redigir; (3) respeitar a retenção.

14.1 Minimização

A prova vale mais que extrações em massa de tabelas de clientes. Um testador precisa mostrar que uma fraqueza existe, não coletar o que ela expõe. Se uma API devolve os saldos de outros clientes, uma resposta contendo o saldo de uma conta sintética prova a falha tão bem quanto dez mil reais, e não cria nenhuma nova cópia de dados reais de clientes. Cada registro extra capturado precisa ser armazenado, protegido, relatado e apagado, e pode ele mesmo se tornar uma violação a ser notificada. Sam para um teste assim que tem a primeira resposta que prova o problema. Ele registra quantos registros o endpoint poderia ter devolvido, em vez de obtê-los para provar isso.

14.2 Redação

Mascare os números de conta; mantenha os dígitos que provam o problema, se necessário. A redação deve remover a identidade enquanto preserva a prova. Uma captura de tela mostrando que a sessão do cliente A exibiu o extrato do cliente B só precisa dos quatro últimos dígitos de cada número de conta para mostrar que os dois diferem. Os números completos acrescentam risco e nenhuma evidência. Nomes, endereços e saldos são cobertos com caixas sólidas. O desfoque às vezes pode ser revertido, e o recorte pode deixar texto nos metadados da imagem. Sam redige numa cópia, mantém o original não redigido no cofre sob sua data de retenção e calcula o hash dos dois, para que um revisor possa confirmar que a imagem redigida veio da evidência original.

14.3 Limitação de finalidade

As evidências do engajamento não são uma fonte de análise de marketing. Os dados dos clientes chegaram à equipe de testes por um único motivo, que era verificar a segurança do banco sob um contrato assinado. Usar as mesmas capturas de tela para estudar como os clientes usam o aplicativo, ou para ilustrar uma apresentação de vendas, é uma nova finalidade que os clientes nunca esperaram e que o contrato nunca cobriu. As leis de privacidade de muitas jurisdições tratam essa mudança de finalidade como algo que precisa de sua própria base legal. A regra prática no TRB é simples. As evidências respondem a perguntas sobre o engajamento de onde vieram, e qualquer outra pergunta precisa de dados separados, coletados para essa finalidade.

14.4 Acesso

Necessidade de saber nos cofres de evidências. As evidências de um engajamento são lidas por seus testadores, seu revisor e o custodiante, e por mais ninguém por padrão. Um desenvolvedor que corrige um achado vê a descrição do achado e a prova redigida, não a captura bruta. Um gestor vê o status e a severidade. Pedidos de acesso fora desses papéis vão ao líder do engajamento com um motivo e uma data de término. A necessidade de saber também limita os danos. Se a conta de um testador for comprometida, o atacante alcança as evidências de um engajamento, não toda captura de tela que a equipe fez em cinco anos.

14.5 Transferências internacionais

Regiões de nuvem podem envolver regras; o jurídico orienta. As evidências armazenadas num serviço de nuvem ficam numa região específica, e backups ou acessos de suporte podem alcançar outras. Se as evidências contêm dados pessoais de clientes de um país e o armazenamento ou a equipe de suporte do fornecedor estão em outro, podem se aplicar regras de transferência de dados, além dos compromissos do próprio banco com seu regulador. Não se espera que os testadores interpretem essas regras por conta própria. Espera-se que percebam quando as evidências estão prestes a cruzar uma fronteira, por exemplo ao enviá-las a uma ferramenta nova ou compartilhá-las com um fornecedor no exterior, e que consultem o jurídico antes de fazê-lo.

14.6 Risco de violação

Os cofres de evidências são alvos de alto valor; proteja-os. O cofre de uma equipe de testes guarda as fraquezas do banco, a prova de como alcançá-las e amostras dos dados por trás delas, o que, junto, forma um roteiro para o atacante. Por isso, o cofre recebe controles pelo menos tão fortes quanto os dos sistemas que ele descreve: autenticação multifator, acesso registrado, criptografia em repouso, retenção curta e seu próprio lugar no plano de incidentes. Se o cofre fosse comprometido, o banco teria de tratar todo achado não corrigido nele como potencialmente conhecido por um atacante. É por isso que o TRB prioriza a correção das fraquezas registradas num cofre exposto, qualquer que seja sua severidade original.

14.7 Exercícios de reidentificação

Os exercícios de reidentificação juntam uma captura de tela redigida a organogramas públicos. Se um colega consegue nomear a pessoa, a redação é reprovada no portão. Sam agora prefere personas sintéticas na maioria das capturas de tela didáticas. O exercício testa o que um leitor consegue deduzir, não só o que foi coberto. A captura de tela de uma página administrativa interna pode esconder um nome, mas deixar um cargo, um código de agência e um carimbo de tempo, e, junto com um organograma público, isso identifica uma pessoa. Os colegas têm dez minutos e apenas fontes públicas. Uma identificação bem-sucedida não conta como erro de quem redigiu. Ela mostra que a regra de redação deixou passar um tipo de campo, e a regra é atualizada.

14.8 Uma biblioteca de evidências sintéticas

Uma biblioteca de capturas de tela sintéticas cobre os achados comuns, para que os alunos não precisem manusear pixels de clientes reais. Sam contribui com uma nova imagem sintética a cada período letivo. Cada entrada recria um achado típico numa maquete das interfaces do TRB, como uma página de extrato mostrando o cliente errado, uma mensagem de erro vazando um stack trace ou um painel administrativo alcançável sem login, usando dados inventados do começo ao fim. Treinamentos, modelos de relatório e palestras em conferências usam a biblioteca em vez das pastas de engajamento. Construir uma entrada leva algumas horas e remove para sempre a tentação de redigir uma captura de tela real para um slide.

14.9 Etiquetas de finalidade nas evidências

Os arquivos de evidência recebem uma etiqueta de finalidade; o uso secundário exige uma nova etiqueta e aprovação. O marketing não pode "só pegar emprestadas" as capturas de tela do engajamento. A etiqueta é definida no upload. Na maioria dos casos, ela é "evidência do engajamento" e, para alguns arquivos, "evidência do engajamento mais uso aprovado em treinamento". O FindingsDesk confere a etiqueta sempre que um arquivo é copiado para outro espaço de trabalho ou anexado a qualquer coisa que não seja um achado, e bloqueia a ação se as finalidades não coincidirem. Acrescentar uma finalidade exige a aprovação do líder do engajamento e uma verificação de privacidade. A etiqueta transforma uma frase de política numa verificação que roda toda vez que um arquivo se move.

14.10 Os alunos escolhem o exemplo sintético

O item SS-17 da biblioteca de capturas sintéticas mostra uma cliente falsa, "Ada Example", com a conta ••••4242. Os alunos o preferem a redigir telas reais. Sam mede essa preferência e financia mais arte sintética. A preferência é prática, além de ética. Redigir corretamente uma captura de tela real toma vinte minutos do aluno e uma verificação do revisor, enquanto a sintética está pronta para uso e não traz risco se acabar no lugar errado. Sam acompanha com que frequência cada item da biblioteca é usado. Os itens mais usados mostram sobre quais achados os alunos mais escrevem, e esses são os próximos a ganhar versões sintéticas.

14.11 Uma cópia bloqueada para uma pasta de design

As etiquetas de finalidade impediram que um trainee bem-intencionado colocasse capturas de tela do engajamento numa pasta de redesenho de UX. A recusa pareceu mesquinha e protegeu cem clientes. A ideia do trainee era razoável à primeira vista. As capturas de tela mostravam telas reais e confusas que a equipe de design queria melhorar. Também mostravam nomes reais de clientes e saldos parciais, e a pasta de design era compartilhada com uma agência externa. A correção levou uma tarde. O trainee descreveu cada tela confusa em palavras, e a equipe de design a reconstruiu com dados sintéticos. A agência obteve o que precisava e nenhum dado de cliente saiu do banco.

14.12 Manter as personas sintéticas obviamente falsas

A sintética Ada Example tem um guia de estilo para que os artistas a mantenham obviamente falsa. Uma persona sintética real demais causa os problemas que deveria evitar. Os leitores podem presumir que é uma cliente real redigida, ou os detalhes podem coincidir por acaso com uma pessoa real. O guia de estilo fixa os sinais reveladores: nomes de uma lista inventada acordada, números de conta terminados em dígitos de teste bem conhecidos, endereços em ruas que não existem na região do TRB e datas num ano de teste reservado. Quem vê esses marcadores reconhece o material didático num relance.

14.13 Acordos com ilustradores

Os artistas assinam um CLA segundo o qual Ada Example não pode se parecer com clientes reais. O jurídico insistiu; Sam concordou com prazer. Os ilustradores às vezes baseiam rostos e caligrafias em pessoas que conhecem ou em fotografias de banco de imagens de pessoas reais. No material de treinamento de um banco, uma persona parecida com um cliente real poderia sugerir que a conta desse cliente esteve envolvida num achado de segurança. O acordo de contribuição faz o artista confirmar que toda semelhança é inventada e dá ao TRB os direitos de reutilizar e alterar a arte. Essa segunda parte importa tanto quanto a primeira, porque os exemplos sintéticos precisam ser atualizados quando as interfaces reais mudam.

14.14 Visitas à mesa para analistas novos

Os coaches de privacidade do TRB incluem uma visita de cinco minutos à mesa quando um analista novo abre o cofre de evidências pela primeira vez. Sam roteiriza a visita: mostrar as datas de retenção, mostrar a lista de acesso, mostrar um exemplo de falha de redação, pedir ao analista que repita a regra da minimização com as próprias palavras. As visitas à mesa pegam a bravata melhor que os módulos do LMS. Os analistas assinam um pequeno cartão que fica no saguão do cofre.

Uma regra aprendida num documento é facilmente esquecida. Uma regra mostrada à mesa, na tela do próprio analista, com a data de retenção do seu próprio engajamento, tende a ficar. O exemplo de falha de redação é escolhido para ser desconfortável: uma captura de tela que parecia limpa até que um colega nomeou a pessoa nela. Pedir ao analista que reformule a regra mostra se ele a entendeu ou apenas concordou com a cabeça.

Exemplo resolvido (TRB sintético)

Sam redige tudo, exceto os quatro últimos dígitos, antes de anexar uma captura de tela ao F4.

Caso sintético — Riverstone Transit Bank (TRB). O banco, Sam Ito, TrackScope/FindingsDesk/PulseMap e todos os números são inventados para fins didáticos.

Erros e limites

Este livro não concede nenhuma autoridade para testar bancos ou sistemas de pagamento reais. Os laboratórios usam apenas endereços de faixas de documentação e dados sintéticos; código de exploit nunca é fornecido.

Exercícios

Síntese

Privacidade é minimização, redação, limites de finalidade e higiene do cofre.

Continue estudando — capítulo 14 de 40

← Capítulo 13 (rascunho) · Índice de capítulos do curso · Capítulo 15 (rascunho) →

Respostas comentadas

EX040. Isso excede a finalidade e a minimização prevista nas ROE; a prova precisa de amostras, não de dados em massa.

EX041. Números de conta (deixando os quatro últimos dígitos, se necessário) e outros identificadores pessoais.

EX042. Eles concentram dados sensíveis de prova, atraentes para atacantes e para pessoas de dentro.