Como Funciona o NIST — Cybersecurity Framework

Uma análise compreensiva dos métodos utilizados durante o procedimento de resposta a incidentes

Sumário

De acordo com as recomendações publicadas pelo NIST, os processos de resposta a incidentes cibernéticos devem ser tratados em 4 etapas. Sendo elas:

• Preparação
• Detecção e Análise
• Contenção, Erradicação e Recuperação
• Atividade pós-incidente

Através deste artigo pretendo explicar cada etapa e seus procedimentos específicos, conforme indicado pelo NIST.

Procedimentos de Preparação

A começar pela etapa de preparação — estão os preparativos feitos antes de intervir em um incidente de segurança cibernética.

Esta fase abrange o trabalho que uma organização realiza para se preparar para a resposta a incidentes, incluindo o estabelecimento das ferramentas e recursos corretos, assim como o treinamento da equipe antes do incidente ocorrer.

Como a rede de comunicação interna também pode ter sido comprometida no momento do incidente, as comunicações devem ser realizadas por diferentes canais durante a resposta ao incidente. Por esta razão, devem ser preparados com antecedência telefones e linhas separados para serem usados pelos respondentes do incidente durante este procedimento.

Também é recomendável criar uma “sala de guerra” para ser usada durante incidentes de segurança cibernética. (Salas de guerra são as salas internas onde os colaboradores se reúnem para discutir estratégias para resolver os problemas encontrados.).

Através deste procedimento é de suma importância possuir as informações de toda a infraestrutura crítica, especialmente os servidores (servidores Web, servidores FTP, servidores Exchange, servidores SWIFT, dentre outros de maior importância); Estas informações devem ser mantidas sempre atualizadas.

As listas de inventário que não são mantidas atualizadas impactarão os processos de resposta a incidentes de forma impactante, podendo causar perda de tempo e decisões erradas durante o processo de resposta a incidentes.

Por exemplo, se o endereço de IP “10.75.11.10” pertencer a “Web-Server” de acordo com uma lista de inventário desatualizada, mas na verdade pertence a um servidor diferente, isso confundirá as coisas, podendo causar atraso das ações necessárias a serem tomadas para conter o incidente. Manter uma lista de inventário atualizada é uma tarefa trabalhosa e, portanto, pode ser realizada de maneira automatizada.

A etapa de preparação também inclui os preparativos para a prevenção de incidentes de segurança cibernética antes que eles ocorram. As organizações devem fazer os investimentos necessários nesse sentido e fornecer proteção em várias camadas, implantando diferentes soluções de segurança, tais como:

• Endpoint detection and response (EDR);
• Sistema de detecção de intrusão (IPS/IDS);
• Antivírus, Web application firewall (WAF), firewall, e Softwares de prevenção de perca de dados (DLP).

Ao mesmo tempo, o nível de conscientização dos funcionários contra ataques de engenharia social deve ser aumentado pela realização de testes de engenharia social regularmente.

De acordo com o NIST, tais etapas de preparação devem ser seguidas de forma em que:

1. Seja primeiro criada uma política e um plano de resposta a incidentes;
2. Devem ser desenvolvidos procedimentos para realizar o tratamento e relatórios de incidentes;
3. Devem ser definidas diretrizes para comunicação com terceiros (sejam diferentes setores ou diretoria) em relação a incidentes;
4. Deve-se estabelecer relacionamentos e linhas de comunicação entre a equipe de resposta a incidentes e outros grupos, tanto internos (por exemplo, departamento jurídico) quanto externos (por exemplo, agências de aplicação da lei);
5. Determinar quais serviços a equipe de resposta a incidentes deve fornecer;
6. Oferecer treinamentos constantes para a equipe de resposta a incidentes.

Detecção & Análise

A Detecção e Análise é a etapa em que o incidente de cibersegurança é detectado e investigado com maior profundidade.

Os eventos de segurança cibernética podem ser transmitidos por meio de diferentes canais. Por exemplo, pode ser por meio de uma regra SIEM acionada, um alerta acionado pelos produtos de segurança instalados, a equipe de TI informando que o sistema está lento ou uma notificação enviada a você por meio do formulário de contato de sua organização.

No entanto, a detecção deve ser inicialmente verificada e avaliada, deve ser avaliado se de fato trata-se de um incidente, ou um possível falso positivo.

Por exemplo, você tem uma detecção da sua equipe de TI indicando alguma anormalidade na extensão dos arquivos no servidor. Se você presumir que é causado diretamente por ransomware e os processos de resposta a incidentes e isolar o servidor, poderá causar alguma interrupção desnecessária do serviço.

