U GANDA

O controlo de acesso ´e uma pol´ıtica baseada em hierarquias que permite especificar, ana- lisar e armazenar tr´afego de rede. Por outras palavras, ´e a funcionalidade da Cisco AMP que permite determinar qual o tr´afego que deve ser analisado e armazenado. Esta pol´ıtica ´e composta essencialmente por dois componentes b´asicos: ac¸˜ao por omiss˜ao (obrigat´oria) e regras (opcionais).

Quando criada pela primeira vez, a pol´ıtica de controlo de acesso lida com o tr´afego de acordo com a ac¸˜ao definida por omiss˜ao. Esta ac¸˜ao pr´e-definida pode bloquear ou permitir tr´afego. Na ausˆencia de qualquer outra configurac¸˜ao, o sistema lida com o tr´afego de acordo com a ac¸˜ao pr´e-definida.

Dentro da pol´ıtica de controlo de acessos, podem ser definidos filtros ou regras que permitem uma manipulac¸˜ao granular do tr´afego. A plataforma Cisco AMP compara o tr´afego com as regras de controlo de acesso na ordem especificada. O sistema controla o tr´afego de acordo com a primeira regra definida na pol´ıtica de controlo de acessos, assumindo que todas as condic¸˜oes dessa regra s˜ao correspondidas.

As regras do controlo de acesso s˜ao numeradas, comec¸ando no n´umero um. O sistema compara o tr´afego com as regras em ordem decrescente (de cima para baixo) e por ordem crescente do n´umero da regra. N˜ao ser´a avaliado tr´afego de menor prioridade caso o mesmo j´a tenha correspondido a uma regra de prioridade superior.

Cada regra tem uma ac¸˜ao associada que determina se o tr´afego deve ser monitorizado (monitor), confiado (trust), bloqueado (block) ou permitido (allow):

• Regra 1: Monitorizac¸˜ao (Monitor) - As regras de monitorizac¸˜ao armazenam um logou registo do tr´afego mas n˜ao afetam o seu fluxo. Caso existam mais regras, o sistema continua a analisar o tr´afego por forma a determinar o que deve permitir ou bloquear;

• Regra 2: Confiar (Trust) - Permitem que o tr´afego flua sem que seja sujeito a qualquer tipo de an´alise. O tr´afego que n˜ao corresponda a estas regras ´e analisado pelas regras seguintes;

• Regra 3: Bloquear (Block) - Bloqueia todo o tr´afego que corresponda `a regra. O tr´afego que n˜ao corresponda `a regra ´e analisado pelas regras seguintes;

• Regra 4: Permitir (Allow) - O tr´afego que corresponda a esta regra ´e permitido. No entanto, o tr´afego ´e analisado por forma a detetar poss´ıveis ameac¸as de malware ou intrus˜oes. Dependendo da configurac¸˜ao da plataforma, passiva ou ativa, o tr´afego malicioso pode ser bloqueado ou, simplesmente, gerar alarm´ıstica. Para cada uma destas regras pode ser definida uma pol´ıtica de ficheiros, de intrus˜oes, ambas ou nenhum tipo de inspec¸˜ao;

• Ac¸˜ao por omiss˜ao - Trata todo o tr´afego que n˜ao corresponda a nenhuma das regras anteriores. Esta regra n˜ao aplica qualquer tipo de an´alise de ficheiros.

Para cada regra que tenha associada a ac¸˜ao allow, podem ser atribu´ıdas pol´ıticas de ficheiros ou intrus˜ao. As pol´ıticas de intrus˜ao dizem respeito `as capacidades de detec¸˜ao e prevenc¸˜ao de intrus˜oes da plataforma. As pol´ıticas de ficheiros, por sua vez, permitem o controlo de ficheiros e a detec¸˜ao de malware (AMP). Ao associar-se uma pol´ıtica de intrus˜ao ou de ficheiros a uma regra do controlo de acesso, est´a a ser comunicado ao sistema que antes de ser permitido o tr´afego, este deve ser analisado para detec¸˜ao de poss´ıveis intrus˜oes ou ficheiros maliciosos. Para cada ligac¸˜ao que corresponda a uma regra, temos que:

• Se n˜ao for atribu´ıda uma pol´ıtica de malware, o fluxo do tr´afego ser´a determinado pela pol´ıtica de intrus˜ao;

• Se n˜ao for atribu´ıda uma pol´ıtica de intrus˜ao, o fluxo do tr´afego ´e determinado pela pol´ıtica de ficheiros;

• Se n˜ao forem atribu´ıdas pol´ıticas de intrus˜ao ou de ficheiros, o tr´afego ´e determi- nado pela pol´ıtica de intrus˜oes por omiss˜ao (ac¸˜ao por omiss˜ao).

Para cada pol´ıtica de ficheiros presente nas regras, podem ser definidos os tipos de an´alise a efetuar aos mesmos quando detetados no tr´afego da rede monitorizada, conforme ser´a explicado em maior detalhe na secc¸˜ao referente aos eventos de malware.

Na pol´ıtica de controlo de acessos apresentada na figura 3.2, encontram-se algumas regras relacionadas com a equipa de resposta a incidentes da Portugal Telecom. Estas re- gras surgem da necessidade de se efetuarem alguns testes, dentro do pr´oprio departamento de ciberseguranc¸a, relacionados com malware. Assim sendo, considerou-se pertinente a exclus˜ao dos IPs de rede afetos `a equipa de resposta a incidentes, na pol´ıtica de controlo de acessos.

Para al´em da equipa SOC, s˜ao usadas regras aplicacionais que ser˜ao detalhados na secc¸˜ao referente `a filtragem de falsos positivos. Pese embora a existˆencia destas exclus˜oes na pol´ıtica de controlo de acessos, ´e preciso salientar que estas encontram-se em log para consultas que se considerem pertinentes. A sua exclus˜ao da pol´ıtica serve apenas para ignorar an´alises de intrus˜oes e de ficheiros que tenham como origem ou destino os j´a referidos objetos.

No caso particular da Portugal Telecom foi implementada a pol´ıtica “Security over Connectivity” por omiss˜ao. A principal diferenc¸a entre as diferentes pol´ıticas por omiss˜ao existentes na plataforma reside essencialmente no n´umero de regras de detec¸˜ao de in- trus˜oes ativadas por omiss˜ao.

Figura 3.2: Pol´ıtica de controlo de acessos implementada na DCY/PT