Por que não fazer pentest com a mesma empresa do SOC?

Na cibersegurança, existe um princípio básico herdado da auditoria: quem opera não deve auditar ou testar a si mesmo. Ainda assim, muitas empresas caem na armadilha de contratar o mesmo fornecedor para operar o seu SOC (Security Operations Center) e, ao mesmo tempo, realizar os testes de penetração (pentests).

À primeira vista, essa decisão parece prática. Afinal, se a empresa já conhece o ambiente, não faria sentido otimizar tempo e custos e deixá-la também conduzir os testes? Na realidade, esse modelo abre brechas perigosas, e pode levar a uma falsa sensação de segurança.

Conflito de interesse: o problema invisível

Quando a mesma empresa executa o monitoramento (SOC) e o teste ofensivo (pentest), cria-se um conflito de interesse. É o chamado risco de auto-revisão: o fornecedor que gerencia os controles pode deixar de expor falhas que ele próprio deveria ter corrigido. Não por má-fé, mas por viés de familiaridade, excesso de confiança ou mesmo pela tendência natural de minimizar pontos sensíveis.

Isso significa que vulnerabilidades críticas podem continuar invisíveis, enquanto relatórios transmitem a sensação de que “tudo está sob controle”.

Exemplos práticos de falhas não detectadas

Regras silenciadas no SIEM: para reduzir falsos positivos, algumas regras podem ter sido desativadas. No pentest conduzido pela própria operação, é improvável que esses pontos sejam devidamente explorados.

Bypass de EDR conhecido: analistas que trabalham diariamente com uma solução conhecem suas limitações. No teste interno, tendem a não reproduzir esses cenários.

Configurações normalizadas: permissões excessivas em nuvem, erros de MFA ou brechas de identidade muitas vezes são vistas como “parte da rotina”. O olhar externo é justamente o que consegue encadear essas falhas até um movimento lateral ou acesso privilegiado.

Relatórios de equipes de red team (como os da CISA nos EUA) reforçam que mesmo em organizações com SOC avançado, brechas passam despercebidas até que um time independente as explora.

O que dizem os padrões de mercado

PCI DSS v4.0 (Requisito 11.3.1): exige que o testador seja qualificado e independente do ambiente avaliado.

Guia de Pentest do PCI SSC: recomenda regras de engajamento claras e separação de funções.

ISO/IEC 27001 (Anexo A 5.3): destaca a necessidade de segregação de funções para reduzir erros e conflitos de interesse.

IIA (Instituto de Auditores Internos): define independência como liberdade de condições que ameacem a imparcialidade, alertando para o risco de auto-revisão.

NIST SP 800-115: descreve o pentest como simulação de ataque real, que exige visão crítica e separada da operação defensiva.

Em resumo: o consenso das normas é claro: quem defende não deve ser o mesmo que ataca.

A boa prática: independência com colaboração

O modelo mais seguro é separar papéis:

O SOC/MDR continua responsável pela defesa e monitoramento.

O pentest é feito por uma equipe independente, que simula ataques reais sem viés.

Após o teste, pode haver um exercício de purple teaming, em que ofensiva e defensiva trabalham juntas para transformar achados em melhorias de detecção e resposta.

Assim, garante-se independência sem perder a integração dos resultados.

A posição da Setrix

Na Setrix, acreditamos que pentest precisa ser independente para ter valor real. Nossa equipe utiliza metodologias reconhecidas (NIST, OWASP) e entrega relatórios com provas de conceito, cadeia de exploração e recomendações práticas. E, quando o cliente deseja, transformamos esses achados em exercícios de purple teaming junto ao SOC, sempre mantendo a separação de funções.

Porque em segurança, não basta vigiar o castelo: é preciso testá-lo com ataques de verdade, e de fora.

Fontes

PCI DSS v4.0 – Requisito 11.3.1 Define a exigência de independência do testador e periodicidade de pentests.

PCI SSC – Penetration Testing Guidance (Information Supplement, 2017). Recomenda metodologias, regras de engajamento e independência em testes.

ISO/IEC 27001:2022 – Annex A 5.3 (Segregation of duties). Reforça a segregação de funções para reduzir conflitos de interesse.

IIA – Definition of Internal Auditing e Standard 1100. Define independência e objetividade, incluindo risco de auto-revisão.

NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment. Guia técnico do NIST para condução de avaliações de segurança ofensivas.

CISA – Red Team Assessments. Relatórios públicos com achados de falhas de detecção e resposta em infraestruturas críticas.