Deve-se primeiro verificar a detecção de entrada. Portanto, a primeira coisa que você precisa fazer é verificar se o arquivo realmente possui uma extensão anormal. Lembre-se de que a detecção correta nem sempre prova que se trata de um incidente de cibersegurança.

Mesmo que a extensão do arquivo seja anormal, alguém com acesso ao servidor pode ter feito isso por engano. O que você precisa fazer é investigar o motivo pelo qual a extensão do arquivo é uma extensão anormal (por exemplo, investigar os Sysmon Logs para poder entender quem modificou o arquivo e qual processo o individuo usou para fazer isso).

Se você realmente acha que há um incidente de segurança cibernética, deve começar a coletar e registrar as evidências. Para coleta de evidências, podem ser utilizados sistemas de rastreamento de problemas para registrar informações, evidências e ações sobre o evento.

As informações que devem constar no sistema de rastreamento de problemas recomendado pelo NIST são as seguintes:

1. Deve ser documentado o status atual do incidente (novo, em andamento, encaminhado para investigação, resolvido, etc.);
2. Deve ser fornecido um resumo do incidente, assim como evidências coletadas, e indicadores de comprometimento (IOCs) relacionados ao incidente;
3. Deve ser analisada a possibilidade de outros incidentes relacionados a este incidente;
4. Documentação das tratativas realizadas durante o incidente;
5. Cadeia de custódia, se aplicável;
6. Avaliações de impacto relacionadas ao incidente;
7. Informações de contato de outras partes envolvidas (por exemplo, proprietários do sistema, ou administradores do sistema);
8. Próximas etapas a serem executadas para mitigação (por exemplo, reconstruir o host, atualizar uma aplicação..).

Os incidentes devem ser prioritizados através da perspectiva de gravidade, criticidade, área de impacto, danos potenciais, e consequentemente, tratados de acordo com essa priorização. Neste quesito, as categorias publicadas pelo NIST podem ser utilizadas para ajudar no procedimento de prioritização dos eventos de segurança cibernética:

Tabela 01: Categorias de impacto funcional de acordo com o NIST SP 800–61

Tabela 02:Categorias de impacto da informação de acordo com o NIST SP 800–61

Tabela 03: Categorias de esforço de recuperabilidade de acordo com o NIST SP 800–61

As organizações também devem estabelecer um processo de escalonamento para as instâncias em que a equipe não responde a um incidente dentro do prazo designado. Isso pode acontecer por vários motivos: por exemplo, os telefones podem falhar ou as pessoas podem ter emergências pessoais.

O processo de escalonamento deve indicar quanto tempo uma pessoa deve esperar por uma resposta e o que fazer se nenhuma resposta ocorrer. Geralmente, o primeiro passo é duplicar o contato inicial. Depois de esperar por um breve período — talvez 15 minutos — deve-se encaminhar o incidente para um nível superior, como o gerente da equipe de resposta a incidentes. Se essa pessoa não responder dentro de um certo tempo, o incidente deve ser escalonado novamente para um nível superior de gerenciamento até que se tenha uma resposta.

Após a realização das ações anteriores, cada detalhe deve ser analisado desde o momento da primeira etapa de acesso do invasor até suas atividades mais recentes nos sistemas corporativos.

Ao responder ao incidente, nossa prioridade deve ser detectar o método de acesso do invasor e interromper esse acesso.

Vamos pensar em um cenário em que um invasor obtém acesso ao sistema explorando uma vulnerabilidade que ele detectou em uma aplicação Web — Se excluído o payload mal-intencionado dos servidores antes de encontrar o método de acesso inicial do invasor, o invasor pode então explorar a vulnerabilidade novamente. Por esse motivo, antes de tudo, a causa raiz deve ser detectada e corrigida.

Após a detecção da causa raiz, devemos executar a etapa de Contenção, Erradicação e Recuperação para evitar que o invasor comprometa os sistemas novamente durante os esforços de resposta a incidentes. Após esta etapa, as demais atividades do invasor devem ser analisadas.

Após comprovação de incidente, e detecção da ameaça, os dispositivos e usuários comprometidos devem ser isolados da rede rapidamente.

Contenção, Erradicação & Recuperação

A etapa de Contenção, Erradicação e Recuperação inclui o isolamento, bloqueio dos indicadores/métodos de persistência utilizados no ataque e restauração dos sistemas.

