Analista de Cibersegurança Perguntas de Entrevista & Respostas

Resposta modelo

Detectei tráfego de saída anômalo de uma estação de trabalho às 2h da manhã por meio dos alertas do nosso SIEM: 500 MB enviados para um IP desconhecido por um canal criptografado. Isolei a estação da rede imediatamente e iniciei a investigação. A análise de memória revelou um beacon do Cobalt Strike ativo há 3 dias, provavelmente instalado via e-mail de spear-phishing com uma macro maliciosa. Rastreei o movimento lateral para mais 2 estações de trabalho, nenhuma das quais havia acessado repositórios de dados sensíveis. Contive todos os sistemas afetados, redefiní as credenciais das contas comprometidas e coordenei com o time de segurança de e-mail para bloquear o domínio de phishing. O tempo total de contenção foi de 4,5 horas. Após o incidente, implementei políticas de bloqueio de macros no Office, adicionei regras de detecção comportamental para padrões de beaconing C2 e conduzi um treinamento direcionado de conscientização sobre phishing. Não houve novos incidentes daquele agente de ameaça.

Resposta modelo

Durante uma revisão de rotina da nossa aplicação web, percebi que o fluxo de redefinição de senha enviava um token por e-mail, mas o token não expirava após o uso. Testei e confirmei: o mesmo token de redefinição podia ser usado várias vezes por até 24 horas. O time de desenvolvimento tinha se concentrado em implementar a expiração do token por tempo, mas havia esquecido o requisito de uso único. Documentei a vulnerabilidade com uma prova de conceito clara mostrando como um atacante com acesso ao e-mail de alguém poderia usar um token antigo dias depois. Classifiquei como severidade média, pois exigia acesso ao e-mail, mas com urgência alta por ser uma correção simples. O time implantou uma correção de uma linha (invalidar o token após o uso) em 2 horas. Em seguida, revisei todos os outros fluxos baseados em token e encontrei um problema semelhante no fluxo de verificação de e-mail, corrigido na mesma sprint.

Resposta modelo

Queria implementar uma solução de gestão de acesso privilegiado (PAM) porque tínhamos mais de 40 contas de administrador compartilhadas sem trilha de auditoria. A gestão via isso como um gasto de US$ 60 mil sem ROI visível. Reencadrei a conversa: calculei o custo de uma violação por escalonamento de privilégios usando dados do setor (média de US$ 4,5 milhões para o porte da nossa empresa), multipliquei pela probabilidade estimada com base nos controles atuais e apresentei a perda esperada. Mostrei também 3 achados recentes de auditoria que apontavam credenciais compartilhadas como risco, o que poderia afetar nossa certificação SOC 2, um requisito de 70% dos nossos clientes enterprise. Por fim, apresentei o custo operacional: 15 horas mensais gastas na rotação manual de credenciais compartilhadas. A solução PAM se pagaria em economia de tempo de gestão de credenciais em 14 meses. A gestão aprovou. A lição: investimentos em segurança precisam ser apresentados em termos de risco de negócio e eficiência operacional, não de medo técnico.

Resposta modelo

Mantenho uma abordagem estruturada de inteligência de ameaças. Diariamente: reviso feeds curados da CISA, Krebs on Security e The Record. Semanalmente: dedico 2 horas a laboratórios práticos, como salas no TryHackMe, desafios no HackTheBox ou reprodução de exploits de CVEs recentes no meu laboratório caseiro. Mensalmente: participo do encontro local do capítulo OWASP e de um grupo online de compartilhamento de inteligência de ameaças com profissionais de segurança de 15 empresas. Trimestralmente: faço um curso focado. No último trimestre foi segurança em nuvem na AWS; neste trimestre é análise de malware com Ghidra. Quando surge uma vulnerabilidade importante (como a Log4Shell), avalio imediatamente nossa exposição, crio regras de detecção e apresento ao time. Essa abordagem já valeu a pena várias vezes: tive regras de detecção para a vulnerabilidade do MOVEit prontas em 6 horas após a divulgação porque acompanhava os TTPs do agente de ameaça pelos meus feeds de inteligência.

Resposta modelo

