Resposta à incidentes e investigações

Resposta à incidentes e investigações
Compartilhar no facebook
Compartilhar no linkedin
Compartilhar no twitter
Compartilhar no whatsapp
Sobre o autor: Guilherme Teles é um cara qualquer que não dorme direito e acaba escrevendo. Sou Certificado CISSP, CHFI, CEH, LPIC-3, AWS CDA, AWS SAA, AWS SOA Quer assinar a newsletter do site e receber esse e outros artigos? Clique aqui! Aproveite e navegue pelo smeu blog. Quem sabe você não está exatamente precisando de uma ajuda ?  

Investigação forense é a investigação e análise de todos os pacotes e eventos gerados em qualquer rede dada na esperança de identificar a famosa agulha num palheiro.

Fortemente relacionada é a resposta a incidentes, o que implica agir em tempo hábil a uma anomalia identificada ou ataque em todo o sistema. Para ser bem sucedido, ambos eventos, de rede e resposta à incidentes dependem fortemente de técnicas de gerenciamento de log de eventos e ferramentas relacionadas apropriadas.

Antes que um incidente possa ter uma resposta adequada, existe o desafio de determinar se um evento é um evento de rotina do sistema ou um incidente real. Isto requer que exista alguma estrutura para a classificação de incidentes (o processo de examinar um possível incidente e determinar se é ou não um falso positivo e requer uma ação).

Relatórios iniciais de usuários finais, sistemas de detecção de intrusão, proteção em host e detecção de malware baseada em rede e administradores de sistemas são todas as formas para controlar e detectar os candidatos à tais incidentes. Como mencionado em meus artigos anteriores, as fases de um incidente normalmente se desdobram na seguinte ordem: preparação, identificação (detecção), contenção, erradicação, recuperação e lições aprendidas.

A fase de preparação requer uma compreensão detalhada dos sistemas de informação e as ameaças que enfrentam (semelhante à uma analise de riscos). De modo a realizar um planejamento adequado, uma organização deve desenvolver respostas predefinidas que orientam os usuários através dos passos necessários para responder adequadamente a um incidente.

Predefinir respostas a incidentes permite uma reação rápida, sem confusão ou desperdício de tempo e esforço, que pode ser crucial para o sucesso de uma resposta a incidentes.

Identificação ocorre uma vez com um incidente real sendo confirmado e devidamente classificado como um incidente que requer açao. Nesse ponto, a equipe de segurança move desde a identificação à contenção. Na fase de contenção, uma série de etapas são tomadas pela equipe de segurança e outros. Estes passos que são para responder a um incidente devem ocorrer rapidamente e podem ocorrer simultaneamente, incluindo notificação de key users, e gerentes de área, com a atribuição de tarefas, e documentação do incidente.

Estratégias de contenção podem se concentrar em duas tarefas: em primeiro lugar, parando o incidente de obter qualquer informação sensível, e em segundo lugar, recuperando o controle do sistema se tiver sido efetivado.

Uma vez que o incidente foi contido e o controle do sistema recuperado, a erradicação pode começar, e a equipe de resposta à incidentes deve avaliar a extensão dos danos para determinar o que deve ser feito para restaurar o sistema.

A determinação imediata do âmbito da violação da confidencialidade, integridade, e disponibilidade dos ativos de informação e informação é chamado de avaliação de danos incidente.

Os integrantes do time de segurança responsáveis por documentar os danos, devem ser treinados para recolher e preservar as provas no caso de o incidente ser parte de uma investigação criminal ou resultados em ação legal.

Checklist Clipboard Shows Test To Do List Or Questionnaire

No momento em que a extensão do dano tenha sido determinada, o processo de recuperação
começa a identificar e a resolver as vulnerabilidades que permitiram o incidente ocorrer em primeiro lugar. A equipe de resposta à incidentes deve abordar os problemas encontrados e determinar se eles precisam instalar e/ou substituir ou atualizar os sistemas e registros que não conseguiram parar ou limitar o incidente ou estavam em falta do sistema em primeiro lugar.

Finalmente, uma discussão das lições aprendidas devem ser sempre conduzida para prevenir futuros incidentes similares ocorram e rever o que poderia ter sido feito diferente.

Em resumo, treinar, multiplicar conhecimento, e divulgar as ações com transparência.

Sobre o autor: Guilherme Teles é um cara qualquer que não dorme direito e acaba escrevendo. Sou Certificado CISSP, CHFI, CEH, LPIC-3, AWS CDA, AWS SAA, AWS SOA Quer assinar a newsletter do site e receber esse e outros artigos? Clique aqui! Aproveite e navegue pelo smeu blog. Quem sabe você não está exatamente precisando de uma ajuda ?  

Conteúdos relacionados

All articles loaded
No more articles to load

© 2019 GRRP Tech. Todos os direitos reservados.

Desenvolvido por Upsites