Z AMBIA

Nesta secc¸˜ao s˜ao abordados os dois tipos de eventos relacionados com as caracter´ısticas de NIDS (baseado em assinaturas) da plataforma Cisco AMP. Sempre que o sensor deteta uma nova ligac¸˜ao, ´e gerado um novo evento de ligac¸˜ao no Defense Center.

Figura 3.7: Integrac¸˜ao Cisco AMP - tr´afego da rede de gest˜ao do datacenter

Por outro lado, sempre que for detetado uma ligac¸˜ao que corresponda a uma das regras Snort definidas na pol´ıtica de acessos, ´e gerado um evento de intrus˜ao. O ´ultimo caso torna-se particularmente relevante no contexto deste trabalho, assumindo que este pode ter como origem a infec¸˜ao de uma m´aquina interna com malware.

3.3.1

Eventos de Ligac¸˜ao

A plataforma tem a capacidade de detetar ligac¸˜oes que tenham como origem ou destino a rede a ser monitorizada. Como m´etodo de comparac¸˜ao, os eventos de ligac¸˜ao podem ser vistos como registos de um sistema Snort em funcionar em modo logger. Considerando o facto da plataforma basear as suas regras de detec¸˜ao de intrus˜oes nas regras do Snort, esta comparac¸˜ao faz ainda mais sentido. Cada evento gerado tem dispon´ıvel a seguinte informac¸˜ao:

• Propriedades b´asicas da ligac¸˜ao: timestamp, IP de origem e destino, pa´ıs de ori- gem e destino, porto de origem e destino, etc.;

• Propriedades adicionais: protocolo aplicacional, aplicac¸˜ao web, URLs, m´aquina respons´avel pela detec¸˜ao (sensor), etc.

Desta forma, s˜ao mantidos os registos das ligac¸˜oes detetadas pelo sistema para que, posteriormente, estes possam ser analisados em maior detalhe sempre que se considerar pertinente.

Os eventos de ligac¸˜ao (ver exemplo da figura 3.8) podem ser consultados no Defense Center de forma arbitr´aria pela equipa de resposta a incidentes (SOC). Estes eventos s˜ao particularmente ´uteis quando se pretende investigar algum incidente que, embora n˜ao tenha sido classificado como uma intrus˜ao, seja considerado suspeito por uma outra pla- taforma de seguranc¸a da DCY ou pela equipa de resposta a incidentes.

Atrav´es da an´alise de eventos de ligac¸˜ao gerados pelo sensor da plataforma Cisco AMP, podem ser detetadas anomalias no tr´afego mesmo que estas n˜ao tenham sido classi- ficadas como sendo maliciosas. Um enderec¸o interno a realizar demasiadas ligac¸˜oes para um enderec¸o externo desconhecido, pode significar um comportamento malicioso.

Podem tamb´em ser detetadas anomalias do ponto de vista de regulamentac¸˜ao interna, por exemplo, a detec¸˜ao de tr´afego gerado por software n˜ao autorizado na rede corporativa da Portugal Telecom. Na pol´ıtica de controlo de acessos ´e definido o tr´afego a ser arma- zenado para posterior an´alise, caso se considere pertinente. Neste caso em particular, da DCY, s˜ao armazenados os registos de todas as ligac¸˜oes detetadas no tr´afego monitorizado.

Figura 3.8: Exemplo de um evento de ligac¸˜ao

3.3.2

Eventos de Intrus˜ao

Sempre que exista correspondˆencia entre uma ligac¸˜ao e uma das regras de Snort da plata- forma AMP, ´e gerado um novo evento de intrus˜ao (ver figura 3.9) com o registo da data, hora, tipo de ameac¸a e restante informac¸˜ao contextual acerca da origem do ataque e o seu destinat´ario. Estes eventos s˜ao posteriormente analisados, pela equipa de resposta a incidentes, por forma a filtrar poss´ıveis falsos positivos.

O sistema disponibiliza ferramentas que permitem analisar os eventos de intrus˜ao de modo a determinar quais deles podem ser relevantes no contexto da rede:

• Uma p´agina de resumo das atividades atuais e dispositivos que est˜ao a ser geridos pelo Defense Center;

• Relat´orios que podem ser gerados consoante o per´ıodo de tempo definido pelo uti- lizador;

• Uma ferramenta de gest˜ao de incidentes que pode ser utilizada para a recolha de informac¸˜ao relacionada com um ataque;

• Sistema de alarm´ıstica autom´atico para SNMP, email e syslog;

• Sistema de correlac¸˜ao de pol´ıticas autom´atico que pode ser utilizado para responder e mitigar eventos de intrus˜ao espec´ıficos;

• Fluxos de trabalho pr´e-definidos e personalizados que podem ser utilizados para investigar em detalhe um evento de intrus˜ao espec´ıfico, incluindo a sua evoluc¸˜ao ao longo do tempo e propagac¸˜ao na pr´opria rede.

Figura 3.9: Exemplo de um evento de intrus˜ao

Sendo este projeto essencialmente dedicado `a detec¸˜ao e mitigac¸˜ao de malware, inte- ressa perceber de que forma os eventos de intrus˜ao est˜ao relacionados com eventos de malware. O Defense Center facilita este processo de an´alise de uma potencial ameac¸a, atribuindo um n´ıvel de impacto a cada evento de intrus˜ao. Para al´em disso, existem re- gras de Snort pr´e-definidas na plataforma que incidem na detec¸˜ao de eventos de intrus˜ao relacionados com malware.

Quando configurada em modo ativo, a Cisco AMP comporta-se como um NIPS, blo- queando de forma ativa todo o tr´afego considerado malicioso. No entanto, no caso da DCY, a plataforma encontra-se configurada em modo passivo tendo em conta a perspetiva de seguranc¸a em profundidade j´a referida.

Tamb´em neste caso, `a semelhanc¸a dos eventos de ligac¸˜ao, ´e necess´ario definir na pol´ıtica de controlo de acesso quais os eventos de intrus˜ao que devem ser alvo de an´alise por parte das regras de Snort da plataforma. No caso da Portugal Telecom, o tr´afego ´e analisado conforme as regras definidas na ac¸˜ao por omiss˜ao referida no cap´ıtulo da pol´ıtica de controlo de acesso.