Os adversários adoram dificultar a vida dos defensores. Uma das melhores maneiras para os atacantes operarem sem serem detectados é desativar as ferramentas de segurança em um dispositivo de comprometimento.
Às vezes, os usuários fazem o trabalho pesado por eles. Quando um usuário frustrado desativa um serviço de segurança que parece estar atrapalhando seu trabalho, ele cria a mesma oportunidade para os invasores. O mesmo acontece com ações não intencionais, como uma atualização malsucedida.
Infelizmente, muitos profissionais de segurança também deixam de verificar se as ferramentas de segurança críticas estão em execução, criando assim um ponto cego evidente. A maioria das organizações depende de verificações periódicas de conformidade, o que deixa essas lacunas totalmente abertas entre as auditorias. Com muita frequência, uma organizações só descobre se as ferramentas de segurança estavam em execução após um comprometimento, quando já é tarde demais.
Por isso, estamos entusiasmados em apresentar verificações avançadas de postura ao cliente Okta Verify para macOS e Windows. Esse recurso transforma cada fluxo de autenticação em um mecanismo de vigilância persistente de ferramentas. Ao executar uma consulta SQL do osquery no momento em que uma conta tenta se autenticar, os administradores podem verificar se as ferramentas de segurança obrigatórias não apenas estão implantadas, mas também estão em execução ativa. Se não houver defesas, o dispositivo não consegue entrar.
A seguir, veremos como aproveitar esse recurso, mas primeiro vamos entender por que ele é importante.
A lacuna que se esconde à vista de todos
A maioria das organizações possui uma lista bem definida de ferramentas que cada endpoint gerenciado deve ter, desde agentes EDR até dispositivos MDM e muito mais. Embora o conjunto exato de ferramentas varie de uma organização para outra, cada categoria de ferramenta de segurança serve a um propósito consistente que é crucial para um ambiente bem protegido.
O problema é que só porque você implantou algo, não significa que ainda esteja em execução. Os agentes travam e os serviços são desativados — às vezes por usuários que querem acelerar seus laptops, e às vezes por malware que sabe exatamente qual processo encerrar primeiro. Um cliente VPN lança uma atualização que quebra o serviço, e a equipe só descobre isso semanas depois, quando você percebe um padrão nos tíquetes de suporte. Nenhum desses problemas aparece no monitoramento regular, a menos que você esteja procurando especificamente pela ausência de processos, e a maioria das equipes não está.
Esse problema é agravado pelo fato de que a maioria das verificações de conformidade apenas verifica uma vez se a ferramenta de segurança está presente, mesmo que ela deixe de estar em conformidade posteriormente. As verificações avançadas de postura invertem isso: a verificação é executada em cada evento de autenticação, portanto, uma ferramenta que para de funcionar às 9h resultará na recusa do acesso do usuário às 9h05.
Comprometimento da defesa no mundo real
Os adversários sabem que, se conseguirem cegar suas operações de segurança, já terão alcançado um objetivo significativo. Essas ações são tão comuns que a MITRE ATT&CK possui uma tática inteira dedicada a elas, chamada Defense Impairment (Prejuízo à Defesa), que consiste em 18 técnicas diferentes. Uma das técnicas mais comuns é a T1685: Desativar ou Modificar Ferramentas, que é o foco da nossa consulta de monitoramento de ferramentas abaixo.
Embora os adversários desativem muitas categorias de ferramentas de segurança, o uso de bloqueadores de EDR tornou-se comum durante intrusões de ransomware, com os operadores frequentemente desativando os EDRs antes da criptografia. Por exemplo, os operadores do ransomware Gentlemen dependem do seu malware "GentleKiller" para desativar processos de telemetria como o osqueryd.exe. De forma semelhante, o ransomware Reynolds utiliza a técnica "Traga seu próprio driver vulnerável" (BYOVD), explorando um driver vulnerável para eliminar processos de agentes EDR locais em uma ampla gama de plataformas. Ao impedir que dispositivos com ferramentas desativadas se autentiquem em seus recursos protegidos (apps e dados), você pode impedir esses invasores antes que eles consigam criptografar os dados.
O padrão watchdog
A consulta de detecção que estamos apresentando nesta publicar — que você pode encontrar no repositório okta/customer-detections — aborda isso como uma "verificação de integridade digital" para um dispositivo do usuário. Em vez de apenas procurar um único processo, a consulta funciona como um scorecard. A consulta atribui um ponto ao dispositivo para cada categoria de ferramenta de segurança obrigatória que esteja em execução, e o dispositivo é “aprovado” somente se sua pontuação total atingir a meta. A cada categoria de ferramenta de segurança é atribuída sua própria Expressão de Tabela Comum (CTE, na sigla em inglês), que retorna 1 se um processo relevante estiver ativo no momento e 0 caso contrário. O resultado final agrega todas as categorias, garantindo que a verificação permita a autenticação somente quando todas as ferramentas obrigatórias forem levadas em conta.
Eis um exemplo de como um dispositivo poderia ser avaliado…
Os dados de telemetria estão sendo transmitidos? Sim, então a pontuação é 1
O dispositivo está executando EDR? Sim, então a pontuação é 1
O dispositivo está executando MDM? Sim, então a pontuação é 1
O dispositivo está executando DLP? Sim, então a pontuação é 1
O dispositivo está executando VPN/ZTNA? Não, então a pontuação é 0
O dispositivo está executando segurança de DNS? Sim, então a pontuação é 1
O dispositivo está executando o gerenciamento de vulnerabilidades? Sim, então a pontuação é 1
Placar: 6 de 7 reprovados! Portanto, o dispositivo não teria acesso concedido.
Existem sete categorias, cada uma abrangendo os principais fornecedores nesse segmento, tanto para macOS quanto para Windows:
COM telemetria_em_execução COMO (
-- Supervisor do Fleet Orbit + daemon osquery
SELECT COALESCE(COUNT(*), 0) AS total
FROM processes
WHERE name IN ('osqueryd', 'orbit', 'osqueryd.exe', 'orbit.exe')
),
edr_running AS (
-- CrowdStrike Falcon | SentinelOne | VMware Carbon Black Cloud |
-- Microsoft Defender for Endpoint | Elastic Security | Palo Alto Cortex XDR |
-- FireEye/Trellix | Sophos | Trend Micro | ESET
SELECT COALESCE(COUNT(*), 0) AS total
FROM processes
WHERE name IN (
'com.crowdstrike.falcon.Agent', 'CSFalconService.exe', 'falcon-sensor',
'SentinelAgent', 'SentinelAgent.exe', 'sentineld',
'cbagentd', 'CbDefense.exe',
'wdavdaemon', 'MsMpEng.exe', 'MsSense.exe',
'elastic-agente',
'CyveraConsole', 'CyServer.exe',
'xagt', 'xagt.exe',
'SophosScanD', 'SAVAdminService.exe',
'iCoreService', 'Ntrtscan.exe',
'esets_daemon', 'ekrn.exe'
)
),
Os cinco CTEs restantes seguem o mesmo padrão para MDM, DLP, VPN/ZTNA, segurança de DNS e gerenciamento de vulnerabilidades. Todos eles convergem para uma única etapa de pontuação:
final_score AS (
SELECIONAR
CASE WHEN telemetry_running.total > 0 THEN 1 ELSE 0 END
+ CASE WHEN edr_running.total > 0 THEN 1 ELSE 0 END
+ CASE WHEN mdm_running.total > 0 THEN 1 ELSE 0 END
+ CASE WHEN dlp_running.total > 0 THEN 1 ELSE 0 END
+ CASE WHEN vpn_ztna_running.total > 0 THEN 1 ELSE 0 END
+ CASE WHEN dns_security_running.total > 0 THEN 1 ELSE 0 END
+ CASE WHEN vuln_scanner_running.total > 0 THEN 1 ELSE 0 END
Pontuação AS
FROM telemetry_running, edr_running, mdm_running, dlp_running,
vpn_ztna_running, dns_security_running, vuln_scanner_running
)
Select
CASO QUANDO pontuação = 7 ENTÃO 1 SENÃO 0
FIM COMO ferramentas_de_segurança_saudáveis
FROM final_score;
Algumas observações sobre a estrutura desta consulta:
Mede a abrangência da categoria. A lógica CASE WHEN total > 0 THEN 1 em torno de cada categoria é o que limita cada sinal a 1 antes de somá-los todos. Sem isso, uma única ferramenta que gera cinco processos contribuiria com 5 pontos para a pontuação em vez de 1, e um dispositivo que não possuísse quatro categorias de ferramentas ainda poderia ser aprovado por ter um agente EDR muito ocupado. O limite reforça o que a verificação realmente mede: a cobertura da categoria, e não a contagem de processos.
Ele normaliza diferentes fornecedores, transformando-os em um sinal consistente. Esta consulta utiliza CTEs independentes em vez de uma cláusula WHERE mais simples para normalizar os resultados entre diferentes fornecedores de ferramentas. Independentemente de um dispositivo executar CrowdStrike ou SentinelOne, a categoria EDR sempre retorna “1”. Uma cláusula WHERE monolítica retornaria uma contagem bruta de processos, o que não atinge o objetivo: não importa quantos processos o EDR crie, ele só recebe crédito por ser uma ferramenta.
Abrange tanto o macOS quanto o Windows. Um dos desafios na criação de verificações de postura multiplataforma é que as ferramentas para macOS geralmente não têm equivalente para Windows, e vice-versa. Esta verificação trata disso: dispositivos macOS recebem pontuação 1 para MDM via JamfDaemon, kandji-daemon, mosyled ou addigy-agent; dispositivos Windows recebem pontuação 1 para o processo MDM do Intune, Microsoft.Management.Services.IntuneWindowsAgent.exe. O mesmo se aplica aos nomes de processos EDR específicos da plataforma. Como cada categoria foi projetada para abranger ambas as plataformas dentro da mesma CTE, o limite permanece em pontuação = 7 em ambos os sistemas operacionais, portanto, não há necessidade de variantes da consulta específicas para cada plataforma.
Faça com que funcione para você
Nem todas as organizações implementam todas as sete categorias de ferramentas. Por exemplo, alguns usam seu EDR para gerenciamento de vulnerabilidades, enquanto outros podem lidar com a segurança de DNS na camada de rede, em vez do endpoint. A lista de nomes de processos em cada CTE abrange os principais fornecedores em cada categoria, permitindo que a verificação funcione em diversas organizações com pouca ou nenhuma modificação. No entanto, esta consulta é um ponto de partida, não uma configuração final. Antes de implementar essa verificação no modo de imposição, você precisa personalizá-la para o seu ambiente e testá-la.
Primeiro, encontre a consulta de detecção específica no repositório okta/customer-detections. Recomendamos clonar o projeto.
Em seguida, ajuste a consulta ao seu ambiente específico. Analise cada CTE e confirme se o nome do processo do seu fornecedor está na lista; caso contrário, adicione-o. Em seguida, reduza o limite para corresponder ao número de categorias de que você realmente precisa. (Por exemplo, uma pilha de cinco ferramentas deve usar =5, não =7.) Recomendamos executar a verificação localmente usando o osqueryi para confirmá-la. Refine os nomes dos processos e ajuste o limite de pontuação até que esteja perfeitamente alinhado com a pilha de segurança exigida pela sua organização.
Execute a consulta em modo monitorar em sua frota durante uma semana. Isso lhe dirá quais categorias estão registrando zero em dispositivos reais, o que geralmente é o primeiro sinal de que uma ferramenta se desviou do estado esperado.
Execute a consulta no modo de imposição depois de ter certeza de que ela funciona conforme o esperado.
Fechando o ciclo
Embora essa verificação de monitoramento de ferramentas possa não parecer glamorosa, é uma base fundamental que vale a pena ter implementada. Essa verificação permite confirmar se a pilha de segurança que você pagou e implementou está realmente em execução em todos os dispositivos que estão prestes a se autenticar em seu ambiente.
Nos próximos dias, exploraremos o que acontece quando você usa verificações avançadas de postura para um desafio completamente diferente.
