Introdução
Esta Live 02 organiza referências que apoiam decisões diferentes. Security by Design, Privacy by Design, PCI DSS, Common Weakness Enumeration (CWE), OWASP, AWS Well-Architected e CIS Benchmarks não são nomes concorrentes para a mesma coisa.
Cada referência possui finalidade, escopo e limitações. A arquitetura madura seleciona o instrumento pelo problema, registra como ele será aplicado e preserva a gestão contínua de riscos.
Objetivos de aprendizagem
- Distinguir Security by Design de Privacy by Design e combiná-los no ciclo do produto.
- Relacionar ameaça, vulnerabilidade, probabilidade e impacto sem criar uma fórmula universal.
- Escolher entre PCI DSS, CWE e projetos OWASP conforme a necessidade.
- Aplicar threat modeling e diferenciar framework arquitetural de benchmark de hardening.
Security by Design
Security by Design incorpora proteção de sistemas, dados e ativos desde a definição da solução. O objetivo é encontrar riscos enquanto fluxos, limites e responsabilidades ainda podem ser alterados com menor custo.
O desenho deve combinar:
- Identificação antecipada de ativos e riscos.
- Threat modeling e cenários de abuso.
- Controles preventivos e menor privilégio.
- Defesa em profundidade e segmentação.
- Controles de detecção e evidências úteis.
- Resposta coordenada e contenção.
- Recuperação testada e aprendizagem.
Prevenção reduz a chance ou o alcance de um incidente. Detecção reconhece sinais. Resposta contém e investiga. Recuperação restaura capacidades e valida integridade. As quatro dimensões precisam ser desenhadas, implementadas e testadas.
Uma decisão tomada cedo pode separar funções administrativas, reduzir dados sensíveis, criar trilha de auditoria e definir trust boundaries. Adicionar essas propriedades após o sistema estar em produção pode exigir mudança de contratos, dados e operação.
Privacy by Design
Privacy by Design incorpora proteção dos interesses e direitos das pessoas ao desenho do tratamento de dados. A primeira pergunta não é “como criptografar tudo?”, mas “quais dados são necessários, para qual propósito e por quanto tempo?”.
Princípios práticos incluem:
- Minimização de dados e limitação de propósito.
- Retenção compatível com necessidade e obrigação.
- Transparência sobre tratamento e decisões.
- Suporte aos direitos do titular conforme o contexto aplicável.
- Controle de acesso e segregação.
- Mascaramento e tokenização quando adequados.
- Criptografia em trânsito e em repouso.
- Avaliação de impacto à privacidade desde o início.
Mascaramento reduz exposição em interfaces ou ambientes; tokenização substitui um valor por um token sob um sistema controlado; criptografia protege dados por algoritmo e chave. Nenhuma técnica autoriza uma finalidade inexistente ou corrige retenção indefinida.
Complementares, mas não equivalentes
| Pergunta | Security by Design | Privacy by Design |
|---|---|---|
| Foco principal | Proteger sistemas, dados e ativos contra ações indevidas | Reduzir impactos do tratamento de dados sobre pessoas |
| Ponto de partida | Ativos, ameaças, vulnerabilidades e controles | Finalidade, necessidade, ciclo do dado e direitos |
| Exemplo de decisão | Separar função admin e detectar elevação de privilégio | Não coletar documento quando uma confirmação basta |
| Falha que a outra não corrige | Controle de acesso forte não justifica coleta excessiva | Minimização não substitui autorização e resposta |
Desafio de decisão
Qual mudança trata Security by Design e Privacy by Design em conjunto?
Um cadastro coleta documento completo para apenas confirmar maioridade e o expõe a todos os atendentes.
A recomendação considera apenas este contexto; mudanças nas restrições podem mudar a decisão.
Risco como relação contextual
Uma avaliação relaciona:
ameaça + vulnerabilidade + probabilidade + impacto → avaliação de riscoEssa expressão é um mapa de raciocínio, não uma fórmula matemática universal. Métodos diferentes usam escalas, pesos e critérios próprios.
O registro precisa descrever cenário, ativo, evidências, controles existentes, hipóteses e incertezas. Risco residual é o risco que permanece após o tratamento escolhido; ele deve ter responsável e condição de revisão.
Pagamentos e PCI DSS
O PCI Security Standards Council (PCI SSC) mantém padrões de segurança para o ecossistema de pagamentos. O Payment Card Industry Data Security Standard (PCI DSS) estabelece requisitos técnicos e operacionais de base para proteger dados de conta de pagamento.
O escopo inclui sistemas que armazenam, processam ou transmitem dados aplicáveis e também componentes que podem afetar a segurança do ambiente de dados de pagamento.
Segmentação pode reduzir escopo quando é efetiva e verificada. Menor exposição de dados também reduz superfície: evitar armazenamento desnecessário costuma ser mais forte do que ampliar controles ao redor de cópias que não precisavam existir.
Controles precisam produzir evidências. Configurações, revisões de acesso, logs, testes e resultados de monitoramento demonstram operação ao longo do tempo.
PCI DSS não é uma certificação genérica de que toda a empresa ou aplicação é segura. Tampouco oferece garantia absoluta. A organização continua responsável por escopo correto, funcionamento dos controles, monitoramento e gestão contínua de riscos.
Decisão por cenário
Cenário: nova aplicação de pagamentos
O time pretende armazenar dados de conta em vários serviços para facilitar relatórios. Qual decisão reduz risco e escopo?
CWE, CVE e OWASP
CWE é um vocabulário e catálogo de tipos de fraqueza em software e hardware. Uma entrada pode descrever ausência de autorização, SQL Injection ou uso de algoritmo criptográfico arriscado.
Common Vulnerabilities and Exposures (CVE) identifica uma vulnerabilidade específica em um produto ou versão. Diversas CVEs podem compartilhar a mesma fraqueza de origem mapeada em CWE.
OWASP é um ecossistema de projetos, padrões, ferramentas e referências voltado à segurança de software. O OWASP Top 10 de aplicações web é uma porta de entrada, não o conjunto inteiro.
| Referência | Unidade descrita | Exemplo de uso |
|---|---|---|
| CWE | Tipo de fraqueza | Classificar a causa “Missing Authorization” |
| CVE | Vulnerabilidade específica | Verificar se uma versão de dependência é afetada |
| OWASP Top 10 | Categoria de risco e conscientização | Organizar revisão de riscos de aplicação web |
Verifique seu entendimento
CWE, CVE e OWASP Top 10 são listas equivalentes com identificadores intercambiáveis.
Resposta: Falso. CWE descreve tipos de fraqueza, CVE identifica vulnerabilidades específicas e o OWASP Top 10 organiza categorias de risco e conscientização.
O ecossistema OWASP
Projetos diferentes atendem superfícies diferentes:
- OWASP Top 10: riscos de aplicações web.
- OWASP API Security: riscos e práticas específicos de APIs.
- OWASP Mobile Application Security: padrões, fraquezas e testes para aplicações móveis.
- OWASP Top 10 for Business Logic Abuse: abuso de estados, transições e regras de negócio.
- OWASP GenAI Security Project: segurança e uso responsável em aplicações de inteligência artificial generativa.
Uma aplicação de pagamentos móvel com API e componente de IA pode precisar de várias lentes. Usar a lista web isoladamente deixaria aspectos relevantes sem linguagem adequada.
Threat modeling começa cedo
Threat modeling funciona melhor antes de contratos e fronteiras se tornarem caros de alterar. O modelo evolui com o sistema; não é um diagrama produzido uma única vez para auditoria.
Um fluxo prático inclui:
- Identificar ativos e objetivos de proteção.
- Desenhar componentes e fluxos de dados.
- Marcar trust boundaries, ou fronteiras onde confiança e controles mudam.
- Identificar ameaças e cenários de abuso.
- Relacionar vulnerabilidades e controles existentes.
- Definir prevenção, detecção, resposta e recuperação.
- Priorizar tratamento e registrar risco residual.
Attack trees decompõem um objetivo adversário em caminhos. Elas ajudam a comparar controles em diferentes ramos, mas não garantem cobertura completa.
Deslize horizontalmente para explorar o diagrama em telas menores.
O Microsoft Threat Modeling Tool apoia criação e análise de modelos como parte do Security Development Lifecycle da Microsoft. O OWASP Threat Dragon cria diagramas, registra ameaças e acompanha mitigações.
Ferramenta não substitui conversa, contexto ou decisão. O modelo precisa refletir o sistema real, e os controles precisam chegar ao backlog, aos critérios de aceite e à operação.
Cloud, arquitetura e hardening
O AWS Well-Architected Security Pillar orienta decisões arquiteturais e trade-offs para workloads na AWS. Suas áreas incluem fundamentos de segurança, identidade e acesso, detecção e rastreabilidade, proteção de infraestrutura, proteção de dados, resposta a incidentes e segurança de aplicações.
O CIS Amazon Web Services Foundations Benchmark fornece recomendações de configuração desenvolvidas por consenso para fundamentos da plataforma AWS. Ele apoia hardening e verificação de configurações específicas.
O framework arquitetural pergunta se a workload possui capacidades e decisões coerentes. O benchmark verifica recomendações de configuração em um escopo definido. Um não substitui o outro.
| Aspecto | AWS Well-Architected Security Pillar | CIS AWS Foundations Benchmark |
|---|---|---|
| Natureza | Orientação arquitetural e operacional | Benchmark de configuração e hardening |
| Pergunta típica | Como a workload protege identidade, dados e resposta? | Esta configuração atende à recomendação definida? |
| Resultado | Riscos, trade-offs e plano de melhoria | Achados de conformidade por recomendação |
| Limite | Não configura a conta automaticamente | Não avalia toda lógica e arquitetura da aplicação |
Responsabilidade em cloud continua compartilhada. O provedor protege determinadas camadas; a organização permanece responsável por dados, identidades, aplicações e configurações conforme o serviço utilizado.
Mapa de referências
| Referência | Finalidade | Quando usar | O que não substitui |
|---|---|---|---|
| PCI DSS | Proteger dados de conta de pagamento com requisitos técnicos e operacionais | Ao armazenar, processar, transmitir ou afetar o ambiente aplicável | Gestão de riscos, escopo correto e segurança de todo o negócio |
| CWE | Nomear e relacionar tipos de fraqueza | Ao classificar causa, prevenção e detecção de um achado | CVE específica, risco contextual ou correção validada |
| OWASP | Fornecer projetos, padrões, ferramentas e guias de segurança de software | Ao orientar design, verificação, maturidade e testes por superfície | Política organizacional e threat model do produto |
| AWS Well-Architected Security Pillar | Avaliar decisões e capacidades de uma workload AWS | Em desenho e revisão arquitetural de cloud | Hardening prescritivo e requisitos regulatórios específicos |
| CIS AWS Benchmark | Verificar recomendações de configuração AWS | Em baseline, auditoria técnica e detecção de desvio | Arquitetura, regras de negócio e resposta a incidentes |
| Microsoft Threat Modeling Tool | Diagramar e analisar ameaças no SDL da Microsoft | Em sessões de modelagem compatíveis com o ecossistema da ferramenta | Conhecimento do sistema e execução dos controles |
| OWASP Threat Dragon | Registrar diagramas, ameaças e mitigações | Em modelagem colaborativa e documentação do risco | Priorização de negócio e validação da implementação |
Referências
- PCI Security Standards Council — PCI DSS — finalidade, público e documentação do padrão.
- MITRE CWE — Frequently Asked Questions — diferença entre fraqueza, vulnerabilidade, CWE e CVE.
- OWASP Projects — catálogo do ecossistema de projetos OWASP.
- OWASP API Security Project — riscos específicos de APIs.
- OWASP Mobile Application Security — MASVS, MASWE e MASTG.
- OWASP Top 10 for Business Logic Abuse — riscos de lógica e fluxo de negócio.
- OWASP GenAI Security Project — segurança de aplicações de IA generativa.
- Microsoft Threat Modeling Tool e OWASP Threat Dragon — ferramentas oficiais de modelagem.
- AWS Well-Architected Security Pillar — orientação arquitetural de segurança para workloads AWS.
- CIS Amazon Web Services Benchmarks — recomendações de configuração por consenso.
- NIST Privacy Framework — gestão de risco de privacidade.
Conclusão
Security by Design protege sistemas, dados e ativos; Privacy by Design reduz riscos do tratamento de dados para pessoas. As duas disciplinas se complementam, mas partem de perguntas diferentes.
PCI DSS, CWE, OWASP, ferramentas de threat modeling, AWS Well-Architected e CIS Benchmarks também possuem papéis distintos. A escolha correta depende do ativo, do fluxo, da ameaça, da obrigação e da decisão que precisa ser sustentada.
Revisão do artigo
Pontos principais
- — Security by Design e Privacy by Design tratam riscos complementares, mas diferentes.
- — Cada padrão, catálogo, framework e ferramenta possui escopo e limite próprios.
- — Threat modeling transforma ativos e fluxos em controles verificáveis e risco residual explícito.