5. Tratamento de Incidentes de Segurança

Este capítulo do documento será um guia a ser usado antes, durante, e depois de um incidente de segurança de computador que aconteça em host, rede, site, ou ambiente de multi-site. A filosofia de operação no caso de uma brecha de segurança de computador é reagir conforme um plano. Isto é verdade se a brecha é o resultado de um ataque de intruso externo, dano não intencional, um estudante testando algum programa novo para explorar uma vulnerabilidade de software, ou um empregado enfadado. Cada um dos possíveis tipos de eventos, como esses listados, deveriam ser previstos com antecedência por planos de contingência adequados.

Segurança de computador tradicional, enquanto bastante importante no plano global de segurança do site, normalmente presta pouca atenção em como agir de fato uma vez que um ataque ocorra. O resultado é que quando um ataque está ocorrendo, são tomadas muitas decisões com pressa e podem estar prejudicando a identificação da fonte do incidente, a coleta de evidências para serem usadas em esforços de prossecução, preparar para a recuperação do sistema, e protegendo os dados valiosos contidos no sistema.

Um dos mais importantes, mas freqüentemente ignorados, benefícios paro tratamento eficiente do incidente é a economia. Quando ambos pessoal técnico e administrativo respondem a um incidente, isto requer recursos consideráveis. Se treinados para lidar com incidentes eficazmente, menos tempo de pessoal é requerido quando um acontece.

Devido à Internet a maioria dos incidentes não estão restritos a um único local. Vulnerabilidade de sistemas operacionais aplicam-se (em alguns casos) para vários milhões de sistemas, e muitas vulnerabilidades são exploradas dentro da própria rede. Então, é vital que todos os sites com partes envolvidas sejam informados o mais cedo possível.

Outro benefício é relacionado a relações públicas. Notícias sobre incidentes de segurança de computadores tendem a danificar a imagem de uma organização entre os clientes atuais ou potenciais. O tratamento eficiente de incidentes minimiza a exposição negativa.

Um benefício final de tratamento incidente eficiente é relacionado a assuntos legais. É possível que num futuro próximo organizações possam ser consideradas responsáveis porque um de seus nodos foi usado para lançar um ataque à rede. Em uma situação semelhante, podem ser processadas as pessoas que desenvolvem remendos ou workarounds, caso estes sejam ineficazes, resultando em comprometimento dos sistemas, ou se danificam os mesmos. Sabendo sobre vulnerabilidades do sistema operacional e padrões de ataques, e tomando medidas apropriadas para se opor a estas ameaças potenciais, é crítico para evitar possíveis problemas legais.

As seções neste capítulo provêem um esboço e ponto de partida para criar a política de seu site para tratar incidentes de segurança. As seções são:

1. preparando e planejando (quais são as metas e objetivos no tratamento de um incidente).

2. notificação (quem deveria ser contactado no caso de um incidente).

3. identificando um incidente (é um incidente e oquanto é sério).

4. tratamento (o que deveria ser feito quando um incidente acontece).

5. conseqüências (quais as implicações de incidentes passados).

6. resposta administrativa para incidentes.

O resto deste capítulo detalhará os assuntos envolvidos em cada dos tópicos importantes listados acima, e provê alguma direção sobre o que deveria ser incluído em uma política do site para tratar incidentes.

5.1 Preparando e Planejando o Tratamento de Incidentes

Parte do tratamento de um incidente é estar preparado para responder a um incidente antes dele acontecer em primeiro lugar. Isto inclui estabelecer um nível satisfatório de proteções como o explicado nos capítulos anteriores. Fazer isto ajudaria seu site a prevenir incidentes como também limitar dano potencial resultante de incidentes. Proteção também inclui preparar diretrizes de tratamento de incidentes como parte de um plano de contingência para sua organização ou site. Ter planos escritos elimina muito da ambigüidade que acontece durante um incidente, e conduzirá a um conjunto mais apropriado e completo de respostas. É vitalmente importante testar o plano proposto antes de um incidente acontecer atraves de "dry runs". Um grupo poderia considerar a contratação de um grupo-tigre até mesmo para agir em paralelo com o "dry runs" (Nota: um grupo-tigre é um grupo de especialistas que tentam penetrar a segurança de um sistema.)

1. Aprender a responder eficazmente a um incidente é importante por um número de razões:

2. proteger os recursos que poderiam ser comprometidos

3. proteger os recursos que poderiam ser utilizados mais eficientemente se um incidente não requeresse seus serviços

4. seguir os regulamentos (do governo ou outros)

5. prevenir o uso de seus sistemas em ataques contra outros sistemas (que poderia implicar em obrigações legais)

6. minimizar o potencial para exposição negativa

Como em qualquer conjunto de procedimentos previamente planejados, deve ser dada a atençãoa um conjunto de objetivos para tratar incidentes. Estas metas terão prioridades diferentes dependendo do site. Um conjunto específico de objetivos pode ser identificado:

1. descobrir como aconteceu.

2. descobrir como evitar exploração adicional da mesma vulnerabilidade.

3. evitar a expansão e incidentes adicionais.

4. avaliar o impacto e dano do incidente.

5. recuperar-se do incidente.

6. atualizar políticas e procedimentos conforme necessário.

7. descobrir quem fez isto (se apropriado e possível).

Devido à natureza do incidente, pode haver um conflito entre analisar a fonte original de um problema e restabelecer sistemas e serviços. Metas globais (como assegurar a integridade de sistemas críticos) pode ser uma razão para não analisar um incidente. É claro, esta é uma decisão de administração importante; mas todas as partes envolvidas devem estar consientes que sem análise pode o mesmo incidente acontecer novamente.

Também é importante priorizar as ações a ser tomadas durante um incidente com bastante antecendência antes do incidente acontecer. Às vezes um incidente pode ser tão complexo que é impossível fazer tudo ao mesmo tempo para responder a ele; prioridades são essenciais. Embora prioridades variem de instituição para instituição, as seguintes sugestões de prioridades podem servir como ponto de partida para definir a resposta de sua organização:

