◇ OpenCyber Academy
Tecnólogo · Capítulo 14 · Português

Capítulo 14 — Arquitetura e engenharia de segurança: métodos I

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 14 — Arquitetura e engenharia de segurança: métodos I

Mapa da aula

Aula 14 publicada. Mapa, exemplo, EX040.

flowchart TD
  N0["14.1 STRIDE no portal"]
  N1["14.2 Registrar os resultados"]
  N2["14.3 Revisar com o desenvolvedor"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX040"]

Desenho lógico

flowchart LR
  N0["14.1 STRIDE no portal"]
  N1["14.2 Registrar os resultados"]
  N2["14.3 Revisar com o desenvolvedor"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3 --> Q["EX040"]

[14.1 STRIDE no portal]
    |
    v
[14.2 Registrar os resultados]
    |
    v
[14.3 Revisar com o desenvolvedor]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX040]

Objetivos de aprendizagem

Você vai (1) aplicar o STRIDE ao projeto do portal de upload; (2) registrar ameaças e mitigações; (3) revisar o resultado com o desenvolvedor.

14.1 STRIDE no portal

A Brightwater constrói o portal de upload de manifestos recomendado no capítulo 12. Tomás aplica ao projeto o STRIDE de Shostack (2014). Spoofing (falsificação de identidade): um criminoso poderia se passar por um varejista, então as contas precisam de login forte. Tampering (adulteração): um manifesto poderia ser alterado em trânsito, então os uploads usam HTTPS. Repudiation (repúdio): um varejista poderia negar ter enviado uma mudança, então os uploads são registrados com a conta. Information disclosure (divulgação de informação): um varejista não pode ver os manifestos de outro. Denial of service (negação de serviço): arquivos enormes poderiam sobrecarregar a importação. Elevation of privilege (elevação de privilégio): uma conta de varejista não pode alcançar funções de administração.

14.2 Registrar os resultados

Tomás registra cada ameaça numa tabela com o elemento afetado, a mitigação, o responsável e como a mitigação será testada. Algumas mitigações já existem no framework do portal, como o HTTPS. Outras exigem trabalho: um limite de tamanho de arquivo, a separação dos dados por varejista conferida por um teste e o login multifator para as contas dos varejistas. Ele marca um item, os picos de alteração de endereços, como dependente de informação do negócio sobre o que conta como incomum. Uma tabela torna a revisão rastreável e dá ao desenvolvedor um checklist.

14.3 Revisar com o desenvolvedor

Tomás percorre a tabela com o desenvolvedor em trinta minutos. O desenvolvedor aponta uma ameaça que Tomás deixou passar: os e-mails de redefinição de senha do portal poderiam ser interceptados se o e-mail de um varejista estiver comprometido. Eles acrescentam uma mitigação: os links de redefinição expiram em quinze minutos e notificam o segundo contato da conta. O desenvolvedor também contesta uma mitigação como excessiva. A revisão conjunta melhora o resultado, porque os desenvolvedores sabem como o código de fato se comporta, e os tecnólogos trazem uma visão estruturada das ameaças. Eles combinam repetir a revisão sempre que o projeto do portal mudar.

Exemplo resolvido

Tomás aplica o STRIDE ao portal, registra seis ameaças com mitigações e testes e as revisa com o desenvolvedor, que acrescenta uma ameaça na redefinição de senha.

Caso sintético. O portal é sintético; Shostack (2014) é real.

Erros e limites

O STRIDE encontra categorias, não todos os ataques. As revisões dependem do tempo disponível.

Exercícios

Síntese

O STRIDE dá estrutura, e a revisão conjunta com os desenvolvedores detecta ameaças que cada lado, sozinho, deixaria passar.

Continue estudando — aula 14 (capítulo 14 de 30)

← Capítulo 13 · Índice das aulas · Capítulo 15 →

Continue para a próxima aula já escrita.