Managing for Results

A presente secc¸˜ao descreve o processo de integrac¸˜ao da plataforma Cisco AMP no ecos- sistema de ciberseguranc¸a da DCY. Cada integrac¸˜ao ´e apresentada segundo a sua ordem cronol´ogica, uma vez que esta obedeceu `as prioridades definidas pelo departamento.

Primeiramente ´e discutida a integrac¸˜ao do SIEM, plataforma essencial para o SOC na resposta a incidentes maliciosos. Em seguida ´e apresentada a integrac¸˜ao com o Hidra, uma plataforma interna importante na agilizac¸˜ao de informac¸˜ao obtida por diversas fontes, podendo estas n˜ao estar diretamente relacionadas com a ciberseguranc¸a.

´

E feita uma referˆencia `a integrac¸˜ao tempor´aria do Endpoint Security da Cisco, tendo como ambiente de teste o departamento de ciberseguranc¸a da Portugal Telecom. Por fim, ´e dada a conhecer a implementac¸˜ao de um script em Python que serve o prop´osito de acrescentar informac¸˜ao relevante sobre os incidentes de seguranc¸a detetados.

3.5.1

Integrac¸˜ao com o SIEM

No caso da DCY, o SIEM existente assume uma importˆancia consider´avel na monitorizac¸˜ao de eventos de ciberseguranc¸a, em geral. Nesse sentido, a integrac¸˜ao da Cisco AMP no ecossistema de seguranc¸a significa, obrigatoriamente, a sua articulac¸˜ao com o SIEM.

A integrac¸˜ao ´e feita atrav´es de um conector propriet´ario da Cisco (eStreamer), que permite o envio de informac¸˜ao relativa a eventos de intrus˜ao e de malware gerados pela plataforma Cisco AMP. Foi necess´ario configurar-se uma rota em ambas as plataformas para que a comunicac¸˜ao fosse poss´ıvel. Neste cen´ario, a plataforma Cisco AMP funciona como um reposit´orio de eventos em relac¸˜ao ao SIEM que utiliza o conector para recolher a informac¸˜ao.

Este sistema integrado permite a automatizac¸˜ao dos processos de alarm´ıstica para que, sempre que um novo evento de malware seja detetado pela plataforma Cisco AMP, este seja automaticamente enviado para o SIEM. Posteriormente, o SIEM abre um novo ticket no RTIR (Request Tracker for Incident Response), sendo a equipa de resposta a incidentes notificada, via email, desse novo evento de malware.

De forma resumida, esta integrac¸˜ao permite que o SOC seja automaticamente notifi- cado, atrav´es de email, sempre que um novo evento de malware ´e detetado pela plataforma Cisco AMP na rede a ser monitorizada. No cen´ario atual o SOC n˜ao ´e notificado por email acerca dos eventos de intrus˜ao, uma vez que n˜ao foram integrados com a plataforma de ticketingde eventos de ciberseguranc¸a da DCY.

Tendo em considerac¸˜ao o volume de tr´afego existente na rede monitorizada (e na rede da Portugal Telecom em geral), optou-se por n˜ao integrar, numa primeira fase, os eventos de intrus˜ao gerados pela plataforma Cisco AMP com o RTIR. A raz˜ao que motivou a sua n˜ao integrac¸˜ao prende-se com os falsos positivos gerados pela plataforma Cisco AMP no que diz respeito a eventos de intrus˜ao. No entanto, a equipa de resposta a incidentes tem

acesso aos eventos gerados atrav´es da interface web da Cisco AMP.

Deste modo, garantiu-se uma nova plataforma de alarm´ıstica que notifica a equipa de resposta a incidentes para os eventos de malware e, futuramente, de intrus˜ao gerados pela Cisco AMP (ver figura 3.13).

Figura 3.13: Integrac¸˜ao com o SIEM

3.5.2

Integrac¸˜ao com o Hidra

O Hidra ´e uma plataforma interna de agregac¸˜ao de informac¸˜ao para an´alise posterior de eventos (Post Mortem Forensics Analysis). A informac¸˜ao agregada por esta plataforma pode n˜ao estar diretamente relacionada com a ciberseguranc¸a, no entanto, nalguns casos pode ser necess´ario o correlacionamento entre ambas. Sendo uma das plataformas obri- gat´orias para a recolha e an´alise de informac¸˜ao interna, tornou-se imperativo a integrac¸˜ao da plataforma Cisco AMP com o Hidra.

Definiram-se dois tipos de eventos essenciais a serem transmitidos entre a Cisco AMP e o Hidra: eventos de intrus˜ao e eventos de malware (ver figura 3.14). Esta informac¸˜ao ´e enviada por syslog, sendo configurado na plataforma da Cisco as rotas necess´arias para a comunicac¸˜ao entre ambas. Foram tamb´em definidos os campos necess´arios para a pos- terior an´alise destes eventos maliciosos detetados pela plataforma Cisco AMP. Estes da- dos poder˜ao ser utilizados para a criac¸˜ao de dashboards e outros elementos que possam ser considerados ´uteis para a monitorizac¸˜ao do tr´afego e em particular da evoluc¸˜ao do malwaredetetado.

Desta forma ´e poss´ıvel consultar os eventos de intrus˜ao e de malware gerados pela plataforma Cisco sem aceder diretamente `a mesma. Simultaneamente, o Hidra pode ser visto, no contexto desta integrac¸˜ao, como sendo uma base de dados de eventos de intrus˜ao e de malware gerados pela Cisco AMP.

Figura 3.14: Exemplo de eventos Cisco AMP no Hidra

3.5.3

Integrac¸˜ao com o Endpoint Security

A Cisco AMP for Endpoints ´e uma soluc¸˜ao de seguranc¸a para estac¸˜oes de trabalho e dispositivos m´oveis, gerida pelo Defense Center. De forma semelhante `a descric¸˜ao dada anteriormente ao HIPS (Host Based Intrusion Prevention), esta soluc¸˜ao pode ser vista como um mecanismo de seguranc¸a complementar aos tradicionais NIPS.