Prioridade 1 --proteja vida humana e segurança das pessoas; vida humana sempre tem precedência sobre outras considerações.

Prioridade 2 -- proteger dados importantes. Previna exploração sistemas, redes ou locais importantes. Informe sistemas, redes ou locais importantes que tenham sido afetados sobre invasões acontecidas.(Esteja atento aos regulamentos de seu site ou do governo)

Prioridade 3--proteja outros dados incluindo dados proprietários, científicos, administrativos e outros, pois perda de dados é cara em termos de recursos.Previna explorações de outros sistemas, redes ou locais e informe os sistemas, redes ou locais afetados sobre invasões bem sucedidas.

Prioridade 4--previna dano para sistemas (por exemplo, perda ou alteração de arquivos de sistemas, danos a unidades de disco, etc.). Danos em sistemas pode resultar em custo de recuperação alto.

Prioridade 5--minimize a interrupçãodos recursos de computação(inclusive processos). É melhor em muitos casos desligar um sistema ou desconecta-lo de uma rede que arriscar dano para dados ou sistemas. Os sites terão que avaliar a melhor opção entre desligar e desconectar, manter o sistema funcionando. Pode haver acordos de serviços em lugares que podem requerer a manutenção dos sistemas no ar mesmo com a possibilidade de danos adicionais. Porém, o dano e escopo de um incidente podem ser tão extensos que aqueles acordos de serviço podem ter que ser ignorados.

Uma implicação importante para definir prioridades é que uma vez que a vida humana e considerações de segurança nacionais foram previstas, é geralmente mais importante salvar dados que software e hardware. Embora é indesejável ter qualquer dano ou perda durante um incidente, sistemas podem ser substituídos. Porém, a perda ou comprometimento de dados (especialmente classificados ou proprietários) normalmente não é de forma alguma um resultado aceitável.

Outra preocupação importante é o efeito em outros, além dos sistemas e redes onde o incidente acontece. Dentro dos limites impostos por regulamentos governamentais é sempre importante informar as partess afetadas o mais cedo possível. Devido às implicações legais deste tópico, ele deveria ser incluído nos procedimentos planejados para evitar demoras adicionais e incertezas para os administradores.

Qualquer plano para responder a incidentes de segurança deveria ser guiado por políticas locais e regulamentos. Sites privados e do governo que lidem com material classificado tem regras específicas que eles devem seguir.

As políticas escolhidas por seu site sobre como reagir a incidentes irá moldar sua resposta Por exemplo, pode fazer pouco sentido criar mecanismos para monitorar e rastrear intrusos se o seu site não planeja entrar em ação contra os intrusos caso eles sejam pegos. Outras organizações podem ter políticas que afetam seus planos. Companhias de telefone freqüentemente liberam informações sobre rastreamento de telefones apenas para agências responsáveis pela execução da lei.

Tratar incidentes pode ser tedioso e requerer qualquer número de tarefas rotineiras que poderiam ser tratadas pelo pessoal de apoio. Para liberar o pessoal técnico, é útil identificar pessoal de apoio que ajudará com tarefas como: fotocopiar, passar fax, etc.

5.2 Notificação e Pontos de Contato

É importante estabelecer contatos com várias pessoas antes de um incidente real acontecer. Muitas vezes, incidentes não são emergências reais. Na realidade, com freqüência você poderá tratar as atividades internamente. Porém, também haverá muitas vezes quando outros fora de seu departamento imediato precisarão ser incluídos no tratamento de incidentes. Estes contatos adicionais incluem os gerentes locais e os administradores de sistemas, contatos administrativos para outros sites na Internet, e várias organizações investigativas. Conhecendo estes contatos antes dos incidentes acontecerem ajudará a fazer seu processo de tratamento de incidentes mais eficiente.

Para cada tipo de contato de comunicação, Pontos de Contato (POC) específicos deveriam ser definido. Estes podem ser de natureza técnica ou administrativa e podem incluir agências legais ou investigativas como também os provedores de serviço e vendedores. Ao estabelecer estes contatos, é importante decidir quanta informação será compartilhada com cada classe de contato. É especialmente importante definir, com antecedência, que informação será compartilhada com os usuários de um site, com o público (inclusive a imprensa), e com outros sites.

Determinar estes assuntos é especialmente importantes para a pessoa local responsável por tratar o incidente, já que essa pessoa é responsável pela notificação dos outros. Uma lista de contatos em cada uma destas categorias representam uma economia de tempo importante para esta pessoa durante um incidente. Pode ser bastante difícil achar uma pessoa apropriada durante um incidente quando muitos eventos urgentes estão acontecendo. É fortemente recomendado que os números de telefone pertinentes (também endereços de correio eletrônicos e números de fax) sejam incluídos na política de segurança do site. Os nomes e informações de contato de todos os indivíduos que estarão envolvidos diretamente no tratamento de um incidente devem ser colocados no topo desta lista.

5.2.1 Gerentes locais e Pessoal

Quando um incidente está ocorrendo, uma questão importante é decidir quem está encarregado de coordenar a atividade dos diversos jogadores. Um dos maiores enganos que pode ser cometido é ter várias pessoas cada qual trabalhando independentemente, mas não trabalhando junto. Isto só aumenta a confusão do evento e provavelmente conduzirá a esforço desperdiçado ou ineficaz.

O único POC pode ou não ser a pessoa responsável por tratar o incidente. Há dois papéis distintos a serem preenchidos quando se está decidindo quem será POC e quem será a pessoa encarregada do incidente. A pessoa emcarregada do incidente tomará decisões sobre a interpretação da política aplicada ao evento. Em contraste, o POC deve coordenar os esforços de todas as partes envolvidas no tratamento do evento.

O POC deve ser uma pessoa com perícia técnica para coordenar com sucesso os esforços dos gerentes de sistemas e usuários envolvidos na monitoração e reação ao ataque. Cuidado deveria ser tomado ao identificar quem será esta pessoa. Não deveria ser necessariamente a mesma pessoa que tem responsabilidade administrativa pelos sistemas comprometidos uma vez que freqüentemente tais administradores tem conhecimento suficiente apenas para o uso dos computadores no dia-a-dia, faltando-lhes conhecimento técnico mais profundo.