O MITRE ATT&CK é uma base de conhecimento de táticas, técnicas e procedimentos (TTPs) de adversários, organizada pelas fases do ciclo de vida de um ataque: acesso inicial, execução, persistência, escalonamento de privilégios, evasão de defesa, acesso a credenciais, descoberta, movimento lateral, coleta, exfiltração e comando e controle. Uso-o de três formas. Primeira, para engenharia de detecção: mapeio as regras de detecção do nosso SIEM para as técnicas do ATT&CK e identifico lacunas de cobertura. Quando percebo que não temos detecções para T1055 (Injeção de Processo), priorizo a criação dessas regras. Segunda, para caça a ameaças: uso o ATT&CK para estruturar buscas baseadas em hipóteses. Se a inteligência de ameaças indica que um grupo APT específico está mirando nosso setor, caço os TTPs documentados deles no nosso ambiente. Terceira, para investigação de incidentes: ao detectar uma técnica, o ATT&CK indica o que o adversário provavelmente fez antes e fará a seguir, ajudando a delimitar a investigação com mais eficiência.

Resposta modelo

A criptografia simétrica usa a mesma chave para criptografar e descriptografar: é rápida, mas exige uma troca segura de chaves. O AES-256 é o padrão. Exemplo real: criptografia de dados em repouso em um banco de dados. O servidor de aplicação mantém a chave e criptografa ou descriptografa os dados conforme lê e escreve. A criptografia assimétrica usa um par de chaves: a chave pública criptografa e a chave privada descriptografa. É mais lenta, mas resolve o problema de troca de chaves. RSA e ECDSA são algoritmos comuns. Exemplo real: o handshake TLS. Ao acessar um site, o navegador usa a chave pública do servidor para estabelecer uma chave de sessão compartilhada e depois passa para criptografia simétrica na transferência efetiva dos dados. Essa abordagem híbrida combina a segurança da criptografia assimétrica na troca de chaves com a velocidade da criptografia simétrica para dados em volume. Na prática, sempre recomendo AES-256 para dados em repouso, TLS 1.3 para dados em trânsito e gestão adequada de chaves por meio de serviços como AWS KMS, em vez de armazenar as chaves junto aos dados que protegem.

Resposta modelo

Seguiria um processo de investigação estruturado. Primeiro, escopo: identificar a fonte do alerta e os indicadores iniciais, como volume de dados incomum para um IP externo, padrões de tunelamento DNS ou acesso não autorizado a armazenamento em nuvem. Preservar as evidências imediatamente: tirar snapshot dos sistemas afetados, capturar logs de rede e registrar a linha do tempo. Segundo, análise: verificar nos logs do SIEM o histórico completo de atividades do usuário ou sistema de origem. Que dados foram acessados? Quando o comportamento anômalo começou? O IP de destino é conhecido como malicioso? Cruzar com alertas de DLP, logs de endpoint e logs de autenticação. Terceiro, determinação: isso é uma exfiltração real, uma transferência autorizada ou um falso positivo? Consultaria o dono dos dados e o gestor do usuário antes de escalar. Quarto, se confirmado como malicioso: isolar os sistemas afetados, desativar as contas comprometidas, bloquear o canal de exfiltração e iniciar o plano de resposta a incidentes, incluindo notificação jurídica e de conformidade. Quinto, documentar tudo no sistema de rastreamento de incidentes com linha do tempo, evidências e cadeia de custódia. Os primeiros 30 minutos são críticos: a velocidade de contenção tem relação direta com o volume de dados perdidos.

Resposta modelo

O Zero Trust opera pelo princípio 'nunca confie, sempre verifique': sem confiança implícita baseada em localização de rede, dispositivo ou identidade do usuário. Cada solicitação de acesso é autenticada, autorizada e criptografada, independentemente de sua origem. Implementação em fases. Primeira fase, identidade: autenticação forte para todos os usuários (MFA obrigatório, de preferência resistente a phishing, como FIDO2). Implementar acesso de privilégio mínimo com provisionamento just-in-time. Segunda fase, dispositivo: garantir que os dispositivos atendam aos requisitos de segurança (SO atualizado, proteção de endpoint, criptografia) antes de conceder acesso. Usar avaliação de postura do dispositivo em cada conexão. Terceira fase, rede: microssegmentação para limitar o movimento lateral. Substituir a VPN por proxies com reconhecimento de identidade (como BeyondCorp ou Zscaler) que concedem acesso por aplicação. Quarta fase, dados: classificar os dados, criptografar em repouso e em trânsito e implementar controles de DLP. Quinta fase, monitoramento: verificação contínua. Monitorar o comportamento durante toda a sessão, não apenas no momento do login. Comportamento anômalo aciona reautenticação ou revogação de acesso. Implementaria isso de forma incremental, começando pelos sistemas mais sensíveis e expandindo ao longo de 12 a 18 meses.

Resposta modelo

