Pular para o conteúdo principal

Questão de Segurança da Informação — Análise de Vulnerabilidade e Gestão de Riscos — FGV 2025

Segurança da InformaçãoAnálise de Vulnerabilidade e Gestão de Riscos
Código
fg114861
Banca
FGV
Órgão
MPE-RJ
Ano
2025
Nível
Superior
Cargo
Analista do Ministério Público - Área Administrativa - Tecnologia da Informação
Segundo o documento OWASP Top 10 vulnerabilities de 2021, o design inseguro é uma categoria ampla que representa diferentes fraquezas que são expressas como "design de controle ausente ou ineficaz". O documento destaca que há uma diferença entre design inseguro e implementação insegura e distingue entre falhas de design e defeitos de implementação, pois eles têm diferentes causas e remediações. Um design seguro pode ter defeitos de implementação que levam a vulnerabilidades que podem ser exploradas. Um design inseguro não pode ser corrigido por uma implementação segura, pois, por definição, os controles de segurança necessários nunca foram criados para se defender contra ataques específicos. Avalie se as formas de prevenção contra o design inseguro expressas no OWASP, incluem:I. Estabelecer e usar um ciclo de vida de desenvolvimento seguro com profissionais de AppSec para ajudar a avaliar e projetar controles relacionados à segurança e privacidade e estabelecer e utilizar uma biblioteca de padrões de projeto seguros.II. Escrever testes unitários e de integração para validar se todos os fluxos críticos são resistentes ao modelo de ameaça e compilar casos de uso e casos de uso incorreto para cada camada do aplicativo.III. Unificar os controles de segurança em histórias de usuários e restringir verificações de plausibilidade em cada camada do seu aplicativo (do frontend ao backend) ao time de design e limitar o consumo de recursos computacionais por usuário ou serviço.Está correto o que se afirma em
  1. AII e III, apenas.
  2. BI e II, apenas.
  3. CI e III, apenas.
  4. DI, apenas.
  5. EIII, apenas.
Revelar gabarito e comentário

GabaritoB — I e II, apenas.

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”.

OWASP Top 10 2021 – Insecure Design (A04:2021)

Gabarito: letra B. De acordo com o OWASP Top 10 2021, as formas de prevenção contra design inseguro incluem estabelecer um ciclo de vida de desenvolvimento seguro com profissionais de AppSec, criar uma biblioteca de padrões de projeto seguros (I) e realizar testes unitários e de integração para validar fluxos críticos, compilando casos de uso e de uso incorreto (II). O item III é incorreto ao afirmar que as verificações de plausibilidade devem ser restritas ao time de design, pois tais verificações devem ser aplicadas em todas as camadas do aplicativo, não exclusivamente pelo time de design.

A questão exige conhecimento das recomendações específicas do OWASP para a categoria Insecure Design, que trata de falhas na arquitetura e no desenho dos controles de segurança, distintas de erros de implementação.

Prevenção – Insecure Design (OWASP 2021)
  • 1Ciclo de vida seguro (SDLC)
    • Profissionais AppSec
    • Biblioteca de padrões seguros
  • 2Testes de validação
    • Unitários e integração
    • Casos de uso e misuse cases
  • 3Restrição ao time de design
    • Verificações em todas as camadas
LEVEL · soulevel.com.br

Item I — ✅ Correto

O OWASP recomenda estabelecer e usar um ciclo de vida de desenvolvimento seguro (SDLC) com profissionais de segurança de aplicações (AppSec) para avaliar e projetar controles de segurança e privacidade, além de criar e utilizar uma biblioteca de padrões de projeto seguros. Essa é uma medida fundamental para prevenir vulnerabilidades de design.

Item II — ✅ Correto

Escrever testes unitários e de integração para validar que todos os fluxos críticos são resistentes ao modelo de ameaça, bem como compilar casos de uso e casos de uso incorreto (misuse cases) para cada camada do aplicativo, são práticas recomendadas pelo OWASP para garantir que o design seja robusto contra ameaças identificadas.

Item III — ❌ Incorreto

Embora unificar os controles de segurança em histórias de usuários seja uma prática válida, a afirmação de que as verificações de plausibilidade devem ser restritas ao time de design é equivocada. O OWASP preconiza que tais verificações sejam aplicadas em cada camada do aplicativo (frontend, backend, etc.) e não limitadas a um único time. Além disso, limitar o consumo de recursos por usuário ou serviço é uma recomendação de controle de acesso e resource management, mas não é uma medida primária de prevenção contra design inseguro — e a forma como foi redigida (restringir ao time de design) distorce a recomendação.

Prática

Item I

Item II

Item III

SDLC com AppSec

✅

—

—

Biblioteca de padrões seguros

✅

—

—

Testes unitários e de integração

—

✅

—

Casos de uso e abuso

—

✅

—

Unificar segurança em histórias

—

—

✅ (parcial)

Verificações em todas as camadas

—

—

❌ (restringe ao design)

Limitar recursos

—

—

❌ (incompleto)

Conclusão: Apenas os itens I e II estão corretos, correspondendo à alternativa B.

NÃO CAIA NESSA!

O item III mistura uma recomendação verdadeira (unificar controles em histórias de usuário) com uma distorcida (restringir verificações de plausibilidade ao time de design). O candidato pode ser levado a crer que todo o item é válido, mas a parte final invalida a assertiva. Memorize: as verificações de plausibilidade devem ser aplicadas em todas as camadas, não limitadas a um único time.

Gabarito: letra B.

Link permanente: /questoes/fg114861