Universidade Federal do Rio Grande do Norte
Centro de Ciências Exatas e da Terra
Departamento de Informática e Matemática Aplicada
Mestrado em Sistemas e Computação
IVANO MIRANDA DOS ANJOS
PUPSI : UMA PROPOSTA DE PROCESSO UNIFICADO PARA
POLÍTICAS DE SEGURANÇA DA INFORMAÇÃO
Catalogação da Publicação na Fonte.UFRN / Biblioteca Central Zila Mamede. Divisão de Serviços Técnicos
Anjos, Ivano Miranda dos.
PUPSI : proposta de processo unificado para políticas de segurança da informação / Ivano Miranda dos Anjos. – Natal, 2004.
123 p. : il.
Orientador : Guido Lemos de Souza Filho. Co-orientador : Jorge Henrique Cabral Fernandes.
Dissertação (Mestrado) – Universidade Federal do Rio Grande do Norte. Centro de Ciências Exatas e da Terra. Departamento de Informática e Matemática Aplicada.
1. Segurança da informação. 2. Políticas de segurança. 3. Políticas de segurança – Processo unificado. 4. RUP. 5. Normas de segurança. 6. Proteção de dados. I. Souza Filho, Guido Lemos de. II. Fernandes, Jorge Henrique Cabral. III. Universidade Federal do Rio Grande do Norte. IV Título.
IVANO MIRANDA DOS ANJOS
PUPSI : UMA PROPOSTA DE PROCESSO UNIFICADO PARA
POLÍTICAS DE SEGURANÇA DA INFORMAÇÃO
Dissertação apresentada ao Departamento de Informática e Matemática Aplicada – DIMAP da Universidade Federal do Rio Grande do Norte -UFRN como parte dos requisitos para obtenção do título de Mestre em Sistemas e Computação na área de Redes de Computadores e Sistemas Distribuídos.
Orientador :Guido Lemos de Souza Filho Co-Orientador : Jorge Henrique Cabral Fernandes
IVANO MIRANDA DOS ANJOS
PUPSI : UMA PROPOSTA DE PROCESSO UNIFICADO PARA
POLÍTICAS DE SEGURANÇA DA INFORMAÇÃO
Dissertação apresentada ao Programa de Pós-Graduação em Sistemas e Computação da Universidade Federal do Rio Grande do Norte –UFRN, como parte dos requisitos para obtenção do título de Mestre em Sistemas e Computação na área de Redes de Computadores e Sistemas Distribuídos.
Aprovada em 30 de abril de 2004
BANCA EXAMINADORA
___________________________________________________ Prof. Dr. Guido Lemos de Souza Filho – Presidente
Universidade Federal da Paraíba – UFPB
___________________________________________________ Prof. Dr. Gustavo Henrique Mattos Bezerra Mota – Examinador
Universidade Federal da Paraíba – UFPB
Dedicatória
Dedico este trabalho,
Primeiramente a minha esposa, Suzana. Sem a sua contribuição e apoio incondicional este trabalho assumiria a dimensão do inatingível.
Aos meus filhos Gabriel, Pedro e Lina, pelas muitas horas que deixei de estar com vocês, seja pelo cansaço da “noite em claro” ou por “estar no computador”, não poderia deixar de dedicar o fruto dessas horas de trabalho a vocês. Aos meus pais, a minha origem, que plantaram a semente, regaram e me encaminharam, tornando possível esta realização.
Agradecimento
Miranda,I. A. PUPSI : Uma Proposta de Processo Unificado para Políticas de Segurança
da Informação. 2004. Dissertação (Mestrado em Informática) Departamento de Informática e
Matemática Aplicada – DIMAP . Universidade Federal do Rio Grande do Norte – UFRN, Natal , 2004.
RESUMO
O trato com os ativos de informação representa hoje principal fator determinante para o sucesso e, até mesmo, permanência das organizações no mundo globalizado. O número de incidentes de segurança da informação está crescendo nos últimos anos. A implantação de políticas de segurança da informação que busquem manter os requisitos de segurança dos ativos nos níveis desejados, caracteriza-se como prioridade maior para as organizações. Esta dissertação propõe um processo unificado para elaboração, manutenção e desenvolvimento de políticas de segurança da informação, o Processo Unificado para Políticas de Segurança da Informação - PUPSI. A elaboração dessa proposta foi iniciada com a construção de uma base de conhecimento fundamentada em documentos e normas oficiais, publicados nas últimas duas décadas, que tratam sobre o tema segurança da informação e políticas de segurança. Trata-se de um modelo elaborado a luz dos documentos pesquisados, que define as políticas de segurança necessárias a serem implantadas em uma organização, seus fluxos de trabalho e identifica uma seqüência e hierarquia entre elas, bem como é feito uma modelagem das entidades participantes do processo. Diante da dimensão e complexidade do problema que o modelo trata, o qual envolve todas as políticas de segurança que uma organização deve possuir, o PUPSI possui uma abordagem iterativa e incremental. Esta abordagem foi adquirida com a instanciação do modelo ao RUP – Rational Unified Process. O RUP é uma plataforma para desenvolvimento de software orientado a objeto, da Rational Software (grupo IBM) que utiliza as melhores práticas reconhecidas pelo mercado. O PUPSI herdou do RUP uma estrutura de processo que oferece funcionalidade, capacidade de difusão e compreensão, desempenho e agilidade na readequação do processo, possuindo capacidade de se adequar as mudanças tecnológicas e estruturais do mercado e da organização.
PALAVRAS-CHAVE : segurança da informação, políticas de segurança, processo
Miranda,I. A. PUPSI : A Proposal of Processo Unificado para Políticas de Segurança da
Informação. 2004. Dissertation (Master´s Degree in Sciences – M.Sc.). Departamento de
Informática e Matemática Aplicada – DIMAP . Universidades Federais do Rio Grande do Norte – UFRN, Natal , Brasil, 2004.
ABSTRACT
The way to deal with information assets means nowadays the main factor not only for the success but also for keeping the companies in the global world. The number of information security incidents has grown for the last years. The establishment of information security policies that search to keep the security requirements of assets in the desired degrees is the major priority for the companies. This dissertation suggests a unified process for elaboration, maintenance and development of information security policies, the Processo Unificado para Políticas de Segurança da Informação – PUPSI. The elaboration of this proposal started with the construction of a structure of knowledge based on documents and official rules, published in the last two decades, about security policies and information security. It’s a model based on the examined documents which defines the needed security policies to be established in the organization, its work flow and identifies the sequence of hierarchy among them. It’s also made a model of the entities participating in the process. Being the problem treated by the model so complex, which involves all security policies that the company must have, PUPSI has an iterative and developing approach. This approach was obtained from the instantiation of the RUP – Rational Unified Process model. RUP is a platform for software development object oriented, of Rational Software (IBM group), which uses the best practice known by the market. PUPSI got from RUP a structure of process that offers functionality, diffusion capacity and comprehension, performance and agility for the process adjustment, offering yet capacity of adjustment to technological and structural charges of the market and the company.
Índice de Figuras
Figura 1 - Incidentes reportados ao CAIS ... 14
Figura 2 - Comparativo, pesquisa da Módulo. ... 14
Figura 3 - Pesquisa 2002 – Principais Obstáculos para Implantação da Segurança... 16
Figura 4 - Pesquisa 2002 – Principais Ameaças e Incidência de Ataques ... 16
Figura 5 - Diagrama de tempo e precedência no surgimento dos documentos ... 18
Figura 6 - Etapas para implantação da BS7799-2 ... 34
Figura 7 - Ciclo PDCA ... 36
Figura 8 - Conceitos e relações de segurança... 38
Figura 9 – Conceitos de Avaliação e suas relações ... 39
Figura 10 – Modelo de Gerência de Risco ... 41
Figura 11 - Etapas do Processo de Avaliação de Risco e Ameaça e documentos gerados em cada etapa. ... 43
Figura 12 - Programa de Treinamento e Sensibilização do NIST... 47
Figura 13 - Processo de engenharia de software ... 49
Figura 14 - Estrutura do RUP ... 51
Figura 15 - Relacionamento entre as entidades ... 57
Figura 16 – Hierarquia das Políticas de Segurança da Informação... 61
Figura 17 - Estrutura da Política de Segurança da Informação ... 61
Figura 18 –Seqüência de elaboração das políticas ... 62
Figura 19 - Fluxo de trabalho da Macro-política de Segurança da Informação. ... 64
Figura 20 - Fluxo de Trabalho da Meta-política de Treinamento e Sensibilização ... 67
Figura 21 - Fluxo de Trabalho da Meta-política de Classificação da Informação ... 69
Figura 22 - Fluxo de Trabalho da Meta-política de Gerência de Risco ... 72
Figura 23 - Fluxo de Trabalho da Meta-política de Tratamento de Incidentes ... 74
Figura 24 - Fluxo de Trabalho da Micro-política de Segurança da Informação ... 76
Figura 25 – Estilo pré concebido de um Artefato no RUP... 85
Figura 26 - Estrutura do PUPSI instanciada ao RUP ... 86
Figura 27 - Esforço x Duração das Fases do PUPSI. ... 88
Figura 28 - Marcos nas fases do PUPSI ... 88
Figura 29 - Parte da estrutura de diretório do PUPSI ... 89
Índice de Tabelas
Tabela I - Escala de classificação da sensibilidade dos ativos... 45
Tabela II- Competência para classificação... 70
Tabela III – Níveis de classificação e perfil típico da informação classificada... 70
Tabela IV – Trabalhos de referência utilizados pelo PUPSI e suas descrições... 97
Tabela V – Artefatos gerados pelo PUPSI e suas descrições... 99
Tabela VI - Atividades desenvolvidas no PUPSI e suas descrições... 103
Tabela VII – Papéis assumidos no PUPSI e suas descrições... 109
Tabela VIII - Capacidade do Agente de Ameaça e Classificação de Motivação... 111
Tabela IX - Combinação da classificação da motivação e da capacidade... 111
SUMÁRIO
Capítulo 1 ... 13
APRESENTAÇÃO... 13
1.1. - O Estado da Arte ... 17
1.2. – OBJETIVOS... 19
1.3. Organização dessa Dissertação...20
Capítulo 2 ... 21
SEGURANÇA DA INFORMAÇÃO ... 21
2.1. - Trusted Computer Evaluation Criteria – TCSEC (Orange Book) ...21
2.2. - The Trusted Interpretation of the Department of Defense Trusted Computacion ( Red Book)….. ... 24
2.3. – Request for Comments 2196 - Site Security Handbook...25
2.3.1. Etapa de Planejamento...28
2.3.2. Etapa de Notificação... 28
2.3.3. Identificação do Incidente ...29
2.3.4. Tratamento... 30
2.3.5. Conseqüências ... 30
2.3.6. Atividades contínuas ... 31
2.4. – Request for Comments 2350 - Expectations for Computer Security Incident Response... 31
2.5. - BS7799-1 Code of Practice for Information Security Management ...32
2.6. -BS7799-2: 1999 Information security management – Part 2: Specification for information security management systems...33
2.7.– BS7799-2:2002 Information security management – Part 2: Specification for information security management systems...35
2.8.- ISO/IEC 15408 Information technology – Security techniques – Evaluation criteria for IT security... 37
2.9.- ISO/IEC 17799:2000 – Information technology – Code of practice for information security management. ... 39
2.10. – Threat and Risk Assessment Working Guide...40
2.11. – Building an Information Technology Security Awareness and Training Program – SP800-50. ... 45
Capítulo 3 ... 49
O RUP - RATIONAL UNIFIED PROCESS ... 49
3.1. As melhores práticas... 50
3.2. Estrutura do processo: duas dimensões ...51
3.2.1. A estrutura estática do RUP ... 52
3.2.2. A estrutura dinâmica do RUP...55
3.3. Modelos de entidades integrantes do processo... 56
3.4. Considerações finais do capítulo ...58
Capítulo 4 ... 59
PROCESSO UNIFICADO PARA POLÍTICAS DE SEGURANÇA DA INFORMAÇÃO – PUPSI ... 59
4.1. Os Fluxos, a estrutura e as Políticas integrantes do PUPSI... 60
4.2. Macro-política de Segurança da Informação...63
4.3. Meta-política de Treinamento e Sensibilização...65
4.4. Meta-política de Classificação da Informação ...68
4.5. Meta-política de Gerência de Risco ...71
4.6. Meta-política de Tratamento de Incidentes ...73
4.7. Micro-políticas de Segurança da Informação...76
4.7.1. Elaborando uma Micro-política de Segurança da Informação ... 78
4.8. Considerações finais do capítulo ...81
Capítulo 5 ... 82
O ESFORÇO E OS RESULTADOS... 82
5.1. Elaboração do modelo ...82
5.2. Instanciando o PUPSI no RUP ... 84
5.2.1. A construção do conhecimento, os desafios e alguns resultados ...86
5.3. Considerações finais do capítulo ...90
CONCLUSÃO... 91
REFERÊNCIAS ... 93
ANEXO A - IDENTIFICAÇÃO DAS ENTIDADES INTEGRANTES DO PUPSI ... 97
ANEXO B - TABELAS PARA CLASSIFICAÇÃO DAS INFORMAÇÕES ...111
Capítulo 1
APRESENTAÇÃO
Na década de 80, tivemos um incremento no processo de descentralização computacional, proporcionado pelo crescente avanço tecnológico na área de hardware em microcomputadores e pelo crescimento da tecnologia do transporte da informação. Esse processo, foi promovido, entre outras razões, pela crescente oferta de canais de comunicação com alta capacidade e confiabilidade. Esses aspectos, associados à redução de preços, com conseqüente popularização dos microcomputadores e aliado ao desenvolvimento dos Sistemas Operacionais, proporcionaram o advento das Redes de Computadores1. Nesse momento tivemos o impulso oferecido pelo surgimento do Personal Computing, fabricado pela International Business Machine (IBM), de tal modo que em 1987, a Internet2 já possuía aproximadamente 20.000 computadores integrantes de centenas de redes espalhadas pelos Estados Unidos e Europa. Temos, então, uma nova realidade de ambiente computacional que nos apresenta uma outra conjuntura de segurança da informação. Observamos, portanto, uma descentralização de processamento e armazenamento da informação e uma integração maciça de ambientes, os mais diversos, o que nos coloca desafios ainda maiores na manutenção dos requisitos de segurança da informação.
No Brasil, em 2000, 85% dos executivos (universo de 165 amostras) de empresas de TI, que responderam a uma pesquisa3 realizada pela Módulo Security Solutions S.A. informaram que não foi possível quantificar o prejuízo provocado por invasões de seus sistemas. A mesma pesquisa realizada no segundo semestre de 2003 (682 questionários), apresentou que, do total entrevistado, 65% não conseguem quantificar os prejuízos, o que representa um amadurecimento da consciência do valor associado à segurança da informação. Em estatística divulgada pelo CAIS4, o volume de incidentes reportados a este centro é crescente, com um incremento de 168,8% entre os anos de 2001 e 2002. Esta tendência se
1
Conjunto de dispositivos capazes de se comunicar através do sistema de comunicação por troca de mensagens, enviando e recebendo informações e partilhando recursos [SOARES,1995].
2
Conjunto de milhares de redes unidas por um conjunto de regras, protocolos de comunicação, que torna possível aos usuários de qualquer rede se comunicarem e usarem os serviços localizados em qualquer das redes [MARINE, 1994].
3
Pesquisa realizada com profissionais de diversos segmentos econômicos. Foram aproximadamente 500 profissionais que responderam questões envolvendo temas como novas tecnologias, tendências de investimento, adoção de soluções, conscientização de usuários etc.
4
confirma para 2003 (FIGURA 1). Outro dado bastante interessante pode ser visto em pesquisa realizada pela Módulo Solutions no primeiro semestre de 2001 e no segundo semestre de 2003, onde 31% e 16% dos executivos de TI entrevistados, respectivamente, não sabem informar se foram atacados, apresentando uma evolução no trato do tema . Observando o comportamento, no tempo, dos gráficos da FIGURA 1 e a da FIGURA 2 e, considerando o ambiente composto por especialistas de segurança, em que o relatório do CAIS foi elaborado, observamos um crescimento no desenvolvimento da matéria segurança da informação nas organizações. Este crescimento, notadamente em 2003, está caracterizado pela conformidade da pesquisa com a estatística.
T o ta l d e i n c ident es re p o rt a d o s Ano T o ta l d e i n c ident es re p o rt a d o s Ano
Fonte: [CAIS, 2003]
Figura 1 - Incidentes reportados ao CAIS
Não sabem informar 43% 2001 2002
31% 32% 29%
26%
40%
Nunca
sofreram Já sofreram ataques e invasões Não sabem
informar
43% 2001 2002
31% 32% 29%
26%
40%
Nunca
sofreram Já sofreram ataques e invasões 7%
16%
77%
2003
Sua empresa já sofreu algum ataque ? Não sabem
informar
43% 2001 2002
31% 32% 29%
26%
40%
Nunca
sofreram Já sofreram ataques e invasões Não sabem
informar
43% 2001 2002
31% 32% 29%
26%
40%
Nunca
sofreram Já sofreram ataques e invasões 7%
16%
77%
2003
a empresa já sofreu algum ataque ? Su
Fonte:[MÓDULO, 2003]
Assim como os ativos físicos e financeiros, as informações envolvem fatores tradicionais de produção: capital, mão-de-obra e, mesmo não sendo tangível, nem tão pouco possível à aplicação de igual tratamento físico-contábil, do ponto de vista do negócio, elas devem ser protegidas e, atualmente são tidas como um dos principais ativos de qualquer organização. Garantir a segurança da informação em uma interligação de redes é complicado, pois requer o entendimento do modo como as entidades participantes (usuários, computadores, serviços e redes) podem confiar um no outro, bem como a compreensão mútua sobre as questões de hardware e protocolos envolvidos nos diversos ambientes integrados [COMER, 1995].
No mercado competitivo que atualmente vivenciamos, o tratamento dado aos ativos de informação está se tornando fator decisivo para a sobrevivência das empresas. A existência de um documento contendo, dentre outras, informações claras para todos os usuários, pessoal de TI (Tecnologia da Informação), gerentes e demais colaboradores,5 sobre as exigências compulsórias de proteção dos ativos de informação é, a cada dia, fator determinante da manutenção dos requisitos de segurança para as informações sensíveis da organização. A relação entre os seguintes itens: funcionalidades que a rede oferece, facilidade no manuseio dos serviços e aplicações, desempenho e garantias de segurança em um patamar desejado, devem ser balizados pelas metas de segurança estabelecidas para cada organização [FRASER,1997].
Atenção especial deve ser dada à pessoa. Observando a Figura 3, integrante da pesquisa anual realizada pela Módulo Security Solutions S.A, em 2002, verificamos que, o nível de consciência em segurança da informação, ainda é o maior obstáculo para implantação de projetos de segurança da informação, sendo seguido pela falta de orçamento. A existência de uma relação direta entre esses dois fatores é eminente. Na mesma pesquisa, Figura 4, os funcionários insatisfeitos são apontados como sendo a principal ameaça às informações restritas das corporações.
A definição de um processo que contemple um programa de sensibilização e formação contínua de uma cultura de segurança da informação na organização, é essencial para guiar a implantação e manutenção de um projeto de segurança da informação.
Observamos, portanto, que tratando-se de segurança da informação, o item tecnologia, dentre todos, é o que menos dificulta sua implantação. Fazer um trabalho de conscientização dos funcionários, implementar um projeto de segurança que esteja em sintonia com o planejamento estratégico da companhia e convencer a alta direção da importância da gestão
5
de segurança da informação, talvez sejam os maiores desafios na missão de implantação de uma estrutura de segurança da informação.
F tal a de consciênci dos executivosa F
F or
F F
C F
33%
alta de consciência dos usuários 29%
alta de çamento 23%
alta de profissionais capacitados 10% alta de ferramenta no mercado 2%
usto de implantação 1% alta de prioridade 1%
Figura 3 - Pesquisa 2002 – Principais Obstáculos para Implantação da Segurança
Fonte:[ MÓDULO, 2003]
Funcionário insatisfeito V A
V D
H U
F F A
64% 55%
írus
cessos locais indevidos 49%
azamento de informações 48%
ivulgação de senhas 47%
ackers 36%
so de notebooks 36% alhas na segurança física 33% raudes, erros e acidentes 30% cessos remotos indevidos 29%
Figura 4 - Pesquisa 2002 – Principais Ameaças e Incidência de Ataques
Fonte: [MÓDULO, 2003]
Um programa que mobiliza toda a organização envolvendo, inclusive, parceiros e demais colaboradores, como um Programa de Segurança da Informação, não pode se expor a riscos desnecessários. O desgaste gerado por programas fracassados é imenso, cria um descrédito que multiplica as dificuldades e os custos de uma nova tentativa. A elaboração de uma Política de Segurança, que inclui o conjunto de leis, regras e práticas que determinam como uma organização gerencia, protege e distribui a informação, deve ser sistematizada de modo que sua implementação não esteja cercada de incertezas.
definidas as etapas do processo e os papéis e responsabilidades de cada colaborador em cada etapa, de forma a orientar as empresas na implantação de Políticas de Segurança. A definição desse processo dará uma visão sistêmica do projeto ao corpo executivo da organização, de modo que este compreenda melhor as necessidades, dificuldades e esforços que deverão ser apropriados no decorrer e na manutenção do Projeto.
1.1. - O Estado da Arte
No decorrer dos anos, várias entidades contribuíram para elaborar estudos sobre as ocorrências de incidentes na área de segurança da informação. Como conseqüência, iniciou-se uma corrida ao encontro de recomendações, critérios e padronização que norteasiniciou-sem o desenvolvimento de procedimentos objetivando a segurança da informação.
Faremos um breve relato de algumas contribuições e documentações geradas por estes esforços. A apresentação a seguir é produto de estudo realizado objetivando a aquisição de fundamentos, critérios, indicadores, mecanismos e práticas existentes, que subsidiaram a elaboração da nossa proposta.
Na pesquisa realizada, identificamos alguns documentos que tiveram sua essência mantida com o decorrer dos anos, sendo referência de outras publicações com novas elaborações e propostas, mantendo as proposições do documento original, preservando assim consistência das idéias e conceitos formulados. A esses documentos foi dada atenção especial e eles embasaram a composição da nossa proposta.
Na FIGURA 5, temos a visão temporal de distribuição e correlações, identificadas entre os documentos comentados.
Como precursores, surgiram no início do anos 80, o Orange Book e o Red Book. Sua importância se apresenta pela fonte que o produziu e pelo requisito de vanguarda que esteve presente por muito tempo nestas publicações. Esses documetnos foram elaborados pelo Departamento de Defesa Americano e contêm critérios e métodos de classificação para equipamentos e sistemas, observando os requisitos para uso em aplicações sensíveis (originalmente militares). No processo de classificação foram definidos níveis (A, B, C e D), que foram usados no enquadramento dos produtos e serviços avaliados a partir do atendimento às exigências especificadas.
para produtos e serviços de TI. Esse padrão é o resultado de entendimentos e a consolidação de documentos originados de vários países (dentre eles estiveram presentes os documentos do DoD), criando um único critério de avaliação aceito internacionalmente.
1987 1995
1983
Figura 5 - Diagrama de tempo e precedência no surgimento dos documentos
A BS7799-1 é a primeira parte de um padrão britânico. Oferece conceitos fundamentais na segurança da informação definindo 128 itens a serem verificados para a gestão da segurança da informação em uma organização. Esses itens, denominados controles, estão agrupados constituindo um objetivo de controle. O conjunto de objetivos de controle, organizados por área, formam 10 cláusulas que tratam desde Segurança Organizacional ao Desenvolvimento e Manutenção de Sistemas. A força deste padrão se concretizou com sua aceitação na íntegra, em meados de 2000, como documento ISO/IEC 17799:2000 que, inclusive, possui norma equivalente no Brasil – NBR ISO/IEC 17799 (agosto/2001).
Documento complementar, o BS7799-2, é a segunda parte do padrão britânico BS7799. Publicado, inicialmente em 1999, trata-se de um modelo de gestão de segurança da informação nas organizações, onde têm-se uma gestão baseada na manutenção dos itens de controle elencados na BS7799-1. Esse documento apresenta um framework para o modelo de gestão de segurança. Sendo usado como padrão para certificação em segurança da informação em diversas organizações em todo o mundo. Segundo essa norma, as empresas obtêm a certificação através da comprovação da existência de um modelo de gestão em conformidade
Threat and risk Assessment Working Guide
2002 1997 1998 1999 2000
Orange Book
Red Book BS7799-1
RFC2350 RFC2196
SP800-16 ISO15408
BS7799-2
SP800-50 ISO17799
com a BS7799-2, que garanta, através de evidências coletadas na auditoria, o controle dos itens anunciados na BS7799-1(igual a ISO/IEC17799).
Buscando adequar o modelo de gestão da segurança da informação, proposto na BS7799-2, aos outros modelos de gestão anunciados pela ISO (ISO 9000 – Gestão da Qualidade, ISO14000- Gestão do Meio Ambiente), a BSI publicou em novembro de 2002 a BS7799:2002. O framework proposto no documento de 1999, foi modelado como um processo de melhoria contínua (PDCA- Plan, Do, Check e Act).
A RFC2196 , publicada pelo IETF, possui a força da entidade que o originou. Seu conteúdo está diretamente ligado ao tema do nosso trabalho. Trata-se de um guia para desenvolvimento de políticas de segurança. Ela propõe um guia prático direcionado para adminstradores que possuem sistemas na Internet, oferecendo conteúdos para formação de políticas, tópicos técnicos de segurança de redes e também de reações a incidentes de segurança.
Entendendo a importância da difusão do conhecimento em segurança da informação, fomos ao encontro dessa base de conhecimento. O SP800-16 é um documento da Série 800 que trata de segurança da informação, e foi publicado pelo NIST em 1998. O NIST (National Institute of Standards and Technology) é uma agência do governo americano vinculada ao departamento de comércio. O documento propõe um programa de treinamento baseado em duas premissas: construção contínua do conhecimento e abordagem individualizada do tema considerando o papel que os indivíduos a serem treinados exercem na organização. Uma melhor sistematização desse Programa foi proposta em 2002 com a publicação do SP800-50. Este documento, “Construindo um Programa de Treinamento e Sensibilização em Segurança de TI”, provê as diretrizes de implementação e manutenção do programa de treinamento. Como embasamento na área de análise de risco, utilizamos um documento publicado pelo Governo do Canadá [CANADA, 1999], que trata desse tema com bastante propriedade. Esse documento apresenta orientações para realização de uma análise de risco em um sistema de TI, detalhando as nove etapas necessárias para identificar os ativos críticos e produzir recomendações para garantir a redução do risco a níveis aceitáveis. Observa-se nesse documento uma herança dos conceitos fornecidos pelo Trusted Computer System Evaluation Criteria -TCSEC ( Orange BooK).
Após esta introdução, continuamos definindo os objetos do presente trabalho, seguido de uma descrição de como ele está organizado.
O objetivo principal deste trabalho é a definição de um processo para elaboração de políticas de segurança para uma organização. Este processo se baseia:
• na identificação de uma seqüência de eventos que ocorrem durante a implantação de um programa de segurança da informação;
• nos produtos gerados por cada evento; • na matriz de papéis e responsabilidades ; • nos pontos críticos do processo;
• na indicação de possíveis dificuldades e ações sugeridas para contorná-las. Para alcançar este objetivo, este trabalho teve como fundamento:
1. base de conhecimento constituída de preceitos apresentados em documentos e normas oficiais sobre políticas de segurança;
2. uma arquitetura de processo comum, definida pela Rational Software (IBM), o RUP6.
1.3. Organização dessa Dissertação
Esta Dissertação está composta por 5 capítulos.
O Capítulo 2 possui uma descrição dos documentos que integram a base de conhecimento das políticas propostas no PUPSI.
O Capítulo 3 analisa a estrutura do RUP em seus vários aspectos estáticos e dinâmicos. O Capitulo 4 apresenta a proposta de processo, adotando os conceitos do RUP de disciplinas, descrevendo os fluxogramas, papéis, atividades e artefatos, necessários para elaboração de uma política de segurança da informação.
O Capítulo 5 apresenta aspectos relacionados a customização do processo na ferramenta do RUP, o esforço realizado e o resultado obtido neste trabalho, as conclusões e perspectivas de trabalhos futuros.
6
Capítulo 2
SEGURANÇA DA INFORMAÇÃO
Este capítulo traz uma descrição dos documentos oficiais, publicados por entidades de referência internacional, que nortearam a elaboração das políticas, integrantes da proposta de processo unificado para geração de políticas de segurança da informação. Neste capítulo são apresentados os seguintes documentos:
• Trusted Computer Evaluation Criteria – TCSEC
• The Trusted Interpretation of the Department of Defense Trusted Computation • Request for Comments 2196 - Site Security Handbook
• Request for Comments 2350 - Expectations for Computer Security Incident Response
• BS7799-1 Code of Practice for Information Security Management
• BS7799-2:2002 Information security management – Part 2: Specification for information security management systems
• ISO/IEC 15408 Information technology – Security techniques – Evaluation criteria for IT security
• ISO/IEC 17799:2000 – Information technology – Code of practice for information security management
• Threat and Risk Assessment Working Guide
• Building an Information Technology Security Awareness and Training Program – SP800-50
2.1. - Trusted Computer Evaluation Criteria – TCSEC (Orange Book)
Este livro teve participação destacada na história dos procedimentos e critérios de segurança para sistemas computacionais.
hardware/firmware/software e metodologias para avaliação e manutenção da política de segurança em Automatic Data Processing (ADP) Systems. Como os critérios das avaliações dos produtos foram divulgados, os mesmos acabaram por se tornar referência para classificação do nível de segurança no mercado comercial. Iniciou-se um questionamento sobre quais os níveis do Livro Laranja tal produto satisfaz e os fabricantes começaram a classificar seus produtos como satisfazendo um ou outro nível do Livro Laranja. Os critérios foram concebidos com os seguintes objetivos:
a) Fornecer aos usuários (DoD) instrumentos para avaliar o grau de confiança que pode ser depositado no processamento de informações classificadas e demais informações sensíveis em sistemas computacionais.
b) Fornecer orientação aos fabricantes para que seus novos produtos incorporassem os requisitos necessários para satisfazer as exigências requeridas para uso em aplicações sensíveis.
c) Fornecer especificações de segurança para aquisição de produtos.
Dois tipos de exigências são colocados para o que o livro define como processamento seguro de informações:
a) Características específicas de segurança. b) Exigência de garantia.
Os critérios de avaliação podem ser aplicados de uma forma global, avaliando-se o conjunto de componentes que compõe o ambiente computacional em que se dará o processamento das informações e não necessariamente, todos os componentes individualmente.
A definição das exigências de segurança passa, necessariamente, pela definição do que seja um sistema computacional seguro. O DoD define: “Os sistemas seguros são controlados, através das características específicas de segurança, de modo a garantir que somente os indivíduos ou processos devidamente autorizados tenham acesso para ler, escrever ou apagar a informação”. Seis exigências fundamentais são derivadas dessa definição básica, das quais quatro referem-se ao que deve ser providenciado para se garantir o controle no acesso à informação e duas são usadas para garantir que um sistema computacional é seguro. Os seis requisitos são :
determinadas informações. Este conjunto de regras divide-se em política de segurança obrigatória (Mandatory Security Policy7) e arbitrária (Arbitrary Security Policy8).
Requisito 2 – Marcação – Todos os objetos do sistema devem ser rotulados, identificando de forma segura seu nível de sensibilidade.9
Requisito 3 – Identificação - Todos os agentes que executem atividades de acesso às informações do sistema devem ser devidamente identificados com seu correspondente nível de autorização.
Requisito 4 - Registro de Eventos – Informações sobre os eventos devem ser guardadas de forma a permitir auditorias que sejam capazes de identificar responsáveis por falhas que afetaram a segurança do sistema .
Requisito 5 – Garantia - O sistema de computação deve conter mecanismos de hardware/software que possam ser avaliados independentemente, quanto ao oferecimento de garantias suficientes de que o sistema atende aos requisitos de 1 ao 4. Os instrumentos utilizados para garantir o cumprimento dos requisitos, tipicamente, estão incluídos no sistema operacional. Para se avaliar independentemente a eficiência, e se ter confiança nos mecanismos aplicados, é necessário se ter uma documentação clara dos mesmos.
Requisito 6 – Proteção Contínua .Os mecanismos utilizados para garantir as exigências, critérios 1 a 4, devem ser protegidos continuamente contra alterações ou modificações não autorizadas, só assim se garante que o sistema computadorizado é verdadeiramente seguro. A exigência contínua da proteção deve ser válida durante toda a vida do sistema. Esses requisitos são a base para os critérios de avaliação aplicados na classificação que faremos a seguir. Maiores informações sobre esses requisitos podem ser adquiridas no documento original Trusted Computer System Evaluation Criteria.
O TSEC define quatro níveis de segurança: D, C, B e A, estruturados de maneira hierárquica, sendo o nível A o de maior nível de segurança. A divisão C está subdividida nas classes: Classe C1- Proteção com Segurança Arbitrária e na Classe C2 - Proteção com Controle de Acesso. A divisão B está subdivida nas classes: Classe B1 - Proteção com Segurança Baseada em Rótulos, Classe B2- Proteção Estruturada e na Classe B3 – Domínios de Segurança. Esta subdivisões também estão organizadas de forma hierárquica.
7
É uma política que garante a segurança da informação sensível ou classificada, por toda sua vida, definindo regras de acesso baseadas na classificação das informações.
8
É uma política que garante a segurança da informação sensível ou classificada, por todo o seu ciclo de vida, definindo regras de acesso baseadas no nível de autorização, temporal ou não (dependendo da necessidade), de um indivíduo acessar informações classificadas.
9
Na Parte II, do Orange Book, são definidos critérios para controles objetivos e são discutidos os objetivos gerais de controle, bem como sua implicação nos projetos de sistemas de segurança confiáveis. Os critérios são divididos, dentro de cada classe, em grupos de exigências. Estes agrupamentos foram desenvolvidos para assegurar que três objetivos do controle básico para a segurança sejam satisfeitos e não negligenciados. Estes objetivos de controle tratam de: Política da Segurança, Responsabilidade e Garantia. A Política de Segurança é declarada em termos de leis, regras, regulamentos e procedimentos, que controlam a permissão de acesso as informações. O segundo objetivo de controle básico lida com um dos princípios fundamentais de segurança, a responsabilidade individual. A responsabilidade individual sobre ações, processos e procedimentos é a chave do controle de qualquer sistema de informação. O terceiro controle básico esta associado ao oferecimento de garantias de que a política de segurança está implementada corretamente e que, com os mecanismos de segurança implementados, os objetivos da política serão atingidos. Esta garantia deve ser fornecida no ciclo de vida do sistema (projeto, desenvolvimento e manutenção) e durante seu uso operacional.
2.2. - The Trusted Interpretation of the Department of Defense Trusted Computacion ( Red Book)
Objetivando a adequação dos critérios de segurança descritos no Orange Book para rede de computadores o NCSC10 elaborou o “The Trusted Interpretation of the Department of Defense Trusted Computacion”, que ficou conhecido como Red Book. Na verdade, este esforço foi concretizado em dois livros de títulos extensos: “Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria (NCSC-TG-005)” e “Trusted Network Interpretation Environments Guideline: Guidance for Applyying the Trusts Network Interpretation (NCSC-TG-011)”, [STANG, 1994]. Segundo o Red Book, uma Arquitetura e Projeto de Segurança de Rede (NSAD) se aplica a todas as redes11. Esse documento identifica como os requisitos descritos são aplicados e como é formada a NTCB12 (Network
10
National Conputer Security Center vinculado ao National Security Agency –NSA , atualmente Department of Defense Computer Security Agency, responsáveis pela elaboração de padrões para segurança da informação no Department of Defense – DoD americano
11
O livro vermelho define dois tipos de redes: Redes Unificadas e Interconexões de Redes ou Computadores Credenciados. A primeira representa uma rede onde seus componentes são integrados (dependentes), de tal forma que não faz sentido falar em certificação individual. A segunda definição mostra que é possível, com a aplicação de critérios adicionais aos serviços de interconexão, garantir que um sistema seja certificado como seguro, a partir da certificação dos seus componentes.
12NTCB
Trusted Computer Base). Duas definições surgem a partir desses documentos: Política de Segurança e Arquitetura de Segurança. Política de Segurança inclui o conjunto de leis, regras e práticas que determinam como uma organização gerencia, protege e distribui informações sigilosas. A política de segurança geral é documentada abrangendo uma política de segurança do sistema, um modelo de política de segurança e requisitos de segurança. A política de segurança do sistema é a primeira a ser elaborada. Ela interpreta e aplica regulamentos a sistemas. Em seguida são elaboradas as outras duas. O modelo de política de segurança define informações e objetos e os relacionamentos entre os dois. O documento de requisitos de segurança identifica requisitos de usuário devem ser avaliados em um sistema seguro. Segundo o documento, uma Arquitetura de Segurança é a parte da arquitetura do sistema que descreve os serviços e recursos de segurança necessários e um mapeamento dos requisitos de segurança para elementos funcionais. A arquitetura de segurança mostra como se consegue o nível de garantia requerido para o sistema. Assim ela é utilizada para documentar decisões do projeto de segurança.
O surgimento dessa série se deu com o objetivo de incentivar o desenvolvimento de sistemas computacionais confiáveis para o uso das organizações e da necessidade de se definir mecanismos de avaliação de produtos no mercado de redes de computadores. Os livros da coleção Red Book, oferecem orientação de como identificar a proteção mínima de segurança e estabelecem métricas para classificar os sistema computacionais conforme a proteção de segurança existente. Esta classificação utiliza as mesmas divisões apresentadas no Orange Book.
2.3. – Request for Comments 2196 - Site Security Handbook
Este documento teve sua versão final distribuída em setembro de 1997 pelo IETF13. Apresenta-se como sendo um manual com orientações para implantação de políticas de segurança em ambientes computacionais integrados ou não à Internet.
A abordagem de segurança da informação, feita pelo documento é a mesma sugerida por Fites, [FITES, 1989] a qual revela que inicialmente deve-se identificar o que proteger. Em seguida determinar do que está tentando se proteger e a probabilidade das ameaças. Implementar os procedimentos e ferramentas que protegerão seus ativos a um custo viável é o
próximo passo. Em seguida deve-se revisar continuamente os processos e implementar melhorias a cada localização de falhas.
A maior parte do documento é dedicada a apresentação de procedimentos e ferramentas. A identificação dos ativos (o que se procura proteger) e das ameaças, são consideradas como análise de risco.
O documento postula que o esforço gasto com segurança da informação não pode ser maior que o benefício efetivo obtido, ou seja, embora possa parecer óbvio, não se deve gastar mais para proteger algo que vale menos do que o gasto com segurança. Na prática, utiliza-se da análise de risco para identificar e classificar, de forma qualitativa ou quantitativa, os riscos em seu grau de severidade.
Uma primeira etapa da Análise de Risco é a identificação dos Ativos, tudo que deve ser protegido. O ponto essencial é listar tudo que possa ser afetado por um problema de segurança. Uma lista proposta por Pfleeger [PFLEEGER,1989] pode ser considerada como base para este estudo: hardware, software, dados-arquivo em trânsito, as pessoas (usuários e administradores), documentação, materiais (mídias magnéticas).
Uma vez identificado o que se deseja proteger, devem ser identificadas as ameaças aos ativos. A título de exemplo, segue uma lista não exaustiva de ameaças clássicas: acessos a informações sem autorização, revelação involuntária ou sem autorização de informações e negação de serviço.
A RFC 2196 define Política de Segurança como sendo: “declaração formal das regras impostas às pessoas que acessam recursos tecnológicos e informações em uma organização.” Para que uma política de segurança se torne apropriada e efetiva, ela deve ter a aceitação e o suporte de todos os níveis de empregados dentro da organização. É especialmente importante que a gerência corporativa suporte de forma completa o processo da política de segurança, caso contrário, dificilmente ela terá o impacto desejado. A seguinte lista de indivíduos, não exaustiva, deve estar envolvida na criação e revisão dos documentos da política de segurança: o administrador de segurança do site, o pessoal técnico de tecnologia da informação, os administradores de grandes grupos de usuários dentro da organização, a equipe de reação a incidentes de segurança, os representantes de grupos de usuários afetados pela política de segurança e o conselho administrativo.
Em decorrência de aspectos legais das várias políticas, em algumas organizações, pode ser apropriado incluir o pessoal de auditoria. Envolver este grupo é importante observando-se que a política resultante deverá alcançar a maior aceitabilidade possível.
Uma das características de uma boa política de segurança, é que ela deve ser implementável através de procedimentos de administração, publicação das regras de uso aceitáveis, ou outros métodos apropriados. A boa política deve ser exigida pelas ferramentas de segurança, onde apropriado, e com sanções onde a prevenção efetiva não seja tecnicamente possível. Ela deve definir claramente as áreas de responsabilidade para os usuários, administradores e gerentes. Os componentes de uma boa Política de Segurança incluem diretrizes para compra de novos hardwares, política de privacidade, política de acesso, política de responsabilidade, política de autenticação, compromisso de disponibilidade de recursos, política de manutenção nos sistemas de informática e na rede, política de informação de violação e incidentes de segurança.
A garantia de viabilidade e longevidade de Política de Segurança passa, necessariamente, pela flexibilidade intrínseca. Portanto, a política não pode estar vinculada a hardware nem a software específico.
incidente, existem outras que são freqüentemente ignoradas, quais sejam: prejuízos financeiros indiretos (tempo e pessoal alocado durante o incidente), prejuízo na imagem da organização (imagem de fragilidade, vulnerabilidade para os clientes) e problemas de ordem legal associados a eficácia das ações tomadas para se opor as ameaças potenciais.
O Capítulo 5 da RFC apresenta ainda, as etapas que devem estar contempladas em uma Política de Tratamento de Incidentes, que são apresentadas nas sub-seções seguintes.
2.3.1. Etapa de Planejamento.
A atividade de planejamento deve explicitar quais são as metas e objetivos no tratamento de incidentes. Antecipar-se e estar preparado para responder a um incidente, antes dele acontecer, faz parte do tratamento de incidente. Planejar tudo, por escrito, evita ambigüidades durante um incidente e conduz a um conjunto de ações mais apropriadas de respostas. A resposta eficaz a incidentes de segurança é importante porque: protege os ativos que poderiam ser comprometidos, otimiza os recursos utilizados na resposta aos incidentes, preserva a coerência das ações com as leis existentes, evita o uso dos sistemas para ataques a outras organizações (responsabilidade legal) e minimiza a exposição potencial à incidentes. O planejamento deve ser realizado para que se entenda como o incidente ocorreu, evitando-se repetições na exploração da mesma vulnerabilidade e desdobramentos com incidentes adicionais, permitindo também que se avalie o impacto e dano provocado buscando recuperar-se do incidente, além de atualizar políticas e procedimentos necessários. Identificar o autor (recuperar-se possível e apropriado) é um objetivo adicional.
Como ponto de partida, são sugeridas as seguintes prioridades no tratamento de um incidente de segurança da informação: 1º Proteja a vida humana e segurança das pessoas; 2º Proteja os ativos mais sensíveis e críticos para a organização; 3º Proteja outros dados proprietários, científicos, administrativos e outros; 4º Previna danos aos sistemas; 5º Minimize a interrupção do funcionamento dos recursos de computação (inclusive processos).
2.3.2. Etapa de Notificação
A etapa de notificação baseia-se na definição de quem deve ser contatado no caso de um incidente, por exemplo, gerentes e pessoal do local afetado, polícia e agências de investigação, grupos de resposta a incidentes de segurança, pessoal de comunicação interna e relações públicas.
contato de comunicação, Pontos de Contato (POC) específicos devem ser definidos. O POC pode ser uma pessoa responsável por tratar o incidente ou não. Estes contatos incluem os gerentes locais e administradores de sistemas, contatos administrativos para outros sites da internet e várias organizações de investigação. A definição desses contatos, antes dos incidentes ocorrerem, ajudará a fazer o processo de tratamento de incidentes mais eficiente. É fortemente recomendado que o nome das pessoas e seus respectivos números de telefones, e-mails, número de fax, estejam disponíveis nos documentos que definem a Política de Segurança. Determinar quais informações e como elas serão compartilhadas (inclusive a forma, a abordagem e o texto) com os usuários do site, com o público (inclusive a imprensa), investidores e com outros sites, é especialmente importante. Para os casos de incidentes que tenham conseqüências legais, é importante que os contatos com agências de investigação (por exemplo, o FBI e o Serviço Secreto nos EUA ) estejam definidos, bem como com as autoridades locais, escritórios de segurança locais e departamento policial .
Deve haver algum mecanismo de reação gradual baseado em um esquema de classificação interno para incidentes. Associados a cada nível de classificação, estarão o POC e procedimento apropriado. Normalmente o POC não é apenas uma pessoa, mas um Time de Resposta a Incidentes de Segurança em Computadores (CSIRTs).
2.3.3. Identificação do Incidente
É necessário confirmar a ocorrência do incidente e identificar sua gravidade. Questões como ⎯ o incidente é real? ⎯ devem ser consideradas. Muitos sinais associados freqüentemente à
infecção de vírus, intrusões de sistemas, usuários maliciosos etc. simplesmente são anomalias de sistemas, tais como falhas de hardware ou comportamento suspeito de sistema ou usuário. A utilização de apoio para identificação de incidentes, como software ou o uso de auditoria tão logo se suspeite que há algo errado, pode ser bastante útil. É fundamental que haja troca de informação com o pessoal técnico qualificado de CSIRT´s em diferentes organizações, buscando atualização quanto a indicadores ou sintomas que merecem atenção especial na identificação incidentes de segurança, para subsidiar uma decisão sobre se um incidente está ou não acontecendo.
está envolvida? (vi) Qual é o dano potencial do incidente? qual é o tempo calculado para encerrar o incidente? (vii) Que recursos poderiam ser exigidos para tratar o incidente? Há autoridades legais envolvidas?
Logo que for confirmado o incidente, o sistema inteiro e seus componentes devem ser considerados suspeitos. Devem ser observados todos os logs e devem ser procuradas anormalidades.
2.3.4. Tratamento.
O tratamento do incidente envolve a definição do que deve ser feito quando o incidente ocorrer. Trata-se inicialmente da notificação, onde deve-se enviar a informação certa para a pessoa adequada da melhor forma possível. A proteção de evidências e logs de atividades, deve ser a preocupação seguinte, onde registros que devem ser mantidos antes, durante e depois do incidente. A contenção, trata de ações que buscam limitar a extensão do ataque, deve-se definir riscos aceitáveis ao lidar com um incidente e prescrever ações adequadas. Com o incidente contido, se inicia a fase da erradicação da causa do dano através de mecanismos de proteção apropriados. Tem-se agora que buscar a recuperação dos sistemas atingidos, através da execução de procedimentos formais estabelecidos. A última fase é a de acompanhamento.É prudente escrever um relatório que apresente a sucessão exata de eventos: o método de descoberta, procedimento de correção, procedimento de monitoração e um resumo da lição aprendida.
A existência de políticas locais em cada site se configura como o mais importante ponto para o tratamento de incidentes. Um dos objetivos fundamentais do tratamento de incidentes é restabelecer controle dos sistemas afetados e limitar o impacto e o dano. No caso extremo, fechar o sistema ou desconectá-lo da rede pode ser a única solução viável. É recomendado se buscar ajuda quando necessário. Procedimentos para tentar pegar o intruso podem ter uma prioridade baixa, em comparação a necessidade de manter a integridade do sistema, por exemplo.
2.3.5. Conseqüências
Após a ocorrência e tratamento de um incidente de segurança é preciso avaliar as conseqüências.
risco deve ser feita, levando em conta o incidente; (iv) uma investigação, com conseqüente acusação dos indivíduos que causaram o incidente, deve ser iniciada desdobrando-se em um julgamento, quando necessário. O principal resultado desse processo para a organização é a aquisição de conhecimento prático da experiência vivida, que leva naturalmente ao desenvolvimento de práticas proativas.
2.3.6. Atividades contínuas
Os sistemas e a rede não são sistemas estáticos, logo a revisão das políticas e procedimentos deve ser um processo contínuo. Uma sugestão para um conjunto inicial de passos visando manter sob controle as mudanças no sistema é a seguinte: (i) assinar publicações que são editadas por CSIRTs; (ii) manter todos os patches14 dos seus sistemas atualizados; (iii) manter as configurações do sistema sob vigilância, afim de identificar mudanças e investigar anomalias; (iv) revisar periodicamente todas as políticas de segurança (conformidade) e procedimentos anualmente (no mínimo); (v) os responsáveis pela segurança do sistema devem ler os mailing lists relevantes e USENET newsgroups para manter-se atualizado.
Em seu Capítulo 7, a RFC 2196, provê uma breve lista de tecnologias de segurança disponíveis na Internet. Entretanto, várias delas estão ultrapassadas ou tornaram-se obsoletas com o passar do tempo.
2.4. – Request for Comments 2350 - Expectations for Computer Security Incident Response
Publicado em junho de 1998 pelo IETF (Network Working Group), este documento foi elaborado com o objetivo de apresentar os Times de Resposta a Incidentes de Segurança em Computadores (CSIRTs), como formá-lo, sua missão, políticas e procedimentos. O documento não se propõe a definir um conjunto de exigências apropriadas para todos os times, mas definir uma lista que descreva, de modo geral, os tópicos e assuntos que são de preocupação e interesse dos usuários da comunidade Internet.
Os CSIRTs são responsáveis pela execução, coordenação e apoio a respostas a incidentes de segurança envolvendo sites dentro de um escopo definido. A comunidade deve ter o conhecimento do que pode esperar dos Times. Para tal, os CSIRTs devem publicar suas
14
políticas e procedimentos operacionais. O documento 2350 recomenda que cada CSIRT publique suas diretrizes e procedimentos em seu próprio servidor de informação (por exemplo um servidor World Wide Web), permitindo o acesso fácil a elas.
O documento 2350 detalha um modelo que deve ser utilizado pelos CSIRTs na comunicação das informações aos seus componentes.
Esta RFC inclui uma proposta onde são definidas quais são as informações que devem ser compartilhadas entre CSIRTs, durante incidentes que requerem cooperação entre diferentes organizações. O documento apresenta também um conjunto de tópicos e assuntos que CSIRTs precisam elaborar para seus integrantes, sem que os conteúdos de cada tópico sejam definitivos.
O Capítulo 2 da RFC 2350 fornece uma avaliação de três principais áreas: a publicação de informação por um time de resposta a incidentes, a definição da relação entre CSIRTs, e a necessidade de que a comunicação se dê de forma segura.
Já o Capítulo 3 descreve, em detalhes, todos os tipos de informação que a comunidade precisa saber sobre o time de resposta.
Para facilitar o uso das informações apresentadas, por toda a comunidade Internet, estes tópicos são condensados em um modelo fornecido no Apêndice D da RFC.
2.5. - BS7799-1 Code of Practice for Information Security Management
denominada “Ato de Proteção de Dados”, recomendou a aplicação da norma na Inglaterra, e em março de 2000, a norma foi efetivamente implantada.
Em dezembro de 2000 a norma BS7799-1 foi homologada como padrão ISO. O conteúdo dessa norma será apresentado quando for descrito o padrão ISO/IEC 17799.
2.6. -BS7799-2: 1999 Information security management – Part 2: Specification for information security management systems.
Devido à necessidade de se definir critérios para garantir que os requisitos e controles da BS7799:1999 estão sendo aplicados nos sistemas, e que estes seguem todos os procedimentos que garantem sua certificação, surgiu a BS7799-2:1999. A finalidade dessa norma é então mostrar como aplicar o ISO/IEC17799 em um ISMS - Information Security Management System. A certificação baseia-se em um processo com seis etapas (Figura 6). Cada etapa gera um documento formal e insumos para a etapa seguinte.
Para iniciar a implantação do um modelo de gestão na organização, deve-se, inicialmente, pensar sobre os recursos de informação e seu valor para a organização, olhando de fora para dentro. Nesta condição planeja-se uma política que identifique as informações relevantes e o porquê de sua relevância. Na prática, a princípio, somente informação com valor significativo para a organização devem ser tratadas pela política de segurança.
O universo a ser abrangido pela gestão de segurança deve ser definido observando-se os locais por onde circulam as informações, que foram identificadas como relevantes. Nesta análise, devem ser identificados os interesses que permeiam a organização como um todo. Assim, é necessário levar em consideração todos os sistemas de informações utilizados, as relações existentes entre eles e o meio externo. Por exemplo, estaria dentro do contexto da definição do escopo da gestão de segurança o universo incluindo: armários de arquivamento, relatórios de informações, memorandos, conversações telefônicas, circulação do público externo, entre outros aspectos.
É necessário controlar os riscos identificados. A principal ferramenta para tal, certamente, é a tecnologia, entretanto não se pode esquecer das pessoas envolvidas, procedimentos administrativos e os acessos físico às instalações, como portas, fechaduras e até mesmo circuito fechado de TV, além do seguro para cobrir os custos de eventuais perdas financeiras. Faz-se necessário escolher as “proteções”, isto é, como será feito o controle dos riscos. A BS7799-1999 (ISO 17799:2000) lista uma variedade de medidas, mas esta lista não é exaustiva e, em cada caso, podem ser identificados controles adicionais a serem aplicados. Uma vez escolhidos os controles de proteção, será necessário comprovar sua eficácia e indicar porque os outros controles, previstos pela BS7799, não são aplicáveis no contexto de uma determinada organização. A norma prevê a possibilidade de se declinar dos controles oferecido pela BS7799, desde que sejam criados controles próprios. Entretanto, cada controle utilizado deve ser adequadamente justificado.
C lassificação da In for m ações d a Or ganização
Definição do escop o do ISM S
Avaliação de Risco
Gerência d e R isco
Seleção d e Co ntroles
C onfirmação da Eficácia dos M ecanismos Etap a 1
Etap a 2
Etapa 3
Etapa 4
Etapa 5
Etapa 6
- T arefas - V ulnerab ilid ades - Impactos
Política de Segurança da
In formação
On de ap licar o ISMS
Valor d os riscos Informaçõ es dos ativos
Resultado s e conclusõ es
G rau d e garan tia req uerida
O pções de seleção de co ntro les A proximação da g erência
de riscos com a organização
Con troles ob jetiv os e controles defin idos na BS1 779 9
Con tro les adicionais
M ecanism os de Co ntroles
D eclaração de aplicabilidade Seleção raci onal Indicadores a serem controlado s
C lassificação da In for m ações d a Or ganização
Definição do escop o do ISM S
Avaliação de Risco
Gerência d e R isco
Seleção d e Co ntroles
C onfirmação da Eficácia dos M ecanismos Etap a 1
Etap a 2
Etapa 3
Etapa 4
Etapa 5
Etapa 6
- T arefas - V ulnerab ilid ades - Impactos
Política de Segurança da
In formação
On de ap licar o ISMS
Valor d os riscos Informaçõ es dos ativos
Resultado s e conclusõ es
G rau d e garan tia req uerida
O pções de seleção de co ntro les A proximação da g erência
de riscos com a organização
Con troles ob jetiv os e controles defin idos na BS1 779 9
Con tro les adicionais
M ecanism os de Co ntroles
D eclaração de aplicabilidade Seleção raci onal Indicadores a serem controlado s
Figura 6 - Etapas para implantação da BS7799-2
controlam a segurança, minimizando o risco residual do negócio e assegurando a permanência da segurança contínua e incorporada, satisfazendo os requisitos do cliente e exigências legais. O padrão BS7799-2 requer a implantação de um ISMS, sem, entretanto, informar exatamente como implementá-lo, o documento informa apenas quais os objetivos de seu uso.
No Capítulo 4 da norma BS7799-2, são identificados e descritos 128 controles, correspondentes aos descritos na ISO/IEC 17799. Todos esses controles estão anunciados no Anexo D dessa dissertação, agrupados conforme seu item de verificação ISO.
A British Standards Institution – BSI publicou um conjunto de documentos para suporte à aplicação da ISO/IEC 17799:2000 e BS7799-2/1999. A série 3000 de documentos prublicados pela BSI, é um guia completo para se obter a certificação da BS7799, fornecendo todos os passos necessários para se certificar e métodos para auto-avaliação da gestão de segurança da informação.
2.7.– BS7799-2:2002 Information security management – Part 2: Specification for information security management systems
No caminho do reconhecimento da BS7799-2 como padrão ISO, foi elaborado em novembro de 2001 o draft BS7799-2:2002, que foi publicado em janeiro de 2002 para comentários. O comitê BDD2 da BSI, juntamente com o International User Group, concluiu a versão final da BS 7799-2:2002 e a publicou em setembro de 2002. Esta revisão surgiu com o objetivo de adequar o padrão BS7799 Part 2, aos outros padrões de sistemas de gestão da ISO, como o ISO9001:2000 e o ISO 14001:1996, promovendo a adoção de uma abordagem de processo. Esta norma promove a introdução e aplicação do modelo de processo PDCA (Plan-planejar, Do-executar, Check-verificar, Act-agir corretivamente) como parte de um sistema de gerência para o desenvolvimento, implantação e aperfeiçoamento da eficácia do sistema de gestão da segurança da informação em uma organização.
nos níveis de risco residual e aceitável, bem como em todo o ISMS, objetivando identificar falhas ou fragilidades no sistema, determinando ações que as eliminem, sempre a luz das prioridades do negócio. A etapa que fecha o processo é a de Ação Corretiva (ACT), onde deve-se desenvolver o ISMS com ações corretivas e preventivas bem como com procedimentos que assegurem que os objetivos das revisões foram alcançados.
Mantém e
Desenvolve o ISMS Act
Estabelece o ISMS Plan
Do
Check Monitora e Revisa o
ISMS
Implementa e Opera o ISMS
Figura 7 - Ciclo PDCA
A documentação do ISMS deve incluir: a) Documentos formais da Política de Segurança e objetivos de segurança; b) Um manual do ISMS contendo: o escopo do ISMS (conforme definido anteriormente no PLAN), os processos que dão sustentação ao ISMS e os procedimentos documentados estabelecidos para o ISMS, ou referências para os documentos listados; c) Relatório de avaliação de riscos e Plano para tratamento de riscos, e) Documentos que assegurem, de forma precisa, o efetivo planejamento, operação e controle dos processos de segurança da informação, f) Registros dos indicadores requeridos pelos padrões, g) Um sumário dos controles efetivamente implantados e justificativas para os controles propostos na BS7799-1 e não implantados, quando couber.
A documentação deve estar disponível para todos os funcionários que precisam dessas informações, de acordo com a política de segurança estabelecida.
ISMS. Além disso, a gerência deve garantir que os procedimentos de segurança são adequados aos negócios da organização.
Após o lançamento da BS 7799-2:2002 a BSI revisou todos os documentos adicionais de suporte a aplicação da BS7799.
2.8.- ISO/IEC 15408 Information technology – Security techniques – Evaluation criteria for IT security
Este documento apresenta o resultado de uma série de trabalhos desenvolvidos para avaliação de segurança em TI. Os trabalhos foram iniciados durante a elaboração do Orange Book (TCSEC), nos Estados Unidos, que foi completado por estudos realizados em vários outros países. Na Europa foi publicado em 1991, pela Comissão européia, o Information Technology Security Evaluation Criteria (ITSEC-1991) sendo sucedido, no Canadá, pelo Canadian Trusted Computer Product Evaluation Criteria (CTCPEC-1993). Outro esforço anterior dos EUA resultou no Federal Critéria for Information Technology Security (FC – 1993). Em junho de 1993, as organizações que elaboraram o CTPEC, FC, TCSEC e o ITSEC reuniram-se com o objetivo de gerar um documento único contendo critérios de reuniram-segurança em TI, que fosse adotado por todos. Esta atividade foi nomeada Projeto CC (Commom Criteria), e seu objetivo era eliminar as diferenças conceituais e técnicas entre todos os critérios desenvolvidos pelas diversas organizações. A idéia era então, ao final do trabalho, entregar os resultados à ISO, como uma base para o desenvolvimento de uma norma internacional.
A norma ISO/IEC15 15408 – Evaluation criteria for IT security ⎯ que, por questões históricas, ficou mais conhecida como Commom Criteria – CC, propõe um conjunto de exigências e um processo de avaliação, para produtos e serviços em seus aspectos de confiabilidade, integridade e disponibilidade. O CC é uma referência para o desenvolvimento e comercialização de produtos ou serviços e garantias de cumprimento dos requisitos de segurança necessários para o ambiente do usuário.
Não é objetivo do CC o fornecimento de critérios e procedimentos de avaliação para aspectos organizacionais, administrativos, de segurança física e pessoal que envolvem um ambiente de TI.
Temos na Figura 8 a apresentação dos conceitos de segurança e suas relações, sob a ótica da ISO 15408-1. Nela identificamos a atuação de dois personagens fundamentais no processo de
segurança da informação: a Alta Direção e os Agentes de Ameaça. Todas as ações de proteção são originadas a partir da Alta Direção, que busca a garantia dos requisitos de segurança dos ativos nos níveis desejados. Os Agentes de Ameaça são a fonte das iniciativas que põem em risco as informações sensíveis da organição.
O CC esta divido em três partes. A Parte 1- ISO/IEC 15408-1 - Introdução e modelo geral, define conceitos e princípios de avaliação de segurança em TI e objetivos de segurança, além de construir especificações para produtos e sistemas, selecionando e definindo exigências de segurança em TI. A Parte 2– ISO/IEC 15408-2 - Exigências de segurança funcionais, estabelece um padrão de exigências funcionais e apresenta um conjunto de componentes
Figura 8 - Conceitos e relações de segurança Alta Direção
Medidas corretivas
Riscos Vulnerabilidades
Ameaças Agentes de Ameaças
Ativos avalia deseja minimizar impõe dão origem que aumentam que exploram que conduz pode estar atendo
podem possuir pode ser reduzido por para reduzir para para
Fig. 4.1. Conceitos e relações de segurança deseja abusar e/ou pode denegrir
Alta Direção
Medidas corretivas
Riscos Vulnerabilidades
Ameaças Agentes de Ameaças
Ativos avalia deseja minimizar impõe dão origem que aumentam que exploram que conduz pode estar atendo
podem possuir pode ser reduzido por para reduzir para para
Fig. 4.1. Conceitos e relações de segurança deseja abusar e/ou pode denegrir
funcionais, famílias e classes. A Parte 3- ISO/IEC 15408-3 - Exigências de garantias de segurança, expressa exigências padrão de garantia de segurança para produtos ou sistemas através do fornecimento de um conjunto de componentes que definirão o nível segurança, conforme estabelecido pelo CC.
técnicas de segurança se propõem a dar, devem ser sempre avaliadas, medidas e os resultados submetidos aos proprietários das informações sensíveis.
Figura 9 – Conceitos de Avaliação e suas relações
Técnicas de Segurança
Confiança
Avaliação
Contramedidas Donos
Ativos Garantia
Riscos exigem
produz Fornece evidências de
que
minimize
para oferecendo
2.9.- ISO/IEC 17799:2000 – Information technology – Code of practice for information security management.
A ISO/IEC 17799:2000 é a legitimação da norma BS7799:1999 e está organizada em 12 capítulos ou divisões, sendo: 1 - Objetivo, 2 - Termos e definições, 3 - Política de segurança, 4 - Segurança organizacional, 5 - Classificação e controle dos ativos de informação, 6 - Segurança de pessoal, 7 - Segurança física e do ambiente, 8 - Gerenciamento das operações e comunicações, 9 - Controle de acesso, 10 - Desenvolvimento e manutenção de sistemas, 11 - Gestão da continuidade do negócio, 12 - Conformidade.
