Por João Galvão, Security Incident Response Manager
Vivemos numa era caracterizada por constantes descobertas e desenvolvimentos, principalmente quando falamos daquilo que é o mundo digital e a grande onda migratória para a cloud, levando ao aumento exponencial do leque de produtos, serviços e plataformas que temos à nossa disposição, e, consequentemente, ao aumento da superfície de ataque, abrindo novos caminhos aos actores maliciosos, que estão sempre à procura de uma porta para entrar.
Desde organizações de renome mundial, passando por pequenas e médias empresas, e tantas outras instituições, o investimento na área da segurança da informação tem vindo a aumentar ao longo dos anos, bem como a procura por profissionais especializados nesta área que, por si mesma, encapsula também tantas especializações diferentes, incluindo a resposta a incidentes de segurança informática.
Apesar dos esforços contínuos de toda uma comunidade internacional, os incidentes de segurança continuam a causar danos reais nas vidas de muitas pessoas, visto que, hoje, muitas vidas dependem também da segurança, acessibilidade e fiabilidade da sua informação, e dos sistemas electrónicos que a suportam.
O relatório anual da Agência Europeia para a Segurança das Redes e da Informação (ENISA) sobre o cenário de ameaças internacional durante o ano de 2022 identificou como principais ameaças os seguintes tipos de incidente de segurança informática:
• Ransomware
• Malware
• Ataques de engenharia social
• Ataques contra dados
• Ataques contra disponibilidade: Negação de serviço
• Ataques contra disponibilidade: Ameaças da Internet
• Desinformação
• Ataques à cadeia de fornecimento
Um estudo recente por parte da empresa Chainalysis, uma plataforma focada na análise de dados sobre a blockchain, revela que os ataques de ransomware continuam a aumentar e os actores maliciosos já estão a caminho do seu segundo ano mais lucrativo de sempre. Em Junho, os valores já atingiram um mínimo de 449,1 milhões de dólares extorquidos a instituições comprometidas.
O Caos
Os incidentes de segurança informática representam, muitas das vezes, cenários de foro caótico. Estando o conceito de Caos relacionado com aspectos como incerteza, confusão, aleatoriedade, entropia, imprevisibilidade ou complexidade, conseguimos relacionar várias destas características com os incidentes de segurança informática. Acontecem sem aviso prévio, em ambientes que estão em constante mutação, com sistemas distintos, complexos e interligados entre si, permitindo muitas vezes que se infectem outros sistemas, aumentando o impacto operacional, financeiro, reputacional, legal, regulatório, entre outros.
“Existem apenas dois tipos de empresas: as que já foram pirateadas e as que ainda o serão”. Esta frase bastante conhecida, atribuída a Robert Mueller, antigo director do FBI, caracteriza bem o panorama actual do mundo da segurança informática.
No entanto, apesar das características associadas ao Caos, listadas acima, este também pode ser uma força motriz para o impulso de melhorias e crescimento, pois estimula aspectos como a criatividade, a adaptabilidade, a resiliência, o combate à estagnação, e pode até estar associado a ganhar uma vantagem competitiva, devido a uma maior preparação para tais cenários.
A Ordem
Com o crescimento do número de ocorrências deste tipo de incidentes, aumenta a probabilidade de que ocorra em todas as instituições que prescindem de sistemas computacionais, conectados entre si, para prestar serviços diversos. Assim, quanto melhor preparada estiver uma organização, mais eficaz vai ser a sua resposta, e menor vai ser o tempo até à, tão desejada, resolução.
Como tal, várias instituições, de foro privado, governamental, ou de fins não-lucrativos, têm vindo a criar diferentes estruturas focadas na resposta a incidentes de segurança informática, de forma a melhorar as possibilidades das instituições para respostas mais ordenadas e coerentes, o que permite também uma maior automatização.
Neste artigo, cobrimos alguns exemplos básicos.
RFC2350
Publicado em 1998, e disponível no site da organização Internet Engineering Task Force (IETF), este documento expressa as expectativas gerais da comunidade da Internet, relativamente às equipas de resposta a incidentes de segurança informática (CSIRT – Computer Security Incident Response Team), e ainda é utilizado por muitas instituições, hoje em dia.
Embora não seja possível criar uma estrutura que se aplique a todas as equipas, este documento pretende definir uma base para alguns dos aspectos que deverão ser comuns à maioria das mesmas.
Entre eles, estão:
• Data, versão, e localização;
• Lista de distribuição para notificações;
• Autenticidade;
• Métodos de comunicação;
• Constituição da equipa;
• Âmbito;
• Autoridade;
• Níveis de suporte;
• Serviços; e
• Templates documentais.
Este documento é muitas vezes disponibilizado publicamente pelas organizações, empresas e agências governamentais, bastando uma pesquisa na Internet por “RFC2350” para encontrarmos bastantes exemplos dos mesmos.
Ciclo de vida
Uma das componentes importantes é também a definição do ciclo de vida de um incidente, ou qual o modelo a seguir, e posterior mapeamento do mesmo para as aplicações utilizadas na gestão deste tipo de ocorrências pelas equipa operacionais em funções.
Embora existam diferentes modelos conhecidos, e até algumas variantes do mesmo, a proposta da agência governamental dos Estados Unidos da América, National Institute of Standards and Technology (NIST), é uma das mais utilizadas globalmente, dividindo a resposta a incidentes de segurança em 7 fases:
- Preparação
- Detecção
- Análise
- Contenção
- Erradicação
- Recuperação
- Actividade pós-incidente
Preparação
Tal como o nome indica, esta fase centra-se na preparação para os incidentes de segurança informática, seja através de medidas para impedir os mesmos, como a criação de uma equipa de resposta a incidentes, ou para medidas para melhorar a resposta em si, aquando de uma ocorrência inesperada. Isto deverá envolver também aspectos como a definição de funções e responsabilidades, a criação de um plano de resposta a incidentes, e a implementação de medidas preventivas e controlos de segurança, para minimizar os riscos dos activos da instituição.
Detecção e análise
Normalmente agregadas visualmente, e até em termos funcionais, as fases de detecção e análise caracterizam-se pela detecção de possíveis ameaças através de sistemas de monitorização, e análise dos mesmos para determinar a sua natureza, e possível impacto. As equipas recorrem a aplicações de segurança para identificar sinais de possível comprometimento ou potenciais violações de dados.
A razão para a agregação visual, e possivelmente cíclica, destas duas fases deve-se ao facto de que, aquando de uma análise, é possível que sejam identificados sinais que indiquem a detecção de novas ocorrências ligadas, directa ou indirectamente, à ocorrência original em análise.
Contenção, Erradicação e Recuperação
Sintetizando, o foco destas três fases é conter o incidente, remover a ameaça e recuperar os sistemas e dados afectados. Isto pode abranger actividades como o isolamento dos sistemas comprometidos, a erradicação da raiz do problema e o restabelecimento das operações normais através de soluções backup, activação de servidores, entre outros.
Usando uma analogia médica, quando existem incidentes relacionados com a saúde, a fase de contenção é representada pelo penso na ferida, o garrote ou a ligadura, que pomos para estancar os danos sofridos de forma temporária, sendo que a fase de erradicação é toda a parte dos procedimentos que se seguem, como as avaliações médicas, os exames efectuados por máquinas complexas, ou intervenções médicas mais precisas. Por último (entre estas três), e tal como o nome indica, a fase de recuperação caracteriza-se pelo período seguinte à erradicação, onde a pessoa recupera operacionalmente, e volta à sua vida de uma forma funcional.
Actividade pós-incidente
Após um incidente de segurança informática, pode ser necessário efectuar uma análise pós-incidente, de forma a tirar lições da experiência.
As lições aprendidas, a documentação e as melhorias identificadas nos próprios processos devem ser documentadas, para referência futura.
Caso haja necessidade, ou assim se justifique, o plano de resposta a incidentes, e os processos associados, podem ser actualizados como resultados destas actividades, bem como os mecanismos de segurança implementados para impedir ou prevenir tipos de ataques semelhantes.
Este é apenas um dos modelos disponíveis, mas que se integrado na plataforma de gestão de incidentes utilizada pelas instituições, pode criar uma base estrutural para começar a implementar alguma ordem, em situações que iriam ser caóticas, tanto por ajudar a consolidar os processos de resposta a incidentes, como por construir mecanismos que permitem que os procedimentos necessários sejam mais coesos.
É ainda importante referir que este ciclo de vida é parte integrante de um documento mais abrangente (publicação 800-61), e também muito utilizado como referência internacional, focado especificamente na resposta a incidentes de segurança informática, e intitulado “Computer Security Incident Handling Guide”.
Classificação
Outro factor crucial durante a resposta a um incidente de segurança é a classificação do mesmo, normalmente durante as fases de detecção e análise. Uma classificação correcta ajuda a entender a urgência da ocorrência e a quantidade de recursos necessários a alocar para lidar com o mesmo, bem como o tipo de situação com que se está a lidar. Alguns aspectos consideráveis quanto à classificação de incidentes de segurança estão descritos, abaixo.
• Severidade: Ao analisar um incidente de segurança, a classificação da sua severidade pode depender do tipo de funcionalidades e privilégios comprometidos ou em risco. Caso um actor malicioso consiga comprometer um sistema, a severidade da ocorrência deve ter em consideração, por exemplo, o tipo de danos que poderiam ser causados com a exploração daquele tipo de falha, com aqueles privilégios, e com o contexto arquitectural da infra-estrutura da organização.
• Criticidade: Ao definir a criticidade dos activos da instituição, as equipas também conseguirão classificar com maior precisão a urgência de cada ocorrência. Podem ser usados diferentes mecanismos para o cálculo da criticidade, sendo uma métrica comum a tríade do risco relativo à falha na confidencialidade, integridade, e disponibilidade.
• Âmbito: Dependendo do âmbito do incidente de segurança informática, também a sua urgência e medidas necessárias muda, visto que o comprometimento de um servidor de frontend da organização, por exemplo, não requer o mesmo tipo de resposta do que o comprometimento adicional de dez servidores internos com ligações ao mesmo.
• Impacto: O impacto de um incidente de segurança é muitas vezes o resultado da combinação dos dados anteriores. Conforme a severidade, a criticidade ou o risco, e o âmbito em questão, a instituição poderá calcular se o impacto total esperado será maior ou menor, bem como fazer decisões mais acertadas quanto à resposta ao incidente em si, e à alocação de meios necessários para esse efeito.
Taxonomia
Para finalizar o tema da classificação, é importante referirmos também o tópico da taxonomia, que se traduz pela classificação e organização sistemática dos incidentes de segurança, com base nas suas características comuns. Fornecendo uma estrutura para a categorização, permite às instituições uma análise, resposta e resolução com uma maior adaptação ao contexto, e com mais coerência.
Um dos exemplos de taxonomia a ser adoptada, neste caso a nível Europeu, é a taxonomia da Agência para a Cibersegurança da União Europeia (ENISA), adoptada também a nível nacional pelo Centro Nacional de Cibersegurança de Portugal, e pela rede nacional de CSIRT, que sugere diferentes categorias e subcategorias, para a classificação dos incidentes de segurança informática.
São elas:
• Conteúdo abusivo
◦ Spam;
◦ Discurso nocivo;
◦ Exploração de menores, racismo e apologia da violência.
• Código malicioso
◦ Sistema infectado;
◦ Servidor C2;
◦ Distribuição de malware;
◦ Configuração de malware.
• Recolha de informação
◦ Scanning;
◦ Sniffing;
◦ Engenharia social.
• Tentativa de intrusão
◦ Exploração de vulnerabilidade;
◦ Tentativa de login;
◦ Nova assinatura de ataque.
• Intrusão
◦ Comprometimento de conta privilegiada;
◦ Comprometimento de conta não privilegiada;
◦ Comprometimento de aplicação;
◦ Arrombamento;
• Disponibilidade
◦ Negação de serviço;
◦ Negação de serviço distribuída;
◦ Configuração incorrecta;
◦ Sabotagem;
◦ Interrupção.
• Segurança da Informação
◦ Acesso não autorizado;
◦ Modificação não autorizada;
◦ Perda de dados.
• Fraude
◦ Utilização indevida ou não autorizada de recursos
◦ Direitos de autor;
◦ Utilização ilegítima de nome de terceiros;
◦ Phishing.
• Vulnerabilidade
◦ Criptografia;
◦ Amplificador DDoS;
◦ Serviços acessíveis potencialmente indesejados;
◦ Revelação de informação.
• Outros
◦ Sem tipo;
◦ Indeterminado.
• Teste
Assim, de forma a estarem preparadas para estes tipos de incidentes de segurança, as instituições podem até criar planos, com procedimentos específicos, para as diferentes categorias ou subcategorias de incidentes adoptadas.
Embora haja muito mais a dizer sobre este tema, estes são alguns aspectos básicos que, apesar de parecerem simples, se bem implementados, já permitem criar uma base sólida para que as equipas operacionais (aquelas que mais lidam com os processos de forma diária) consigam fazê-lo de forma racionalizada e eficaz, e para que as equipas de gestão consigam garantir uma ordenação e coerência, bem como métricas fiáveis que demonstrem a taxa de sucesso e oportunidades de melhoria contínua.
Concluindo, usar bons modelos para a resposta de incidentes de segurança informática fornece também uma boa base para uma resposta mais Ordeira, através de mecanismos para gerir da melhor forma possível o Caos.
Para ler artigos como este, subscreva a nossa newsletter semanal.
