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.)

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:

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:

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:

(cap 5.3)