Questão de Segurança da Informação — Ciclo de Vida de Desenvolvimento Seguro — CESPE / CEBRASPE 2024
Segurança da Informação›Ciclo de Vida de Desenvolvimento Seguro
Código
ce404104
Banca
CESPE / CEBRASPE
Órgão
STJ
Ano
2024
Cargo
AJ
A respeito de desenvolvimento de software seguro, julgue os itens que se seguem.
No SDL (Security Development Lifecycle), a modelagem de ameaças é uma prática que ajuda a identificar e avaliar possíveis ameaças ao sistema durante a fase de design do software.
CCerto
EErrado
Revelar gabarito e comentário▾
GabaritoC — Certo
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Modelagem de ameaças no SDL (Security Development Lifecycle)
✅ CERTO. A modelagem de ameaças é, de fato, uma prática central do SDL (Security Development Lifecycle) e é aplicada durante a fase de design do software, com o objetivo de identificar e avaliar possíveis ameaças ao sistema. O gabarito oficial é a alternativa C. Essa prática permite que a equipe de desenvolvimento antecipe ataques e vulnerabilidades antes mesmo da codificação, incorporando a segurança desde a concepção do software.
O SDL, criado pela Microsoft, é uma metodologia que integra a segurança em todas as fases do ciclo de vida de desenvolvimento de software, desde a concepção até a manutenção. Ele segue o modelo espiral e o princípio SD3 + C, que inclui: Secure by Design (arquitetura e implementação devem proteger o software), Secure by Default (a segurança deve ser alta por padrão, com privilégio mínimo), Secure by Deployment (o software deve facilitar seu uso seguro) e Communications (divulgação de vulnerabilidades e atualizações).
A modelagem de ameaças é uma técnica que se encaixa perfeitamente na fase de design, pois é nela que se define a arquitetura do sistema, os fluxos de dados, os pontos de entrada e os componentes. Ao modelar as ameaças, a equipe consegue:
Identificar potenciais atacantes e seus objetivos.
Analisar os vetores de ataque e as vulnerabilidades que podem ser exploradas.
Avaliar o risco de cada ameaça, considerando probabilidade e impacto.
Priorizar as ações de mitigação, focando nos riscos mais críticos.
Um exemplo prático: ao desenvolver um sistema de comércio eletrônico, a modelagem de ameaças na fase de design pode identificar o risco de SQL Injection no formulário de busca. Com essa informação, a equipe pode definir, já na arquitetura, o uso de consultas parametrizadas e a validação rigorosa de entrada, evitando que a vulnerabilidade chegue ao código final.
A modelagem de ameaças não é um add-on ou uma ferramenta que se adiciona ao software depois de pronto; ela é uma prática integrada ao processo de design. O OWASP (Open Web Application Security Project) também recomenda o uso de modelagem de ameaças como uma das principais medidas de prevenção contra o Design Inseguro, uma categoria do OWASP Top 10 que se concentra em falhas estruturais no planejamento e arquitetura das aplicações.
A banca explora aqui um ponto fundamental: a fase em que a modelagem de ameaças é aplicada. O candidato pode confundir e achar que ela é feita na fase de implementação ou testes, mas o correto é que ela ocorre na fase de design, antes da codificação. É nessa fase que as decisões arquiteturais são tomadas e onde a modelagem de ameaças tem o maior impacto.
1Identificar atacantes e objetivos
2Analisar vetores de ataque
3Avaliar risco (probabilidade × impacto)
4Priorizar mitigações
LEVEL · soulevel.com.br
NÃO CAIA NESSA!
A banca pode tentar induzir o candidato a associar a modelagem de ameaças a uma fase posterior do ciclo de vida, como a fase de testes ou de implementação. No entanto, a modelagem de ameaças é uma prática da fase de design, pois é nela que se define a arquitetura e se identificam as possíveis ameaças antes que o código seja escrito. Lembre-se: a segurança deve ser incorporada desde a concepção, e a modelagem de ameaças é a ferramenta para isso.