Início do Bloco E. Foco: você responde perguntas de CISO sem improvisar, sabe avaliar maturidade de segurança do cliente, e identifica onde Team Studio precisa endurecer pra vender pra empresa com programa de segurança sério.
Pré-requisito: Semana 9 (autenticação) ajuda. Tempo estimado: 4-5 horas de leitura + 1 hora de exercício. Output prático: você sustenta reunião de 45 min com CISO sem virar passageiro e identifica 3 gaps de segurança em produto/operação típica.
Por que essa semana importa
Empresa de 200+ funcionários quase sempre tem CISO (Chief Information Security Officer) ou pelo menos head de segurança. Antes de aprovar Team Studio, vão fazer security review que pode incluir: - Questionário de 50-100 perguntas - Pentest do produto (interno ou contratado) - Avaliação SOC 2 / ISO 27001 - Threat modeling - Análise de subprocessadores
Sem preparação, Team Studio é REPROVADO. Vira venda perdida que pareceu prestes a fechar.
Bônus: muita coisa de segurança que você aprende pra cliente, você aplica na própria operação. ROI duplo.
1. Zero Trust - paradigma moderno
Zero Trust é princípio que substitui "castelo com muros" por "verifica tudo, todo lado".
1.1 Modelo tradicional (perímetro)
Internet (perigosa)
↓ Firewall
Rede interna (confiável - tudo aqui dentro é amigo)
- Apps
- Bancos
- Funcionários
Problema: se atacante entrar no perímetro (phishing, VPN comprometida), ele anda livre.
Casos famosos: invasão da Target 2013 entrou via fornecedor de HVAC, andou pela rede interna por meses.
1.2 Modelo Zero Trust
Sem rede "interna confiável".
Todo acesso é verificado:
- Quem é o usuário? (identity)
- Em qual device? (device posture)
- O que tá tentando fazer? (context)
- Quais permissões tem? (authorization)
Cada request: nova validação.
Princípios: 1. Never trust, always verify 2. Assume breach (parta do princípio que já tem atacante dentro) 3. Least privilege access (mínimo necessário) 4. Verify explicitly (autentique cada request)
1.3 Como implementar Zero Trust na prática
Identity verification: SSO + MFA obrigatório em tudo.
Device posture: só dispositivos gerenciados pela empresa (corporate-managed) acessam. Endpoint security (Crowdstrike, Sentinel) reporta saúde.
Microsegmentation: rede interna dividida em segmentos. App A só acessa Banco A, não acessa Banco B.
Continuous verification: sessão expira frequentemente, re-autentica. Comportamento anômalo dispara MFA challenge.
Encryption everywhere: trânsito (TLS) e repouso (disco encriptado). Mesmo dentro da rede.
1.4 BeyondCorp (Google)
Google publicou paper em 2014 descrevendo seu modelo zero trust. Virou referência.
Características: - Sem VPN. Funcionários acessam apps via internet (com SSO + device cert) - Device é critical: cada laptop tem certificado. Sem cert válido, sem acesso. - Context-aware: localização, hora, comportamento influenciam decisão de acesso
Sinal de empresa moderna: tem zero trust formalizado, não usa VPN tradicional.
1.5 Pergunta de reunião
"Vocês implementam zero trust? Sem VPN, com identity como perímetro?"
Resposta revela maturidade. Empresa tradicional ainda usa VPN, empresa moderna implementou zero trust.
2. IAM avançado (Identity and Access Management)
IAM é como você organiza permissões. Conceitos chave:
2.1 RBAC (Role-Based Access Control)
Usuários são associados a roles. Roles têm permissões.
User: Ana
└─ Role: Manager
├─ permission: read_financial_reports
├─ permission: approve_expenses_up_to_5000
└─ permission: view_team_metrics
Vantagens: - Simples de entender - Auditoria clara - Funciona pra maioria dos casos
Desvantagens: - "Role explosion": muitas roles surgem pra casos específicos (Manager-Marketing-SP, Manager-Marketing-RJ, Manager-Tech-SP...) - Difícil expressar regras contextuais (manager pode aprovar em horário comercial)
2.2 ABAC (Attribute-Based Access Control)
Permissões baseadas em ATRIBUTOS de subject, object, action, environment.
Subject (usuário): Ana, role=Manager, dept=Marketing, region=SP
Object (recurso): Report, type=Financial, region=SP, classification=Internal
Action: read
Environment: time=09:00, day=Monday, location=office
Policy: Permitir read em Financial Report SE:
user.role == 'Manager' AND
user.region == report.region AND
user.dept == 'Marketing' AND
environment.time BETWEEN 08:00 AND 18:00
Vantagens: - Expressivo (qualquer combinação) - Escala melhor (não tem role explosion)
Desvantagens: - Mais complexo de implementar - Auditoria mais difícil - Performance pior (avalia muitos atributos)
2.3 PBAC (Policy-Based Access Control)
Evolução do ABAC. Políticas centralizadas em engine de política (OPA - Open Policy Agent).
# OPA Rego policy
allow {
input.user.role == "Manager"
input.action == "read"
input.resource.type == "financial_report"
input.user.region == input.resource.region
is_business_hours
}
is_business_hours {
time.now().hour >= 8
time.now().hour < 18
}
Vantagens: - Policies declarativas, versionadas em Git - Mesma engine pra múltiplos sistemas - Audit log natural
Quando usar: empresa grande com muitos sistemas e regras complexas.
2.4 Princípio do Menor Privilégio (PoLP)
CONCEITO MAIS IMPORTANTE de IAM. Cada usuário/serviço recebe SÓ as permissões mínimas pro trabalho.
Anti-padrão clássico: dev tem acesso root em produção "porque precisa de vez em quando". Padrão correto: dev acessa via just-in-time (pede acesso temporário quando precisa, expira em 1h).
Ferramentas: AWS IAM, HashiCorp Vault, CyberArk (enterprise), Teleport, Boundary.
Sinal de empresa madura: nenhuma pessoa tem acesso root permanente. Tudo é JIT + auditado.
3. OWASP Top 10 com exemplos
OWASP Top 10 é lista atualizada (a cada 3-4 anos) dos 10 riscos mais comuns em aplicações web. Versão atual (2021):
3.1 A01 - Broken Access Control
Mais comum hoje. Usuário acessa o que não deveria.
Exemplo: URL /api/orders/123 retorna order 123. Mas qualquer usuário logado pode acessar order de outro mudando ID pra /api/orders/456.
Mitigação: check de autorização EM CADA endpoint. Não confie em "usuário não vai descobrir".
3.2 A02 - Cryptographic Failures
Antes "Sensitive Data Exposure". Dados sensíveis sem proteção adequada.
Exemplos: - Senhas em texto puro no banco - Comunicação via HTTP (sem TLS) - Encriptação fraca (MD5, SHA1, DES) - Chave de encriptação commitada no Git
Mitigação: TLS 1.3, bcrypt/argon2 pra senhas, AES-256 pra dados, secrets manager.
3.3 A03 - Injection
SQL injection, NoSQL injection, command injection, etc.
Exemplo SQL Injection clássico:
-- Código vulnerável:
db.execute(f"SELECT * FROM users WHERE email = '{user_input}'")
-- Atacante envia: ' OR '1'='1
-- Query vira: SELECT * FROM users WHERE email = '' OR '1'='1'
-- Retorna TODOS os users.
Mitigação: prepared statements / parametrized queries. Nunca concatene input em query.
3.4 A04 - Insecure Design
Falha no design fundamental do sistema. Não é bug, é arquitetura errada.
Exemplos: - Não ter rate limit em endpoint de password reset - Permitir recuperar senha por perguntas secretas com respostas óbvias - Compartilhar mesma sessão entre usuários (multi-tenancy quebrada)
Mitigação: threat modeling no design, security review antes de implementar.
3.5 A05 - Security Misconfiguration
Configuração errada em servidor, framework, biblioteca.
Exemplos: - Headers de segurança ausentes (CSP, X-Frame-Options) - Diretório de admin acessível na URL padrão - Stack traces em erros expondo estrutura interna - Default credentials não mudadas
Mitigação: hardening checklists, security scanners no CI/CD.
3.6 A06 - Vulnerable and Outdated Components
Usar libraries com vulnerabilidades conhecidas.
Exemplo: Log4Shell (CVE-2021-44228) em Log4j permitiu RCE em milhares de sistemas globalmente.
Mitigação: dependabot/renovate (atualizações automáticas), SCA tools (Snyk, GitHub security scanning).
3.7 A07 - Identification and Authentication Failures
Autenticação fraca.
Exemplos: - Brute force em login (sem rate limit) - Senhas fracas aceitas - Reset de senha vulnerável - MFA opcional - Session fixation
Mitigação: rate limit, password policies, MFA obrigatório, rotação de tokens.
3.8 A08 - Software and Data Integrity Failures
Integridade comprometida na cadeia de suprimentos.
Exemplos: - Atualizações de software sem verificação de assinatura - Dependências baixadas sem checksum - Pickled data deserializado sem validar
Mitigação: Signed releases, SBOM (Software Bill of Materials), reproducible builds.
3.9 A09 - Security Logging and Monitoring Failures
Eventos de segurança não logados ou monitorados.
Exemplo: atacante teve acesso por 6 meses. Quando descoberto, logs já foram rotacionados. Forensics impossível.
Mitigação: log centralizado, retenção long-term, SIEM (Splunk, Datadog Security).
3.10 A10 - Server-Side Request Forgery (SSRF)
Atacante força servidor a fazer requests pra URLs internas.
Exemplo: feature "import imagem por URL" aceita http://169.254.169.254/latest/meta-data/ (metadata endpoint AWS) e retorna credenciais IAM da instância.
Mitigação: whitelist de hosts permitidos, validação de URL.
4. Threat Modeling - STRIDE
Threat modeling é exercício de "como alguém ataca isso?" feito ANTES de construir.
4.1 STRIDE (Microsoft)
Framework pra identificar ameaças. Cada letra é uma categoria:
- Spoofing (passar por outro): atacante finge ser usuário legítimo
- Tampering (alterar dado): modifica dado em trânsito ou repouso
- Repudiation (negar ação): "não fui eu que apaguei"
- Information Disclosure (vazamento): dados privados acessíveis
- Denial of Service (DoS): sistema fica indisponível
- Elevation of Privilege (escalada): usuário comum vira admin
4.2 Como aplicar
- Diagrama do sistema: Data Flow Diagram com componentes e interfaces
- Identificar trust boundaries: onde dado passa de zona menos confiável pra mais confiável
- Pra cada componente/interface: pensar nos 6 tipos STRIDE
- Priorizar: probabilidade × impacto = severidade
- Mitigar: implementar controles pros riscos mais severos
4.3 Exemplo simplificado
Sistema: app Team Studio que recebe webhook do Stripe.
STRIDE no webhook:
- S Spoofing: atacante manda webhook falso. Mitigação: validar HMAC com chave do Stripe.
- T Tampering: atacante intercepta e modifica. Mitigação: HTTPS obrigatório.
- R Repudiation: Stripe nega ter enviado. Mitigação: webhook IDs únicos, audit log com timestamp Stripe-signed.
- I Disclosure: payload contém dado sensível em log. Mitigação: log filtra fields sensíveis.
- D DoS: atacante envia 10k webhooks/seg. Mitigação: rate limit por origem, queue assíncrona.
- E Elevation: webhook handler escala privilégio. Mitigação: handler roda com perm mínima, não acessa dados não relacionados.
Exercício de 30 min que identifica 5-10 mitigações concretas.
5. Pentest - testando ofensivamente
Pentest (penetration test) é teste autorizado de invasão.
5.1 Tipos
Black box: pentester não recebe info. Simula atacante externo. - Realista - Demora mais (precisa fazer reconhecimento) - Pode perder vulnerabilidades de código
White box: pentester tem acesso completo (código, arquitetura, credenciais). - Mais profundo - Mais rápido - Menos realista
Gray box: mistura. Pentester tem ALGUMAS info (como usuário comum tem). - Equilíbrio bom - Mais comum em pentests anuais
5.2 Como funciona
Empresa contrata pentester (interno ou externo, geralmente externo pra independência).
1. Escopo: o que pode atacar (apps, IPs, contas)
2. Regras: o que NÃO pode fazer (DoS, social engineering, leak)
3. Janela: período específico (geralmente 1-2 semanas)
4. Reconhecimento: pentester estuda o alvo
5. Exploitation: tenta vulnerabilidades
6. Post-exploitation: se entrou, escala privilégios
7. Reporting: documenta tudo encontrado
8. Remediation: empresa corrige, pentester re-testa
5.3 Frequência
- Anual (mínimo): pra empresa séria
- Trimestral: pra empresa SaaS B2B grande
- Por feature crítica: novo módulo de pagamento, autenticação, etc
5.4 Pentest é diferente de bug bounty
Bug bounty (HackerOne, Bugcrowd): empresa publica programa aberto. Hackers em todo mundo procuram, ganham por bug encontrado. Custo: variável (US$ 50-50k por bug).
Quando usar: - Pentest: avaliação periódica controlada - Bug bounty: descoberta contínua
Empresas maduras usam AMBOS.
5.5 SAST, DAST, SCA - testes automatizados
- SAST (Static Application Security Testing): analisa CÓDIGO sem executar. Encontra padrões inseguros.
- DAST (Dynamic Application Security Testing): testa APP RODANDO. Simula ataques.
- SCA (Software Composition Analysis): analisa DEPENDÊNCIAS. Encontra libs vulneráveis.
Ferramentas: Snyk, Veracode, GitHub Advanced Security, Sonar.
CI/CD maduro tem os 3.
6. Supply chain attacks
Categoria que explodiu desde 2020. Atacante compromete fornecedor, infiltra clientes via update legítimo.
6.1 Casos famosos
SolarWinds (2020): atacante comprometeu update do Orion (software de monitoramento). 18.000 empresas (incluindo governo US) baixaram update malicioso.
Codecov (2021): bash uploader modificado pra exfiltrar secrets do CI/CD de milhares de empresas.
Log4Shell (2021): vulnerabilidade em Log4j (lib amplamente usada) permitiu RCE em milhões de servers.
xz-utils (2024): backdoor sutil inserido em lib de compressão amplamente usada. Quase chegou em distros Linux estáveis.
6.2 Por que importam
Você pode ter app seguro, autenticação certa, MFA em tudo. Mas se uma dependência (de uma dependência) for comprometida, atacante entra.
6.3 Mitigações
- SBOM (Software Bill of Materials): catalogo de TODAS as dependências (diretas + transitivas)
- Dependency pinning: versão exata, não "latest"
- Reproducible builds: build sempre dá o mesmo binário
- Code signing: artefatos assinados, verificado antes de instalar
- Sigstore: ecossistema open source pra signing
- Renovate/Dependabot: atualizações automatizadas (mas review humano)
Sinal de empresa madura: tem SBOM, faz signing, monitora supply chain.
7. Como Team Studio se posiciona em segurança
Quando vender pra empresa séria, você vai ser AVALIADO. Coisas concretas que esperam:
7.1 Postura mínima viável
- Senha forte + MFA em TUDO da operação Team Studio
- Secrets em Vault/Secrets Manager (não .env)
- TLS 1.3 em comunicações
- Logs centralizados com retenção mínima 1 ano
- Backup encriptado e testado
- Política de privacidade pública (já temos)
- DPA template (já temos)
- Lista de subprocessadores (já temos)
7.2 Postura "empresa B2B média"
Tudo acima + - Pentest anual (por empresa especializada) - SAST/DAST/SCA no CI/CD - Compliance SOC 2 Type 1 (caminho pra Type 2) - Threat modeling documentado de features críticas - Incident response plan - Audit log de TODAS as ações administrativas - RBAC interno (não admin pra tudo)
7.3 Postura "enterprise grande"
Tudo acima + - SOC 2 Type 2 - ISO 27001 - Bug bounty program - Dedicated security team (ou SOC terceirizado) - Zero Trust full implementation - Customer-managed encryption keys (BYOK) - Pode passar por questionário SIG Lite/Core - Single-tenant deployment opcional
Team Studio hoje está em "postura mínima viável". Caminho pra "B2B média" é claro, mas não é rápido: chegar até SOC 2 Type II leva ~24 meses (Type I em ~12, Type II em ~24) e custa na faixa de USD 130-250k no primeiro ciclo (ferramenta GRC, consultoria, auditoria, tempo). Detalhamento na Semana 11.
7.4 Pergunta de reunião
"Qual o nível de compliance que vocês exigem? Vocês têm SOC 2? Aceitam fornecedor sem SOC 2?"
Resposta define se Team Studio precisa investir em compliance pra fechar venda.
8. Cinco perguntas que destravam reunião com CISO
8.1 "Vocês usam zero trust ou perímetro tradicional?"
Por que importa: revela maturidade. Tradicional = mais difícil pra Team Studio integrar (precisa VPN).
8.2 "Quem decide aprovar fornecedor novo? Como funciona o vendor assessment?"
Por que importa: descobre stakeholder real. Geralmente CISO + procurement + legal + business sponsor.
8.3 "Qual o nível de compliance que vocês exigem? SOC 2, ISO 27001, outro?"
Por que importa: define se Team Studio precisa investir.
8.4 "Como vocês fazem pentest? Interno, externo, bug bounty?"
Por que importa: empresa madura tem programa estruturado.
8.5 "Qual o protocolo de incidente? Quem comunica em caso de breach?"
Por que importa: define o que Team Studio precisa estar preparado pra reportar e quando.
9. Exercício prático
Cenário: cliente Team Studio em discovery. Banco digital médio (R$ 5B em depósitos), 800 funcionários, regulado pelo Bacen. Diz:
"Pra qualquer fornecedor entrar na nossa stack, precisamos avaliar com nosso CISO. Vocês conseguem responder questionário SIG Lite? Aceita pentest da nossa equipe interna? Tem SOC 2 Type 2?"
Pratique: 1. Liste 5 perguntas pra entender escopo real do que esperam 2. Identifique 3 áreas onde Team Studio atual ESTÁ pronto 3. Identifique 3 áreas onde Team Studio NÃO está pronto e estimativa pra ficar 4. Decida: vale ir atrás do contrato? Como precificar pra cobrir investimento de compliance?
(Sugestões no fim.)
10. Material extra
Leitura essencial: - "OWASP Top 10" (atualizado a cada 3 anos) - leitura obrigatória - "BeyondCorp" paper (Google) - fundação do zero trust - "Threat Modeling: Designing for Security" (Adam Shostack) - "Awesome Security" no GitHub - lista curada de recursos
Frameworks/Compliance pra estudar: - SOC 2 Trust Services Criteria - ISO 27001 - NIST Cybersecurity Framework - CIS Controls
Vídeos: - DefCon, BlackHat talks (gratuitos no YouTube) - palestras de pesquisadores top - "Security Now" podcast (Steve Gibson)
Hands-on (3 horas): - HackTheBox ou TryHackMe: plataformas pra praticar segurança ofensiva legalmente - Configure scanner SAST grátis (Semgrep) num repo seu - Configure Snyk free tier pra dependency scanning
11. Sugestões pro exercício prático
5 perguntas pra entender escopo:
- "SIG Lite tem 100 perguntas, SIG Core tem 1000+. Qual exatamente vocês exigem? E qual frequência (anual)?"
- "O pentest interno é black box? Quanto tempo de janela? Pode ter resultado em PR ou só relatório?"
- "SOC 2 Type 2: precisa antes de assinatura ou pode comprometer caminho pra X meses?"
- "Quais sistemas de vocês Team Studio vai tocar? Core bancário ou só periférico? Define risco proportional."
- "Quem é o sponsor business desse projeto? Sem ele empurrando, security review pode demorar 6 meses."
3 áreas onde Team Studio está pronto:
- Política de privacidade + LGPD básico: política pública, DPA template, lista de subprocessadores. Coberto.
- Autenticação + secrets básico: SSO funcionando, MFA obrigatório, secrets em variáveis (não código). Não é Vault mas é decente.
- HTTPS + encriptação em trânsito: TLS 1.2/1.3 em tudo. Coberto.
3 áreas NÃO prontas:
- SOC 2 Type II: ~24 meses pra obter (Type I + observation window + audit). Custo USD 130-250k no primeiro ciclo (GRC + auditor + tempo). Sem isso, banco digital provavelmente reprova.
- Pentest anual com remediation tracking: Team Studio não tem ainda. Custo 15-30k USD/ano.
- Secrets management profissional (Vault): hoje secrets em .env. Migrar pra Vault ou AWS Secrets Manager: 2-4 semanas de trabalho, US$ 100-500/mês de operação.
Decisão estratégica:
Banco digital é cliente de "postura enterprise grande". Investimento total pra ser aprovado: 100-200k USD + 6-12 meses.
Vale ir atrás SE: - Contrato projetado é R$ 500k+/ano (cobre investimento em 12 meses) - Banco é "anchor customer" que abre portas pra outros (caso de uso pra venda) - George tem fôlego financeiro pra 6-12 meses de investimento antes de retorno
Não vale SE: - Contrato é R$ 100k/ano (não cobre investimento) - Team Studio ainda tá validando produto-mercado fit - Risco de rejeitar depois de 6 meses gastos é alto
Recomendação prática: começar com clientes médios (sem CISO formal) primeiro. Crescer pra enterprise quando tiver track record + fluxo de caixa pra suportar compliance.
12. Próxima semana
A Semana 11 fecha o Bloco E (Segurança e Compliance) com LGPD/GDPR avançado, SOC 2, ISO 27001 e auditoria de cliente grande: LGPD em detalhe (DPO, comunicação à ANPD, direitos do titular, transferência internacional Art 33), GDPR (Schrems II, Standard Contractual Clauses), SOC 2 Type I vs II, ISO 27001:2022 com 93 controles Annex A, HIPAA, Vendor Security Review com CAIQ e SIG, data residency vs sovereignty. 8 princípios não-negociáveis Team Studio + roadmap SOC 2 18 meses + exercício cliente brasileiro com filial europeia.