A etapa de contenção é onde o atacante é isolado para que não possa causar mais danos. Esta etapa deve ser realizada assim que o evento for detectado e confirmado como um incidente de cibersegurança para que o atacante não cause mais danos aos sistemas vulneráveis.

Essa etapa pode ser diferente dependendo do tipo e criticidade do incidente de segurança cibernética. Alguns métodos de contenção que podem ser aplicados são:

1. Colocar o dispositivo em um segmento de rede isolado;
2. Interromper os serviços afetados;
3. Desligar o aparelho afetado;
4. Desligar o dispositivo da rede;
5. Desativar a conta do usuário na rede corporativa.

Os softwares de EDR atuais vem com recurso de contenção. Com esse recurso, o dispositivo no qual o agente está instalado é separado da rede e se comunica apenas com o servidor central EDR. Desta forma, ao realizar a análise ao vivo no dispositivo, o isolamento do dispositivo também é garantido.

Como não é possível isolar servidores críticos diretamente da rede, é altamente recomendável preparar um procedimento de contenção separado para aplicativos/servidores críticos.

A etapa de erradicação inclui atividades remoção e bloqueio do software malicioso deixado pelo invasor, desabilitar os usuários comprometidos, excluir possíveis usuários criados pelo invasor.

O ponto mais importante que não deve ser esquecido nesta etapa é que os indicadores pertencentes ao ataque devem ser registrados como evidência antes de serem excluídos.

Por exemplo — antes de excluir um software malicioso usado no ataque do servidor, é necessário fazer uma captura de tela da pasta onde o malware está localizado, salvar as informações de hash do malware e gravar uma cópia do malware em um ambiente isolado.

As atividades a serem realizadas na etapa de erradicação podem ser listadas como:

1. Remoção dos arquivos enviados pelo invasor;
2. Desativar/excluir usuários comprometidos;
3. Excluir usuários criados pelo invasor;
4. Encerramento de processos suspeitos em execução.

A fase de recuperação inclui a restauração dos servidores/dispositivos/serviços afetados para seu estado operacional anterior e a confirmação de seu funcionamento adequado.

A fase de recuperação varia de organização para organização. Certifique-se de que sua organização tenha uma estratégia de recuperação adequada. As estratégias que podem ser aplicadas na fase de recuperação podem ser listadas como:

1. Utilização do backup pré ataque;
2. Reconstruir os sistemas do zero;
3. Substituir softwares comprometidos por versões atualizadas;
4. Realizar a instalação de patches de segurança;
5. Alteração de senhas cadastradas na rede.

Atividade pós-incidente

A partir deste ponto o incidente ocorrido deve ser avaliado desde o início e o que pode ser feito para melhor evitar ou prevenir outro incidente de segurança cibernética deve ser discutido. Um incidente de segurança cibernética é inevitável, mas isso não significa que não podemos aprender com incidentes passados e utilizarmos dos mesmos para nos prevenirmos.

Após um incidente, é recomendado que seja realizada uma reunião sobre o incidente de segurança cibernética com todas as equipes envolvidas.

O NIST também fornece um roteiro de pontos que devem ser discutidos após a ocorrência de um incidente:

1. O que aconteceu exatamente e em que momento?
2. Quão bem a equipe e a gerência lidaram com o incidente?
3. Os procedimentos documentados foram seguidos? Eles foram adequados?
4. Que informação era necessária antes?
5. Foram tomadas medidas ou ações que possam ter inibido a recuperação?
6. O que a equipe e a gerência fariam de maneira diferente na próxima vez que um incidente semelhante ocorresse?
7. Como o compartilhamento de informações com outras organizações poderia ter sido melhorado?
8. Que ações corretivas podem evitar incidentes semelhantes no futuro?
9. Quais precursores ou indicadores devem ser observados no futuro para detectar incidentes semelhantes?
10. Quais ferramentas ou recursos adicionais são necessários para detectar, analisar e mitigar futuros incidentes?

Um relatório completo de resposta ao incidente deve ser preparado e armazenado em local seguro.

Este estudo foi conduzido com base no NIST. Mais informações podem ser verificadas sob os seguintes links (em inglês):

• Understanding the NIST cybersecurity framework: https://www.ftc.gov/business-guidance/small-businesses/cybersecurity/nist-framework
• NIST — Cybersecurity Incident Handling Guide (LetsDefend): https://app.letsdefend.io/training
• NIST SP 800–61: https://learn.saylor.org/mod/book/view.php?id=29706&chapterid=5347