Trataria isso com cuidado, porque pode ser desde uma configuração incorreta inocente de controle de acesso até uma ameaça interna intencional. Primeiro, verificaria o achado silenciosamente: confirmaria a precisão dos logs de acesso, verificaria se o cargo do funcionário mudou recentemente (alteração de cargo sem atualização de acesso é comum) e determinaria quais dados foram acessados. Não alertaria o funcionário. Segundo, escalaria para o meu gestor de segurança e o RH com evidências documentadas: o que foi acessado, quando, com que frequência e se algum dado foi baixado ou transferido externamente. Terceiro, com base na orientação deles, trabalharia com a TI para restringir o acesso silenciosamente (se parece um problema de controle de acesso) ou implementaria monitoramento aprimorado se houver suspeita de ameaça interna. Preservaria todas as evidências caso o assunto tome um rumo jurídico. O essencial é a resposta proporcional: tratar como ameaça interna o que é apenas uma política de RBAC quebrada cria drama desnecessário e corrói a confiança.

Resposta modelo

Ações imediatas (primeira hora): avaliar nossa exposição. O componente vulnerável está acessível pela internet? A quais dados ele tem acesso? Há um exploit conhecido em circulação? Se estamos ativamente exploráveis, implementaria mitigações de emergência: regras de WAF para bloquear padrões de exploit conhecidos, restrições de rede para limitar o acesso ao serviço vulnerável e desativação do recurso afetado se o impacto no negócio for aceitável. Curto prazo (primeiro dia): implementar monitoramento para os indicadores de exploração específicos, aumentar a verbosidade dos logs do sistema afetado e buscar sinais de exploração passada. Comunicação: informar a liderança de segurança e os responsáveis pelo sistema com uma avaliação clara de risco e status das mitigações. Médio prazo: aplicar o patch do fornecedor assim que estiver disponível, com ele pré-preparado e testado em staging para implantação em horas após o lançamento. Se nenhum patch surgir em uma semana, avaliar migração para uma alternativa ou alterações arquiteturais para isolar o risco. Durante todo o processo: registrar a vulnerabilidade no registro de riscos com os controles compensatórios documentados.

Resposta modelo

Conduziria uma avaliação estruturada de risco de fornecedor. Primeiro, classificação de dados: quais dados de clientes a ferramenta processará? PII, dados financeiros, dados de saúde? Isso determina os requisitos regulatórios (LGPD, GDPR, HIPAA, PCI-DSS). Segundo, postura de segurança do fornecedor: solicitar o relatório SOC 2 Tipo II, a certificação ISO 27001 e os resultados de testes de penetração. Revisar as práticas de criptografia de dados (em repouso e em trânsito), controles de acesso e capacidades de resposta a incidentes. Terceiro, revisão técnica: como funciona a integração? OAuth ou autenticação por senha? Quais permissões de API são necessárias? Onde os dados são armazenados geograficamente (relevante para a LGPD e o GDPR)? É possível aplicar SSO e MFA? Quarto, revisão contratual: acordo de processamento de dados, prazo de notificação de violação, cláusulas de propriedade e exclusão de dados e direito de auditoria. Pontuaria o fornecedor em uma matriz de risco e apresentaria uma recomendação: aprovar, aprovar com condições (requisitos específicos de segurança) ou rejeitar com alternativas. Se aprovado com condições, definiria uma data de revisão para verificar se as condições foram atendidas.

Resposta modelo

Escalaria o risco de forma clara, sem ser confrontador. Apresentaria o achado com uma avaliação concreta de risco: a severidade da vulnerabilidade (pontuação CVSS), a explorabilidade (existe um exploit público? é remotamente explorável?), os dados em risco e o impacto estimado no negócio em caso de violação. Proporia controles compensatórios para o período interim: segmentação de rede para limitar a exposição, regras de WAF para bloquear padrões de ataque conhecidos, monitoramento e alertas aprimorados para tentativas de exploração e redução das permissões de acesso. Trabalharia com o responsável pelo sistema para entender por que o patch leva 3 meses: às vezes o prazo é real (janelas de mudança regulatórias, dependências complexas); às vezes é apenas inércia de agenda. Se os controles compensatórios conseguirem reduzir o risco a um nível aceitável, documentaria o risco residual aceito com aprovação do responsável pelo sistema e sua gestão. Se o risco for verdadeiramente crítico e nenhum controle compensatório for suficiente, escalaria ao CISO com uma recomendação clara. Isso passa a ser uma decisão de negócio, não apenas técnica.