CompTIA SecurityX — Questões de prática e simulado

No AWS Shared Responsibility Model, a AWS cuida da segurança "da" nuvem (infraestrutura física, hipervisor, rede global), enquanto os clientes cuidam da segurança "na" nuvem (AWS Shared Responsibility Model, aws.amazon.com/compliance/shared-responsibility-model). Security groups (stateful, no nível da instância) e NACLs (stateless, no nível da subnet) são sempre controles de rede configurados pelo cliente, independentemente do modelo de serviço. Por que não as outras? A segurança física do data center é uma obrigação central da AWS. A infraestrutura de rede global é gerenciada pela AWS. Aplicar patches no hipervisor é responsabilidade da AWS conforme a fronteira de IaaS. Essa fronteira muda conforme o modelo de serviço: EC2 (IaaS) dá mais responsabilidade ao cliente; Lambda (serverless) dá menos. Segundo o AWS Well-Architected Security Pillar, qualquer decisão de configuração sobre as cargas de trabalho do cliente cabe ao cliente. Ref: AWS Shared Responsibility Model; AWS Well-Architected Security Pillar; NIST SP 800-145.

Classifique pelo mecanismo de entrega, não pela história construída em volta dele. Um adversário que envia mensagens para obter acesso aos sistemas das vítimas está fazendo phishing, e a classe cobre explicitamente anexos e links maliciosos, além de se passar por uma fonte confiável. Passar-se por um fornecedor é um refinamento de alvo que torna a mensagem mais convincente, mas não muda qual é a técnica.

Os distratores pertencem a etapas posteriores ou a objetivos diferentes. Abusar de credenciais existentes descreve um adversário que já tem acesso a uma conta válida, que é como uma intrusão continua e não como esta chega. Misturar o tráfego de comando a protocolos comuns de camada de aplicação é um comportamento de comando e controle que só importa depois que existe um ponto de apoio. Executar código dentro de outro processo é uma técnica de execução e evasão em um host que já foi comprometido.

Dica de prova: acertar a classificação importa porque as contramedidas são diferentes. A entrega é combatida com autenticação de mensagens, detonação de anexos e um caminho de denúncia para os usuários, enquanto o abuso de credenciais e a execução de código precisam de controles totalmente diferentes, então rotular a técnica errado te leva para a defesa errada.

Shadow IT é o uso de sistemas, dispositivos, softwares ou serviços em nuvem sem aprovação explícita da organização, criando risco não gerenciado e pontos cegos de governança. Aqui, o departamento de TI usou armazenamento em nuvem não aprovado — a definição de manual. Por que não os outros? Risco residual é o risco que sobra depois que os controles são aplicados, e pressupõe que existam controles. Risco inerente é o risco de base antes de qualquer controle, e não trata de uso não autorizado. Risco transferido envolve passar o risco a um terceiro por meio de seguro ou terceirização. O shadow IT compromete o inventário de ativos, a conformidade, a resposta a incidentes e a proteção de dados, porque as equipes de segurança não conseguem proteger o que não sabem que existe. Ele abre lacunas nas avaliações de risco, na aplicação de políticas e na conformidade regulatória. Ref: NIST CSRC Glossary (shadow_it); NIST SP 800-53 Rev 5 CM-8 (System Component Inventory); NIST CSF Identify function.

O certificate pinning vincula um certificado ou uma chave pública específicos ao servidor esperado de uma aplicação, complementando a validação padrão da cadeia TLS. O TLS padrão confia em qualquer CA presente no repositório do dispositivo; uma CA comprometida ou fraudulenta pode emitir certificados falsos e viabilizar a interceptação MITM. O pinning impede isso ao verificar se o certificado do servidor corresponde a um hash embutido previamente. Abordagens: pinning da folha (estrito), pinning da CA intermediária (flexível) ou pinning da chave pública (sobrevive à renovação do certificado). Por que não os outros? Ataques DoS miram a disponibilidade, não a autenticação. O XSS explora o DOM do navegador, sem relação com a segurança do transporte. A injeção de SQL mira a interpretação das consultas, não o TLS. Entre os riscos do pinning está a complexidade operacional durante a rotação de certificados; pins de backup são essenciais para evitar o bloqueio de acesso. Ref: OWASP Mobile Security Testing Guide (MSTG); OWASP Mobile Top 10 M3; RFC 7469 (HTTP Public Key Pinning).