Outra função importante do POC é manter contato com as autoridades legais competentes e outras agências externas para assegurar que o envolvimento multi-agência. O nível de envolvimento será determinado através de decisões de administração bem como por restrições legais.

Um único POC também deveria ser a única pessoa encarregada de coletar evidências, desde que como regra geral, quanto mais pessoas tocam uma peça potencial de evidência, o maior a possibilidade de que esta seja inadmissível no tribunal. Para assegurar que as evidências serão aceitáveis para a comunidade legal, a coleta de evidências deve ser feita seguindo-se procedimentos predefinedos, de acordo com leis locais e regulamentos legais.

Um das tarefas mais críticas para o POC é a coordenação de todos os processos pertinentes. Responsabilidades podem ser distribuídas sobre o site inteiro, envolvendo múltiplos departamentos ou grupos independentes. Isto irá requerer um esforço bem coordenado para alcançar sucesso global. A situação fica ainda mais complexa se múltiplos sites estão envolvidos. Quando isto acontece, raramente um único POC num site poderá coordenar o tratamento do incidente inteiro adequadamente. Ao invés disso, deveriam ser envolvidos grupos apropriados de resposta a incidentes.

O processo de tratamento de incidentes deveria prover alguns mecanismos de ampliação. Para definir tal mecanismo, os sites precisarão criar um esquema de classificação interno para incidentes. Associado a cada nível de incidente estarão o POC e procedimentos apropriados. Conforme um incidente aumenta, pode haver uma mudança do POC que precisará ser comunicada a todos os outros envolvidos no tratamento do incidente. Quando uma mudança no POC acontece, o POC antigo deve fazer um resumo para o POC novo sobre toda a informação background.

Finalmente, usuários têm que saber informar incidentes suspeitos. Os sites devem estabelecer procedimentos de informe que irão funcionar durante e fora de horas de trabalho normais. "Help desks" freqüentemente são usadas para receber estes relatórios durante horas de trabalho normais, enquanto beepers e telefones podem ser usados fora de hora.

5.2.2 Agências de Investigação e de Execução da Lei

No caso de um incidente que tem conseqüências legais, é importante estabelecer contato com agências investigativas (por exemplo, o FBI e Serviço Secreto nos E.U.A.) o mais cedo possível. As autoridades locais, escritórios de segurança locais, e departamento policial do campus também deveriam ser informados conforme apropriado. Esta seção descreve muitos dos assuntos que serão confrontados, mas é reconhecido que cada organização terá suas próprias leis e regulamentos locais e do governo que terão impacto sobre como eles interagem com a execução da lei e agências investigativas. O ponto mais importante é que cada site precisa trabalhar estes assuntos.

Uma razão primária por determinar estes pontos de contato com antecedência, antes de um incidente é que uma vez que um ataque maior está em progresso, há pouco tempo para chamar estas agências para determinar exatamente quemé o ponto de contato correto. Outra razão é que é importante cooperar com estas agências de maneira a nutrir uma boa relação de trabalho, e a estar de acordo com os procedimentos de trabalho destas agências. Conhecer os procedimentos de funcionamento com antecedência, e as expectativas de seu ponto de contato é um grande passo nesta direção. Por exemplo, é importante juntar evidências que serão admissíveis em qualquer procedimento legal subseqüente, e isto requer conhecimento anterior de como juntar tal evidência. Uma razão final para estabelecer contatos o mais cedo possível é que é impossível conhecer que agência em particular assumirá a jurisdição em um dado incidente. Fazer contatos e achar os canais apropriados cedo farão a resposta a um incidente transcorrer consideravelmente mais suavemente.

Se sua organização ou site tem um conselho legal, você precisa notificar esta entidade logo em seguida que você perceber que um incidente está ocorrendo. Nomínimo, seu conselho legal precisa estar envolvido para proteger os interesses legais e financeiros de seu site ou organização. Existem muitos assuntos legais e práticos, alguns deles sendo:

(1) Se seu site ou organização está disposta a arriscar publicidade ou exposição negativa para cooperar com esforços de prossecução legais.

(2) Obrigação "downstream"-se você deixa um sistema comprometido como está para poder ser monitorado e outro computador é danificado porque o ataque se originou de seu sistema, seu site ou organização pode ser responsável por danos incorridos.

(3) Distribuição de informação--se seu site ou organização distribui informações sobre um ataque no qual outro site ou organização pode ser envolvida ou a vulnerabilidade dm um produto isso pode afetar a habilidade de comercializar aquele produto, seu site ou organização pode ser novamente responsabilizado por qualquer dano (incluindo dano de reputação).

(4) Obrigações devido a monitoração--seu site ou organização pode ser processada se usuários em seu site ou em outro lugar descobrem que seu site está monitorando atividades das contas sem informar os usuários.

Infelizmente, não há ainda nenhum precedente claro nas obrigações ou responsabilidades de organizações envolvidas em um incidente de segurança ou quem poderia ser envolvido no apoio a um esforço investigativo. Investigadores encorajarão freqüentemente organizações para ajudar a rastrear e monitorar intrusos. Realmente, a maioria dos investigadores não pode procurar intrusões de computador sem apoio extenso das organizações envolvidas. Porém, investigadores não podem prover proteção contra reivindicações de obrigação, e estes tipos de esforços podem se arrastar por meses e tomar muito esforço.

Por outro lado, o conselho legal de uma organização pode aconselhar precaução extrema e sugerir que atividades de rastramento sejam detidas e um intruso mantido fora do sistema. Isto, em si mesmo, pode não prover proteção de responsabilidades, e pode impedir os investigadores de identificar o perpetrador.

O equilíbrio entre apoiar atividade investigativa e limitar obrigação é enganador. Você precisará considerar as sugestões de seu conselho legal e o dano que o intruso está causando (se algum) ao tomar sua decisão sobre o que fazer durante qualquer incidente em particular.

