tipo: Documentos
publicado em: 07 de janeiro de 1999
por: CGI.br
idiomas:
publicado em: 07 de janeiro de 1999
por: CGI.br
idiomas:
Grupos de Trabalho
Documentos do GT-S
Expectativas quanto a Grupos de Resposta a Incidente de Segurança em Computador
Comitê Gestor da Internet/Brasil
Grupo de Trabalho em Seguranca de Redes (GTS)
Janeiro 1999
Status deste Documento
Este documento fornece informações para a comunidade Internet do Brasil, e solicita discussão e sugestões para melhorias. Este documento não especifica padrões Internet de qualquer tipo. A distribuição deste documento é ilimitada.
Resumo
O objetivo deste documento é expressar as expectativas da Comunidade Internet em geral quanto aos Grupos de Resposta a Incidente de Segurança em Computador (CSIRTs - Computer Security Incident Response Teams). Não é possivel definir um conjunto de requisitos que seriam mais apropriados a todos os grupos, mas é possível e de grande ajuda listar e descrever o conjunto geral dos tópicos e assuntos que são de interesse e concernentes s comunidades constituintes. Os constituintes de um CSIRT têm uma legítima necessidade e direito de entender completamente a política e o procedimento do grupo a que estão vinculados. Uma maneira de promover essa compreensão é fornecer informação detalhada, que ser submetida à apreciação dos usuários, na forma de um formulário elaborado pelo grupo. Um esboço de formulário e um exemplo preenchido são fornecidos adiante.
1. Introdução
O grupo de trabalho GRIP foi formado para criar um documento que descrevesse as expectativas da comunidade em relação aos Grupos de Resposta a Incidente de Segurança em Computador.
Embora a necessidade de tal documento tenha se originado na comunidade Internet em geral, as expectativas expressas corresponderiam também àquelas de comunidades mais restritas. No passado houve mal entendidos quanto ao que esperar dos CSIRTs. O objetivo deste documento é prover uma estrutura apresentando assuntos importantes (relacionados a resposta a incidente) concernentes à comunidade.
Antes de continuar, é importante compreender claramente o significado do termo "Grupo de Resposta a Incidente de Segurança em Computador" - CSIRT. Para o que se propõe este documento, um CSIRT é um grupo que executa, coordena e dá suporte, respondendo a incidentes de segurança que envolvam sites e equipamentos de usuários, entidades e empresas comerciais ou não que este represente. Qualquer grupo que se denomine CSIRT perante uma comunidade específica deve, daí em diante, atender aos relatos de incidentes de segurança e a ameaças à "sua" comunidade nos moldes em que esta comunidade específica concordar que seja do seu interesse geral.
Como é de vital importância que cada membro de uma comunidade esteja apto a compreender o que razoavelmente pode esperar do seu grupo, um CSIRT deve deixar claro quem pertence à sua comunidade e definir os serviços que oferece comunidade. Além disso, cada CSIRT deve publicar a sua política e procedimentos operacionais. Em contrapartida, esses mesmos constituintes precisam saber o que é esperado deles para que recebam os serviços do seu grupo. Isso exige que o grupo publique também como e onde relatar incidentes.
Este documento detalha um formulário que será usado pelos CSIRTs para comunicar essa informação aos seus constituintes. Estes certamente esperarão que o CSIRT execute os serviços descritos nos formulários.
Deve-se enfatizar que sem a participação ativa dos usuários, a eficácia dos serviços dos CSIRTs pode diminuir significativamente. Este é particularmente o caso dos relatos. No mínimo, os usuários precisam saber que eles devem relatar incidentes de segurança, saber como e onde relatá-los.
Muitos incidentes de segurança em computadores originam-se fora dos limites da comunidade local e afetam os sites internos, outros originam-se dentro da comunidade local e afetam equipamentos ou usuários de fora. Freqüentemente, no entanto, o trabalho com incidentes de segurança envolve vários sites e potencialmente vários CSIRTs. Resolver esses incidentes exigirá cooperação entre sites individuais e CSIRTs e entre diferentes CSIRTs.
Comunidades constituintes precisam saber exatamente como o seu CSIRT trabalhará com outros CSIRTs e organizações fora da sua comunidade e que informações serão compartilhadas.
O resto deste documento descreve o conjunto de tópicos e assuntos que os CSIRTs precisam elaborar para os seus constituintes. No entanto, não há nenhuma tentativa de especificar a resposta "correta" a cada tópico. Ao contrário, cada tópico é discutido nos termos do seu significado.
O capítulo dois nos traz uma visão mais ampla de três áreas importantes: a publicação da informação por um grupo de resposta, a definição do relacionamento entre um grupo de resposta e outros grupos de resposta e a necessidade de comunicação segura.
O capítulo três descreve em detalhes todos os tipos de informação que a comunidade precisa saber sobre o seu grupo de resposta. Para facilitar o uso por parte da comunidade, esses tópicos estão condensados num esboço de formulário encontrado no Apêndice D. Esse formulário pode ser usado pela comunidade como exemplo.
O Grupo de Trabalho espera sinceramente que através da elucidação dos tópicos neste documento, a compreensão entre a comunidade e os respectivos CSIRTs aumente.
2. Escopo
As interações entre um Grupo de Resposta a Incidente e sua comunidade constituinte requer primeiro que a comunidade compreenda a política e os procedimentos do seu Grupo de Resposta. Em segundo lugar, como muitos grupos colaboram com outros, a comunidade deve também entender o relacionamento entre o seu Grupo de Resposta com os outros Grupos de Resposta. Finalmente, muitas interações se darão com as infra-estruturas públicas existentes, de maneira que a comunidade precisa saber como essas comunicações serão protegidas. Cada um desses assuntos será descrito em detalhes nas próximas três seções.
2.1. Publicação da Política e dos Procedimentos dos CSIRTs
Cada usuário que tiver acesso a um Grupo de Resposta a Incidente de Segurança em Computador deve saber tanto quanto possível sobre os serviços e as interações com esse grupo muito antes que venha a precisar dele.
Um claro estabelecimento da política e dos procedimentos do CSIRT ajuda os constituintes a compreender a melhor maneira de relatar um incidente e que tipo de suporte esperar depois. O CSIRT ajudará a resolver o incidente? Ele ajudará a evitar incidentes no futuro?
Tornar claras as expectativas, particularmente quanto às limitações dos serviços prestados por um CSIRT, tornará a interação com ele mais eficiente e efetiva.
Há vários tipos de grupos de resposta: alguns têm constituições bastante abrangentes (p.ex., CERT Coordination Center and the Internet), outros são de constituições mais limitadas ( p.ex., DFN-CERT, CIAC), e outros ainda têm constituições muito restritas (e.g., grupos de resposta comerciais, grupos de resposta corporativos). Independentemente do tipo de grupo de resposta, a comunidade a que ele dá suporte deve ter conhecimento da política do grupo e dos seus procedimentos. Por isso, é imperativo que os grupos de resposta publiquem esse tipo de informação para sua comunidade.
Um CSIRT deve comunicar toda a informação necessária a respeito de sua política e serviços num formulário correspondente às necessidades da sua comunidade. É importante entender que nem todas as políticas e procedimentos precisam estar publicamente disponíveis. Por exemplo, não é necessário entender a operação interna de um grupo para interagir com ele, como quando um usuário reporta um incidente ou recebe orientação ou como o grupo analisa ou assegura os sistemas de alguém.
No passado, alguns grupos forneciam uma espécie de Estrutura Operacional, outros forneciam uma Lista de Perguntas mais Freqüentes (FAQ ), enquanto outros escreviam textos técnicos para distribuição em encontros de usuários ou os enviavam para publicações especializadas.
Recomenda-se que cada CSIRT publique suas diretrizes e procedimentos no seu próprio servidor de informações (p.ex., servidor da World Wide Web). Isto permitirá que os constituintes possam facilmente acessá-los, embora permaneça o problema de como um constituinte poderá encontrar o seu grupo; as pessoas dentro de uma comunidade terão que descobrir que existe um CSIRT "à sua disposição".
É de se supor que os formulários dos CSIRTs tornem-se em breve acessíveis através de mecanismos de busca, que ajudarão na divulgação sobre a sua existência e das informações básicas necessárias para se chegar até eles.
Seria bastante útil ter um repositório central contendo todos os formulários. Tal repositório não existe no momento, embora isso possa mudar no futuro.
Independentemente da fonte onde a informação foi obtida, o usuário do formulário deve checar sua autenticidade. É extremamente recomendável que documentos de tamanha importância estejam protegidos por assinaturas digitais. Isso permitirá ao usuário verificar que o formulário foi realmente publicado pelo CSIRT e não foi alterado. Presume-se que o leitor esteja familiarizado com o uso adequado de assinaturas digitais como forma de determinar se um documento é autêntico.
2.2. Relacionamento entre diferentes CSIRTs
Em alguns casos um CSIRT terá condições de efetivamente operar sozinho e em estreita cooperação com seus constituintes, mas com a atual internacionalização das redes torna-se mais provável que a maioria dos incidentes de que um CSIRT esteja tratando envolvam partes externas à sua comunidade. Por essa razão, um grupo precisará interagir com outros CSRITs e sites fora externos.
A comunidade deve entender a natureza e extensão dessa colaboração,como informações sensíveis sobre uma determinada instalação podem ser divulgadas nesse processo.
Interação entre CSIRTs podem incluir questionamento a outro grupo, para advertir, disseminar conhecimento de problemas, e trabalho cooperativo para resolver incidentes de segurança que afetem um ou mais usuários dos CSIRTs.
No estabelecimento desse relacionamento onde existirá uma interação, os CSIRTs devem decidir que tipos de acordo podem existir entre eles, sobre como compartilhar informações sigilosas , se esse relacionamento pode ser divulgado, e em caso afirmativo, para quem.
Observe que há uma diferença entre um acordo de parceria, em que os CSIRTs envolvidos concordam em trabalhar juntos e compartilhar informações e uma simples cooperação, em que um CSIRT (ou qualquer outra organização) simplesmente entra em contato com outro CSIRT epede ajuda ou orientação.
Embora o estabelecimento de tais relacionamentos seja muito importante e afete a capacidade de um CSIRT dar suporte aos seus constituintes, cabe aos grupos envolvidos decidir sobre os detalhes. Está além do escopo deste documento fazer recomendações sobre esse processo.
De qualquer forma, o mesmo conjunto de informações disponibilizado aos usuários tratando da divulgação de informações ajudará outras partes a compreender os objetivos e serviços de um CSIRT específico, facilitando um primeiro contato.
2.3. Estabelecimento de comunicações seguras
Uma vez que uma parte tenha decidido trocar informação com outra parte, ou duas partes tenham concordado em trocar informação ou trabalhar em conjunto - como exigido para a coordenação de resposta a incidente de segurança em computador - todas as partes envolvidas precisam de canais de comunicação seguros. (Neste contexto "seguro" refere-se a transmissão de comunicação protegida compartilhada entre as várias partes, e não ao uso apropriado da informação pelas partes).
Os objetivos de comunicação segura são:
- Sigilo Alguém mais pode ter acesso ao conteúdo da comunicação?
- Integridade Alguém mais pode manipular o conteúdo da comunicação?
- Autenticidade Estou me comunicando com a pessoa "certa"?
É muito fácil enviar e-mails falsos e não é difícil criar uma (falsa) identidade por telefone. Técnicas criptográficas, por exemplo Pretty Good Privacy (PGP) ou Privacy Enhanced Mail (PEM) podem eficazmente prover meios de proteger e-mail. Com o equipamento correto também é possível proteger comunicação telefônica. Mas antes de usar tais mecanismos, ambas as partes precisam da infra-estrutura "certa", ao que se chamaria de preparação prévia. A preparação mais importante é assegurar a autenticidade das chaves criptográficas usadas na comunicação segura:
- Chaves públicas (para técnicas como PGP e PEM): Como são acessíveis através da Internet, as chaves públicas devem ser autenticadas antes de usadas. Enquanto PGP se baseia numa "Rede de Confiança" (onde usuários assinam as chaves de outros usuários), PEM se baseia numa hierarquia (onde autoridades de certificação assinam as chaves dos usuários).
- Chaves secretas (para técnicas como DES e PGP/conventional encrytion): Como devem ser conhecidas tanto pelo emissor quanto pelo receptor, as chaves secretas devem ser trocadas antes da comunicação através de um canal seguro.
A comunicação é crítica em todos os aspectos de resposta a incidentes um grupo pode fazer melhor uso das técnicas acima mencionadas recolhendo toda informação relevante, de maneira consistente. Requerimentos específicos (como discar um número específico para checar a autenticidade das chaves) devem estar claros desde o começo. Os formulários dos CSIRTs fornecem um meio padronizado para transportar esta informação. Está além do escopo deste documento endereçar os problemas técnicos e administrativos de comunicação segura. A questão é que grupos de resposta devem dar suporte e utilizar um método para assegurar a comunicação entre eles e seus constituintes (ou outros grupos de resposta). Qualquer que seja o mecanismo, o nível de proteção que ele oferecer deve ser aceitável à comunidade constituinte.
3. Informação, Política e Procedimentos
No capítulo 2 foi mencionado que a política e os procedimentos de um grupo de resposta precisam ser publicados para a comunidade constituinte. Neste capítulo listaremos todos os tipos de informação que a comunidade precisa receber do seu grupo de resposta. Como esta informação é comunicada varia de grupo para grupo, da mesma forma que varia também o conteúdo da informação. A intenção aqui é descrever claramente os diversos tipos de informação que uma comunidade constituinte espera do seu grupo de resposta.
Para facilitar a compreensão dos assuntos e tópicos relevantes à interação dos constituintes com o seu CSIRT, sugerimos que o grupo publique toda a informação, política e procedimentos endereçando-os aos seus constituintes como um documento, seguindo o formulário fornecido no Apêndice D. O formulário organiza itens, facilitando o acréscimo de informação específica; no Apêndice E fornecemos um exemplo de formulário preenchido para uma universidade XYZ fictícia.
Enquanto nenhuma recomendação é feita quanto ao que um CSRIT deve adotar como sua política ou procedimentos, diversas possibilidades aparecem como exemplos. O mais importante é que um CSIRT tenha uma política e que aqueles que com ele interagem estejam aptos a obtê-la e compreendê-la.
Como sempre, nem todos os aspectos para cada ambiente e/ou grupo podem ser listados. Este modelo deve ser visto como uma sugestão. Cada grupo deve sentir-se livre para incluir o que quer que eles achem que seja necessário para o suporte da sua comunidade.
3.1. Obtenção do documento
Detalhes de um CSIRT mudam com o tempo, portanto, o formulário deve indicar quando foi modificado pela última vez. Adicionalmente, informação sobre como encontrar futuras atualizações deve ser fornecida. Do contrário, é inevitável que mal-entendidos e concepções errôneas surjam com o tempo. Documentos desatualizados podem trazer mais prejuízo do que benefício.
- Data da última atualização - Deve ser suficiente para permitir a qualquer interessado avaliar se o formulário é atual ou não.
- Distribuição de listas - Enviar listas é um mecanismo conveniente para distribuir informação atualizada a um grande número de usuários. Um grupo pode decidir se usa sua própria lista ou alguma já existente para notificar os usuários sempre que houver mudanças no documento. A lista pode ser de grupos com os quais os CSIRTs interajam com freqüência. Assinaturas digitais devem ser utilizadas em mensagens de atualização enviadas por um CSIRT.
- Localização do documento - O lugar onde uma versão atualizada do documento poderá ser acessada através dos serviços de informação on-line do grupo. Os constituintes poderão então facilmente aprender mais sobre o grupo e checar atualizações recentes Esta versão on-line também deve vir acompanhada de uma assinatura digital.
3.2. Informação sobre contato
Detalhes completos sobre como contatar o CSIRT deve ser listada aqui, embora eles possam diferir muito de grupo para grupo; por exemplo, alguns podem optar por não listar os nomes dos membros do seu grupo.
Nenhum esclarecimento adicional deve ser dado quando o significado de um item pode ser presumido.
- Nome do CSIRT
- Endereço para correspondência
- Fuso horário É útil para coordenar incidentes em que ocorra diferença de fuso horário. - Número de telefone
- Número de fax
- Outros tipos de telecomunicação Alguns grupos podem oferecer contato telefônico seguro
- Endereço de correio eletrônico
- Chaves públicas e criptografia O uso de técnicas específicas depende da habilidade de os parceiros na comunicação acessar os programas, chaves, etc. Informação relevante deve ser dada para capacitar os usuários a determinar se e como eles podem fazer uso de comunicação criptografada durante a interação com o CSIRT.
- Membros do grupo
- Horário de funcionamento Horário de funcionamento e escala em feriados devem ser Fornecidas. Existe uma linha funcionando 24 horas?
- Informação adicional sobre contato Existe alguma informação específica sobre contato do cliente Informação detalhada adicional sobre contato deve ser fornecida. Isso pode incluir diferentes contatos para diferentes serviços. Se houver procedimentos específicos para acesso a alguns serviços (por exemplo endereços para solicitação de mala direta), deve ser explicado aqui.
3.3. Estatuto
Cada CSIRT deve ter um estatuto que especifique o que fazer e sob a autoridade de quem fazer. O estatuto deve incluir ao menos os seguintes itens:
- Estabelecimento de metas - Constituição - Patrocínio/afiliação
- Autoridade
3.3.1. Estabelecimento de metas
O estabelecimento das metas deve focalizar as atividades essenciais do grupo, já especificadas na definição de um CSIRT. Para ser considerado um Grupo de Resposta a Incidente de Segurança em Computador, um grupo deve dar suporte aos relatos de incidentes e à sua comunidade lidando com os incidentes.
As metas e proposições de um grupo são especialmente importantes e exigem uma definição clara, não ambígua.
3.3.2. Constituição
A constituição de um grupo pode ser determinada de várias maneiras. Pode tratar-se, por exemplo, dos empregados de uma companhia ou dos seus assinantes pagos, ou pode ser definida, ainda, a partir de um ângulo tecnológico, como os usuários de um sistema operacional em particular.
A definição de uma constituição deve criar em torno do grupo um perímetro a quem o mesmo prestará serviço. A seção de política do documento (veja abaixo) explicará como as solicitações de fora deste perímetro serão conduzidas.
Se um CSIRT decidir não divulgar suas diretrizes, deve explicar as razões por trás dessa decisão. Por exemplo, alguns CSIRTs podem não listar seus clientes, mas declararão que prestam serviços a uma vasta clientela que será mantida sob sigilo em decorrência de acordos contratuais.
Pode ocorrer sobreposição de constituições, como quando um ISP provê um CSIRT que transporta serviços a um cliente que também tem CSIRTs. A seção "Autoridade" da descrição dos CSIRTs (veja abaixo) deve esclarecer essas relações.
3.3.3. Organização patrocinadora / Afiliação
A organização patrocinadora, que autoriza as ações de um CSIRT deve vir em seguida. Sabendo que isso ajudará os usuários a entender o que está por trás de um CSIRT e a sua estruturação, e é uma informação vital para construir a confiança entre os constituintes e um CSIRT.
3.3.4. Autoridade
Esta seção vai variar muito de um CSIRT para outro, baseada no relacionamento entre um grupo e a sua comunidade. Enquanto a autoridade de um CSIRT organizacional será dada pela gerência da organização, um CSIRT comunitário será escolhido e legitimado pela comunidade, normalmente num papel de orientação.
Um CSIRT pode ou não ter autoridade para intervir na operação de todos os sistemas dentro do seu perímetro. Ele deve identificar o escopo do seu controle diferenciando-o do perímetro da sua comunidade. Se outros CSIRTs operam hierarquicamente dentro do seu perímetro, isto deve ser mencionado os CSIRTs devem ser identificados.
A divulgação da autoridade de um grupo pode expô-la a reivindicações de responsabilidade legal. Cada grupo deve procurar aconselhamento legal nesta matéria (veja mais sobre responsabilidade na seção 3.7).
3.4. Política
É crucial que um grupo de resposta defina sua política. As seções seguintes discutem a comunicação da política do grupo à comunidade constituinte.
3.4.1. Tipos de Incidentes e Níveis de Suporte
Os tipos de incidente que o grupo está capacitado a endereçar e o nível de suporte que irá oferecer ao responder a cada tipo de incidente deve estar resumido aqui na lista do formulário. A seção "Serviços" (ver abaixo) oferece a oportunidade de dar descrições mais detalhadas e de endereçar tópicos não relacionados a incidentes.
O nível de suporte pode mudar dependendo de fatores tais como a carga de trabalho do grupo e a integridade da informação disponível. Tais fatores devem ser esboçados e o seu impacto deve ser explicado.
Como uma lista de tipos conhecidos de incidentes será incompleta tendo em vista possíveis ou futuros incidentes, um CSIRT deve também dar algum tipo de informação de como será tratado um tipo de incidente que não tenha sido mencionado.
O grupo deve estabelecer se vai agir ao receber informação sobre vulnerabilidades que criem oportunidades para futuros incidentes. O compromisso de agir diante de tal informação no interesse de sua comunidade é visto como uma política de serviços de precaução do que um serviço essencial exigido de um CSIRT.
3.4.2. Cooperação, Interação e Divulgação de Informação
Esta seção deve explicitar com que grupos correlatos o CSIRT interage. Essas interações não são necessariamente relacionadas a resposta a incidente de segurança , mas são usadas para facilitar cooperação em tópicos técnicos ou serviços. De maneira alguma há necessidade de fornecer os detalhes sobre os acordos de cooperação.;o objetivo principal desta seção é dar aos constituintes uma compreensão básica do tipo de interação que é estabelecida e qual o seu propósito.
Cooperação entre CSIRTs pode ser facilitada pelo uso de um único número de protocolo combinado com procedimentos acordados de maneira explicita.
Isso reduz a chance de mal-entendidos, duplicação de esforços, ajuda no rastreamento de incidente e evita repetições na comunicação. O relatório e a divulgação da política deve deixar claro quem será o receptor do relato de um CSIRT em qualquer circunstância. Deve também assinalar se o grupo espera operar através de outro CSIRT ou diretamente com um membro de outra comunidade em assuntos especificamente concernentes àquele membro.
Grupos correlatos com os quais um CSIRT irá interagir são listados abaixo:
Grupos de Resposta a Incidente:
Um CSIRT precisará freqüentemente interagir com outros CSIRTs. Por exemplo, um CSIRT dentro de uma grande companhia talvez precise relatar incidentes a um CSIRT nacional, e um CSIRT nacional talvez precise relatar incidentes a CSIRTs nacionais de outros países para lidar com todos os sites envolvidos num ataque de larga escala.
Colaboração entre CSIRTs pode levar a divulgação de informação. Seguem-se exemplos de tal divulgação, mas não são se pretende que seja uma lista exaustiva:
- Relatando incidentes dentro da comunidade a outros grupos. Se isso ocorre, informação de sites correlatos podem se tornar de conhecimento público, acessível a qualquer um, em particular a imprensa.
- Lidando com incidentes ocorrendo dentro da comunidade, mas relatados de fora dele (o que implica que alguma informação já foi disponibilizada fora do site).
- Reportando observações de dentro da comunidade indicando suspeita ou confirmação de incidente de fora.
- Agindo em relatos de incidentes de fora da comunidade.
- Passando informação sobre vulnerabilidades a fabricantes, a parceiros dos CSIRTs ou diretamente a sites afetados dentro ou fora da comunidade.
- Resposta a outras partes que relatem incidentes ou vulnerabilidades.
- A provisão de informação sobre contato relacionada a membros da comunidade, a outros CSIRTs ou representantes da lei.
Fabricantes:
Alguns fabricantes têm seu próprio CSIRT, mas alguns podem não ter. Nesses casos, um CSIRT precisará trabalhar diretamente com um fabricante para sugerir melhoramentos ou modificações, para analisar o problema técnico ou para testar novas soluções. O fabricantes têm um papel importante em casos de incidente se as vulnerabilidades do seu produto estiverem envolvidas no incidente.
Representantes da Lei:
Incluem-se nesses a polícia e outras agências investigadoras. CSIRts e usuários do formulário devem estar atentos às leis locais e regulamentos, que podem variar consideravelmente em diferentes países. Um CSIRT pode dar aconselhamento em detalhes técnicos de ataques ou buscar aconselhamento sobre as implicações legais de um incidente. As leis locais podem incluir exigência de relatos específicos ou sigilo.
Imprensa:
Um CSIRT pode ser abordado pela imprensa para informações e comentários de tempos em tempos.
Uma política explícita concernente a divulgação para a imprensa pode ser de grande ajuda, particularmente para clarificar as expectativas de uma comunidade de um CSIRT. A política de imprensa terá detalhar os tópicos, uma vez que a comunidade estará normalmente muito sensível a contatos da imprensa.
Outros:
Este pode incluir atividades de pesquisa em relação à organização patrocinadora. O estado de qualquer e todas as informações relacionadas com segurança que um grupo receba será normalmente "confidencial", mas uma adesão rígida a isso faz com que o grupo apareça como um "buraco negro" informal que pode reduzir a probabilidade de o grupo obter cooperação dos clientes e de outras organizações. O formulário do CSIRT deve definir que informação ele vai relatar ou divulgar, para quem e quando.
Grupos distintos estão igualmente propensos a ser sujeitos de diferentes restrições legais que exijam ou limitem a divulgação, especialmente se eles funcionam em jurisdições diferentes. Além disso, eles podem ter exigências de relatos impostas por sua organização patrocinadora. Cada formulário de grupo deve especificar qualquer uma dessas restrições, tanto para esclarecer as expectativas dos usuários quanto para informar outros grupos.
Conflitos de interesse, particularmente em assuntos comerciais também podem restringir a divulgação por parte de um grupo; este documento não trata de como tais conflitos poderão ser conduzidos.
Um grupo normalmente colherá estatísticas. Se informação estatística for distribuída, a parte do formulário que trata da política de relato e divulgação deve explicitar isso e descrever como obter tais estatísticas.
3.4.3. Comunicação e Autenticação
Você deve ter uma política que descreva os métodos de comunicação segura e verificável que você usará. Isso é necessário para comunicação entre CSIRTs e entre um CSIRT e a sua comunidade. O formulário deve incluir chaves públicas ou indicação de onde elas se encontram, incluir chaves de impressões digitais, juntamente com a orientação de como utilizar esta informação para checar a autenticidade e como lidar com informações corrompidas (por exemplo, onde reportar este fato).
No momento é recomendável que , no mínimo, cada CSIRT tenha (se possível) uma chave PGP disponível. Um grupo deve também disponibilizar outros mecanismos (por exemplo, PEM, MOSS, S/MIME) de acordo com as suas necessidades e da sua comunidade. Observe-se no entanto que cada grupo e usuários devem estar atentos às leis e regulamentos locais.
Alguns países não permitem criptografia forte ou obriga políticas específicas sobre o uso da tecnologia de criptografia. Além de informação criptografada sempre que possível, a correspondência deve incluir assinaturas digitais. (Por favor observem que na maioria dos países, a proteção ou autenticidade do uso de assinaturas digitais não é afetado pelos regulamentos de criptografia já existentes).
Para comunicação via telefone ou fax um CSIRT deve estabelecer, entre as partes com as quais está lidando uma forma de autenticar as informações, como o uso de uma senha ou frase. Obviamente, tais chaves secretas não devem ser divulgadas, embora seja possível a divulgação da sua existência.
3.5. Serviços
Os serviços prestados por um CSIRT podem ser a grosso modo divididos em duas categorias: atividades em tempo-real diretamente relacionadas à tarefa principal de reposta a incidente, e atividades preventivas em tempo- não-real, de suporte à tarefa de resposta a incidente. A Segunda categoria e parte da primeira categoria consiste nos serviços que são opcionais no sentido de que nem todos os CSIRTs irão oferecê-los.
3.5.1. Resposta a Incidente
Resposta a incidente normalmente inclui a avaliação dos relatos sobre incidentes recebidos ("Triagem de Incidentes") e o acompanhamento deles com outros CSIRTs, ISPs (provedor de acesso à Internet) e sites ("Coordenação de Incidente"). Um terceiro nível de serviços, ajudar um site local a se recuperar de um incidente (Resolução de Incidentes), é incluído como típico serviço opcional, que nem todo CSIRT oferecerá.
3.5.1.1. Triagem de Incidente
A triagem de incidente normalmente inclui:
- Avaliação de relato Interpretação dos relatos de incidentes recebidos, priorizando-os, e relacinando-os aos incidentes em andamento e direcionando-os.
- Verificação Ajuda a determinar se um incidente realmente ocorreu e o seu escopo.
3.5.1.2. Coordenação de Incidente
A Coordenação normalmente inclui:
- Categorização da informação Categorização da informação sobre incidentes (arquivos de log, informação sobre contato, etc). Respeitando a política de divulgação de informação.
- Coordenação Notificação de outras partes envolvidas, descrevendo sucintamente o incidente e informando a política de divulgação de informações.
3.5.1.3. Resolução de Incidentes
Normalmente adicionais ou opcionais, os serviços de resolução de incidentes incluem:
- Assistência Técnica Podendo incluir a análise dos sistemas comprometidos.
- Erradicação Eliminação da causa do incidente de segurança (a vulnerabilidade explorada) e dos seus efeitos (por exemplo, acessos contínuos ao sistema por um intruso).
- Recuperação Ajudar a restaurar sistemas afetados e serviços à sua condição anterior ao incidente.
3.5.2. Atividades Preventivas
Normalmente adicionais ou opcionais, os serviços preventivos podem incluir:
- Provisão de informação Este pode incluir um arquivo de vulnerabilidades conhecidas, consertos ou resoluções de problemas anteriores ou uma lista para divulgação de boletins.
- Ferramentas de segurança Este pode incluir ferramentas para auditar a segurança de um site.
- Educação e treinamento
- Avaliação de produto
- Auditoria de segurança de site e consultoria
3.6. Formulários de Relatos de Incidente
O uso de formulários de relatos facilita, tanto para os usuários quanto para os grupos. A comunidade pode preparar respostas para várias questões importantes antes de efetivamente entrar em contato com o grupo, chegando a ele melhor preparada, de maneira que o grupo recebe toda a informação necessária já no primeiro relato, podendo agir mais eficientemente.
Dependendo dos objetivos e serviços de um CSIRT em particular, vários formulários podem ser usados, por exemplo, um formulário de relato para uma nova vulnerabilidade pode ser bem diferente de um formulário usado para relato de incidentes.
É mais eficaz fornecer formulários através dos serviços de informação on-line do grupo. Na página do grupo podem ser colocados indicadores para acessá-los, juntamente com orientações sobre o uso correto e sobre quando e como usá-los.
Se existir um endereço de e-mail especificamente para envio de formulários de relato de incidentes, ele também deve ser listado.
Um exemplo desse tipo de formulário é o "Fomulário de Relato de Incidente" fornecido pelo Centro de Coordenação do CERT: - ftp://info.cert.org/incident_reporting_form
3.7. Avisos
Embora o documento de descrição do CSIRT não constitua um contrato, responsabilidades podem derivar das suas descrições de serviços e propósitos. A inclusão de um aviso no final do formulário é recomendada e deve alertar os usuários sobre possíveis limitações.
Em situações em que a versão original de um documento deve ser traduzida em outra língua, a tradução deve trazer um aviso e um indicador para o original. Por exemplo:
Embora tenhamos tentado traduzir cuidadosamente o documento original do alemão para o inglês, não podemos estar certos que os dois documentos expressam os mesmos pensamentos no mesmo nível de detalhes e correção. Em todos os casos, onde houver uma diferença entre as duas versões, prevalecerá a versão alemã.
O uso e a proteção dos avisos são afetados pela leis e regulamentos locais de que cada CSIRT deve estar ciente. Em caso de dúvida, o CSIRT deve checar o aviso com um advogado.
5. Considerações sobre Segurança
6. Referências
[1] Brownlee & Guttman, "Expectations for Computer Security Incident
Response", BCP 21, RFC 2350, June 1998.
7. Endereços dos Tradutores
nelson@pangeia.com.br
Apêndice A: Glossário
Este glossário define termos usados na descrição de incidentes de segurança e Grupos de Resposta a Incidente de Segurança em Computador. Para mais definições, favor buscar outras fontes como por exemplo o Glossário de Usuários da Internet [RFC 1983].
Comunidade
A comunidade é um dos objetivos implícitos de um Grupo de Resposta a Incidente de Segurança em Computador. Trata-se do grupo de usuários, sites, redes ou organizações servidas pelo grupo. Este deve ser reconhecido pela sua comunidade para ser efetivo.
Incidente de Segurança
Para o propósito deste documento, este termo é sinônimo de Incidente de Segurança em Computador: qualquer evento adverso que comprometa algum aspecto do computador ou de segurança da rede.
A definição de um incidente pode variar entre organizações, mas pelo menos as seguintes categorias são geralmente aplicáveis:
- Quebra do sigilo da informação
- Comprometimento da integridade da informação
- Recusa de serviço
- Mal uso de serviço, sistemas ou informação
- Danos aos sistemas
Essas são categorias bem gerais. Por exemplo a substituição de um programa por um Cavalo de Tróia é um exemplo de comprometimento da integridade e um ataque bem sucedido a uma senha é um exemplo de 'quebra de sigilo'. Os ataques, mesmo que tenham falhado em virtude de proteção adequada, podem ser vistos como incidentes.
Dentro da definição de um incidente a palavra 'comprometido' é usada. Algumas vezes um administrador pode apenas 'suspeitar' de um incidente. Durante a resposta deve ficar estabelecido se um incidente realmente ocorreu ou não.
Grupo de Resposta a Incidente de Segurança em Computador
Baseado em duas das definições acima, um CSIRT é um grupo que coordena e dá suporte, resposndendo a incidente de segurança que envolvam sites dentro de uma determinada comunidade.
Para ser considerado um CSIRT, um grupo deve:
- Prover um canal (seguro) para recebimento de relatos sobre suspeita de incidentes.
- Prover assistência aos membros da sua comunidade, cuidando dos incidentes
- Disseminar informações sobre incidentes relatados para a sua comunidade e para as outras partes envolvidas.
Observe que não estamos nos referindo aqui à polícia ou a outras entidades de reforços da lei que podem investigar crimes relacionados a computadores.
Os membros dos CSIRTs não precisam de forma alguma ter poderes acima daqueles dos cidadãos comuns.
Fabricante
Um 'fabricante' é uma entidade que produz redes ou tecnologia de computador e é responsável pelo conteúdo técnico dessa tecnologia. Exemplos de 'tecnologia' inclui hardware (computador de mesa, roteadores, switches, etc), e software (sistemas operacionais, sistemas de encaminhamento de e-mail, etc).
Observe que o fornecedor de uma tecnologia não é necessariamente o fabricante dessa tecnologia. Como um exemplo, um Provedor de Acesso à Internet (ISP) pode fornecer roteadores a cada um dos seus clientes, enquanto que o fabricante, mais que o ISP, é a entidade responsável pelo conteúdo técnico do roteador.
Vulnerabilidade
Apêndice B: Material Correlato
Publicações importantes relativas a incidente de segurança em nível de um site são encontrados no [RFC 2196], o Site Security Handbook, produzido pelo Site Security Handbook Working Group (SSH). Este documento será atualizado pelo SSH Working Group e dará recomendações para políticas locais e procedimentos, principalmente relacionados a como evitar incidentes de segurança.
Outros documentos de interesse para a discussão de CSIRTs e de suas atribuições estão disponíveis em um FTP anônimo: - ftp://ftp.cert.dfn.de/pub/docs/csir/
Maiores informações sobre o conteúdo desse diretório são encontradas no arquivo 01-README. Alguns documentos especialmente interessantes em relação a este documento são os seguintes:
- ftp://ftp.nic.surfnet.nl/surfnet/net-security/cert-n1/docs/reports/R-92-01
Este relatório contém a Estrutura Operacional do CERT-NL, o CSIRT do SURFnet (provedor de rede na Holanda).
- Para leitores interessados na operação de um FIRST (Fórum de Resposta a Incidente e Grupos de Segurança) mais informação é coletada no Apêndice C.
- http://hightop.nrl.navy.mil/news/incident.html
Este documento leva ao NRL Manual de Resposta a Incidente.
- http://www.cert.dfnde/eng/team/kpk/certbid.html
Este documento contém uma bibliografia anotada de material disponível, documentos e arquivos sobre o funcionamento de CSIRTs com links para vários dos itens mencionados.
- ftp://info.cert.org/incident_reporting_form
Este Formulário de Relato de Incidente é fornecido pelo Centro de Coordenação do CERT para coletar informação sobre incidente e evitar maiores atrasos causados pela necessidade de se obter informação mais detalhada do site que está relatando.
- http://www.cert.org/cert.faqintro.html
Uma coletânea das perguntas mais freqüentes do Centro de Coordenação do CERT.
Apêndice C: Grupos de Resposta a Incidente de Segurança conhecidos
Existem hoje muitos CSIRTs, mas nenhuma fonte lista todos eles. Grande parte dos maiores e mais antigos CSIRTs (o primeiro foi fundado em 1988) são hoje membros do FIRST, o Fórum Mundial de Resposta a Incidente e Grupos de Segurança. Até o momento, mais de 55 grupos são membros (1 na Austrália, 13 na Europa e todos os outros na América do Norte). Informação sobre o FIRST pode ser encontrada em:
- http://www.first.org
A lista corrente de membros também está disponível, com relevantes informações sobre contato e algumas informações adicionais fornecidas por alguns grupos em particular:
- http://www.first.org/team-info/
Para os CSIRTs que querem se tornar membros deste Fórum (por favor observem que cada grupo precisa de um patrocinador -um grupo que já seja membro do FIRST - que o apresente). Os seguintes arquivos contêm mais informação:
- http://www.first.org/about/op_frame.html
A Estrutura Operacional do FIRST
- http://www.first.org/docs/newmen.html
Diretrizes para grupos que queiram se tornar membros do FIRST
A maioria dos grupos europeus independentemente de serem membros do FIRST ou não, são listados por países numa página mantida por um CSIRT alemão:
- http://www.cert.dfn.de/eng/csir/europe/certs.html
Para saber sobre a existência de grupos mais indicados para uma necessidade específica, é freqüentemente de grande ajuda perguntar ou a grupos conhecidos ou a um Provedor de Acesso à Internet qual o contato "certo".
No Brasil utilize: http://www.nic.br/nbso.html
Documentos do GT-S
Expectativas quanto a Grupos de Resposta a Incidente de Segurança em Computador
Comitê Gestor da Internet/Brasil
Grupo de Trabalho em Seguranca de Redes (GTS)
Janeiro 1999
Status deste Documento
Este documento fornece informações para a comunidade Internet do Brasil, e solicita discussão e sugestões para melhorias. Este documento não especifica padrões Internet de qualquer tipo. A distribuição deste documento é ilimitada.
Resumo
O objetivo deste documento é expressar as expectativas da Comunidade Internet em geral quanto aos Grupos de Resposta a Incidente de Segurança em Computador (CSIRTs - Computer Security Incident Response Teams). Não é possivel definir um conjunto de requisitos que seriam mais apropriados a todos os grupos, mas é possível e de grande ajuda listar e descrever o conjunto geral dos tópicos e assuntos que são de interesse e concernentes s comunidades constituintes. Os constituintes de um CSIRT têm uma legítima necessidade e direito de entender completamente a política e o procedimento do grupo a que estão vinculados. Uma maneira de promover essa compreensão é fornecer informação detalhada, que ser submetida à apreciação dos usuários, na forma de um formulário elaborado pelo grupo. Um esboço de formulário e um exemplo preenchido são fornecidos adiante.
- 1.Introdução
- 2. Escopo
- 3. Informação, Política e Procedimentos
- 4. Agradecimentos
- 5. Considerações a respeito de Segurança
- 6. Referências
- 7. Endereços do autores
- 8. Indicação completa do Copyright
- Apêndice A: Glossário
- Apêndice B: Material Correlato
- Apêndice C: CSIRTs Conhecidos
- Apêndice D: Modelo para formulário do CSIRT
- Apêndice E: Exemplo - Formulário preenchido
1. Introdução
O grupo de trabalho GRIP foi formado para criar um documento que descrevesse as expectativas da comunidade em relação aos Grupos de Resposta a Incidente de Segurança em Computador.
Embora a necessidade de tal documento tenha se originado na comunidade Internet em geral, as expectativas expressas corresponderiam também àquelas de comunidades mais restritas. No passado houve mal entendidos quanto ao que esperar dos CSIRTs. O objetivo deste documento é prover uma estrutura apresentando assuntos importantes (relacionados a resposta a incidente) concernentes à comunidade.
Antes de continuar, é importante compreender claramente o significado do termo "Grupo de Resposta a Incidente de Segurança em Computador" - CSIRT. Para o que se propõe este documento, um CSIRT é um grupo que executa, coordena e dá suporte, respondendo a incidentes de segurança que envolvam sites e equipamentos de usuários, entidades e empresas comerciais ou não que este represente. Qualquer grupo que se denomine CSIRT perante uma comunidade específica deve, daí em diante, atender aos relatos de incidentes de segurança e a ameaças à "sua" comunidade nos moldes em que esta comunidade específica concordar que seja do seu interesse geral.
Como é de vital importância que cada membro de uma comunidade esteja apto a compreender o que razoavelmente pode esperar do seu grupo, um CSIRT deve deixar claro quem pertence à sua comunidade e definir os serviços que oferece comunidade. Além disso, cada CSIRT deve publicar a sua política e procedimentos operacionais. Em contrapartida, esses mesmos constituintes precisam saber o que é esperado deles para que recebam os serviços do seu grupo. Isso exige que o grupo publique também como e onde relatar incidentes.
Este documento detalha um formulário que será usado pelos CSIRTs para comunicar essa informação aos seus constituintes. Estes certamente esperarão que o CSIRT execute os serviços descritos nos formulários.
Deve-se enfatizar que sem a participação ativa dos usuários, a eficácia dos serviços dos CSIRTs pode diminuir significativamente. Este é particularmente o caso dos relatos. No mínimo, os usuários precisam saber que eles devem relatar incidentes de segurança, saber como e onde relatá-los.
Muitos incidentes de segurança em computadores originam-se fora dos limites da comunidade local e afetam os sites internos, outros originam-se dentro da comunidade local e afetam equipamentos ou usuários de fora. Freqüentemente, no entanto, o trabalho com incidentes de segurança envolve vários sites e potencialmente vários CSIRTs. Resolver esses incidentes exigirá cooperação entre sites individuais e CSIRTs e entre diferentes CSIRTs.
Comunidades constituintes precisam saber exatamente como o seu CSIRT trabalhará com outros CSIRTs e organizações fora da sua comunidade e que informações serão compartilhadas.
O resto deste documento descreve o conjunto de tópicos e assuntos que os CSIRTs precisam elaborar para os seus constituintes. No entanto, não há nenhuma tentativa de especificar a resposta "correta" a cada tópico. Ao contrário, cada tópico é discutido nos termos do seu significado.
O capítulo dois nos traz uma visão mais ampla de três áreas importantes: a publicação da informação por um grupo de resposta, a definição do relacionamento entre um grupo de resposta e outros grupos de resposta e a necessidade de comunicação segura.
O capítulo três descreve em detalhes todos os tipos de informação que a comunidade precisa saber sobre o seu grupo de resposta. Para facilitar o uso por parte da comunidade, esses tópicos estão condensados num esboço de formulário encontrado no Apêndice D. Esse formulário pode ser usado pela comunidade como exemplo.
O Grupo de Trabalho espera sinceramente que através da elucidação dos tópicos neste documento, a compreensão entre a comunidade e os respectivos CSIRTs aumente.
2. Escopo
As interações entre um Grupo de Resposta a Incidente e sua comunidade constituinte requer primeiro que a comunidade compreenda a política e os procedimentos do seu Grupo de Resposta. Em segundo lugar, como muitos grupos colaboram com outros, a comunidade deve também entender o relacionamento entre o seu Grupo de Resposta com os outros Grupos de Resposta. Finalmente, muitas interações se darão com as infra-estruturas públicas existentes, de maneira que a comunidade precisa saber como essas comunicações serão protegidas. Cada um desses assuntos será descrito em detalhes nas próximas três seções.
2.1. Publicação da Política e dos Procedimentos dos CSIRTs
Cada usuário que tiver acesso a um Grupo de Resposta a Incidente de Segurança em Computador deve saber tanto quanto possível sobre os serviços e as interações com esse grupo muito antes que venha a precisar dele.
Um claro estabelecimento da política e dos procedimentos do CSIRT ajuda os constituintes a compreender a melhor maneira de relatar um incidente e que tipo de suporte esperar depois. O CSIRT ajudará a resolver o incidente? Ele ajudará a evitar incidentes no futuro?
Tornar claras as expectativas, particularmente quanto às limitações dos serviços prestados por um CSIRT, tornará a interação com ele mais eficiente e efetiva.
Há vários tipos de grupos de resposta: alguns têm constituições bastante abrangentes (p.ex., CERT Coordination Center and the Internet), outros são de constituições mais limitadas ( p.ex., DFN-CERT, CIAC), e outros ainda têm constituições muito restritas (e.g., grupos de resposta comerciais, grupos de resposta corporativos). Independentemente do tipo de grupo de resposta, a comunidade a que ele dá suporte deve ter conhecimento da política do grupo e dos seus procedimentos. Por isso, é imperativo que os grupos de resposta publiquem esse tipo de informação para sua comunidade.
Um CSIRT deve comunicar toda a informação necessária a respeito de sua política e serviços num formulário correspondente às necessidades da sua comunidade. É importante entender que nem todas as políticas e procedimentos precisam estar publicamente disponíveis. Por exemplo, não é necessário entender a operação interna de um grupo para interagir com ele, como quando um usuário reporta um incidente ou recebe orientação ou como o grupo analisa ou assegura os sistemas de alguém.
No passado, alguns grupos forneciam uma espécie de Estrutura Operacional, outros forneciam uma Lista de Perguntas mais Freqüentes (FAQ ), enquanto outros escreviam textos técnicos para distribuição em encontros de usuários ou os enviavam para publicações especializadas.
Recomenda-se que cada CSIRT publique suas diretrizes e procedimentos no seu próprio servidor de informações (p.ex., servidor da World Wide Web). Isto permitirá que os constituintes possam facilmente acessá-los, embora permaneça o problema de como um constituinte poderá encontrar o seu grupo; as pessoas dentro de uma comunidade terão que descobrir que existe um CSIRT "à sua disposição".
É de se supor que os formulários dos CSIRTs tornem-se em breve acessíveis através de mecanismos de busca, que ajudarão na divulgação sobre a sua existência e das informações básicas necessárias para se chegar até eles.
Seria bastante útil ter um repositório central contendo todos os formulários. Tal repositório não existe no momento, embora isso possa mudar no futuro.
Independentemente da fonte onde a informação foi obtida, o usuário do formulário deve checar sua autenticidade. É extremamente recomendável que documentos de tamanha importância estejam protegidos por assinaturas digitais. Isso permitirá ao usuário verificar que o formulário foi realmente publicado pelo CSIRT e não foi alterado. Presume-se que o leitor esteja familiarizado com o uso adequado de assinaturas digitais como forma de determinar se um documento é autêntico.
2.2. Relacionamento entre diferentes CSIRTs
Em alguns casos um CSIRT terá condições de efetivamente operar sozinho e em estreita cooperação com seus constituintes, mas com a atual internacionalização das redes torna-se mais provável que a maioria dos incidentes de que um CSIRT esteja tratando envolvam partes externas à sua comunidade. Por essa razão, um grupo precisará interagir com outros CSRITs e sites fora externos.
A comunidade deve entender a natureza e extensão dessa colaboração,como informações sensíveis sobre uma determinada instalação podem ser divulgadas nesse processo.
Interação entre CSIRTs podem incluir questionamento a outro grupo, para advertir, disseminar conhecimento de problemas, e trabalho cooperativo para resolver incidentes de segurança que afetem um ou mais usuários dos CSIRTs.
No estabelecimento desse relacionamento onde existirá uma interação, os CSIRTs devem decidir que tipos de acordo podem existir entre eles, sobre como compartilhar informações sigilosas , se esse relacionamento pode ser divulgado, e em caso afirmativo, para quem.
Observe que há uma diferença entre um acordo de parceria, em que os CSIRTs envolvidos concordam em trabalhar juntos e compartilhar informações e uma simples cooperação, em que um CSIRT (ou qualquer outra organização) simplesmente entra em contato com outro CSIRT epede ajuda ou orientação.
Embora o estabelecimento de tais relacionamentos seja muito importante e afete a capacidade de um CSIRT dar suporte aos seus constituintes, cabe aos grupos envolvidos decidir sobre os detalhes. Está além do escopo deste documento fazer recomendações sobre esse processo.
De qualquer forma, o mesmo conjunto de informações disponibilizado aos usuários tratando da divulgação de informações ajudará outras partes a compreender os objetivos e serviços de um CSIRT específico, facilitando um primeiro contato.
2.3. Estabelecimento de comunicações seguras
Uma vez que uma parte tenha decidido trocar informação com outra parte, ou duas partes tenham concordado em trocar informação ou trabalhar em conjunto - como exigido para a coordenação de resposta a incidente de segurança em computador - todas as partes envolvidas precisam de canais de comunicação seguros. (Neste contexto "seguro" refere-se a transmissão de comunicação protegida compartilhada entre as várias partes, e não ao uso apropriado da informação pelas partes).
Os objetivos de comunicação segura são:
- Sigilo Alguém mais pode ter acesso ao conteúdo da comunicação?
- Integridade Alguém mais pode manipular o conteúdo da comunicação?
- Autenticidade Estou me comunicando com a pessoa "certa"?
É muito fácil enviar e-mails falsos e não é difícil criar uma (falsa) identidade por telefone. Técnicas criptográficas, por exemplo Pretty Good Privacy (PGP) ou Privacy Enhanced Mail (PEM) podem eficazmente prover meios de proteger e-mail. Com o equipamento correto também é possível proteger comunicação telefônica. Mas antes de usar tais mecanismos, ambas as partes precisam da infra-estrutura "certa", ao que se chamaria de preparação prévia. A preparação mais importante é assegurar a autenticidade das chaves criptográficas usadas na comunicação segura:
- Chaves públicas (para técnicas como PGP e PEM): Como são acessíveis através da Internet, as chaves públicas devem ser autenticadas antes de usadas. Enquanto PGP se baseia numa "Rede de Confiança" (onde usuários assinam as chaves de outros usuários), PEM se baseia numa hierarquia (onde autoridades de certificação assinam as chaves dos usuários).
- Chaves secretas (para técnicas como DES e PGP/conventional encrytion): Como devem ser conhecidas tanto pelo emissor quanto pelo receptor, as chaves secretas devem ser trocadas antes da comunicação através de um canal seguro.
A comunicação é crítica em todos os aspectos de resposta a incidentes um grupo pode fazer melhor uso das técnicas acima mencionadas recolhendo toda informação relevante, de maneira consistente. Requerimentos específicos (como discar um número específico para checar a autenticidade das chaves) devem estar claros desde o começo. Os formulários dos CSIRTs fornecem um meio padronizado para transportar esta informação. Está além do escopo deste documento endereçar os problemas técnicos e administrativos de comunicação segura. A questão é que grupos de resposta devem dar suporte e utilizar um método para assegurar a comunicação entre eles e seus constituintes (ou outros grupos de resposta). Qualquer que seja o mecanismo, o nível de proteção que ele oferecer deve ser aceitável à comunidade constituinte.
3. Informação, Política e Procedimentos
No capítulo 2 foi mencionado que a política e os procedimentos de um grupo de resposta precisam ser publicados para a comunidade constituinte. Neste capítulo listaremos todos os tipos de informação que a comunidade precisa receber do seu grupo de resposta. Como esta informação é comunicada varia de grupo para grupo, da mesma forma que varia também o conteúdo da informação. A intenção aqui é descrever claramente os diversos tipos de informação que uma comunidade constituinte espera do seu grupo de resposta.
Para facilitar a compreensão dos assuntos e tópicos relevantes à interação dos constituintes com o seu CSIRT, sugerimos que o grupo publique toda a informação, política e procedimentos endereçando-os aos seus constituintes como um documento, seguindo o formulário fornecido no Apêndice D. O formulário organiza itens, facilitando o acréscimo de informação específica; no Apêndice E fornecemos um exemplo de formulário preenchido para uma universidade XYZ fictícia.
Enquanto nenhuma recomendação é feita quanto ao que um CSRIT deve adotar como sua política ou procedimentos, diversas possibilidades aparecem como exemplos. O mais importante é que um CSIRT tenha uma política e que aqueles que com ele interagem estejam aptos a obtê-la e compreendê-la.
Como sempre, nem todos os aspectos para cada ambiente e/ou grupo podem ser listados. Este modelo deve ser visto como uma sugestão. Cada grupo deve sentir-se livre para incluir o que quer que eles achem que seja necessário para o suporte da sua comunidade.
3.1. Obtenção do documento
Detalhes de um CSIRT mudam com o tempo, portanto, o formulário deve indicar quando foi modificado pela última vez. Adicionalmente, informação sobre como encontrar futuras atualizações deve ser fornecida. Do contrário, é inevitável que mal-entendidos e concepções errôneas surjam com o tempo. Documentos desatualizados podem trazer mais prejuízo do que benefício.
- Data da última atualização - Deve ser suficiente para permitir a qualquer interessado avaliar se o formulário é atual ou não.
- Distribuição de listas - Enviar listas é um mecanismo conveniente para distribuir informação atualizada a um grande número de usuários. Um grupo pode decidir se usa sua própria lista ou alguma já existente para notificar os usuários sempre que houver mudanças no documento. A lista pode ser de grupos com os quais os CSIRTs interajam com freqüência. Assinaturas digitais devem ser utilizadas em mensagens de atualização enviadas por um CSIRT.
- Localização do documento - O lugar onde uma versão atualizada do documento poderá ser acessada através dos serviços de informação on-line do grupo. Os constituintes poderão então facilmente aprender mais sobre o grupo e checar atualizações recentes Esta versão on-line também deve vir acompanhada de uma assinatura digital.
3.2. Informação sobre contato
Detalhes completos sobre como contatar o CSIRT deve ser listada aqui, embora eles possam diferir muito de grupo para grupo; por exemplo, alguns podem optar por não listar os nomes dos membros do seu grupo.
Nenhum esclarecimento adicional deve ser dado quando o significado de um item pode ser presumido.
- Nome do CSIRT
- Endereço para correspondência
- Fuso horário É útil para coordenar incidentes em que ocorra diferença de fuso horário. - Número de telefone
- Número de fax
- Outros tipos de telecomunicação Alguns grupos podem oferecer contato telefônico seguro
- Endereço de correio eletrônico
- Chaves públicas e criptografia O uso de técnicas específicas depende da habilidade de os parceiros na comunicação acessar os programas, chaves, etc. Informação relevante deve ser dada para capacitar os usuários a determinar se e como eles podem fazer uso de comunicação criptografada durante a interação com o CSIRT.
- Membros do grupo
- Horário de funcionamento Horário de funcionamento e escala em feriados devem ser Fornecidas. Existe uma linha funcionando 24 horas?
- Informação adicional sobre contato Existe alguma informação específica sobre contato do cliente Informação detalhada adicional sobre contato deve ser fornecida. Isso pode incluir diferentes contatos para diferentes serviços. Se houver procedimentos específicos para acesso a alguns serviços (por exemplo endereços para solicitação de mala direta), deve ser explicado aqui.
3.3. Estatuto
Cada CSIRT deve ter um estatuto que especifique o que fazer e sob a autoridade de quem fazer. O estatuto deve incluir ao menos os seguintes itens:
- Estabelecimento de metas - Constituição - Patrocínio/afiliação
- Autoridade
3.3.1. Estabelecimento de metas
O estabelecimento das metas deve focalizar as atividades essenciais do grupo, já especificadas na definição de um CSIRT. Para ser considerado um Grupo de Resposta a Incidente de Segurança em Computador, um grupo deve dar suporte aos relatos de incidentes e à sua comunidade lidando com os incidentes.
As metas e proposições de um grupo são especialmente importantes e exigem uma definição clara, não ambígua.
3.3.2. Constituição
A constituição de um grupo pode ser determinada de várias maneiras. Pode tratar-se, por exemplo, dos empregados de uma companhia ou dos seus assinantes pagos, ou pode ser definida, ainda, a partir de um ângulo tecnológico, como os usuários de um sistema operacional em particular.
A definição de uma constituição deve criar em torno do grupo um perímetro a quem o mesmo prestará serviço. A seção de política do documento (veja abaixo) explicará como as solicitações de fora deste perímetro serão conduzidas.
Se um CSIRT decidir não divulgar suas diretrizes, deve explicar as razões por trás dessa decisão. Por exemplo, alguns CSIRTs podem não listar seus clientes, mas declararão que prestam serviços a uma vasta clientela que será mantida sob sigilo em decorrência de acordos contratuais.
Pode ocorrer sobreposição de constituições, como quando um ISP provê um CSIRT que transporta serviços a um cliente que também tem CSIRTs. A seção "Autoridade" da descrição dos CSIRTs (veja abaixo) deve esclarecer essas relações.
3.3.3. Organização patrocinadora / Afiliação
A organização patrocinadora, que autoriza as ações de um CSIRT deve vir em seguida. Sabendo que isso ajudará os usuários a entender o que está por trás de um CSIRT e a sua estruturação, e é uma informação vital para construir a confiança entre os constituintes e um CSIRT.
3.3.4. Autoridade
Esta seção vai variar muito de um CSIRT para outro, baseada no relacionamento entre um grupo e a sua comunidade. Enquanto a autoridade de um CSIRT organizacional será dada pela gerência da organização, um CSIRT comunitário será escolhido e legitimado pela comunidade, normalmente num papel de orientação.
Um CSIRT pode ou não ter autoridade para intervir na operação de todos os sistemas dentro do seu perímetro. Ele deve identificar o escopo do seu controle diferenciando-o do perímetro da sua comunidade. Se outros CSIRTs operam hierarquicamente dentro do seu perímetro, isto deve ser mencionado os CSIRTs devem ser identificados.
A divulgação da autoridade de um grupo pode expô-la a reivindicações de responsabilidade legal. Cada grupo deve procurar aconselhamento legal nesta matéria (veja mais sobre responsabilidade na seção 3.7).
3.4. Política
É crucial que um grupo de resposta defina sua política. As seções seguintes discutem a comunicação da política do grupo à comunidade constituinte.
3.4.1. Tipos de Incidentes e Níveis de Suporte
Os tipos de incidente que o grupo está capacitado a endereçar e o nível de suporte que irá oferecer ao responder a cada tipo de incidente deve estar resumido aqui na lista do formulário. A seção "Serviços" (ver abaixo) oferece a oportunidade de dar descrições mais detalhadas e de endereçar tópicos não relacionados a incidentes.
O nível de suporte pode mudar dependendo de fatores tais como a carga de trabalho do grupo e a integridade da informação disponível. Tais fatores devem ser esboçados e o seu impacto deve ser explicado.
Como uma lista de tipos conhecidos de incidentes será incompleta tendo em vista possíveis ou futuros incidentes, um CSIRT deve também dar algum tipo de informação de como será tratado um tipo de incidente que não tenha sido mencionado.
O grupo deve estabelecer se vai agir ao receber informação sobre vulnerabilidades que criem oportunidades para futuros incidentes. O compromisso de agir diante de tal informação no interesse de sua comunidade é visto como uma política de serviços de precaução do que um serviço essencial exigido de um CSIRT.
3.4.2. Cooperação, Interação e Divulgação de Informação
Esta seção deve explicitar com que grupos correlatos o CSIRT interage. Essas interações não são necessariamente relacionadas a resposta a incidente de segurança , mas são usadas para facilitar cooperação em tópicos técnicos ou serviços. De maneira alguma há necessidade de fornecer os detalhes sobre os acordos de cooperação.;o objetivo principal desta seção é dar aos constituintes uma compreensão básica do tipo de interação que é estabelecida e qual o seu propósito.
Cooperação entre CSIRTs pode ser facilitada pelo uso de um único número de protocolo combinado com procedimentos acordados de maneira explicita.
Isso reduz a chance de mal-entendidos, duplicação de esforços, ajuda no rastreamento de incidente e evita repetições na comunicação. O relatório e a divulgação da política deve deixar claro quem será o receptor do relato de um CSIRT em qualquer circunstância. Deve também assinalar se o grupo espera operar através de outro CSIRT ou diretamente com um membro de outra comunidade em assuntos especificamente concernentes àquele membro.
Grupos correlatos com os quais um CSIRT irá interagir são listados abaixo:
Grupos de Resposta a Incidente:
Um CSIRT precisará freqüentemente interagir com outros CSIRTs. Por exemplo, um CSIRT dentro de uma grande companhia talvez precise relatar incidentes a um CSIRT nacional, e um CSIRT nacional talvez precise relatar incidentes a CSIRTs nacionais de outros países para lidar com todos os sites envolvidos num ataque de larga escala.
Colaboração entre CSIRTs pode levar a divulgação de informação. Seguem-se exemplos de tal divulgação, mas não são se pretende que seja uma lista exaustiva:
- Relatando incidentes dentro da comunidade a outros grupos. Se isso ocorre, informação de sites correlatos podem se tornar de conhecimento público, acessível a qualquer um, em particular a imprensa.
- Lidando com incidentes ocorrendo dentro da comunidade, mas relatados de fora dele (o que implica que alguma informação já foi disponibilizada fora do site).
- Reportando observações de dentro da comunidade indicando suspeita ou confirmação de incidente de fora.
- Agindo em relatos de incidentes de fora da comunidade.
- Passando informação sobre vulnerabilidades a fabricantes, a parceiros dos CSIRTs ou diretamente a sites afetados dentro ou fora da comunidade.
- Resposta a outras partes que relatem incidentes ou vulnerabilidades.
- A provisão de informação sobre contato relacionada a membros da comunidade, a outros CSIRTs ou representantes da lei.
Fabricantes:
Alguns fabricantes têm seu próprio CSIRT, mas alguns podem não ter. Nesses casos, um CSIRT precisará trabalhar diretamente com um fabricante para sugerir melhoramentos ou modificações, para analisar o problema técnico ou para testar novas soluções. O fabricantes têm um papel importante em casos de incidente se as vulnerabilidades do seu produto estiverem envolvidas no incidente.
Representantes da Lei:
Incluem-se nesses a polícia e outras agências investigadoras. CSIRts e usuários do formulário devem estar atentos às leis locais e regulamentos, que podem variar consideravelmente em diferentes países. Um CSIRT pode dar aconselhamento em detalhes técnicos de ataques ou buscar aconselhamento sobre as implicações legais de um incidente. As leis locais podem incluir exigência de relatos específicos ou sigilo.
Imprensa:
Um CSIRT pode ser abordado pela imprensa para informações e comentários de tempos em tempos.
Uma política explícita concernente a divulgação para a imprensa pode ser de grande ajuda, particularmente para clarificar as expectativas de uma comunidade de um CSIRT. A política de imprensa terá detalhar os tópicos, uma vez que a comunidade estará normalmente muito sensível a contatos da imprensa.
Outros:
Este pode incluir atividades de pesquisa em relação à organização patrocinadora. O estado de qualquer e todas as informações relacionadas com segurança que um grupo receba será normalmente "confidencial", mas uma adesão rígida a isso faz com que o grupo apareça como um "buraco negro" informal que pode reduzir a probabilidade de o grupo obter cooperação dos clientes e de outras organizações. O formulário do CSIRT deve definir que informação ele vai relatar ou divulgar, para quem e quando.
Grupos distintos estão igualmente propensos a ser sujeitos de diferentes restrições legais que exijam ou limitem a divulgação, especialmente se eles funcionam em jurisdições diferentes. Além disso, eles podem ter exigências de relatos impostas por sua organização patrocinadora. Cada formulário de grupo deve especificar qualquer uma dessas restrições, tanto para esclarecer as expectativas dos usuários quanto para informar outros grupos.
Conflitos de interesse, particularmente em assuntos comerciais também podem restringir a divulgação por parte de um grupo; este documento não trata de como tais conflitos poderão ser conduzidos.
Um grupo normalmente colherá estatísticas. Se informação estatística for distribuída, a parte do formulário que trata da política de relato e divulgação deve explicitar isso e descrever como obter tais estatísticas.
3.4.3. Comunicação e Autenticação
Você deve ter uma política que descreva os métodos de comunicação segura e verificável que você usará. Isso é necessário para comunicação entre CSIRTs e entre um CSIRT e a sua comunidade. O formulário deve incluir chaves públicas ou indicação de onde elas se encontram, incluir chaves de impressões digitais, juntamente com a orientação de como utilizar esta informação para checar a autenticidade e como lidar com informações corrompidas (por exemplo, onde reportar este fato).
No momento é recomendável que , no mínimo, cada CSIRT tenha (se possível) uma chave PGP disponível. Um grupo deve também disponibilizar outros mecanismos (por exemplo, PEM, MOSS, S/MIME) de acordo com as suas necessidades e da sua comunidade. Observe-se no entanto que cada grupo e usuários devem estar atentos às leis e regulamentos locais.
Alguns países não permitem criptografia forte ou obriga políticas específicas sobre o uso da tecnologia de criptografia. Além de informação criptografada sempre que possível, a correspondência deve incluir assinaturas digitais. (Por favor observem que na maioria dos países, a proteção ou autenticidade do uso de assinaturas digitais não é afetado pelos regulamentos de criptografia já existentes).
Para comunicação via telefone ou fax um CSIRT deve estabelecer, entre as partes com as quais está lidando uma forma de autenticar as informações, como o uso de uma senha ou frase. Obviamente, tais chaves secretas não devem ser divulgadas, embora seja possível a divulgação da sua existência.
3.5. Serviços
Os serviços prestados por um CSIRT podem ser a grosso modo divididos em duas categorias: atividades em tempo-real diretamente relacionadas à tarefa principal de reposta a incidente, e atividades preventivas em tempo- não-real, de suporte à tarefa de resposta a incidente. A Segunda categoria e parte da primeira categoria consiste nos serviços que são opcionais no sentido de que nem todos os CSIRTs irão oferecê-los.
3.5.1. Resposta a Incidente
Resposta a incidente normalmente inclui a avaliação dos relatos sobre incidentes recebidos ("Triagem de Incidentes") e o acompanhamento deles com outros CSIRTs, ISPs (provedor de acesso à Internet) e sites ("Coordenação de Incidente"). Um terceiro nível de serviços, ajudar um site local a se recuperar de um incidente (Resolução de Incidentes), é incluído como típico serviço opcional, que nem todo CSIRT oferecerá.
3.5.1.1. Triagem de Incidente
A triagem de incidente normalmente inclui:
- Avaliação de relato Interpretação dos relatos de incidentes recebidos, priorizando-os, e relacinando-os aos incidentes em andamento e direcionando-os.
- Verificação Ajuda a determinar se um incidente realmente ocorreu e o seu escopo.
3.5.1.2. Coordenação de Incidente
A Coordenação normalmente inclui:
- Categorização da informação Categorização da informação sobre incidentes (arquivos de log, informação sobre contato, etc). Respeitando a política de divulgação de informação.
- Coordenação Notificação de outras partes envolvidas, descrevendo sucintamente o incidente e informando a política de divulgação de informações.
3.5.1.3. Resolução de Incidentes
Normalmente adicionais ou opcionais, os serviços de resolução de incidentes incluem:
- Assistência Técnica Podendo incluir a análise dos sistemas comprometidos.
- Erradicação Eliminação da causa do incidente de segurança (a vulnerabilidade explorada) e dos seus efeitos (por exemplo, acessos contínuos ao sistema por um intruso).
- Recuperação Ajudar a restaurar sistemas afetados e serviços à sua condição anterior ao incidente.
3.5.2. Atividades Preventivas
Normalmente adicionais ou opcionais, os serviços preventivos podem incluir:
- Provisão de informação Este pode incluir um arquivo de vulnerabilidades conhecidas, consertos ou resoluções de problemas anteriores ou uma lista para divulgação de boletins.
- Ferramentas de segurança Este pode incluir ferramentas para auditar a segurança de um site.
- Educação e treinamento
- Avaliação de produto
- Auditoria de segurança de site e consultoria
3.6. Formulários de Relatos de Incidente
O uso de formulários de relatos facilita, tanto para os usuários quanto para os grupos. A comunidade pode preparar respostas para várias questões importantes antes de efetivamente entrar em contato com o grupo, chegando a ele melhor preparada, de maneira que o grupo recebe toda a informação necessária já no primeiro relato, podendo agir mais eficientemente.
Dependendo dos objetivos e serviços de um CSIRT em particular, vários formulários podem ser usados, por exemplo, um formulário de relato para uma nova vulnerabilidade pode ser bem diferente de um formulário usado para relato de incidentes.
É mais eficaz fornecer formulários através dos serviços de informação on-line do grupo. Na página do grupo podem ser colocados indicadores para acessá-los, juntamente com orientações sobre o uso correto e sobre quando e como usá-los.
Se existir um endereço de e-mail especificamente para envio de formulários de relato de incidentes, ele também deve ser listado.
Um exemplo desse tipo de formulário é o "Fomulário de Relato de Incidente" fornecido pelo Centro de Coordenação do CERT: - ftp://info.cert.org/incident_reporting_form
3.7. Avisos
Embora o documento de descrição do CSIRT não constitua um contrato, responsabilidades podem derivar das suas descrições de serviços e propósitos. A inclusão de um aviso no final do formulário é recomendada e deve alertar os usuários sobre possíveis limitações.
Em situações em que a versão original de um documento deve ser traduzida em outra língua, a tradução deve trazer um aviso e um indicador para o original. Por exemplo:
Embora tenhamos tentado traduzir cuidadosamente o documento original do alemão para o inglês, não podemos estar certos que os dois documentos expressam os mesmos pensamentos no mesmo nível de detalhes e correção. Em todos os casos, onde houver uma diferença entre as duas versões, prevalecerá a versão alemã.
O uso e a proteção dos avisos são afetados pela leis e regulamentos locais de que cada CSIRT deve estar ciente. Em caso de dúvida, o CSIRT deve checar o aviso com um advogado.
5. Considerações sobre Segurança
6. Referências
[1] Brownlee & Guttman, "Expectations for Computer Security Incident
Response", BCP 21, RFC 2350, June 1998.
7. Endereços dos Tradutores
nelson@pangeia.com.br
Apêndice A: Glossário
Este glossário define termos usados na descrição de incidentes de segurança e Grupos de Resposta a Incidente de Segurança em Computador. Para mais definições, favor buscar outras fontes como por exemplo o Glossário de Usuários da Internet [RFC 1983].
Comunidade
A comunidade é um dos objetivos implícitos de um Grupo de Resposta a Incidente de Segurança em Computador. Trata-se do grupo de usuários, sites, redes ou organizações servidas pelo grupo. Este deve ser reconhecido pela sua comunidade para ser efetivo.
Incidente de Segurança
Para o propósito deste documento, este termo é sinônimo de Incidente de Segurança em Computador: qualquer evento adverso que comprometa algum aspecto do computador ou de segurança da rede.
A definição de um incidente pode variar entre organizações, mas pelo menos as seguintes categorias são geralmente aplicáveis:
- Quebra do sigilo da informação
- Comprometimento da integridade da informação
- Recusa de serviço
- Mal uso de serviço, sistemas ou informação
- Danos aos sistemas
Essas são categorias bem gerais. Por exemplo a substituição de um programa por um Cavalo de Tróia é um exemplo de comprometimento da integridade e um ataque bem sucedido a uma senha é um exemplo de 'quebra de sigilo'. Os ataques, mesmo que tenham falhado em virtude de proteção adequada, podem ser vistos como incidentes.
Dentro da definição de um incidente a palavra 'comprometido' é usada. Algumas vezes um administrador pode apenas 'suspeitar' de um incidente. Durante a resposta deve ficar estabelecido se um incidente realmente ocorreu ou não.
Grupo de Resposta a Incidente de Segurança em Computador
Baseado em duas das definições acima, um CSIRT é um grupo que coordena e dá suporte, resposndendo a incidente de segurança que envolvam sites dentro de uma determinada comunidade.
Para ser considerado um CSIRT, um grupo deve:
- Prover um canal (seguro) para recebimento de relatos sobre suspeita de incidentes.
- Prover assistência aos membros da sua comunidade, cuidando dos incidentes
- Disseminar informações sobre incidentes relatados para a sua comunidade e para as outras partes envolvidas.
Observe que não estamos nos referindo aqui à polícia ou a outras entidades de reforços da lei que podem investigar crimes relacionados a computadores.
Os membros dos CSIRTs não precisam de forma alguma ter poderes acima daqueles dos cidadãos comuns.
Fabricante
Um 'fabricante' é uma entidade que produz redes ou tecnologia de computador e é responsável pelo conteúdo técnico dessa tecnologia. Exemplos de 'tecnologia' inclui hardware (computador de mesa, roteadores, switches, etc), e software (sistemas operacionais, sistemas de encaminhamento de e-mail, etc).
Observe que o fornecedor de uma tecnologia não é necessariamente o fabricante dessa tecnologia. Como um exemplo, um Provedor de Acesso à Internet (ISP) pode fornecer roteadores a cada um dos seus clientes, enquanto que o fabricante, mais que o ISP, é a entidade responsável pelo conteúdo técnico do roteador.
Vulnerabilidade
Apêndice B: Material Correlato
Publicações importantes relativas a incidente de segurança em nível de um site são encontrados no [RFC 2196], o Site Security Handbook, produzido pelo Site Security Handbook Working Group (SSH). Este documento será atualizado pelo SSH Working Group e dará recomendações para políticas locais e procedimentos, principalmente relacionados a como evitar incidentes de segurança.
Outros documentos de interesse para a discussão de CSIRTs e de suas atribuições estão disponíveis em um FTP anônimo: - ftp://ftp.cert.dfn.de/pub/docs/csir/
Maiores informações sobre o conteúdo desse diretório são encontradas no arquivo 01-README. Alguns documentos especialmente interessantes em relação a este documento são os seguintes:
- ftp://ftp.nic.surfnet.nl/surfnet/net-security/cert-n1/docs/reports/R-92-01
Este relatório contém a Estrutura Operacional do CERT-NL, o CSIRT do SURFnet (provedor de rede na Holanda).
- Para leitores interessados na operação de um FIRST (Fórum de Resposta a Incidente e Grupos de Segurança) mais informação é coletada no Apêndice C.
- http://hightop.nrl.navy.mil/news/incident.html
Este documento leva ao NRL Manual de Resposta a Incidente.
- http://www.cert.dfnde/eng/team/kpk/certbid.html
Este documento contém uma bibliografia anotada de material disponível, documentos e arquivos sobre o funcionamento de CSIRTs com links para vários dos itens mencionados.
- ftp://info.cert.org/incident_reporting_form
Este Formulário de Relato de Incidente é fornecido pelo Centro de Coordenação do CERT para coletar informação sobre incidente e evitar maiores atrasos causados pela necessidade de se obter informação mais detalhada do site que está relatando.
- http://www.cert.org/cert.faqintro.html
Uma coletânea das perguntas mais freqüentes do Centro de Coordenação do CERT.
Apêndice C: Grupos de Resposta a Incidente de Segurança conhecidos
Existem hoje muitos CSIRTs, mas nenhuma fonte lista todos eles. Grande parte dos maiores e mais antigos CSIRTs (o primeiro foi fundado em 1988) são hoje membros do FIRST, o Fórum Mundial de Resposta a Incidente e Grupos de Segurança. Até o momento, mais de 55 grupos são membros (1 na Austrália, 13 na Europa e todos os outros na América do Norte). Informação sobre o FIRST pode ser encontrada em:
- http://www.first.org
A lista corrente de membros também está disponível, com relevantes informações sobre contato e algumas informações adicionais fornecidas por alguns grupos em particular:
- http://www.first.org/team-info/
Para os CSIRTs que querem se tornar membros deste Fórum (por favor observem que cada grupo precisa de um patrocinador -um grupo que já seja membro do FIRST - que o apresente). Os seguintes arquivos contêm mais informação:
- http://www.first.org/about/op_frame.html
A Estrutura Operacional do FIRST
- http://www.first.org/docs/newmen.html
Diretrizes para grupos que queiram se tornar membros do FIRST
A maioria dos grupos europeus independentemente de serem membros do FIRST ou não, são listados por países numa página mantida por um CSIRT alemão:
- http://www.cert.dfn.de/eng/csir/europe/certs.html
Para saber sobre a existência de grupos mais indicados para uma necessidade específica, é freqüentemente de grande ajuda perguntar ou a grupos conhecidos ou a um Provedor de Acesso à Internet qual o contato "certo".
No Brasil utilize: http://www.nic.br/nbso.html
O conteúdo publicado no site CGI.br está licenciado com a Licença Creative Commons - Atribuição-CompartilhaIgual 4.0 Internacional a menos que condições e/ou restrições adicionais específicas estejam claramente explícitas na página correspondente.