Traduzido do 日本語 • Ver original 
Na verdade, olhando para incidentes recentes, há muito mais casos em que "registros existiam, mas não foram usados" ou "anomalias foram registradas, mas foram ignoradas" do que casos em que "registros não existiam".
Em outras palavras, o problema não é a quantidade de toras, mas sim como a operação dos registros é projetada e utilizada.
Neste artigo, partindo da pergunta "Por que os ataques não podem ser detectados mesmo havendo registros?", vamos explicar as armadilhas típicas nas operações de segurança e como melhorá-las de acordo com o conceito de defesa em profundidade. Por favor, leia isso como uma dica para passar de um estado de "apenas guardar" registros para um estado de "utilizá-los para defesa".
Contexto: Os registros continuam crescendo, mas a realidade é indetectável
Com a expansão da nuvem, SaaS, trabalho remoto, IoT, etc., a quantidade e o tipo de logs tratados pelas empresas aumentam ano após ano. As informações que podem ser obtidas, como logs do sistema operacional, logs de aplicações, logs de rede, logs de autenticação, logs de acesso à API, etc., são incomparavelmente mais ricas.
Por outro lado, o ataque começou a ocorrer de forma mais "silenciosa".
Em vez de cometer sabotagem imediatamente após a intrusão inicial, é comum passar semanas ou meses explorando o interior para escalar privilégios ou rolar lateralmente. Durante esse tempo, todas as ações do atacante podem permanecer registradas.
Por que ainda não pode ser detectado?
Frequentemente, os seguintes desafios ficam em segundo plano:
- Coletando toras, mas sem definir o que ver
- Os critérios para normalidade e anormalidade são ambíguos, e os alertas são na forma de formalidade
- Dependência de monitoramento manual, análise que não acompanha
- Logaritmos são dispersos e análise de correlação transversal não é possível
Essas são mais questões de design operacional do que falta de ferramentas.
Métodos de ataque e riscos: Medo de não perceber os "sinais" que aparecem nos registros
Os ataques modernos não ocorrem como um evento único, mas como uma "pilha sucessiva de ações."
Por exemplo, o fluxo é o seguinte.
- Logar a partir de um endereço IP que normalmente não é usado no meio da noite
- Aumento das falhas de autenticação em um curto período de tempo
- Acesso a APIs e recursos de gerenciamento que normalmente não são usados em empresas
- Alterar permissões e criar novas contas
- Acesso em seção transversal a sistemas internos
Essas podem parecer "operações comuns" por si só. No entanto, são claramente antinaturais quando relatadas em ordem cronológica ou contexto.
Se você olhar apenas para o tronco nesse ponto, vai perder essa "linha".
Como resultado, a descoberta de uma violação é a "etapa final" da execução de ransomware ou exfiltração de informações, maximizando os danos.
Isso significa que o mecanismo de detecção e julgamento não está funcionando mais do que um problema técnico.
Contramedidas: Uma abordagem multicamada para transformar toras em "defesas"
A detecção registrada exige mais do que apenas SIEM. Tudo gira em torno de design e operações.
1. Preparação do Ambiente: Repensando o Design do Tronco
Primeiro, organize "quais registros são necessários para quê".
Em vez de armazenar tudo, é importante priorizá-los para cada propósito: detecção, investigação e trilha. Além disso, a sincronização de tempo e a uniformidade de formato dos registros também afetam muito a precisão da análise nos processos posteriores.
2. Construindo um Regime de Monitoramento: Análise de Correlação e Automação
É necessário ter um sistema que possa analisar logs em múltiplas fontes, não apenas logs. Utilize SIEM e XDR para detectar automaticamente combinações de comportamentos que não são perceptíveis para humanos.
O segredo é projetar para detectar "cadeia anormal de operações".
3. Operação de Teste: Validando a Detecção
Não adianta criar regras e acabar com isso.
Com base em ataques simulados e incidentes passados, verificamos se realmente pode ser detectado. Se houver alertas demais, ajustamos a precisão e reduzimos a um nível que possa ser tratado em campo.
4. Produção: Esclarecimento do fluxo de resposta
Mesmo que seja detectado, não faz sentido se a resposta parar.
Defina antecipadamente as decisões iniciais de resposta, escalonamento e contenção quando ocorra um alerta, e crie um estado onde qualquer pessoa possa ver e agir. Se isso for ambíguo, a detecção termina com uma "notificação".
5. Melhoria Contínua: Acompanhando Ameaças e Mudanças Ambientais
Atualize seu design de logs e regras de detecção para acomodar novos vetores de ataque, adições ao sistema empresarial, mudanças na configuração da nuvem e muito mais.
Ao incorporar inteligência sobre ameaças cibernéticas, você pode se preparar para ataques desconhecidos.
Artigos relacionados:
O que deveria ser: Um estado em que os registros se tornam "alerta precoce" em vez de "retrospectivo"
Em uma operação de segurança ideal, os registros servem como sensores para detectar no meio de um ataque, em vez de evidências pós-incidente.
Para isso, é necessário realizar o seguinte:
- Garantir que ações importantes sejam registradas
- A definição de anomalias é acordada pela organização
- Detecção automática e julgamento humano são divididos em funções
- O processo da detecção à resposta é treinado
Isso também é consistente com a mentalidade Zero Trust e NIST CSF 2.0.
Artigos relacionados:
Conclusão
Não é incomum em situações em que há um registro, mas não pode ser detectado.
Mas não é que os troncos sejam inúteis, é só que não foram feitos para serem usados.
Troncos, quando devidamente projetados, correlacionados e continuamente aprimorados, podem ser uma defesa poderosa.
Antes de passar para a implementação de ferramentas, o primeiro passo para a maturidade operacional de segurança é esclarecer o que queremos detectar e quais logs precisamos fazer isso.
Ataques sempre deixam rastros. Se uma organização pode ou não perceber os rastros determinará o tamanho do dano.
Se você tiver problemas como "Tenho logs, mas não posso usá-los" ou "Estou preocupado em otimizar e definir regras de detecção no meu ambiente", o caminho mais curto é consultar um especialista. Na Colorkrew Security, vamos te apoiar no design de operações práticas de log adaptadas ao seu ambiente.