Seu conselho legal também deveria ser envolvido em qualquer decisão para contactar agências investigativas quando um incidente acontece em seu site. A decisão para coordenar esforços com agências investigativas é de seu site ou organização. Envolver seu conselho legal também nutrirá a coordenação multi-nível entre seu site e a agência investigativa envolvida, o que resulta em uma divisão eficiente de trabalho. Outro resultado é que é provável que você obtenha direcionamento que o ajudará a evitar futuros enganos legais.

Finalmente, sua conselho legal deveria avaliar o procedimentos escritos de seu site para responder a incidentes. É essencial obter uma aprovação de uma perspectiva legal antes que você de fato leve a cabo estes procedimentos.

É vital, quando lidando com agências investigativas, verificar que a pessoa que chama pedindo informação é uma representante legítima da agência em questão. Infelizmente, muitas pessoas bem intencionadas têm vazado detalhes sensíveis sobre incidentes sem perceber, permitido pessoas sem autorização nos sistemas, etc., porque um visitante disfarçou-se como representante de uma agência governamental. (Nota: esta palavra de precaução na verdade se aplica a todos os contatos externos.)

Uma consideração semelhante envolve usar meios seguros de comunicação. Porque muitos atacantes de rede podem desviar correio eletrônico facilmente, evite usar correio eletrônico para comunicar-se com outras agências (como bem com outros lidando com o incidente em questão). Linhas telefônicas inseguras (os telefones normalmente usados no mundo empresarial) também são alvos freqüentes para escutas por intrusos de rede, logo tenha cuidado!

Não há um conjunto estabelecido de regras para responder a um incidente quando o governo local é envolvido. Normalmente (nos E.U.A.), exceto através de ordem legal, nenhuma agência pode o forçá-lo a monitorar, desconectar da rede, evitar contato de telefone com os atacantes suspeitos, etc. Cada organização terá um conjunto de leis e regulamentos locais e nacionais aos quais devem ser aderidos quando do tratamento de incidentes. É recomendado que cada site esteja familiarizado com essas leis e regulamentos, e identifique e conheça os contatos para agências com jurisdição com antecedência do tratamento de um incidente.

5.2.3 Grupos de Tratamento de Incidentes de Segurança de Computadores

Há atualmente vários Grupos de Resposta a Incidentes de Segurança (CSIRTs) como o CERT Coordination Center, o DFN-CERT alemão, e outros ao redor do globo. Esses grupos existem para muitas agências governamentais importantes e corporações grandes. Se um desses grupos está disponível, notificá-lo deveria ser de consideração primária durante as fases iniciais de um incidente. Estes times são responsáveis por coordenar incidentes de segurança de computador numa série de de sites e entidades maiores. Até mesmo acreditando-se que o incidente está contido dentro de um único site, é possível que a informação disponível por um grupo de resposta possa ajudar a solucionar o incidente completamente.

Se é determinado que a brecha aconteceu devido a uma falha no hardware do sistema ou software, o vendedor (ou provedor) e um Grupos de Tratamento de Incidentes de Segurança de Computadores deve ser notificado tão logo possível. Isto é especialmente importante porque muitos outros sistemas são vulneráveis, e este vendedor e gruopos de resposta podem ajudar a disseminar ajuda para outros locais afetados.

Ao montar uma política de site para tratamento de incidente, pode ser desejável criar um subgrupo, semelhante aos que já existem, que será responsável por tratar de incidentes de segurança para o site (ou organização). Se tal grupo é criado, é essencial que linhas de comunicação sejam abertas entre este gurpo e outros. Uma vez que um incidente ocorre, é difícil abrir um diálogo confiante entres gurpos, se não havia nenhum antes.

5.2.4 Sites Afetados e Envolvidos

Se um incidente tem um impacto em outros sites, informálos é uma boa prática. Pode ser óbvio desde o princípio que o incidente não é limitado para o site local, ou isso pode só emergir depois de análise adicional.

Cada site pode escolher contatar outros sites diretamente ou passar a informação para um grupo de resposta a incidentes apropriado. É freqüentemente difícil de achar o POC responsável por sites distantes e o grupo de resposta poderá facilitar essecontato fazendo uso de já canais estabelecidos.

As questões legais e de obrigação que surgem de um incidente de segurança diferirá de site para site. É importante definir uma política para o compartilhando e logging de informação sobre outros sites antes que um incidente aconteça.

Informação sobre pessoas específicas é especialmente sensível, e pode estar sujeito a leis de privacidade. Para evitar problemas nesta área, deveria ser apagada informação irrelevante e uma declaração de como tratar a informação restante deveria ser incluída. Uma declaração clara de como esta informação será usada é essencial. Ninguém que informa um aite sobre um incidente de segurança quer ler sobre isto na imprensa pública. Grupos de resposta a incidentes são valiosos neste sentido. Quando eles passam informações para POCs responsáveis, eles podem proteger o anonimato da fonte original. Mas, esteja atento que, em muitos casos, a análise de logs e informações em outros sites vai revelar endereços de seu site .

Os problemas discutidos acima não deveriam ser considerados razões para não envolver outros sites. De fato, as experiências de grupos existentes revelam que a maioria dos sites informados sobre problemas de segurança nem mesmo haviam notado que seu site havia sido comprometido. Sem serem informados a tempo, outros sites estão freqüentemente impossibilitados entrar em ação contra intrusos.

5.2.5 Comunicações internas

É crucial durante um incidente grande, comunicar porque certas ações estão sendo tomadas, e como se espera que os usuários (ou departamentos) se comportem. Em particular, deveria ser deixado muito claro para os usuários o que lhes é permitido dizer (e não dizer) para o mundo externo (incluindo outros departamentos). Por exemplo, não seria bom para uma organização se os usuários respondessem aos clientes com algo como, " Eu lamento, os sistemas estão fora do ar, nós tivemos um intruso e nós estamos tentand escalrecer as coisas". Seria muito melhor se ensinassem que eles respondessem com uma declaração preparada como, " Lamento, nossos sistemas não estão disponíveis, eles estão sendo em manutenção para melhor servi-lo no futuro".

