De acordo com o dicionário, a palavra contexto significa “inter-relação de circunstâncias que acompanham um fato ou uma situação”. Não é uma definição muito longa, mas, na cibersegurança, entender o significado do contexto pode significar a diferença entre caçar fantasmas e detectar uma ameaça ou dano em andamento.
Não é difícil defender o contexto no ambiente atual. Quando mais de 350.000 novos malwares ou outros programas indesejados são descobertos diariamente e os invasores fazem uso de ferramentas padrão do sistema para realizar suas campanhas, qualquer um pode ver que é impossível proteger seu ambiente investigando isoladamente cada evento suspeito.
Infelizmente, hoje muitos Centros de Operações de Segurança (Security Operations Centers, SOCs) se encontram submersos em um mar de eventos de segurança, muitos dos quais não têm o contexto necessário para governá-los como benignos ou elevar sua prioridade como eventos críticos ou graves que precisam de atenção imediata.
Um dos piores infratores que aumenta essa explosão de dados na pilha de segurança é uma classe de tecnologia chamada EDR (Endpoint Detection and Response).
O conceito que impulsionou a criação da tecnologia EDR foi simples: o antivírus (AV) não pode identificar e evitar todas as ameaças ao ambiente, por isso foi preciso desenvolver algo que monitorasse o endpoint em busca de comportamento suspeito e, se encontrado, alertasse o analista de segurança.
Assim como muitas ideias que podem ser declaradas simples, a implementação pode se tornar complexa rapidamente. A complicação da tecnologia começa e termina com dados. Para identificar “tudo” que o AV possa ter deixado passar, você precisa capturar e analisar “tudo” de “todo” endpoint “o tempo todo”.
Não é preciso ser um matemático para descobrir que essa é uma enorme quantidade de dados. Onde esses dados serão armazenados? Como isso será coletado? Como será analisado?
Antes que pudesse perceber, a empresa de médio porte que implementava essa nova tecnologia estava encarando um crescente monólito de dados; gigabytes, terabytes e até petabytes.
Cada vez que um usuário liga seu laptop, verifica seu e-mail, cria um novo documento do Word, até mesmo lê esse material online, o EDR está escutando e capturando todas as alterações.
Durante todo o dia, todos os dias. É impressionante quando você considera que até mesmo uma empresa pequena ou média pode ter 500 endpoints sendo executados a cada dia – isso sem pensar na organização multinacional que tem várias centenas de milhares de terminais para monitorar.
Supondo que uma estratégia aceitável seja identificada para lidar com esses dados, o próximo problema a ser resolvido é o da análise. Os dados são apenas dados até você analisá-los.
Isso geralmente significa um mecanismo de regras funcionando continuamente, à procura da proverbial agulha no palheiro. Esses mecanismos de regras são carregados com centenas, se não milhares, de regras que algum guru da segurança – talvez até mesmo o fornecedor – criou para encontrar ameaças.
O único problema é que, como se sabe, o cenário de ameaças não é estático. Os invasores estão constantemente refinando e modificando suas abordagens, o que, por sua vez, significa que qualquer regra destinada a identificar essas ameaças deve ser refinada e modificada regularmente.
Se isso não ocorrer, os SOCs rapidamente verão seu volume de alertas de EDR encolher, o que não significa que os ataques tenham diminuído, mas que os invasores conseguiram subverter as regras com êxito e podem estar livres no ambiente digital.
Assim, supondo que você tenha resolvido o problema de dados e descoberto uma maneira de manter suas regras atualizadas, o último obstáculo a ser lançado nos leva de volta ao ponto de partida: o contexto.
O problema com o contexto
Para entender o problema com o contexto, vamos primeiro pensar em como as máquinas funcionam. Uma máquina, especialmente uma projetada para um propósito específico, tem visão de túnel.
Vamos pegar o exemplo de um despertador. Digamos que alguém normalmente precisa acordar todos os dias às 6 horas. O alarme é definido e, a cada dia, ele toca a música favorita ou um tom que solicita que a pessoa acorde e comece o dia.
Agora, digamos que o alarme não seja desligado no final de semana e ele acorde esse trabalhador com um grande susto às 6 da manhã. O despertador funcionou incorretamente? Não. O alarme funcionou perfeitamente. O problema é que faltava o contexto “hoje não preciso levantar cedo”.
Voltando ao mundo da segurança, os mecanismos tradicionais de regras basicamente gerenciam uma série de despertadores, cada um aguardando o minuto, o segundo e até mesmo o milissegundo. O problema – assim como com o despertador à cabeceira – é que, sem o contexto adequado, esses relógios soam continuamente nos ouvidos dos analistas do SOC, tendo pouco ou nenhum conceito de que outros despertadores também estejam tocando.
É um cenário exaustivo e, felizmente, que pode ser resolvido com o contexto. O contexto adicionaria – da mesma forma que o despertar às 6 horas – um “portão” ou série de portas para cada relógio, que instruiria o alarme a tocar somente se todas as condições ou conjuntos de condições existirem.
Portanto, por exemplo, se houver um relógio procurando o uso do Prompt de Comando ou do PowerShell e não houver um conjunto de "condições", prepare-se para ficar sobrecarregado com alarmes.
Agora, ao fornecer algum contexto para esse alarme, em vez de ficarem sobrecarregados, os SOCs verão a diminuição dos alarmes pelas razões certas, evitando-se esses falsos alarmes de antes.
Vejamos um exemplo do mundo real: o aumento de táticas, técnicas e procedimentos que abusam de programas comumente confiáveis, que são instalados por padrão em um sistema operacional, comumente chamado de ataques living-off-the-land, é um exemplo perfeito de por que um conjunto forte de dados contextuais é um requisito para fornecer o nível mais alto de proteção sem sobrecarregar os operadores de segurança em um ambiente.
Os ataques living-off-the-land estão se tornando mais comuns devido à sua dificuldade em serem detectados e depois responderem automaticamente de forma apropriada em ambientes mal instrumentados. Isso ocorre porque esses ataques utilizam programas confiáveis desenvolvidos pelas equipes de desenvolvimento do sistema operacional.
Esse nível implícito de confiança permite que a execução desses programas passe despercebida pelas soluções de antivírus, já que colocar em quarentena ou excluir um desses programas, simplesmente com base na análise do arquivo, causaria instabilidade no sistema.
Para complicar ainda mais a situação, muitos desses programas confiáveis eram, até recentemente, desconhecidos pelos administradores de sistemas e pela equipe de segurança.
Além disso, alguns desses programas fornecem pouca ou nenhuma documentação detalhando alguns de seus recursos ou habilidades robustas e inesperadas. Isso, é claro, cria uma situação em que uma equipe de segurança pode nem saber o que procurar ou entender nas várias áreas de risco existentes em seu ambiente.
Um bom exemplo disso é a conhecida vulnerabilidade do Microsoft Office Dynamic Data Exchange, que muitas empresas encontraram ao longo de 2018.
Essa vulnerabilidade utilizou um recurso pouco conhecido dos aplicativos do Microsoft Office, conhecido como DDE (Dynamic Data Exchange), um recurso projetado para transferir perfeitamente dados entre aplicativos da Microsoft, essencialmente executando comandos arbitrários em um sistema.
Em técnicas comuns, essa vulnerabilidade seria usada para forçar o aplicativo da Microsoft a gerar um processo filho, normalmente o PowerShell, para baixar e executar uma carga adicional (um malware, um script ou outro código não confiável) no sistema alvo.
Quando todo o ciclo de vida de um ataque DDE é destrinchado, semelhante à descrição acima, fica bastante claro como e por que ele pode ser usado para fins maliciosos. Isso ocorre porque o contexto é fornecido com a descrição geral do ataque.
Quando se desconstrói a descrição do ataque em pedaços atômicos menores, a necessidade de contexto fica ainda mais clara. O nível mais básico de contexto necessário para detectar e evitar esse ataque exige que um analista tenha acesso aos processos envolvidos, como o aplicativo Microsoft Office (Microsoft Word) e o PowerShell, nesse exemplo.
Observar esses dois programas em execução em um sistema normalmente não é motivo para alarme pois ambos são comumente utilizados em muitos ambientes. O próximo nível de contexto exigido é a herança do processo. Nesse caso, o Microsoft Word está gerando o PowerShell.
Em muitas situações, esse nível de contexto, por si só, pode ser suficiente para justificar uma investigação ou resposta, já que essa relação de processo é tipicamente desnecessária e anômala em muitos ambientes; no entanto o processo ainda é propenso a falsos alarmes em algumas situações.
Os detalhes do processo continuarão a adicionar um contexto valioso para analistas e ações de resposta automatizadas. Alguns detalhes do processo, como argumentos de linha de comando, podem ser o atributo contextual final para fornecer um mecanismo quase perfeito para determinar a má intenção de uma determinada ação, especialmente quando combinada com camadas de contexto mais fundamentais.
No exemplo acima, o PowerShell poderia ser chamado com um conjunto de argumentos de linha de comando, indicando a tentativa de baixar o conteúdo de um local remoto.
A solução: contexto inteligente
O auge dos detalhes contextuais vem com a capacidade de correlacionar de forma automática ou inteligente os diferentes níveis de atividade do sistema (ou seja, processos iniciados e arquivos sendo criados) de alguma maneira lógica. Esse nível de contexto permite que a lógica de detecção e resposta seja afinada para parâmetros imensamente específicos.
Destrinchar um evento até esse nível de contexto não apenas ajuda a explicar as complexidades para detectar o comportamento do sistema malicioso bem como permite uma compreensão clara de como a lógica de detecção e resposta pode ser implementada em vários níveis da pilha de contexto para ajustar os tipos e o volume de alertas que uma equipe de segurança receberá sobre o estado de seu ambiente.
O contexto resolve todos os problemas de segurança? Claro que não! Fazer essa afirmação seria tolice. Os atacantes são um bando determinado e sempre procurarão novas maneiras de alcançar seus objetivos.
Mas uma coisa é certa: quem tiver a opção de trabalhar em um SOC que tenha implementado alguma forma de análise contextual automatizada e outra que não tenha contexto detalhado, deve escolher o contexto. Ele pode ter suas noites e finais de semana de volta.