A AMP for Endpoints encontra-se sincronizada com a plataforma Cisco AMP, im- plementada no ˆambito da Portugal Telecom, fornecendo tamb´em um mecanismo de an- tiv´ırus que permite detetar e bloquear ataques `a entrada, uma plataforma de sandboxing e protec¸˜ao pr´o-ativa.

Os utilizadores instalam um conector nos terminais (computadores dispositivos m´oveis). Estes conectores permitem a an´alise de ficheiros, comunicando diretamente com a nuvem da AMP por forma a determinar se estes contˆem malware. Sempre que um ficheiro for identificado como malware, ´e enviada a identificac¸˜ao da ameac¸a para o Defense Center, impedindo ao mesmo tempo a execuc¸˜ao do mesmo. O sistema Cisco AMP armazena esta informac¸˜ao como um novo evento de malware.

Como parte das pr´oprias caracter´ısticas da Cisco AMP, tamb´em nos terminais ´e ga- rantida a monitorizac¸˜ao cont´ınua da atividade dos ficheiros. Assim sendo, ´e tamb´em garantida a retrospetividade dos eventos, permitindo que as equipas de seguranc¸a sejam alertadas para eventos de malware que tenham ocorrido anteriormente no terminal afe- tado. Permite identificar a origem do malware, os terminais que foram afetados e o seu comportamento. `A data deste trabalho, a protec¸˜ao de terminais era garantida em disposi- tivos Windows, Mac OS, Linux e dispositivos m´oveis Android e iOS.

No caso da Portugal Telecom, foi testada a Cisco AMP for Endpoints nalguns termi- nais afetos ao departamento de ciberseguranc¸a. Durante um per´ıodo de 6 meses foi-nos atribu´ıda uma licenc¸a que serviria para testar a integrac¸˜ao dos terminais com a plataforma central Cisco AMP.

3.5.4

Integrac¸˜ao com o Orion

Tal como ´e referido anteriormente, a plataforma Cisco AMP classifica alguns ficheiros como desconhecidos, por n˜ao conseguir obter mais informac¸˜ao que ajude a perceber o seu comportamento. Assim sendo, e tendo em conta que n˜ao se pode excluir a hip´otese de alguns desses ficheiros serem maliciosos, analisaram-se alguns exemplares por forma a perceber se a plataforma poderia estar a descartar malware.

O Orion ´e um script em Python, desenvolvido no ˆambito deste projeto, que pesquisa um determinado hash na API (Application Programming Interface) do Virustotal. Inici- almente, este script foi desenvolvido como uma ferramenta complementar na an´alise de eventos classificados como desconhecidos pela plataforma Cisco AMP. Tendo em conta o volume consider´avel de ficheiros gerados com essa classificac¸˜ao, investigou-se a possi- bilidade do Virustotal e da Cisco AMP n˜ao estarem totalmente de acordo acerca desses ficheiros. De facto, em alguns casos, existiam ficheiros tidos como maliciosos pela pla- taforma Cisco AMP que n˜ao apareciam sequer nas bases de dados do Virustotal e, por sua vez, eventos classificados como desconhecidos (unknowns) na plataforma Cisco que eram classificados como malware no Virustotal.

Primeira Fase

A primeira fase do script encontrava-se pouco automatizada, tendo em conta que era necess´ario gerar (manualmente) um ficheiro com uma listagem de hashes desconhecidos da plataforma Cisco AMP para se executar o Orion, tal como apresentado na figura 3.15. Pese embora a colaborac¸˜ao do Virustotal na disponibilizac¸˜ao de uma licenc¸a de estudante que permitisse o envio de um volume consider´avel de ficheiros, as potencialidades do scriptalteraram a abordagem a seguir.

Figura 3.15: Primeira fase de desenvolvimento - Orion.py Segunda Fase

Constatou-se que o script desenvolvido poderia ter outras utilidades que n˜ao a consulta de ficheiros desconhecidos, levando a uma segunda vers˜ao do mesmo (ver figura 3.16). Esta segunda vers˜ao tinha como principal motivac¸˜ao a consulta do Virustotal como uma segunda opini˜ao. Quer isto dizer que, para cada evento de malware gerado pela plataforma Cisco AMP, seria consultado o hash desse ficheiro no Virustotal por forma a obter mais informac¸˜ao sobre o mesmo.

Tendo em conta que a equipa de resposta a incidentes consultava regularmente o servic¸o Virustotal, considerou-se pertinente a sua integrac¸˜ao com a informac¸˜ao prestada pela Cisco AMP. Assim sendo, otimizou-se o script de modo a fornecer essa informac¸˜ao juntamente com a que ´e fornecida pela Cisco AMP sempre que ´e despoletado um novo evento de malware. De forma resumida, a ideia seria a seguinte: para cada evento de malwaregerado pela Cisco AMP, seria aberto um ticket para a equipa de resposta a in- cidentes no RTIR cuja informac¸˜ao seria a junc¸˜ao dos resultados obtidos pela plataforma e pelo Virustotal. A integrac¸˜ao destas trˆes componentes n˜ao foi implementada durante o per´ıodo em que se desenvolveu este trabalho, ficando planeada para trabalhos futuros.