Comunicações com os clientes e sócios contratuais devem ser dirigidos de modo sennsato, mas também sensível. Uma pessoa pode se preparar para os assuntos principais preparando um cheklist. Quando um incidente acontece, a lista pode ser usada com a adição de uma frase ou duas sobre as circunstâncias específicas do incidente.

Departamentos de relações públicos podem ser muito úteis durante incidentes. Eles deveriam ser envolvidos em todo o planejamento e podem prover respostas bem construídas para uso quando contato de fora dos departamentos e organizações são necessários.

5.2.6 Relações públicas - "Press Releases"

Houve um tremendo crescimento na cobertura de mídia dedicada a incidentes de segurança de computador nos Estados Unidos. Tal cobertura de imprensa está fadada a se estender a outros países, como a Internet continua crescendo e se expandindo internacionalmente. Leitores de países onde tal atenção da mídia ainda não aconteceu, podem aprender com as experiências dos E.U.A. e deveriam ser avisados e preparado.

Um dos assuntos mais importantes a considerar é quando, quem, e quanto liberar ao público em geral pela imprensa. Há muitos assuntos para considerar quando decidindo este ponto em particular. Primeiro e antes de mais nada, se um escritório de relações públicas existe para o site é importante usar este escritório como ligação para a imprensa. O escritório de relações públicas é treinado no tipo e formulação de informação a serem liberadas, e ajudará a assegurar que a imagem do site é protegida durante e depois do incidente (se possível). Um escritório de relações públicas tem a vantagem de que você pode se comunicar francamente com eles, e provê um pára-choque entre a atenção de imprensa constante e a necessidade do POC para manter controle sobre o incidente.

Se um escritório de relações públicas não está disponível, a informação, lançado à imprensa deve ser considerada cuidadosamente. Se a informação é sensível, pode ser vantajoso só prover mínima informação para a imprensa. É bastante possível que qualquer informação provida à imprensa será vista depressa pelo perpetrador do incidente. Também note que enganar a imprensa pode sair pela culatra freqüentemente e pode causar mais dano que liberar informações delicadas.

Enquanto é difícil de determinar com antecedência que nível de detalhe prover à imprensa, algumas diretrizes para serem lembradas são:

(1) mantenha o nível de detalhes técnicos baixo. Informação detalhada sobre o incidente pode prover bastante informação para outros lançarem ataques semelhantes em outros sites, ou até mesmo danificar habilidade do sitel para processar a parte culpada uma vez que o evento terminou.

(2) Mantenha a especulação fora de declarações de imprensa. Especulação sobre quem está causando o incidente ou os motivos, está muito sujeita a erros e pode causar uma visão inflamada do incidente.

(3) Trabalhe com profissionais da lei para assegurar que a evidência é protegida. Se prossecução for envolvida, assegurar que a evidência coletada não é divulgada à imprensa.

(4) Tente não ser forçado a uma entrevista de imprensa antes de você estar preparado. A imprensa popular é famosa pela "entrevista das 2 das manhã", onde a esperança é pegar o entrevistado desprevenido e obter informação não disponível em outras circunstâncias.

(5) Não permita que a atenção de imprensa diminua o tratamento do evento. Sempre se lembre que o fechamento com sucesso de um incidente é de importância fundamental.

5.3 Identificando um Incidente

5.3.1 É Real?

Esta fase envolve determinar se um problema realmente existe. Naturalmente muitos, se não a maioria, dos sinais associados freqüentemente com infecção de vírus, intrusões de sistema, usuários maliciosos, etc., simplesmente são anomalias tal como falhas de hardware ou comportamento de suspeito de sistema/usuário. Para ajudar a identificar se realmente há um incidente, é normalmente útil obter e usar qualquer software de detecção que possa estar disponível. Informação de auditoria também é extremamente útil, especialmente para determinar se há um ataque a rede. É extremamente importante obter um retrato instantâneo do sistema assim que se suspeite que algo está errado. Muitos incidentes levam uma cadeia dinâmica de eventos a acontecer, e um retrato instantâneo do sistema inicial pode ser a mais valiosa ferramenta para identificar o problema e qualquer fonte de ataque. Finalmente, é importante começar um livro de log. Gravar eventos de sistemas , conversas de telefone, timestamps, etc., pode conduzir a uma identificação mais rápida e sistemática do problema, e é a base para fases subseqüentes de tratamento de incidente.

Há certas indicações ou " sintomas " de um incidente que merecem atenção especial:

(1) Crashes de sistemas.

(2) Novas contas de usuário (a conta RUMPLESTILTSKIN foi criada inesperadamente), ou atividade alta em uma conta previamente pouco usada.

(3) arquivos novos (normalmente com nomes de arquivo estranhos, como data.xx ou k ou .xx).

(4) discrepâncias de contabilidade (em um sistema de UNIX pode você notar a diminuição de um arquivo de contabilidade chamado /usr/admin/lastlog, algo que o deveria muito desconfiado de que pode haver um intruso).

(5) mudanças em tamanho ou data de arquivo (um usuário deveria desconfiar se .arquivos EXE em um computador MS-DOS tenha inexplicavelmente aumentado mais de 1800 bytes).

(6) Tentativas de escrever em system (um gerente de sistema nota que um usuário privilegiado em um sistema de VMS está tentando alterar RIGHTSLIST.DAT).

(7) modificação de dados ou apagamento (arquivos começam a desaparecer).

(8) negação de serviço (gerente de sistema e todos os outros usuários são impedidos de entrar num sistema de UNIX, agora em modo de usuário único).

(9) desempenho de sistema inexplicavelmente, baixo

(10) anomalias (GOTCHA " é exibido no monitor ou há freqüentes e inexplicáveis "beeps ").

(11) sondas suspeitas (há numerosas tantativas de login sem sucesso de outro nodo).

(12) Browsing suspeito (alguém se torna um usuário root em um sistema UNIX e acessa arquivos arquivo após arquivo em contas de muitos usuário.)

(13) inabilidade de um usuário para se logar devido a modificações em sua conta.

De forma alguma esta lista é completa; nós listamos apenas um certo número de indicadores comuns. É melhor colaborar com outro pessoal técnico e de segurança de computador para tomar uma decisão como um grupo sobre se um incidente está acontecendo.

5.3.2 Tipos e Escopo de Incidentes

Junto com a identificação do incidente, está a avaliação do âmbito e impacto do problema. É importante identificar os limites do incidente corretamente para lidar efetivamente com ele e priorizar respostas.

Para identificar o escopo e impacto um conjunto de critérios deveria ser definido, o qual é apropriado para o site e para o tipo de conexões disponíveis. Alguns dos pontos incluem:

5.3.3 Avaliando Dano e Extensão

A análise do dano e extensão do incidente pode consumir muito tempo, mas deveria conduzir a alguma idéia sobre a natureza do incidente, e ajudar na investigação e prossecução. Assim que a brecha tenha acontecido, o sistema inteiro e todos seus componentes deveriam ser considerado suspeitos. Software de sistema é o alvo mais provável. Preparação é chave para poder descobrir todas as mudanças num sistema possivelmente afetado. Isto inclui fazer checksum de todas os meios do vendedor usando um algoritmo que é resistente a falsificações. (Veja seções 4.3)

Assumindo que meios de distribuição originais do vendedor estão disponíveis, uma análise de todos os arquivos de sistemas deveria começar, e qualquer irregularidade deveria ser notada e deveria referida a todas as partes envolvidas no tratamento do incidente. Pode ser muito difícil, em alguns casos, decidir que meios de backup estão mostrando um estado de sistema correto. Considere, por exemplo que o incidente pode ter continuado por meses ou anos antes de descoberta, e o suspeito pode ser um empregado do site, ou que tenha conhecimento íntimo ou acesso aos sistemas. Em todos os casos, a preparação antes do incidente determinará se a recuperação é possível.

Se o sistema suporta logs centralizados (a maioria o faz), volte para os logs e procure anormalidades. Se contabilidade de processo e tempo de conexão estiver habilitada, procure padrões de uso do sistema. Numa menor extensão, o uso do disco pode jogar luz no incidente. Contabilidade pode prover muita informação útil em uma análise de um incidente e prossecução subseqüente. Sua habilidade para verificar todos os aspectos de um incidente específico depende fortemente do sucesso desta análise.

5.4 Tratando um Incidente

São necessários certos passos durante o tratamento de um incidente. Em todas as atividades de segurança relacionadas, o mais importante ponto à ser feito é que todos os sites deveriam ter políticas no local.

Sem políticas e metas definidas, as atividades empreendidas permanecerão sem enfoque. As metas deveriam ser definidas com antecedência pela administração e com deliberação legal.

Um dos objetivos mais fundamentais é restabelecer controle dos sistemas afetados e limitar o impacto e dano. No pior caso, fechando o sistema, ou desconectando o sistema da rede, possa ser a única solução prática.

Como as atividades envolvidas são complexas, tente adquirir tanta ajuda quanto necessário. Enquanto tenta resolver o problema sozinho, danos reais podem acontecer devido a demoras ou a informações perdidas. A maioria administradores levam a descoberta de um intruso como um desafio pessoal.

Procedendo deste modo, outros objetivos como esboçou em suas políticas locais sempre podem não ser consideradas. Tentar pegar os intrusos pode ser uma prioridade muito baixa, se comparada a integridade do sistema, por exemplo. Monitorar a atividade de um hacker é útil, mas pode não sido considerado preço o risco para permitir o acesso continuado.

5.4.1 Tipos de Notificação e Troca de Informação

Quando você confirmou que um incidente está acontecendo, o pessoal apropriado deve ser notificado. Como esta notificação é passada é muito importante para mantenção do evento sob controle ambos pontos de vista, o técnico e o emocional. As circunstâncias devem ser descritas em tantos detalhes quanto possível para facilitar o pronto reconhecimento e entender o problema. Muito cuidado quando determinar para quais grupos técnicos a informação será enviada durante a notificação.Por exemplo, é útil passar este tipo de informação para um grupo de tratamento de incidentes pois eles podem lhe ajudar com sugestões úteis para erradicar as vulnerabilidades envolvidas em um incidente. Por outro lado, pondo o conhecimento crítico no domínio público (por exemplo, por newsgroups de USENET ou remetendo para listas) pode pôr um número grande de sistemas potencialmente a risco de intrusão. É nulo assumir que todos os administradores que lêem um newsgroup particular têm acesso ao código fonte do sistema operacional, ou podem entender o bastante para fazer os passos adequados.

Em primeiro lugar, qualquer notificação para local ou pessoal de fora do site deve ser explícito. Isto requer que qualquer declaração (seja isto uma mensagem de correio eletrônico, telefonema, fac-símile, beeper, ou semaphone) provendo informação sobre o incidente seja clara, concisa, e completamente qualificada. Quando você está notificando outros que o ajudarão a tratar um evento, uma "tela de fumaça" só dividirá o esforço e criará confusão. Se uma divisão de trabalho é sugerida, é útil prover informações para cada participante sobre o que está sendo realizado em outros esforços. Isto não só reduzirá duplicação de esforços, mas permite que as pessoas que trabalham em partes do problema possam saber onde obter informações pertinentes a parte deles no incidente.

Outra consideração importante quando comunicar sobre o incidente é ser efetivo. Tentar esconder aspectos do incidente provendo falsa ou incompleta informação não só podem evitar uma solução com sucesso para o incidente, mas pode até mesmo piorar a situação.

A escolha do idioma usado quando notificar as pessoas sobre o incidente pode ter um efeito profundo no modo que informação é recebida. Quando você usa termos emocionais ou inflamatórios, você eleva o potencial para dano e resultados negativos do incidente. É importante permanecer tranqüilo ambos as comunicações escrita e falada.

Outra consideração é que nem todas as pessoas falam o mesmo idioma.

Devido a este fato, podem surgir enganos e demora, especialmente se é um incidente multi-nacional. Em outras preocupações internacionais inclua a diferença nas implicações legais de um incidente de segurança e diferenças culturais. Porém, diferenças culturais não só existem entre países. Elas igualmente existem dentro de países, entre diferente grupos sociais ou de usuários. Por exemplo, administrador de um sistema universitário é muito relaxado sobre tentativas para conectar o sistema por telnet, mas é provável que o administrador de um sistema militar considere a mesma ação como um possível ataque.

Outro assunto associado com a escolha de idioma é a notificação de pessoas não técnicas ou de fora do site. É importante descrever o incidente com precisão sem gerar alarme impróprio ou confusão. Enquanto é mais difícil de descrever o incidente a uma conjunto de pessoas não-técnicas, é freqüentemente mais importante. Uma descrição não-técnica pode ser requerida pela administração de níveis superiores, a imprensa, ou instituições responáveis pela execução de lei. A importância destas comunicações não pode ser menosprezada e pode fazer a diferença entre a solução do incidente corretamente ou eleva-lo a algum nível mais alto de dano.

Se um grupo de resposta a incidentes é envolvido, poderia ser necessário preencher um modelo para a troca de informação. Embora isto possa parecer ser um fardo adicional e possa somar uma certa demora, isto, ajuda o grupo para agir neste mínimo conjunto de informação. O grupo de resposta poderá responder a aspectos do incidente do qual o administrador local é desavisado. Se a informação é dada para uma pessoa de fora então, esta pessoa deveria ter um mínimo de informação contando o seguinte:

Se informações locais (i.e., IDs de usuários locais) são incluídas nas entradas de logs, será anteriormente necessário a **sanitize** as entradas para evitar assuntos de isolamento. Em geral, toda a informação que poderia ajudar um local distante solucionando um incidente deveria ser distribuídas, a menos que políticas locais proibem isto.

5.4.2 Protegendo as Evidências e Logs de Atividade

Quando você responde a um incidente, documente todos os detalhes relacionados ao incidente. Isto proverá valiosa informação para você e outros como você tentando desvendar o curso dos eventos. Documentando todos os detalhes economizarão em última instância, seu tempo. Se você não documenta todos os telefonemas importantes, por exemplo, é provável que você esqueça uma porção significante de informação você obtém o que requer que voce contacte a fonte de informação novamente. Ao mesmo tempo, detalhes armazenados proverão evidências para esforços de prossecução e proverão os movimentos naquela direção. A documentação de um incidente também lhe ajudarão a executar uma taxa final de dano (alguém da administração, como também institições de execução de lei, poderão querer saber), e proverá a base para mais recentes fases do processo de tratamento de incidentes:

erradicação, recuperação, e seqüência, "lições aprendidas".

Durante as fases iniciais de um incidente, é freqüentemente imprevisível determinar se a prossecução é viável, assim você deveria documentar como se você pois está juntando evidências para um caso de tribunal. Um mínimo, você deverá registrar:

O modo mais direto para manter documentação é mantendo um livro de log. Isto lhe permite ter uma centralizada e cronológica fonte de informação quando você precisar disto, em vez do requerer, chame por folhas individuais de papel. Muitas destas informações são evidências potenciais em um tribunal de lei. Assim, quando um procedimento legal é uma possibilidade, a pessoa deveria seguir os procedimentos preparados e evitar por em perigo o procedimento legal por manipulação imprópria de possível evidência. Se apropriado, os passos seguintes podem ser levados.

1. regularmente (por exemplo, diariamente) fazer cópias assinadas de seu logbook (como também mídias que você usa para registrar eventos de sistemas) para um adminitrador de documentos.

2. adminitrador deveria armazenar estas páginas copiadas em um seguro lugar (por exemplo, uma caixa forte).

3. quando você submete informação para armazenamento, você deve receba um recibo datado e assinado pelo administrador do documento.

Fracasso para observar estes procedimentos pode resultar em invalidação de qualquer evidência que você obtém em um tribunal de lei.

5.4.3 Retenção

O propósito de retenção é limitar a extensão de um ataque. Uma parte essencial de retenção é decisão do que fazer (por exemplo, determinando desligar um sistema, desconectar da rede, monitorar sistemas ou atividades de rede, set traps, incapacitar funções como transferência de arquivo remotoss, etc.).

Às vezes esta decisão é trivial; desligar o sistema se a informação é secreta, importante, ou proprietária. Tenha em mente que isso remove todo o acesso enquanto um incidente está em prograsso, obviamente notifique todos os usuários, inclusive os usuários que alegaram problemas, que os administradores estão atentos ao problema; isto pode ter um efeito danoso uma investigação. Em alguns casos, é prudente remover todo o acesso ou funcionalidade o mais cedo possível, então restabeleça operação normal em fases limitadas. Em outros casos, vale a pena arriscar algum dano para o sistema, se manter o sistema poderiam habilitar você à identificar o intruso.

Esta fase deveria se desenvolver levando a cabo procedimentos predeterminados.

Sua organização ou site devem, por exemplo, definir riscos aceitável lidando com um incidente, e deveria prescrever ações específicas e estratégias adequadas. Isto é especialmente importante quando uma decisão rápida é necessária e não é possível contactar todas as partes envolvidas primeiro para discutir a decisão. Na ausência de procedimentos predefinidos, a pessoa no cargo do incidente não terá freqüentemente o poder para tomar decisões de administração difíceis (como perder os resultados de uma experiência cara desligando um sistema). Uma atividade final que deveria acontecer durante esta fase de tratamento do incidente é a notificação de autoridades apropriadas.

5.4.4 Erradicação

Uma vez que o incidente foi contido, é tempo para erradicar a causa. Mas antes de erradicar a causa, deveria ser tomado grande cuidado colecionar todas as informações necessárias sobre os sistemas comprometidos e a causa do incidente como elas serão provavelmente serão perdidas quando o sistema for limpo.

Softwares podem estar disponíveis para ajudar no processo de erradicação, como software de anti-vírus. Se qualquer falso arquivos foram criados, devem ser apagados. No caso de infecções de vírus, é importante limpar e reformatar qualquer mídia que contém arquivos infetados. Finalmente, assegura que todos os backups estão limpos. Muitos sistemas infetados com vírus ficam periodicamente ré-infetados simplesmente porque as pessoas não erradicam o vírus do backup. Depois de erradicação, deveria ser feito um novo backup.

Removendo todas as vulnerabilidades uma vez um incidente aconteceu é difícil. A chave para remover vulnerabilidades é conhecimento e entendimento da brecha.

Pode ser necessário voltar para as mídia de distribuição originais e ré-customizar o sistema. Para facilitar esta situação de pior caso, um registro do setup do sistema original e de cada mudança de customização deveria ser mantido. No caso de um ataque baseado na rede, é importante instalar remendos para cada vulnerabilidade de sistema operacional que foi explorado.

Como discutido na seção 5.4.2, um log de segurança pode ser muito valioso durante esta fase de remover vulnerabilidade. Os logs que mostram como o incidente foi descoberto e foi contido pode ser usado para ajudar depois a determinar qual a extensão do dano de um determinado incidente. O passos podem ser usados no futuro para ter certeza que o problema não irá ocorrer. Idealmente, a pessoa deveria automatizar e regularmente deveria aplicar o mesmo teste como foi usado para descobrir o incidente de segurança.

Se uma vulnerabilidade particular é isolada como explorada, o próximo passo é achar um mecanismo para proteger seu sistema. A segurança que remete listas e boletins seria um lugar bom para procurar esta informação, e você pode obter conselhos dos grupos de resposta a incidentes.

5.4.5 Recuperação

Uma vez que a causa de um incidente foi erradicada, a fase de recuperação define a próxima fase de ação. A meta de recuperação é retornar o sistema ao normal. Em geral, expondo serviços na ordem de demanda e com um mínimo de inconveniência aos usuário é a melhor prática. Entenda que os procedimentos de recuperação formais para o sistema é extremamente importante e deveria ser específico para o site.

5.4.6 Acompanhamento

Uma vez que você acredita que o sistema foi restabelecido a um " estado seguro ", ainda é possível que buracos, e até mesmo armadilhas, podem estar espreitando o sistema. Uma das fases mais importantes de respostas a incidentes também é freqüentemente omitida, a fase de acompanhamento. Na fase de acompanhamento, o sistema deveria ser monitorado para itens que podem ter sido perdidos durante a fase de limpeza. Seria prudente utilizar algumas das ferramentas mencionados capítulo 7 como um começo.

Lembre-se, estas ferramentas não substituem uma monitoração continuada do sistema e boas práticas de administração de sistemas.

O elemento mais importante da fase de seguimento é executar uma análise de pos morte. Exatamente o que aconteceu, em que momento? Como foi o desempenho do pessoal envolvido com o incidente? Que tipo de informação foi necessária rapidamente para o pessoal, e como eles obtiveram aquela informação o mais cedo possível? O que faria o pessoal diferentemente da próxima vez?

Após um incidente, é prudente escrever um relatório que descreve a sucessão exata de eventos: o método de descoberta, procedimento de correção, procedimento de monitoração, e um resumo da lição aprendida.

Isto ajudará na compreensão clara do problema. Criando uma cronologia formal de eventos (inclusive time stamps) também é importante por razões legais.

Um relatório de seguimento é valioso por muitas razões. Provê uma referências a serem usadas no caso de outros incidentes semelhantes. Também é importante para que, tão depressa quanto possível obtenha-se uma estimativa da quantia monetária dos danos que o incidente causou. Esta estimativa deve incluir custos associados com qualquer perda de software e arquivos(especialmente o valor de dados proprietário que podem ter sido descoberto), dano de hardware, e força de trabalho usada para restabelecer arquivos alterados, reconfigure sistemas afetados, e assim sucessivamente. Esta estimativa pode se tornar a base para atividade de prossecução subseqüente. O relatório também pode ajudar justifique o esforço de segurança dos computadores de uma organização para administração.

5.5 Resultado de um Incidente

Após um incidente, deveriam acontecer várias ações. Estas ações podem ser resumidas nas seguintes:

1. um inventário deveria ser feito dos recursos dos sistemas,(i.e., um exame cuidadoso deveria determinar como o sistema foi afetado pelo incidente).

2. as lições aprendidas como resultado do incidente deveria ser incluído em plano de segurança revisado para impedir o incidente de ré-acontecer.

3. uma análise de risco nova deveria ser desenvolvida levando em conta o incidente.

4. uma investigação e prossecução dos indivíduos que causaram o incidente deveria começar, se é julgado desejável.

Se um incidente está baseado em política pobre, e a menos que a política seja mudada, você então é sentenciado repetir o passado. Uma vez que um site se recuperou de um incidente deveriam ser revisadas a política do site e os procedimentos para cercar mudanças para prevenir incidentes semelhantes. Até mesmo sem um incidente, seria prudente revisar políticas e procedimentos com uma base regular. Revisões são imperativas devido aos ambientes de computação variáveis de hoje.

O propósito inteiro deste processo de pos morte é melhorar tuda a segurança para proteger o site contra ataques futuros. Como resultado de um incidente, um site ou organização ganhar conhecimento prático da experiência. Uma meta concreta do pos morte é desenvolver novos métodos de proactive. Outra faceta importante do resultado pode ser a educação do usuário final e administrador para prevenir a nova ocorrência do problema de segurança.

5.6 Responsabilidades

5.6.1 Não cruzando a Linha

É uma coisa para proteger a sua própria rede, mas outra é assumir que deveria proteger outras redes. Durante o tratamento de um incidente, certas vulnerabilidades dos próprios sistemas e os sistemas de outros ficam aparentes. É bastante fácil e pode ser tentado a procurar os intrusos para localiza-los. Persista em mente que isso em um certo ponto é possível cruzar a linha e, com a melhor das intenções, não se torne melhor que o intruso.

A melhor regra quando vem a decoro é não usar facilidades de locais distantes que não são públicos. Isto exclui qualquer entrada claramente sobre um sistema (como uma concha distante ou sessão de login) que não é permitido expressamente. Isto pode ser muito tentador depois de uma brecha de segurança é descoberta, um administrador de sistema pode ter os meios para fazer isto, averiguar que danos pode estár danificando o site remoto. Não fa