Relatório

Projeto AGRIS

Análise e Gerência de Riscos em Segurança

Luiz Fernando Rust da Costa Carmo 1

Gustavo Alberto de Oliveira Alves Ricardo de Barros Costa Edson Barbosa de Souza

Carlos Augusto Reis Junior Tiago Monteiro do Nascimento

Ana Cristina Ribeiro Dutra de Almeida

PROGRAMA FRIDA

23 de Março 2005

NÚCLEO DE COMPUTAÇÃO ELETRÔNICA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO

1 Luiz Fernado Rust (rust@nce.ufrj.br, 55-21-25983214) é o ponto de contado para este relatório.

Índice 1 Introducão .....................................................................................................................7

2 Conceitos Básicos .........................................................................................................8

2.1 Definições ........................................................................................................... 9 3 Estudo das Principais Ferramentas de Análise de Riscos existentes ..........................11

3.1 Introdução ......................................................................................................... 11 3.2 Visual Assurance............................................................................................... 11 3.3 Compliance Guardian........................................................................................ 12 3.4 Enterprise Suíte ................................................................................................. 13 3.5 Check-up Tool................................................................................................... 14 3.6 Foundstone Enterprise Manager ....................................................................... 16 3.7 Bindview ........................................................................................................... 18 3.8 CRAMM Express.............................................................................................. 18 3.9 Conclusão:......................................................................................................... 21

4 Funcionalidades selecionadas para a ferramenta GRIS..............................................22

5 Análise das Principais Ferramentas de Análise e Bases de Vulnerabilidades............25

5.1 Ferramentas de Análise (scanners) ................................................................... 25 5.2 Bases de vulnerabilidades ................................................................................. 26

6 Proposta para a Base AGRIS ......................................................................................35

6.1 Teste de Vulnerabilidade................................................................................... 35 6.2 Ferramenta de Gerenciamento da Base............................................................. 37

7 Métodos de Cálculo de Risco .....................................................................................42

7.1 Introdução ......................................................................................................... 42 7.2 Definições ......................................................................................................... 42 7.3 Método de CRAMM ......................................................................................... 42 7.4 Belifed-Based CRAMM.................................................................................... 43 7.5 Método Estatístico............................................................................................. 46 7.6 Método de Mosler ............................................................................................. 47 7.7 Método Willian T. Fine..................................................................................... 48 7.8 Graphical Risk Analysis – GRA ....................................................................... 50 7.9 Conclusão:......................................................................................................... 52

8 Proposta inicial de cálculo de risco para o projeto AGRIS ........................................53

9 Contexto de implementação........................................................................................54

9.1 Plataforma alvo ................................................................................................. 54 9.2 Ambiente de Desenvolvimento ......................................................................... 55

10 Metodologia para levantamento de requisitos.........................................................56

10.1 Descrição do processo.................................................................................... 56 10.2 Definições ...................................................................................................... 57 10.3 Nomenclatura e formato de um cenário de utilização ................................... 58 10.4 Cenários de utilização primários.................................................................... 59

11 Considerações finais................................................................................................62

12 Referências ..............................................................................................................63

13 Anexo 1 – Cronograma inicial ................................................................................65

Núcleo de Computação Eletrônica Universidade Federal do Rio de Janeiro Relatório do Projeto Análise e Gerência de Riscos de Segurança do programa FRIDA

23/03/2005

SUMÁRIO EXECUTIVO

Esse relatório descreve os resultados atingidos durante a primeira fase do projeto AGRIS, de um total de quatro fases (com duração de seis meses cada) suportado pelo Programa FRIDA (Fundo Regional para a Inovação Digital na América Latina e Caribe), O projeto está sendo desenvolvido no Núcleo de Computação Eletrônica da Universidade Federal do Rio de Janeiro, sendo oficialmente contratado em meados de setembro de 2004. As duas primeiras fases compreendem o desenvolvimento de uma ferramenta de análise dos riscos de segurança em sistemas operacionais. Este aplicativo deverá ser capaz de identificar ameaças, vulnerabilidades e impactos ao negócio das empresas, gerando relatório a níveis técnicos e executivos.

Basicamente, o planejamento inicial da primeira fase do projeto AGRIS focava a definição e implementação da infra-estrutura básica de desenvolvimento:

� pesquisa sobre plataformas - verificação dos ambiente/plataformas para o desenvolvimento dos aplicativos;

� teste de usabilidade das plataformas - contato inicial dos desenvolvedores do projeto com os ambientes;

� avaliação e escolha da plataforma para o projeto - escolha do ambiente de desenvolvimento das ferramentas de análise de risco;.

� definição de conjunto de serviços genérico - detalhamento dos elementos da arquitetura da ferramenta, bem como do relacionamento com o usuário final.

� modelagem da interface de abstração. O C++ Builder 6 foi escolhido como ambiente de programação para a ferramenta pois, além de sua complitude funcional, todos os participantes do projeto já tinham experiência na sua utilização. O Interbase Server 6 será utilizado num primeiro momento como servidor local principal para a base de dados. Na etapa final, o Firebird será utilizado para abrigar a base (possui código aberto e extrema compatibilidade com o Interbase). O sistema da Microsoft Windows 2000 foi escolhido como plataforma alvo como base para o desenvolvimento da solução de análise de risco. Desde a sua inauguração em 1989, atingiu uma marca de 45 mil pessoas, que de alguma forma utilizam a plataforma para desenvolvimento, treinamento ou mesmo prestam serviço, espalhados por mais de 10 mil empresas brasileiras. Atualmente, tanto para o uso como cliente (97% do mercado), como para servidor (62% do mercado), existe uma forte predominância dos produtos Microsoft no mercado brasileiro. Esta mesma situação é também observada na América Latina como um todo.

O desenvolvimento das duas últimas atividades previstas no planejamento inicial (serviços e interfaces) foi iniciado através de um levantamento e estudo das ferramentas de Risco presentes no mercado, com o intuito de dar sustentação ao estabelecimento das funcionalidades esperadas para a ferramenta AGRIS. Um resultado expressivo deste estudo foi a nítida necessidade de incorporar as funcionalidades de uma ferramenta de análise de vulnerabilidades ao projeto. Atualmente nenhum ambiente de análise de riscos de segurança oferece uma solução sem costuras (seamless), integrando análise de vulnerabilidades, controles e riscos. Para isso, foi realizado um estudo das ferramentas e fontes de vulnerabilidades disponíveis, que culminou no desenvolvimento de uma

ferramenta para criação e manutenção da base de vulnerabilidades/controles da ferramenta AGRIS. Uma base deste tipo é fundamental para automatizar o processo de análise, identificação e correção de vulnerabilidades encontradas nos ativos pertencentes a um dado sistema. Esta base unirá os dados oriundos de bases já existentes (CVE, OVAL, ..) com as informações definidas por futuros usuários da ferramenta. Nesta primeira versão, a alimentação da base é feita por meio da especificação de arquivos em XML, (no caso da CVE e OVAL), e diretório contento plugins .nasl (no caso do Nessus). Na próxima versão, as atualizações serão extraídas automaticamente dos sites das organizações mantenedoras das bases. Em seguida foi realizado um estudo aprofundado dos principais métodos de cálculo de risco normalmente empregados, sendo constadas duas grandes deficiências:

� ausência de uma visão do ativo como parte do negócio, onde o valor de um ativo deve ser visto segundo o lucro que o mesmo gera para a empresa, e não ser avaliado apenas pelo valor de aquisição;

� o cálculo do risco de um ativo não considera o impacto que o mesmo causa em outros ativos (dependência entre ativos), por torná-los indisponíveis ou não permitir que o fluxo do negócio escoe por deles.

Uma nova proposta de cálculo de risco foi elaborada permitindo estimar o valor do ativo em relação ao seu papel dentro do negócio do qual o mesmo participa. A proposta realiza o cálculo de risco levando também em consideração a dependência entre os ativos, tendo como base o cálculo utilizado pelo método de CRAMM (ativo x vulnerabilidade x impacto) . Para a especificação definição de serviços e interfaces do projeto optou-se pelo emprego da metodologia de criação de cenários de utilização (uma derivação de use cases). Um cenário de utilização é uma descrição estruturada de um uso típico da ferramenta para a realização de tarefas ou funções. Os cenários de utilização são tipicamente úteis nas atividades específicas de desenvolvimento de software, proporcionando um ponto de partida no levantamento dos requisitos do sistema, ou mesmo substituindo este processo (opção feita pelo projeto de forma a acelerar sua implementação). Na próxima fase os cenários de utilização serão explodidos, promovendo um refinamento dos requisitos, em paralelo às atividades de codificação.

1 Introducão

As atuais medidas de segurança não garantem 100% de eficácia contra todos os possíveis ataques. A análise de risco, processo de avaliação das vulnerabilidades do sistema e das potenciais ameaças, é portanto um componente essencial de qualquer programa de gerência de segurança da informação. O processo de análise identifica as prováveis conseqüências, ou riscos associados com as vulnerabilidades, e gera a base para estabelecimento de um programa de segurança que seja custo-efetivo.

Este projeto tem como principal objetivo o desenvolvimento de ferramentas customizadas às práticas organizacionais latino-americanas (enfatizando as brasileiras), levando em conta nossas particularidades culturais e restrições de recursos, mas respeitando integralmente às recentes normas e padrões internacionais correlatos. O resultado deste projeto incluirá a disponibilização destas ferramentas na qualidade de software de domínio público, que funcionarão como habilitadores das mais modernas práticas de gerência de segurança da informação.

O apoio do programa FRIDA têm sido essencial para o desenvolvimento de uma ferramenta de domínio público nesta área, fazendo com que o custo associado a esta prática não seja mais um impeditivo para sua ampla utilização. Além disso, certamente haverá uma maior confiança da parte dos empresários, já que a sua utilização não necessitará obrigatoriamente do envolvimento de consultoria externa. A primeira, e a maior, barreira para uma profunda disseminação de práticas de análise de risco de segurança no âmbito Brasil/América latina é o alto custo destes produtos. Algumas vezes o próprio custo de uma sólida consultoria nesta área é superior ao custo da infra-estrutura de informação existente nas pequenas e microempresas nacionais. Um outro problema também muito freqüente é oriundo da disseminação voluntária/involuntária de práticas de pirataria de software, fazendo com que muito dos recursos de TI usados na empresa não sejam revelados aos consultores, comprometendo profundamente qualquer análise mais aprofundada dos riscos de segurança.

O restante deste relatório está estruturado em 11 capítulos. No segundo capítulo, são apresentados os conceitos básicos necessários para o entendimento do processo de análise de riscos de segurança da informação. O terceiro capítulo detalha as principais ferramentas para análise de riscos de segurança existentes no mercado, através das suas principais características/funcionalidades, seus pontos fortes e pontos fracos. O quarto capítulo descreve o conjunto das principais funcionalidades selecionado para a ferramenta AGRIS. O quinto capítulo é dedicado ao estudo das principais ferramentas de análise/base de vulnerabilidades, abordando suas principais características e limitações. O capítulo 6 apresenta uma proposta de base de vulnerabilidades/controles para o projeto, bem como a ferramenta de gerenciamento desenvolvida. No sétimo capítulo é feita uma descrição comentada dos principais métodos de cálculo de risco de segurança existentes no mercado, embasando a proposta inicial adotada pelo projeto AGRIS, apresentada no capítulo 9. O décimo capítulo é dedicado ao ambiente de desenvolvimento escolhido para implementação do projeto. No capítulo 11, a metodologia escolhida para o levantamento dos requisitos é apresentada, bem como a descrição dos requisitos primários. O relatório é finalizado no capítulo 11, onde são apresentadas as considerações finais.

2 Conceitos Básicos

O conceito segurança significa no dicionário Houaiss “conjunto de processos, de dispositivos, de medidas de precaução que asseguram o sucesso de um empreendimento, do funcionamento preciso de um objeto, do cumprimento de algum plano etc”. Já para o mundo informatizado segurança significa, segundo a NBR ISO/IEC 17799 [15] (código de melhores práticas para implementar a segurança da informação), a proteção da informação, que como qualquer outro ativo importante para os negócios, tem um valor para a organização e necessita ser adequadamente salvaguardada. A segurança tem estado presente em diversos cenários, desde um simples contrato para assegurar um automóvel, até a implementação de controles de segurança para colocar um sistema bancário no ar. Percebe-se que a segurança é um item comum no dia a dia de pessoas e empresas, passando de simples complemento para uma real necessidade.

A segurança da informação protege a informação de forma a garantir a continuidade dos negócios, minimizando os danos e maximizando o retorno dos investimentos e as oportunidades de negócios.

Conforme descrição feita pela Norma ISO/IEC 17799, a proteção da informação é uma questão fundamental, podendo ser caracterizada pela preservação de alguns princípios considerados críticos para o estabelecimento de padrões de segurança:

� confidencialidade - “garantia de que a informação é acessível somente por pessoas autorizadas”;

� integridade - “salvaguarda da exatidão e completeza da informação e dos métodos de processamento”;

� disponibilidade - “garantia de que os usuários autorizados obtenham acesso à informação e aos ativos correspondentes sempre que necessário”;

� autenticidade - “necessidade de verificar que uma comunicação, transação ou acesso a algum serviço é legítimo”;

� não-repúdio - “o remetente de uma mensagem não deve ser capaz de negar que enviou a mensagem”;

� legalidade - “observar os aspectos legais envolvidos nos processos de negócio”.

Para existir um nível de segurança aceitável, não é necessário que todos estes fatores estejam presentes ao mesmo tempo. Basta imaginar um site onde as informações são de cunho público. Neste caso, seria necessário garantir a disponibilidade e integridade, porém como a informação foi classificada como pública, a confidencialidade não precisa estar presente. Podemos associar a combinação destes fatores com a teoria dos conjuntos, como sugere a figura 1.

Figura 1: Teoria dos conjuntos aplicado à segurança

2.1 DEFINIÇÕES

A segurança da informação é formada pela salvaguarda da informação, como vimos anteriormente. Dentro deste contexto, existem diversos elementos e terminologias que compõem o cenário da segurança. Alguns dos principais elementos estão enumerados a seguir:

Ativo Tudo que representa valor para o negócio da instituição. Exemplos:

� Humanos (Ex. Pessoas) � Tecnológicos (Ex. Software, Hardware) � Físicos (Ex. Escritórios, CPD)

Ameaças Causas potenciais (agente) responsáveis por um incidente de segurança; Exploram falhas (vulnerabilidades). Exemplos:

� Hackers � Crackers � Agentes naturais � Vândalos

Vulnerabilidades Falha e/ou conjunto de falhas que podem ser exploradas por ameaças. Exemplos:

� Contas sem senha � Buffer Overflow (DNS, FTP, SMTP, etc) � SQL Injection

Year 2000 2001 2002 2003 2004

Vulnerabilities 1,090 2,437 4,129 3,784 3,780

Tabela 1: Estatística de Vulnerabilidades divulgadas pelo CERT

Integridade

Disponibilidade Confidencialidade

Impacto Resultado de um incidente de segurança, que poderá resultar em perdas ou danos pequenos, médios ou grandes. Um exemplo claro, seria o comprometimento de um site de comércio eletrônico na Internet, e a posterior divulgação deste incidente pelos meios de comunicação. Provavelmente as compras com cartão de crédito cairiam em grande escala, podendo chegar até a comprometer a existência do negócio. Risco A avaliação dos riscos permite identificar as ameaças dos ativos, as vulnerabilidades e a sua probabilidade de ocorrência, e também os seus impactos sobre as organizações. Quanto maior o conhecimento sobre os riscos, mais fácil será decidir como tratá-lo. Basicamente, podemos conduzir o tratamento do risco de três formas: aceitá-lo, reduzi-lo ou mesmo transferi-lo. É através da análise de risco que teremos informação suficiente para identificar qual das três opções melhor se aplica ao cenário, sempre levando em consideração os objetivos de negócio. Para garantir a continuidade e a evolução da análise de risco, é necessário implementar uma Gestão de Risco, de forma a otimizar o processo e custos de operação.

3 Estudo das Principais Ferramentas de Análise de Riscos existentes

3.1 INTRODUÇÃO

O principal objetivo desta seção é estabelecer um perfil do que se espera de uma ferramenta de análise de risco, através de uma avaliação minuciosa das ferramentas existentes no mercado, observando duas premissas básicas:

� as funcionalidades comuns à maioria das ferramentas existentes devem ser mantidas por se tratar de características esperadas em ferramentas desse tipo;

� evitar a necessidade de uso de ferramentas adicionais para garantir uma gerência integral dos riscos.

As ferramentas foram selecionadas segundo a importância que as mesmas possuem dentro da área de Tecnologia da Informação.

3.2 VISUAL ASSURANCE

Visual Assurance foi desenvolvida pela Kilclare Software em 1984, sendo uma ferramenta pró-ativa que tem como metas avaliar, monitorar e reportar riscos identificados, visando à redução dos custos associados. Faz uso do paradigma cliente/servidor, de forma que o aplicativo possa ser executado ininterruptamente, gerando resultados em tempo real.

Permite a criação de templates, bem como a importação dos mesmos (de versões anteriores). Sua análise é orientada a entidades, que definem um checklist (conjunto de análises) a ser executado em determinado setor empresarial.

Permite à alta gerência ver a empresa sob o prisma do nível de exposição e risco agregado, e ainda quantificar o nível da exposição atual do sistema por meio de um ranking de exposição.

A persistência é garantida pela utilização de uma base de dados em Oracle, MSSQL Server, Interbase ou Sybase.

Para cada entidade analisada a ferramenta busca associar manuais, tutoriais, e outras documentações que possam auxiliar o processo de mitigação dos riscos encontrados. As novas versões da ferramenta atualizam automaticamente a Base de Informação (Knowledge Base - KB) da ferramenta; com acesso a documentos on-line.

Pontos fortes:

� uso de templates; � identificação de ativos; � permite definir valor de ativos; � associação de documentos ao risco; � relatórios especializados para a alta gerência.

Pontos fracos:

� o cálculo de risco de um ativo é visto independente de sua função no negócio da empresa;

� não existe geração de um plano de ação (para apoio a tomada de decisão); � não identifica alteração no parque tecnológico; � não permite a inclusão de vulnerabilidades não previstas; � não permite ver o custo por controle; � não valida controle, isto é, não verifica se a vulnerabilidade foi mitigada; � não há verificação de compliance com padrões pré-estabelecidos; � não mostra a evolução da gerência de risco, em termos de maturidade.

3.3 COMPLIANCE GUARDIAN

Desenvolvida pela Ernest & Young, a ferramenta é acessada unicamente via interface web. Seus objetivos principais são: (i) amadurecer a prática em gerência de risco do setor de T.I. da empresa e (ii) verificar a conformidade (compliance) da mesma com padrões pré-estabelecidos, apontando as políticas necessárias para que tal conformidade seja atingida.

A ferramenta divide-se em dois módulos: um de avaliação e outro de gerência.

Avaliação

O módulo de avaliação visa auxiliar a equipe de compliance a monitorar as próprias práticas de governança e ferramentas para compliance. Com os resultados obtidos pela ferramenta é possível criar um plano de ação e documentação necessários para garantir o padrão desejado. A ferramenta pode ser utilizada de tal forma que cada setor da empresa pode, independente dos demais, configurar a mesma, com informações de seu setor apenas. Este módulo é caracterizado por quatro fases:

1. uma série de perguntas (do tipo sim/não) que visam avaliar o nível de conformidade atual;

2. a cada resposta positiva, um texto explicativo (sobre o tema da pergunta em questão) é apresentado;

3. na medida em que pontos falhos são identificados, um plano de ação é desenvolvido com toda documentação necessária para servir de orientação na eliminação de falhas; todos os responsáveis no processo recebem e-mail informando os procedimentos necessários que cada setor deve adotar;

4. a equipe informa o nível de conformidade, para geração de relatórios, ordenado por data e pela importância dos serviços prestados pela organização.

Gerência

O módulo de gerência produz relatórios para que a equipe possa medir o nível de conformidade. O intuito desse módulo é permitir que os gerentes de conformidade verifiquem as informações enviadas pelos diversos setores da organização através do módulo de avaliação, indicando as áreas, setores e departamentos mais vulneráveis.

A ferramenta permite a utilização de padrões estabelecidos pela própria empresa, ou o uso de padrões estabelecidos pelo mercado e demais órgãos.

Pontos fortes:

� verificação de conformidade; � independência entre os setores da empresa envolvidos, o que permite colher

uma gama maior de visões; � criação de um plano de ação; � verificação do nível de maturidade.

Pontos fracos:

� não permite a classificação de ativos; � não permite a inserção de vulnerabilidades não previstas; � plano de ação dependente do conhecimento da equipe; � não identifica vulnerabilidades; � não identifica alteração no parque tecnológico; � cálculo de risco não leva em conta a dependência entre ativos.

3.4 ENTERPRISE SUÍTE

Conjunto de ferramentas da empresa Encore, visando integrar quatro áreas críticas de T.I.: mudanças, configuração, segurança e documentação.

� Ecora Enterprise Auditor � Software de Gerência de Configuração. � Gera relatório sobre as configurações dos sistemas pertencentes à

organização e verifica o nível de maturidade destes, de acordo com padrões pré-estabelecidos.

� Coleta informações críticas sobre sistemas heterogêneos, para posterior auditoria, relatórios, recuperação de desastres identificação de mudanças, etc.

� Ecora Patch Manager (fig. 2)

� Análise e correção (por meio de patches – Windows) da rede, a partir de uma máquina central.

� Utiliza os dados coletados dos sistemas para determinar quais patches são necessários.

� Ecora Reporter

� Subconjunto do Ecora Enterprise Auditor, usando uma base MSDE. Relatórios pré-definidos.

� Não oferece sistema de gerência de mudanças ou identificação de alterações.

� Ecora DeviceLock

� Controles que procuram evitar danos à rede e /ou aos sistemas, periféricos causados por programas maliciosos restringindo o acesso a dispositivos wireless, bluetooth, CD-ROM, disquetes, etc.

Figura 2: Ciclo de operações do Ecora Patch Manager

Pontos fortes:

� identificação automática de ativos tecnológicos; � verifica a maturidade de ativos em relação à configuração; � relatórios sobre as vulnerabilidades encontradas; � estende a segurança nativa do Sistema Windows; � coleta informações sobre os ativos.

Pontos Fracos:

� verifica vulnerabilidades do tipo patch apenas; � não permite customização de relatórios; � não associa a aplicação de patches a custos; � não gera relatórios voltados para a alta gerência; � não gera plano de ação.

3.5 CHECK-UP TOOL

Desenvolvida pela Módulo, essa ferramenta leva em conta ativos tecnológicos e não tecnológicos em sua análise de risco. Sua análise de risco gera tanto relatórios voltados para o setor de T.I., quanto para alta gerência, respeitando as particularidades e interesses de cada um deles. Além disso, associa o amadurecimento da gerência de risco ao ROI sobre os gastos com risco.

A análise de risco é feita por meio de checklists, que utilizam as respostas recebidas para a geração do planejamento de gestão e segurança e para a criação de índices de risco (Secure Scorecard).

Possui interface Desktop e Web. Esta última funciona como uma série de entrevistas feitas com os membros de diversos setores da empresa.

Apoio à implementação dos requisitos de Certificação BS7799, COBIT, de agências reguladoras, Sarbanes-Oxley Act e Basiléia II.

Usa a tecnologia Risk Wizard, para a geração dos relatórios (fig. 3) em forma de gráficos (setor empresarial) e tabelas (setor técnico) para a tomada de decisão.

Figura 3: Exemplo de relatório gerado pelo Check-up tool

Os resultados podem ser individuais, referentes a um componente ou ativo; ou resultado consolidados por vários componentes e ativos, com visões por componentes de negócios, ameaças, perímetros, etc.

Pontos positivos:

� grande dependência da entrada do usuário; � fornece subsídios para a análise de ativos não tecnológicos; � gera relatórios diversificados (técnico e alta gerência); � verifica o nível de maturidade; relação entre gerência de risco e ROI; � criação de plano de ação; � verificação de conformidade; � customização de gráficos.

Pontos negativos:

� não realiza o scanning de vulnerabilidades; � não fornece relatório Risco x Impacto; � cálculo de risco não leva em conta a dependência entre ativos; � mistura diferentes visões da empresa;

3.6 FOUNDSTONE ENTERPRISE MANAGER

Criado pela empresa de mesmo nome, é um sistema distribuído de gerência de risco. O Foundstone Enterprise Manager (FEM) congrega várias funcionalidades existentes em diversas ferramentas de gerência de risco.

Devido a sua alta escalabilidade, a FEM pode ser considerada uma excelente candidata para a gerência de empresas de grande porte, além de proporcionar a mitigação de riscos associados a vulnerabilidades tecnológicas.

Figura 4: Elementos envolvido no cálculo do risco - Foundstone

A partir da identificação dos ativos inicia-se o inventário e a priorização destes dentro da infra-estrutura da rede. O segundo passo é o início da análise inteligente de vulnerabilidades e o processo de correlação das mesmas. Terminado essa etapa, inicia-se o módulo de remediação, que a partir da coleta de informação sobre os ativos gera o plano de ação a ser executado.

O módulo de correlação cria um ranking com as possíveis ameaças identificadas, apresentando as vulnerabilidades e riscos associados.

Considerando a continuidade do negócio e a adoção de modelos pré-definidos que a empresa deve seguir (compliance), a tomada de decisão é feita visando garantir uma ação pró-ativa que coloquea empresa dentro do nível de maturidade desejado.

Além de analisar e reportar ameaças e vulnerabilidades encontradas, a FEM também registra os esforços da empresa no processo de remediação/prevenção das ameaças identificadas. Com base nesses dados, emitem-se relatórios e gráficos mostrando a evolução de tais esforços, por ativo ou por unidade de negócio (setor empresarial, processo empresarial, etc.).

Com base nesses gráficos é possível identificar o processo de maturidade da empresa no que diz respeito às suas vulnerabilidades.

Para cada vulnerabilidade encontrada, o FEM gera um ticket que fica ativo até que ele

avalie se a solução adotada foi eficaz.

O FEM define níveis de relação com a ferramenta, ou seja, um conjunto de ações possíveis de serem tomadas pelo usuário em questão. Dessa forma é possível que a alta gerência possa, por exemplo, analisar relatórios sem se preocupar com os processos que os geraram.

Figura 5 – Ciclo de operações da ferramenta Foundstone

Com relação aos relatórios gerados, os principais tipos são: � técnico – caracterizado pelo alto detalhamento; � alerta - novas vulnerabilidades encontradas � executivo - auxílio à tomada de decisão de melhor custo/benefício.

Pontos fortes:

� correlação de vulnerabilidades; � geração do plano de ação; � classificação de ativos; � verificação de conformidade; � tomada de decisão em relação ao nível de maturidade pretendido; � histórico de esforços realizados na gerência de risco; � validação de controle; � definição de perfil de usuário da ferramenta.

Pontos fracos:

� escalabilidade apenas para média e grande empresa; � correlação não busca enquadrar grupo de vulnerabilidades que poderiam ser

mitigados por um mesmo controle; � não correlaciona riscos.

Ilustração 0 - Ciclo de vida do FEM

3.7 BINDVIEW

Desenvolvida pela BindView Corporation baseada em três pilares:

� políticas de conformidade; � gerência de vulnerabilidades; � administração de diretórios (Active Directory, NDS, etc.).

Políticas de conformidade

� Ferramentas para gerar e medir políticas de segurança e compliance. Auxilia na adoção dos padrões estabelecidos pelo mercado e órgãos competentes (Sarbanes-Oxley, HIPAA, GLBA, COBIT e o CIS Benchmarks).

� Feito isso, a ferramenta verifica (dentre os setores, departamentos e pessoal) os que estão e os que não estão dentro do padrão adotado.

� Provê salvaguardas para os principais ativos, ajudando a desenvolver políticas para classificação dos ativos e avaliação dos riscos.

� Estabelecimento de prioridades. � Benchmark.

Gerência de Vulnerabilidades

� Auditoria pró-ativa sobre os principais ativos para evitar ataques externos. Auxilia na configuração e aplicação de patch nos ativos.

� Emissão de alertas automáticos. � Emissão de relatórios de vulnerabilidade.

Administração de diretórios

� Gerência de controle de permissão sobre os ativos tecnológicos, definindo o papel (e as permissões) de cada pessoa envolvida no processo.

Pontos fortes:

� realiza compliance com padrões do mercado; � benchmark; � possui metodologia para auxiliar no cálculo do valor do ativo e avaliação de

risco. Pontos fracos:

� não realiza cálculo de risco; � não define perfil de usuário; � não correlaciona riscos.

3.8 CRAMM EXPRESS

Ferramenta baseada no método CRAMM através de uma metodologia que envolve aspectos técnicos e não técnicos da gerência de risco. Segue as regulamentações da BS-7799 para a classificação de controles e ameaças, bem como sua associação com vulnerabilidades. Possui wizard para auxiliar na definição de políticas.

A ferramenta divide-se em três fases:

� identificação e cálculo do valor do ativo; � avaliação de vulnerabilidade e ameaças;

� seleção de contramedidas e recomendação.

Identificação e cálculo do valor do ativo

Identificação dos ativos que compõe o sistema (hardware, software, etc.). Ativos físicos (e.g. hardware) podem ser avaliados em termos do custo de reposição. Ativos lógicos (dados e software) são avaliados em termos do impacto devido a sua destruição, indisponibilidade ou alteração.

Avaliação de vulnerabilidades e ameaças

Identificação dos possíveis problemas associados com os ativos classificados. Analisa, além do tipo de problema, a forma em que eles podem ocorrer (deliberados, acidentais, etc.) e os classifica segundo as categorias:

� hacking; � virus; � falhas de hardware ou software; � catástrofe ou terrorismo; � erro humano;

Nesse estágio, utiliza-se o método de CRAMM para calcular o risco.

Contramedida e Recomendação

As recomendações e contramedidas são retiradas de sua base, com mais de 3000 contramedidas organizadas em 70 grupos. A justificativa de implementação é feita confrontando o risco encontrado com a sua informação na base. Cada entrada na base possui um limiar que identifica se o risco é alto o suficiente para justificar a instalação da contramedida. O sistema fornece relatórios sobre os riscos encontrados

Pontos fortes:

� realiza compliance com BS 7799; � wizard para classificação de ativo; � possui metodologia para auxiliar no cálculo do valor do ativo e avaliação de

risco. Pontos fracos:

� não define perfil de usuário; � não correlaciona riscos; � não agrupa vulnerabilidades segundo o seu controle.

O quadro a seguir (Tabela 2) fornece um comparativo com algumas características que foram identificadas como importantes em uma ferramenta de gerência de Risco:

Visual

Assurance Compliance Guardian Ecora

Check-up tool

Foundstone Enterprise Risk Mgnt

BindView CRAMM Express

Visualização ao nível de

Ativos

Sim, Visão em árvore

Não Não, ao nível de

Tecnologia

Sim (integra ativos não

tecnológicos) Sim Sim Sim

Customização dos custos

de ativo Não Não Não Não Sim Não Não

Definição de Políticas por

ativo Sim Não Não

Sim (checklist, sem definir

riscos).

Sim Sim Não

Suporte a Sistemas

Heterogêneos Não Sim Sim Não Sim Sim Não

Uso de Templates na Definição de

Políticas

Não Não Sim Não Sim Sim Não

Correção de Falhas

Não Não Sim (patch manager)

Não Não

Não (mas possui

módulo de migração)

Não

Associação do Risco à

KB Sim Não Não Sim Sim ---- Sim

Atualização da KB

Sim --- Não Sim ----

Benchmark empresas de

Mercado Não Não Não Não

Não (apenas em relação à própria e a

padrões internos)

Não (padrões internos apenas)

Não

Controle de Correções

Não Não Não Não Sim, apenas

Ticket. Sim Sim

Atualização de

Compliance Sim

Sim, no servidor.

Sim Sim Sim Sim Sim

Relatórios Empresariais

Sim (resumo)

Sim, custos relacionados junto com

dados técnicos

Não Sim (Risk Wizard)

Sim, (com impacto

financeiro inclusive).

---- ----

Relatórios Técnicos

Sim (Gráficos de

exceção, matrizes de

Risco)

Sim, limitado a um

conjunto de perguntas

Sim, ao nível da

Tecnologia Sim

Sim, (Com detalhamento técnico dos

ativos)

Sim Sim

Análise de Risco

Qualitativa e Quantitativa

Quant. Quant. Quant. Qual. e Quant.

Quant. Quant.

Tabela 2: Quadro comparativo das principais ferramentas de análise de riscos

3.9 CONCLUSÃO:

As ferramentas estudadas fornecem alguns aspectos importantes na gerência de risco, mas não há nenhuma que ofereça todas as funcionalidades essenciais, o que leva a necessidade do uso de mais de uma delas para uma completa realização da Gerência de Risco. Este procedimento pode levar a uma desnecessária repetição de testes (pelo fato dessas ferramentas possuírem características em comum) ou mesmo a uma possível incompatibilidade de resultados (pelo fato dessas ferramentas utilizarem métricas diferentes). Uma solução seria uma ferramenta que integrasse a análise de risco e análise de vulnerabilidades, possuindo um conjunto mínimo de características comuns às principais ferramentas:

� classificação de ativos por meio de sua funcionalidade em relação ao negócio; � identificação automática de alterações tecnológicas na empresa; � scanning de vulnerabilidades; � criação de um plano de ação que leve em conta a melhor relação

custo/benefício; � cálculo de risco deve levar em conta a dependência entre ativos; � geração relatórios diversificados (técnico e alta gerência) previstos,

relacionando características diversificadas (Risco x Ativo, Controle x Impacto, etc.).

� justificativa de investimento através do ROI; � customização de gráficos; � verificação de compliance com diversos padrões do mercado; � verificação do nível de maturidade.

22

4 Funcionalidades selecionadas para a ferramenta GRIS

Tendo em vista o atual quadro de fragilidade das infra-estruturas coorporativas de TI brasileiras e latino-americanas, tanto no aspecto estrutural quanto no metodológico, acredita-se que uma ferramenta de análise e gerência de riscos de segurança deva ter tanto um caráter funcional (focando eficiência), quanto educativo (para ajudar aos profissionais de TI envolvidos a gerar bons métodos para a análise e gerência de riscos de segurança). Após uma análise criteriosa das diversas ferramentas existentes no mercado, foi gerada uma lista das principais funcionalidades que devem estar presentes no projeto AGRIS: Visualização por ativos A ferramenta deve fazer uso de um nível de abstração que permita ao usuário definir ações sobre cada ativo individualmente. Nessa mesma linha, os resultados da análise (vulnerabilidades encontradas e gráficos de tendência gerados) devem ser mostrados por ativo. Como os prejuízos de uma empresa podem ser quantificados em termos de seus ativos (tecnológicos ou não), é importante que a ferramenta identifique quais ativos estão (ou não) dentro dos parâmetros estabelecidos pela empresa e, qual o prejuízo estimado para essa falta de conformidade. Definição do valor do ativo Ativos iguais podem assumir diferentes graus de importância em diferentes empresas, mesmo quando estas empresas pertencem a segmentos de mercado semelhantes. Desta forma, para que a ferramenta reflita com fidelidade o impacto que a indisponibilidade do mesmo causaria, é necessário que além do valor de mercado que o ativo venha a possuir, seja possível realizar ajustes individualizados. Definição de políticas por ativos Além de uma visão especializada por ativo, é importante que a ferramenta também permita a definição de políticas diferenciadas para cada ativo de uma mesma empresa. Para isso, a ferramenta precisa prover informações sobre a maturidade (em termos de gerência e análise de risco em redes) de empresas do mesmo segmento, e de ativos, que possam pertencer, ou não, ao mesmo segmento. Uso de templates A configuração de uma ferramenta deste porte pode ser extremamente complexa, restringindo o uso da mesma a profissionais com razoável experiência em processos de análise de risco de segurança. Para que isso não seja um impeditivo ao uso da ferramenta, é necessário disponibilizar modelos básicos -templates- (baseados nos diferentes tipos de

23

empresas) que sejam apropriados a todos os tipos de usuários da ferramenta. O uso de templates possibilita: (i) uma avaliação mais acurada da ferramenta no que diz respeito à adoção da mesma ou não; e (ii) um aprendizado sobre o uso da ferramenta e das técnicas de análise de risco, à medida que o modelo vai sendo ajustado à realidade da empresa. Controle e correção de falhas Além da identificação de um risco, é importante a existência de um mecanismo de verificação dos controles implementados pelo usuário para mitigar as vulnerabilidades encontradas. Tal mecanismo deve ter a função de instruir, acompanhar a implementação dos controles, verificar se o controle foi corretamente aplicado e quais riscos foram mitigados. Em outras palavras, deve-se integrar à ferramenta de análise de risco, todas as funcionalidades comumente encontradas em ferramentas de análise de vulnerabilidades. Este tipo de abordagem permite ao usuário interagir com apenas uma única ferramenta, criando um ambiente de análise “sem costuras” (seamless) - o que não é atualmente disponível em nenhuma ferramenta disponível no mercado. Para isso, outras características se fazem necessárias:

� disponibilização de uma KB - visando orientar o profissional de TI na correção de riscos encontrados é importante viabilizar um mecanismo de associação com documentos informativos sobre o problema e sua precisa correção;

� mecanismos para ampliação da KB - possivelmente alguma estratégia

implementada por um profissional de TI pode não estar prevista em nenhuma KB e ainda assim se mostrar mais eficiente que as existentes; para isso deve ser prevista na ferramenta, uma interface para a atualização da KB, com informações geradas pelo próprio usuário;

� sincronização da KB - é importante que a ferramenta possa sincronizar (com

freqüência definida pelo usuário) sua base com a de um servidor central constantemente atualizada;

Benchmarks e conformidade É importante para uma empresa saber como a mesma está situada (no que diz respeito à gerência de risco – implementação de políticas e alocação de recursos) em relação a outras empresas do mesmo segmento. A comparação é uma importante fonte de inspiração para o processo de alocação de recursos em segurança, ou ainda na estratégia de marketing. Por isso a ferramenta deve fornecer diferentes subsídios sobre implementação de políticas de segurança:

� comparação entre a empresa e outras do mercado; � comparação entre o momento atual da empresa e algum momento anterior; � comparação entre diferentes setores e/ou ativos da mesma empresa; � comparação com algum padrão pré-estabelecido (compliance).

24

Relatórios O ponto crucial de uma ferramenta de análise de risco de segurança é a sua capacidade de apresentar os resultados das análises de uma forma completa e didática, de acordo com o público alvo a que estes se destinam. A partir destes resultados serão definidas as políticas que devem ser adotadas e a prioridade que cada uma deve ter. Como a linguagem utilizada por profissionais de TI, gerentes e executivos é diferente, os relatórios produzidos devem adequar-se a cada um desses grupos: � relatórios técnicos - informando com detalhes que dispositivos e qual o nível de

exposição cada um possui, exemplos: o Gráficos: importância do ativo x dificuldade de implementação do controle; o Gráficos: ativo x nível de exposição.

� Relatórios empresariais: relatórios com formatação e características próprias para empresários e administradores; exemplos:

o Gráficos: custo x benefício na implementação de controles; o Gráfico gasto com segurança x retorno obtido.

25

5 Análise das Principais Ferramentas de Análise e Bases de Vulnerabilidades

5.1 FERRAMENTAS DE ANÁLISE (SCANNERS)

Um scanner de segurança é um programa que busca brechas de segurança em uma máquina/rede que possam vir a ser usadas por um cracker. A seguir, serão apresentadas as melhores ferramentas de scanners de vulnerabilidades disponíveis no mercado, com suas características mais importantes. Nessus

O Nessus tem exatamente essa função, encontrar "brechas" em sua máquina. Ele foi criado em 1998, como uma alternativa open-source aos vários softwares de segurança comerciais da época. Ele busca ser o mais atualizado possível e simples de usar (dentro das limitações), sendo dividido em “Nessusd” (servidor) e “nessus” (cliente), sendo que o último pode rodar sobre o ambiente X com uma interface amigável e fácil de entender. Utiliza técnicas intrusivas para varrer a rede. O Nessus necessita do Nmap, do GTK (se for rodar no ambiente X) e do SSL (opcional) para funcionar corretamente. Plataformas: Unix Sara

Ferramenta gratuita que funciona como scanner remoto e local. Oferece suporte ao SANS TOP 20 de vulnerabilidades, sendo que as atualizações são feitas duas vezes por mês. É baseada no CIS BENCHMARK, o que permite que sejam feitas comparações de sistemas com padrões de segurança mundialmente reconhecidos. Apenas classifica o nível de vulnerabilidade: vermelho, amarelo e marrom. Sua base de dados está em XML Plataformas: Unix e MAC OS X Retina

Ferramenta comercial que atua como scanner remoto e local. Utiliza técnicas não intrusivas para a varredura da rede, ou seja, permite varrer a rede sem causar indisponibilidades de serviços e sistemas. Permite validar vulnerabilidades de redes sem fio. A sua arquitetura permite que os próprios usuários cadastrem as suas vulnerabilidades.

26

Retina exibe dois tipos de relatórios:

� técnico (bem detalhado); � \executivo (gráficos e informações superficiais).

Possui uma extensa base de vulnerabilidades, com monitoramento constante dos principais fabricantes, sendo a atualização feita pelo Retina’s Auto Update. Languard

Ferramenta comercial que pode ser um scanner remoto e local, permitindo varrer um ou mais IP´s. Verifica a atrás de possíveis vulnerabilidades que um hacker poderia explorar (ausência de patches e erros de configurações) e, para cada vulnerabilidade encontrada, apresenta uma solução de segurança (KB Microsoft, fabricante, etc). Permite agendar scanners periódicos e comparar com execuções anteriores, permitindo ainda, configurar o tipo de vulnerabilidade a ser pesquisada (ausência de patches, erros de configurações, etc) e exportar resultados em XML. Sua base de vulnerabilidades é extensa e gratuita: SANS, CVE, KB Microsoft, etc Plataforma: Windows 2000 5.2 BASES DE VULNERABILIDADES

CVE

CVE é uma base que padroniza nomes e descrições de vulnerabilidades. É usada como padrão pela indústria de segurança. Atualmente, possui 205 produtos compatíveis, isto é, que usam e produzem referências a esta base, e 128 organizações contribuindo com ela. É organizada pelo MITRE, que supervisiona o processo de nomeação das vulnerabilidades. Seu quadro editorial, que atua no processo de nomeação, adota duas definições para analisar as entradas: vulnerabilidades universais e exposições. As entradas em análise são chamadas candidatas e recebem uma identificação provisória (CAN-AAAA-NNNN). Entretanto, seu objetivo é servir como uma referência para informações de vulnerabilidades de diferentes fontes. Por isso, em suas entradas não há informações como correções, risco, etc. Não é feito nenhum tipo classificação em suas entradas, nem mesmo quanto a serem vulnerabilidades ou exposições.

27

Uma entrada nesta base consiste de um nome padrão (CVE-AAAA-NNNN) e uma breve descrição e referências para fontes que possuem mais informações. É distribuída em vários formatos, incluindo XML. Exemplo de uma entrada:

CVE-2004-0186 CVE Version: 20040901

Name CVE-2004-0186

Description

smbmnt in Samba 2.x and 3.x on Linux 2.6, when installed setuid, allows local users to gain root privileges by mounting a Samba share that contains a setuid root program, whose setuid attributes are not cleared when the share is mounted.

References

� BUGTRAQ:20040209 Samba 3.x + kernel 2.6.x local root vulnerability � BUGTRAQ:20040211 Re: Samba 3.x + kernel 2.6.x local root vulnerability � DEBIAN:DSA-463 � XF:samba-smbmnt-gain-privileges(15131) � BID:9619 � OSVDB:3916

OVAL

Open Vulnerability Assessment Language (OVAL) foi desenvolvida em 2002, quando foi constatada a ausência de uma forma estruturada de se avaliar a existência de vulnerabilidades em softwares de rede. A idéia inicial era criar consultas SQL para determinar a existência de vulnerabilidades em redes de computadores e outros dispositivos. Atualmente o formato preferencial de OVAL é em XML. Sua detecção é feita em termos das características do sistema e informações sobre a configuração do mesmo, sem o uso de exploits. Por características do sistema entende-se o sistema operacional instalado, as configurações feitas no mesmo, aplicativos instalados e suas configurações. Por configurações do sistema entende-se valor de chave de registros, atributos de arquivos de sistemas e arquivos de configuração. Sua base de informações é retirada da CVE, desenvolvido pela Mitre. A partir das entradas presentes na CVE, a base OVAL acrescenta maiores detalhes sobre a

28

vulnerabilidade e informações necessárias para a identificação da mesma. Além das informações retiradas da CVE (considerada metadados), cada entrada OVAL inclui metadados, uma descrição em alto nível, e uma consulta detalhada: • metadados - identificação OVAL (OVAL-ID), status da entrada na base (Submissão

inicial, ínterim ou aceita) e uma breve descrição sobre a vulnerabilidade; • descrição em alto nível

o primeira seção ("Vulnerable software exists"), que informa qual o sistema operacional, o nome do arquivo, a vulnerabilidade, versão de aplicação e o status da correção;

o segunda seção ("Vulnerable configuration"), que indica se o serviço está rodando, configurações específicas e afins;

• consulta detalhada: acesso a chaves de registro, arquivos de configuração e atributos

do sistema operacional e de outros arquivos. Organizações que dão suporte à base OVAL:

� CERIAS/Purdue University � SANS Institute � Debian � IBM � Microsoft � Red Hat � Bastille Linux � Center for Internet Security � CERT/CC (Software Engineering Institute,Carnegie Mellon University) � Defense Information Systems Agency (DISA) � National Security Agency (NSA) � MITRE Corporation � BindView Corporation � Cisco Systems � Citadel Security Software � Harris Corporation � Symantec

BugTraq

É uma “mailing list” moderada, organizada pela SecurityFocus. Nela, vulnerabilidades são postadas e discutidas em detalhe. Porém há uma recomendação para que novas vulnerabilidades sejam primeiramente postadas para o fabricante. Isto evita que alguém possa explorá-la antes que o fabricante tome alguma medida. Não disponibiliza um arquivo com as vulnerabilidades, como por exemplo, em formato XML. O conteúdo e a exatidão das postagens são verificadas somente pela SecurityFocus. Os itens de busca podem ser por palavra-chave, título, fabricante, BugTraq ID ou pela correspondente

29

entrada na CVE. Suas entradas são classificadas em 10 categorias. 1. Condição de erro limite - ocorre quando:

� um processo tenta ler ou escrever além de um endereço limite válido; � um recurso de sistema é esgotado; � um erro resulta de um overflow de uma estrutura de dados estática. Esta classe

é a classe da condição de buffer overflow. 2. Erro de validação de acesso - ocorre quando:

� alguém invoca uma operação ou um objeto fora do domínio de acesso; � um erro ocorre com resultado de leitura ou escrita de/para um arquivo ou

dispositivo; � um erro ocorre quando um objeto aceita entrada de algo não autorizado; � um erro ocorre porque o sistema falhou ao autenticar alguém.

3. Erro de validação de entrada - ocorre quando:

� um erro ocorre porque um programa falhou ao reconhecer sintaticamente uma entrada incorreta;

� um erro ocorre quando o módulo aceita campos de entrada estranhos; � um erro ocorre quando um módulo falha, ao tratar campos de entrada não

preenchidos. 4. Origem do erro de validação - ocorre quando o sistema falha ao autenticar alguém

antes de executar operações privilegiadas; por exemplo, o erro pode ocorrer quando um objeto aceita uma entrada de alguém não autorizado, ou porque falha ao autenticar o sujeito.

5. Falha no tratamento de exceções - ocorre quando o sistema falha ao tratar exceções

geradas por um módulo, dispositivo ou entrada do usuário. 6. Erros de condição de corrida - é explorado durante uma janela de tempo entre duas

operações 7. Erro de serialização - resulta da serialização inadequada ou imprópria de operações. 8. Erros de atomicidade - ocorrem quando:

� estruturas de dados parcialmente modificadas são observadas por outro processo;

� porque o código terminou com dados modificados apenas parcialmente de alguma operação que deveria ter sido atômica.

9. Erros de ambiente – resulta de uma interação em um ambiente específico entre

módulos corretos funcionalmente; ocorrem quando: � um programa é executado em uma máquina específica, em uma configuração

particular. � o sistema operacional é diferente daquele para o qual o software foi escrito.

30

10. Erros de Configuração – ocorrem:

� quando o sistema utilizado foi instalado com parâmetros incorretos; � pela exposição do sistema que foi instalado em lugar errado; � porque o acesso a permissões foi incorretamente configurado.

Exemplo de uma entrada (a mesma acima para o CVE):

Info

bugtraq id 9619

object

class Access Validation Error

cve CAN-2004-0186

remote No

local Yes

published Feb 09, 2004

updated Sep 15, 2004

vulnerable Gentoo Linux 1.4 _rc3 Gentoo Linux 1.4 _rc2 Gentoo Linux 1.4 _rc1 Gentoo Linux 1.4 Linux kernel 2.6 -test9-CVS Linux kernel 2.6 -test9 (…)

not vulnerable

Discussion A local privilege escalation vulnerability has been reported to affect the 2.6 Linux kernel. The issue appears to exist due to a lack of sufficient sanity checks performed when executing a file that is hosted on a remote Samba share. An attacker may exploit this condition to gain elevated privileges, as the setuid/setgid bit of a remote file is honored on the local system. Exploit http://www.securityfocus.com/bid/9619/exploit/ Solution http://www.securityfocus.com/bid/9619/solution/ Credits http://www.securityfocus.com/bid/9619/credit/

31

SANS Top 20 É uma lista das 20 classes de vulnerabilidades mais críticas, feita pela SANS Institute e pela NIPC (National Infrastructure Protection Center) do FBI. A idéia, é que com essa lista, as empresas possam priorizar as correções realizadas em seus sistemas. É apenas uma lista das vulnerabilidades mais críticas e não uma base. Divide-se em duas, 10 de ambientes Windows e 10 de ambiente Unix/Linux: Vulnerabilidades Top para Sistemas Windows

� w1 Servidor web & Serviços � w2 Workstation Service � w3 Serviço de Acesso Remoto do Windows � W4 Microsoft SQL Server (MSSQL) � W5 Autenticação do Windows � W6 Web Browsers � W7 Aplicações de Compartilhamento de Arquivo � W8 Exposição LSAS � W9 Cliente de Email � W10 Mensagens Instantâneas

Vulnerabilidades Top para sistemas Unix

� U1 BIND Domain Name System � U2 Servidor Web � U3 Autenticação � U4 Controle de Versão do Sistema � U5 Serviço de Transporte de Mensagens � U6 Simple Network Management Protocol (SNMP) � U7 Open Secure Sockets Layer (SSL) � U8 Misconfiguration of Enterprise Services NIS/NFS � U9 banco de Dados � U10 Kernel

Cada classe inclui instruções passo a passo para correção dessas vulnerabilidades, e também links para mais informações em outras fontes, como, por exemplo, entradas na CVE.

Nessus Constituída de uma série de arquivos, cada um sendo uma entrada em sua base. Esses arquivos, chamados de plugins, são escritos numa linguagem (interpretada) desenvolvida para o Nessus, a NASL. Eles contêm scripts que exploram uma determinada vulnerabilidade, e também, informações sobre a vulnerabilidade. É possível extrair de sua base os seguintes dados:

• ID; • BUGTRAQ_ID � lista de id’s bugtraq (opcional);

32

• CVE_ID � lista de id’s da base CVE (opcional); • REVISAO; • NOME ; • DESCRICÃO � descrição sobre a vulnerabilidade identificada, podendo possuir

os seguintes campos: o descrição propriamente dita; o solução (opcional); o fator de risco (opcional);

• SUMMÁRIO; • CATEGORIA ao qual ele pertence dentro do Nessus; • COPYRIGHT; • FAMÍLIA � grupo ao qual o mesmo está relacionado;

Com essa base é possível extrair além da descrição da vulnerabilidade, o fator de risco e um possível controle. Base Microsoft A lista de vulnerabilidades dos produtos da Microsoft é publicada pelo MSRC (Microsoft Security Response Center), órgão responsável por detectar e corrigir vulnerabilidades nos produtos da Microsoft. Basicamente, ele faz a coleta de relatos de consumidores, sites especializados em segurança, suporte da Microsoft e de seus próprios desenvolvedores, e realiza uma triagem para averiguar se correspondem a alguma vulnerabilidade de segurança. Para passar na triagem, o relato precisa se encaixar na definição de vulnerabilidade de segurança da MSRC:

“A security vulnerability is a flaw in a product that makes it infeasible (even when using the product properly) to prevent an attacker from usurping privileges on the user's system, regulating its operation, compromising data on it, or assuming ungranted trust.”

Ou seja, para eles, vulnerabilidade se restringe à existência de uma falha específica no produto que o torne incapaz de prevenir que uma entidade aja de forma maliciosa no sistema. Após a triagem, uma investigação formal é realizada junto com o time de desenvolvimento, para concluir de que se trata de uma legítima vulnerabilidade. Caso proceda, o patch é criado. O boletim de segurança é escrito e o artigo na “Knowledge Base” é desenvolvido.

33

O Boletim de Segurança

Atualmente, os boletins podem ser encontrados num único arquivo XML, que é atualizado a cada publicação de um novo boletim. O arquivo XML (MSSecure.XML) é disponibilizado em formato comprimido (.cab). Várias ferramentas da Microsoft para gerenciamento de atualizações, utilizam este arquivo como fonte de atualização. Programas como HFNetChk e Microsoft Baseline Security Analyzer (MBSA) ao realizarem o “update”, utilizam o arquivo MSSecure.cab. Exemplo de informações contidas num boletim:

� Issued (Data de publicação) � Last Revised (Data de revisão) � Version Number (Versão) � Summary (Sumário) � Who should read this document (Informações sobre o público alvo do

boletim) � Impact of vulnerability (Impacto da vulnerabilidade) � Maximum Severity Rating (Nível de severidade) � Racommendation (Recomendações) � Patch Replacement (Quais patches serão substituídos pelo patch do boletim) � Caveats (Considerações especiais ao instalar o patch) � Tested Products and Patch Download Locations:

o Affected Software (lista softwares afetados e links para os patchs) o Non Affected Software (lista de softwares não afetados)

� Technical Details (Detalhes técnicos) o Technical Description (uma descrição mais técnica) o Mitigation Factors (fatores de mitigação) o Severity Rating (explicação para o nível de severidade atribuído) o Vulnerability Identifier (ID na base CVE, como candidato ou entrada

definitiva) � Workaround (contornos, “Quebra-galhos”)

o Description (Descrição do contorno) o Impact of workaround (Descrição do impacto, caso o contorno seja

implementado) � FAQ � Security Patch Information (Detalhes sobre informações de instalação do

patch) o Prerequisites (Quais produtos e service packs são necessários para o patch) o Installation Information o Deployment Information (informações de como instalar o patch) o Restart Requirement (informa de será necessário reinicializar) o Removal Information (informações de como desinstalar o patch) o File Information (informações sobre o executável do patch) o Verifying Patch Installation (descreve como certificar que o patch está

instalado)

34

Os boletins possuem um identificador para a base CVE (Common Vulnerabilities and Exposures). Os mais recentes, porém, possuem um identificador “CVE Candidate”. Todo boletim possui um código, que o identifica: MSAA-NNN, onde AA indica os dois dígitos do ano em que o patch foi publicado e NNN é o número (contador) atribuído ao patch dentro do ano. Este contador é reiniciado a cada ano.

35

6 Proposta para a Base AGRIS

6.1 TESTE DE VULNERABILIDADE

Uma base de teste de vulnerabilidades para redes heterogêneas é importante para automatizar o processo de análise, identificação e correção de vulnerabilidades encontradas nos ativos pertencentes a uma LAN. A idéia é coletar dados oriundos de bases já existentes e informações definidas por futuros usuários da ferramenta para servir dados para um interpretador comum a todos os S.O. Inicialmente os dados passam por um interpretador que os coloca em um mesmo formato acessível por uma biblioteca para análise de vulnerabilidades, construída de tal forma que novos tipos de análise possam ser aceitos sem grandes alterações no código. Inicialmente definem-se os possíveis tipos de teste e os acessos relacionados: 1. teste de registro: acesso a chaves e valores de chaves em registro; 2. teste de arquivo: acesso a informações contidas em arquivo; 3. teste de socket: acesso remoto a serviços.

Para cada tipo de teste acima, as seguintes consultas podem ser realizadas:

a) existencial - verifica se o recurso (arquivo, chave de registro, recurso, processo, etc)

existe (está instalado) no sistema em questão. (resultado true/false); b) permissão - verifica o tipo de permissão que o recurso possui (ler, escrever, executar).

(resultado access_perm{int,int,int}, com os valores de acesso dono/grupo/todos); c) chave/valor - busca o valor associado a uma dada chave (resultado string, contendo o

valor relacionado à chave); d) valor - busca a existência de determinada seqüência em um recurso (resultado

true/false); e) write-before-read - envia uma seqüência e lê o resultado (resultado string, contendo o

valor retornado). A tabela 3 descreve a relação entre os tipos de teste e tipos de consulta (sim/não):

Teste/Consulta Existencial Permissão Chave/Valor Valor Write-B-Read

Registro S S S N N

Arquivo S S S S N

Socket S N S N S

Tabela 3: tipos de teste versus tipos de consulta

36

Inicialmente, para qualquer teste devem ser criados os recursos necessários para a devida consulta. Após a criação dos recursos, uma ou mais consultas devem ser realizadas no intuito de se estabelecer a existência ou não da vulnerabilidade em questão (exemplo de especificação da classe para esse fim: Classe: AGRIS_TestVul). Atributos

� ID: estrutura de acesso aos recursos necessários para a execução do teste; � SysTarget: informações sobre o sistema alvo (plataforma, família); � SysTest: informações sobre o tipo de teste a ser executado e link para os

recursos necessários. Métodos

• ID openTest(test_id): retorna o identificador para o teste e armazena informações do sistema alvo e recursos necessários à execução.

• Bool execTest(test_id): retorna o resultado de uma análise de vulnerabilidade -verdadeiro para “vulnerável”.

• String writeRead(ID &, String & in): envia a string in via socket, e retorna o resultado como string.

• Bool getStuff (ID &, String & pattern): verifica se o recurso existe no sistema. Dependendo de SysTest associado a ID pode procurar por serviço, ou arquivo, etc.

• access_perm stuffStatus(ID &, String & pattern): retorna a permissão associada ao recurso em questão.

• String getKeyValue(ID &, String & key): retorna o valor associado a chave informada por “key”.

• bool getValue((ID &, String & value): verifica se recurso possui o valor informado por “value”.

Persistência

O conjunto de informações a serem persistidas é o mesmo utilizado pelo interpretador: � identificador do teste; � a plataforma: define as primitivas a serem usadas; � adentificador de ações: identifica o conjunto de ações que utilizados para a

análise da vulnerabilidade em questão; � operador de agregação: informa se uma única resposta positiva ou o conjunto

delas é necessário para identificar-se uma vulnerabilidade; � ação: Par “pergunta – resposta” que valida se o resultado de uma análise é

idêntica a resposta esperada. O diagrama apresentado na figura 6 mostra uma proposta inicial de persistência dessas informações:

37

Figura 6: Proposta incial de persistência das informações 6.2 FERRAMENTA DE GERENCIAMENTO DA BASE

A ferramenta visa facilitar a entrada de dados na Base de Vulnerabilidades e Controles do projeto AGRIS. Ela oferece ao gerenciador, entradas de outras bases (Nessus, OVAL e CVE), permitindo que este escolha qual a melhor fonte para determinado campo de uma entrada na Base AGRIS.

ação_id

tipo_de_consulta dados_da_consulta

resposta_id

resposta_id

resultado_esperado

teste_id

plataforma comentário

tipo_de_teste operador_de_agregação

plataforma comentário

tipo_de_teste operador_de_agregação

Obs: 1 N 1 N

38

Base AGRIS A Base Agris é formada por 6 tabelas: agris_vul (Armazena as entradas relacionadas às vulnerabilidades) ag_v_id nome autor data autor_revisao data_revisao versao descricao plataforma familia produto

agris_ctrl (Armazena entradas dos controles) ag_c_id ag_agr_id nome autor data autor_revisao data_revisao versao implementacao dificuldade tempo kb

ag_vul_ctrl_ref (Relaciona vulnerabilidades com seus controles) ag_v_id ag_c_id

agris_agrupamento (Armazena os agrupamentos) ag_agr_id agrupamento

agris_ameaca (Armazena as ameaças) ag_am_id ameaça

ag_am_ref (Relaciona controles com suas ameaças) ag_c_id ag_am_id

Cada vulnerabilidade, na Base AGRIS, pode ter zero ou mais controles associados. Cada entrada informa a família, plataforma e produto suscetível à vulnerabilidade. Os controles, em particular, possuem o campo dificuldade e tempo, que informam o nível de dificuldade e o tempo gasto (em minutos) para a implementação do controle, respectivamente. Estes dois campos entrarão no cálculo do custo de implementação do controle. Cada controle pode, ainda, ser classificado em um agrupamento, e ter zero ou mais ameaças relacionadas.

39

Estas tabelas formam a parte principal da Base AGRIS. Existem ainda, outras tabelas que armazenam informações das Bases de Pesquisa. Elas implementam as entradas para a base de plugins do Nessus, CVE e OVAL.

Figura 7: Diagrama de relações da Base AGRIS A ferramenta possibilita a atualização das entradas nas Bases de Pesquisa. Nesta primeira versão, a atualização é feita por meio da especificação de arquivos em XML, no caso da CVE e OVAL, e diretório contento plugins .nasl, no caso do Nessus. Na próxima versão da ferramenta, as fontes de atualização serão extraídas automaticamente de repositórios remotos, como o site das organizações das bases. A ferramenta foi toda desenvolvida no ambiente O C++ Builder, sendo que os componentes de comunicação com bases de dados foram intensamente utilizados. O Interbase Server 6 foi utilizado num primeiro momento durante a programação como servidor local principal para a base de dados. Na etapa final, o Firebird foi utilizado para abrigar a base, permitindo que conexão da ferramenta com a base fosse modificada de local para remota.

40

A interface desenvolvida visa agilizar ao máximo a entrada de dados na Base AGRIS e a consulta as outras Bases de Pesquisa. Basicamente é divida em dois painéis tabulados (fig. 8). Na esquerda está a parte da Base AGRIS, com tábuas separadas para vulnerabilidades e controles. Na direita estão as tábuas para acesso as entradas das Bases de Pesquisa.

Figura 8: Tela de consulta/entrada de dados da Base AGRIS

As ações de copiar e colar podem ser utilizadas para transmitir informação de um campo para outro. As Bases de Pesquisa não são editáveis, sendo disponibilizadas somente para consulta. A atualização, como já dito, é feita através de uma caixa de diálogo (fig. 9), onde se especificam os arquivos e quais bases serão alvo da atualização.

41

Figura 9: Tela de atualização da Base AGRIS

42

7 Métodos de Cálculo de Risco

7.1 INTRODUÇÃO

Diferentes métodos são utilizados para realizar a estimativa de perdas no setor empresarial, sejam elas relacionadas a bens duráveis ou mesmo a pessoas.Porém, poucos são os métodos nativos da área de TI (em sua maioria na Engenharia de Software). O que normalmente acontece é a apropriação de métodos nascidos em outros campos do conhecimento (como o Financeiro) e sua adaptação à Análise de Risco em T.I.. Em se tratando da Segurança da Informação (SI), os métodos empregados possuem o inconveniente de possuírem muitas deficiências, tais como:

� altamente dependentes da tecnologia e possuem pouca (ou nenhuma) portabilidade;

� alto grau de complicação na implementação do método; � não existe um padrão único para a condução da análise e, nem sempre é

possível comparar diferentes análises, mesmo se utilizaram a mesma metodologia;

� orientados à tecnologia e não ao negócio; a análise não reflete o negócio da empresa;

� incompletos (vários métodos não deixam de incluir vários aspectos da análise de risco).

7.2 DEFINIÇÕES

Fator de Exposição � Porcentagem da perda que um evento específico causa em um ativo

Valor do Ativo � Valor monetário do Ativo

Perda média esperada � Fator de exposição x Valor do ativo

Taxa de Ocorrência Anual � Média anual em que um evento é esperado

7.3 MÉTODO DE CRAMM

Government’s Risk Analysis and Management Method (CRAMM) é desenvolvido e mantido pelo departamento de segurança nacional do governo Canadense. A base do método é a dependência direta que o risco possui da tríade ativo (valor), ameaças e vulnerabilidade. Tais valores são mensurados a partir de entrevistas aos “donos” dos ativos em questão. A saída da ferramenta é um conjunto de contramedidas a serem tomadas para garantir a proteção da informação. O Método é dividido em três etapas: 1 identificação de ativos: 2 quantificação de vulnerabilidades e ameaças conhecidas;

43

� as categorias de ameaças e vulnerabilidades são previamente conhecidas e cadastradas em bases de dados;

� as ameaças correntes bem como as vulnerabilidades são identificadas e associadas a categorias existentes;

3 levantamento de contramedidas: � são persistidas em bases de dados (base de contramedidas); � a base possui registros sobre

� o objetivo da contramedida (o que é mitigado); � a descrição detalhada da contramedida; � exemplos de implementação;

� geração de relatórios � com base nas informações coletadas na primeira etapa e após os mesmos

serem confrontados com as bases na segunda etapa é gerado um guideline que visa por o sistema dentro das políticas pré-definidas.

Cálculo Após a quantificação da vulnerabilidade (baixo, médio, alto) da ameaça/ativo, é verificada a entrada na look-up table correspondente a esses três parâmetros. O resultado obtido classifica o risco do ativo relativo.

Ameaça Baixo Médio Alto Vulnerabilidade Baixo Médio Alto Baixo Médio Alto Baixo Médio Alto

Ativo

1 1 1 1 1 1 1 1 1 2

2 1 1 1 1 1 1 1 1 2

3 1 1 2 1 2 2 2 2 3

4 1 2 2 2 2 3 3 3 4

5 2 2 3 2 3 3 3 3 4

6 2 3 3 3 3 4 3 4 4

7 3 3 4 3 4 4 4 4 5

8 3 4 4 4 4 5 4 5 5

9 4 4 5 4 5 5 5 5 5

10 4 5 5 5 5 5 5 5 5

Tabela 4: Look-up table do método CRAMM

7.4 BELIFED-BASED CRAMM

Método desenvolvido no Departmento de Telemática da Norwegian University of Science and Technology, leva em conta a incerteza inerente de uma proposição BMA (Belief Mass Assignement) para refino do cálculo de risco. Esse método baseia-se na definição de risco como um produto. O método busca quantificar as opiniões sobre os ativos, vulnerabilidades e risco associados, de forma que a incerteza sobre esses fatores seja refletida no resultado final. A incerteza é expressa em termos de uma medida de probabilidade definida como Belief Mass Assignment (BMA), onde:

44

� seja 2θ – {Ø}, onde θ é o conjunto das proposições exaustivas e mutuamente

exclusivas e x ⊆ θ um subconjunto dele;

� uma BMA m sobre θ é definido como m: 2θ – {Ø} � [0,1], satisfazendo: � ∑

⊆

=θx

xm 1)(

� m(x) > 0

� define-se, baseado na lógica subjetiva, wx (bx,dx,ux,ax) como uma opinião, onde:

� bx, (função de confiança) =

θ2 , )( Ø

∈∀∑⊆≠

xymxy

� dx (função de desconfiança) =

θ2 , )(Ø

∈∀∑=∩

xymxy

� ux (função de incerteza) =

θ2 , )(Ø

∈∀∑⊄

≠∩xym

xy

xy

� ax (relação de atomicidade) =

θ2 , y

yx∈∀

∩x

� E[X] (média) =

θ

θθ 2 , )y

xa()( ∈∀⋅∑⊆

xymy

� uma opinião pode ser expressa como uma função beta (α,β):

�

−++ )1(2,2

2),,,( x

x

xx

x

xxxxxx a

u

da

u

bBetaaudbw a

� sejam wx e wy duas opiniões; elas são ordenadas segundo as seguintes regras: � a opinião com maior média é a maior opinião; � a opinião com a menor incerteza é a maior opinião; � a opinião com a menor relação de atomicidade é a maior opinião.

� define-se as seguintes operações entre opiniões:

sejam Ai, Vj e IAk respectivamente o indicador de Ameaça do tipo i, o indicador de ameaça do tipo i Vulnerabilidade do tipo j e Impacto associado ao Ativo do tipo k, i,j,k = 1, 2, ... Uma combinação válida de Ameaça, Vulnerabilidade e Impacto de Ativo é representada por A/V/IAl , onde l indica uma combinação particular. Uma opinião sobre

45

uma combinação A/V/IAl válida pode ser expressa como:

jil VTIAVA www ⋅=//

O método é ilustrado por meio de um exemplo; sejam as seguintes tabelas (fig. 10) que expressam opinião sobre ativos, vulnerabilidades e ameaças:

IA Impacto do Ativo Custo do Impacto 1 Arquivos deletados R$ 1.000.000,00

2 Perda de integridade R$ 200.000,00

3 Perda de confidencialidade R$ 100.000,00

4 Indisponibilidade do Sistema R$ 500.000,00

A/V/IA A V IA Opinião BetaA/V/IA Impacto (R$)

1 1 3 3 (0.021, 0.952, 0.026, 0.250) Beta(2.1,74.7) 100.000

2 2 1 1 (0.073, 0.870, 0.057, 0.250) Beta(3.1, 32.0) 1.000.000

3 2 1 3 (0.073, 0.870, 0.057, 0.250) Beta(3.1, 32.0) 100.000

4 2 1 4 (0.073, 0.870, 0.057, 0.250) Beta(3.1, 32.0) 500.000

5 3 4 2 (0.006, 0.980, 0.014, 0.250) Beta(1.4, 141.5) 200.000

6 3 4 3 (0.006, 0.980, 0.014, 0.250) Beta(1.4, 141.5) 100.000

7 4 4 1 (0.025, 0.940, 0.035, 0.250) Beta(1.9, 55.2) 1.000.000

8 4 4 2 (0.025, 0.940, 0.035, 0.250) Beta(1.9, 55.2) 200.000

Figura 10: Exemplo do método de cáculo do Belifed-Based CRAMM Com base nos valores estimados na tabela acima é possível gerar gráficos, usando a pdf beta para avaliar a probabilidade impacto do ativo no negócio:

Figura 11: exemplo do gráfico da probabilidade do impacto para um dado ativo

A Ameaça Opinião

1 Ataque Externo (Hacker) (0.90, 0.05, 0.05, 0.5)

2 Desenvolvedor Malicioso (0.08, 0.80, 0.12, 0.5)

3 Operador Malicioso (0.03, 0.90, 0.07, 0.5)

4 Erro de Usuário (0.20, 0.75, 0.05, 0.5)

V Vulnerabilidade Opinião

1 Controle de Código Fonte (0.60, 0.35, 0.05, 0.5)

2 Controle de Executável (0.05, 0.90, 0.05, 0.5)

3 Acesso ao Firewall (0.01, 0.95, 0.04, 0.5)

4 Controle de entrada de dados (0.10, 0.80, 0.10, 0.5)

46

e o gráfico do risco sobre esse impacto:

Figura 12: Exemplo do gráfico do risco para um dado impacto O método ainda faz estimativa sobre o custo médio do impacto do ativo sobre a partir da probabilidade média de impacto do ativo:

Combinação A/V/IA

Estimativa de Impacto Médio

Sobre ativo

Risco Esperado R$

1 0.02750 2.750 2 0.08725 87.250 3 0.08725 8.725 4 0.08725 43.625 5 0.00950 1.900 6 0.00950 950 7 0.03375 33.750 8 0.03375 6.750

Caso o mesmo ativo esteja envolvido em mais de uma combinação A/V/IA, o risco correspondente será dado pela co-multiplicação dos riscos. 7.5 MÉTODO ESTATÍSTICO

É normalmente utilizado quando há histórico de eventos a serem considerados e a sua ocorrência é relativamente constante. O método é composto pelas seguintes etapas:

� A partir do histórico calcula-se a média (normalmente mensal) de ocorrências de um determinado problema:

(n) meses de #

tipoum de socorrência #∑=ix

� Calcula-se o desvio padrão S, segundo a relação:

( )n

XxS i

2−

= .

� Dessa forma, o resultado esperado está no intervalo [ ]SxSx ii +− , ;

� Calcula-se o grau de incerteza V de cada avaliação xi:

47

ii x

SV = ;

� O resultado esperado normalmente é apresentado em uma tabela contendo os valores mínimo, máximo e o erro; exemplo:

Intervalo Mínimo Máximo Erro

1 x1-S x1+S V1 2 x2-S x2+S V2

7.6 MÉTODO DE MOSLER

Método bastante utilizado em segurança patrimonial e empresarial, sobretudo quando não se conhece o valor das perdas reais ou potenciais; Sua aplicação divide-se em quatro etapas, descritas a seguir. 1) Identificação do Risco - identificar qual o ativo e quais os possíveis danos

(decorrentes de um ataque, por exemplo). 2) Cálculo do Nível do Risco - segue seis quesitos para realizar tal classificação:

� Critério de Função (F) - avalia as conseqüências que a empresa poderá sofrer caso o risco se concretize;

� Critério de Substituição (S) - avalia a dificuldade de substituição dos ativos atingidos;

� Critério de Profundidade (P) - avalia o nível de perturbações internas decorrentes dano sofrido;

� Critério de Extensão (E) - busca projetar a extensão do dano que causaria à empresa;

Escala Pontuação

Muito dificilmente 5

Dificilmente 4

Sem muitas dificuldades 3

Facilmente 2

Muito Facilmente 1

� Critério de Agressão (A) - mede a possibilidade de o risco vir realmente a

ocorrer, de acordo com as características do local onde a avaliação está sendo realizada;

� Critério de Vulnerabilidade (V) - baseado no item anterior (critério de agressão), esta tabela indica o impacto financeiro caso o risco venha a concretizar-se.

48

Escala Pontuação Muito Gravemente 5

Gravemente 4

Medianamente 3

Levemente 2

Muito Levemente 1

3) Cálculo da Evolução do Risco Definidas as graduações dentro das tabelas anteriores, inicia-se a terceira etapa.

� Inicia-se com o cálculo da Magnitude do Risco (C) através da relação: o C = I + D o D → Danos causados = P x E (Profundidade x Extensão) o I → Importância do sucesso = F x S (Função x Substituição) o C = I (F x S) + D (P x E)

� Feito isto, calcula-se a Probabilidade de Ocorrência (Pb) através da fórmula: o Pb = A x V (Agressão x Substituição)

� O próximo passo é calcular a Evolução do Risco (ER), por meio da fórmula: o ER = C x Pb

4) Classificação do Risco

Neste caso, basta comparar o resultado obtido em ER com a tabela abaixo:

Valor do ER Classe de Risco 02 à 250 Muito Baixo

251 à 500 Pequeno

501 à 750 Normal

751 à 1000 Grande

1001 à 1250 Muito Grande

De acordo com os resultados obtidos pelas análises de todos os riscos identificados, pode-se estabelecer um cronograma, de acordo com a gravidade de cada um, buscando sanar antes os riscos mais graves. 7.7 MÉTODO WILLIAN T. FINE

Avalia os riscos, associando o grau de criticidade (GC) de um determinado item avaliado com a justificativa de prioridade de execução para a solução dos problemas, ou seja, justifica os investimentos (JI) apontados pela gerência de risco. O primeiro passo consiste no cálculo do Grau de Criticidade (GC) pela relação:

� GC=C x E x P � C � Conseqüência (impactos decorrentes da ocorrência concretizada, ou seja

devido à exploração de uma ameaça);

49

C=Conseqüência Classificação peso

Quebra da atividade-fim da empresa / Dano superior a 1.000.000 100

Dano entre 500.000 e 1.000.000 50

Dano entre 100.000 e 500.000 25

Dano entre 1.000 e 100.000 15

Dano abaixo de 1.000 5

Pequenos Danos 1

� E � Exposição (freqüência com que o evento ocorre na empresa);

E=Exposição

Classificação peso Diariamente 10

Frequentemente 5

Ocasionalmente 3

Irregularmente 2

Raramente 1

Remotamente possível 0,5

� P � Probabilidade (chance de o evento vir a ocorrer em um espaço de tempo

determinado). P=Probabilidade

Classificação peso Espera-se que aconteça 10

Possível 6

Coincidência, se acontecer 3

Coincidência remota, sabe-se que já aconteceu 1

Extremamente remota, mas possível 0,5

Preticamente impossível 0,1

Após classificar o item de avaliação de acordo com as tabelas acima, obteremos um resultado que deve ser comparado com a seguinte tabela:

Grau de Criticidade Prioridades- Ações a executar GC ≥ 200 Correção imediata – Risco deve ser diminuído imediatamente

85 ≤ GC < 200 Correção urgente - risco requer atenção

GC < 85 Risco a eliminar

Cálculo da justificativa do investimento (JI) Para cada risco a ser mitigado é realizado uma avaliação do tipo custo/benefício para a geração de um plano de ação.

Custo deFator x Correção deGrau GC

JI =

50

Grau de Correção Classificação Pontos

Risco eliminado em 100% 1

Risco reduzido em 75% 2

Risco reduzido entre 50 e 75% 3

Risco reduzido entre 25 e 50% 4

Risco reduzido em menos de 25% 6

Fator de Custo

Classificação Pontos Maior que 50.000 10

Entre 25.000 e 50.000 6

Entre 10.000 e 25.000 4

Entre 1.000 e 10.000 3

Entre 100 e 1.000 2

Entre 25 e 100 1

Menor que 25 0,5

Índice de Justificação (JI) Resultado

JI ≤ 10 Investimento Duvidoso

10 < JI ≤ 20 Investimento Justificado Normalmente

JI > 20 Investimento Plenamente Justificado

7.8 GRAPHICAL RISK ANALYSIS – GRA

GRA procura, não eliminando a subjetividade inerente ao processo de análise, fornecer meios para realizar uma análise que permita a comparação com elementos (ativos) similares. A característica central nessa metodologia é que os elementos são definidos em termos dos ativos e da relação entre eles (chamado de sistema). O método evita atribuição de valores para definir a importância de um ativo. Sua importância é derivada a partir de diagramas (DFD e casos de uso podem ser usados) onde o negócio da empresa é explicitado. Dessa forma o valor de um ativo seria analisado em termos de sua importância para o negócio. O Risco de um ativo é dado em termos dos serviços em que o mesmo participa; Categorias definidas pelo método:

� Recurso - elemento básico do sistema que representa qualquer “coisa” (computador, página web, roteador, etc);

� Grupo - Determina um número qualquer de recursos do mesmo tipo; � Sistema: Representa um conjunto de recursos heterogêneos e a relação entre

eles; � Acesso Fim e acesso meio - Indica se o recurso, ou grupo é o destino

(Servidor, impressora) ou caminho (proxy, filtro).

51

Indices de Risco

� Define se o risco refere-se a um recurso (sem notação especial); � Define se o risco refere-se a um grupo (valor seguido de g); � Define se o risco refere-se a um Sistema (valor seguido de s).

Princípio do Risco pelo Serviço Cada acesso implica em um risco (em termos de impacto e probabilidade) e que cada uma dessas variáveis possui valor diferente de zero, então o nível de risco (R) também será maior que zero. Quanto maior o número de acessos diretos a um elemento, maior o risco. Logo, para dois elementos idênticos E1 e E2, se E1 possui mais acessos que E2, então R(E1) > R(E2) Princípio do Risco pela dependência Todo elemento contém riscos devido ao processo em que participa e contribui para o risco dos processos ou funções em que estão envolvidos; quanto mais elementos participam de um processo, maior o risco do mesmo. Princípio do Negócio A segurança serve para apoiar o negócio e não ser um negócio ela mesma, por isso todos os diagramas de segurança devem manter o foco no negócio da empresa. Cálculo do Risco Geral do Sistema

� Calcula-se o Risco Geral (GR), que é baseado no número de acessos direcionado a um certo elemento do negócio (acesso a um site, acesso externo, impressão de documentos, etc), a partir dos Elementos Gerais de Risco (GER): � EE AGER = , onde |A| é a cardinalidade do conjunto de acessos

direcionado ao elemento E; � O Risco geral do Sistema (GSR) é definido segundo a equação

∑=

=n

iiGERGSR

0

, onde n é o número de elementos do sistema analisado;

� Exemplo de cálculo de GSR e GER: cenário - o acesso a um servidor de banco de dados (recurso) realizado pelos membros da tesouraria (grupo) passando pela internet (sistema): � GER da tesouraria = |Atesouraria| = 0g � GER da internet = |Ainternet| = 1s � GER do servidor = |Aservidor| = 1 � GSR= 0g + 1s +1 = 1 + 1s (s deve ser substituído pelo risco de um sistema

desse tipo).

Cálculo do Risco pela dependência � O risco pela dependência de um elemento (EDR) é dado pela cardinalidade do

conjunto de acessos que utilizam o elemento como “ponte”. � O risco pela dependência do Sistema (SDR) é dado pela soma de seus EDR.

52

� Exemplo de cálculo de EDR e SDR para o mesmo cenário acima; � EDR da tesouraria = |Btesouraria| = 0g (nenhum acesso através deles); � EDR da internet = |Binternet| = 1s; � EDR do servidor = |Bservidor| = 0 (pois é o destino); � SDR= 0g + 1s +0 = 1s.

7.9 CONCLUSÃO:

Inicialmente os métodos de cálculo de risco utilizavam somente o valor do ativo e uma valoração arbitrária das vulnerabilidades encontradas e do impacto relacionado às mesmas. Normalmente, esse valor é extraído da experiência adquirida no processo de análise de risco. Um dos pontos negativos associados a um cálculo baseado na experiência é sua portabilidade para outros sistemas. O custo de adaptação, quando possível, é tão alto a ponto de se tornar impossível realizar tal adaptação em sistemas de grande porte. Por isso métodos antigos não possuem como premissa a adaptação do mesmo à realidade da empresa. Um outro importante fator que se encontra ausente na maioria dos métodos é a visão do ativo como parte do negócio, sendo o seu valor dependente do mesmo. O valor de um ativo deve ser visto segundo o lucro que o mesmo gera para a empresa e não ser avaliado segundo o seu valor de aquisição. Algumas abordagens mais modernas buscam acrescentar à rigidez de métodos mais antigos o fato de que nem sempre é possível definir exatamente o peso de uma vulnerabilidade ou o seu impacto sobre uma empresa (como o Belief-Based), acrescentando variáveis de “folga” de forma a dar uma modelagem mais estruturada ao cálculo de risco. Mas, apenas isso não é o suficiente pra refletir a diferenças entre os diversos ambientes onde a gerência de risco é realizada. O cálculo do risco de um ativo isolado não reflete o impacto que o mesmo causa em outros ativos, por torná-los indisponíveis ou não permitir que o fluxo do negócio chegue ou passa deles, impedindo a empresa de atingir seu objetivo fim.

53

8 Proposta inicial de cálculo de risco para o projeto AGRIS

Uma nova proposta de cálculo de risco deveria estimar o valor do ativo em relação ao seu papel dentro do negócio do qual o mesmo participa. A seguinte proposta realiza o cálculo de risco levando em consideração a dependência entre os ativos, além do cálculo isolado já existente: O método tem como base o cálculo de risco sobre ativos utilizado pelo método de CRAMM (Ativo x Vulnerabilidade x Impacto) porém com as diferenças descrita a seguir.

� O valor de um ativo é dado em relação à função que desempenha para a realização do negócio, sua função dentro da empresa. Dessa forma a indisponibilidade de um ativo refletirá corretamente o impacto que o mesmo causará na empresa.

� O Risco de um ativo é dado em relação às vulnerabilidades encontradas nesse (risco individual) e a dependência que os outros têm do mesmo (risco por negócio).

� Possibilita verificar o impacto que a dependência entre ativos acarreta ao cálculo de risco.

� O custo do controle por negócio, calculado pelo somatório do custo de implementação do controle por ativo.

� Risco Individual: ∑

∀ iviR , onde iii xIAxVR = , ou seja, o somatório dos riscos

associados a cada uma das vulnerabilidades encontrada. Calculado o risco associado a cada uma das vulnerabilidades usando o método de CRAMM e depois realizando o somatório dos mesmos.

� A partir desses somatórios para cada ativo é construída um vetor de Risco.

�

=

nR

R

R

R...

2

1

� Cálculo do Risco por negócio: DxR, o produto entre as matrizes de dependência de ativos extraída de uma análise orientada aos negócios � D é a matriz de dependência construída da seguinte forma:

o Sejam os sistemas S1 e S2, pertencentes ao negócio; o Se S1 depende funcionalmente de S2, então os ativos de S1

dependem de S2; o A matriz Dij é construída pela regra: o aij = 1, se j depende de i, 0 caso contrário; o vetor de Risco é dado por DxR

o vetor de custo de controle é dado por ∑∀

⋅i

i Dc, que obtém o custo

de controle por ativo; o somatório de controle do mesmo tipo dará o custo de

implementação do controle por ativo;

54

9 Contexto de implementação

9.1 PLATAFORMA ALVO

O projeto “Análise e Gerência em Riscos de Segurança da Informação”, conforme definido anteriormente, visa implementar um software para análise do risco de sistemas operacionais. Este aplicativo será capaz de identificar ameaças, vulnerabilidades e impactos ao negócio das empresas, gerando relatório técnicos e executivos. O sistema da Microsoft Windows 2000 foi escolhido como plataforma alvo para a base para o desenvolvimento da solução de análise de risco. Desde a sua inauguração em 1989, atingiu uma marca de 45 mil pessoas, que de alguma forma utilizam a plataforma para desenvolvimento, treinamento ou mesmo prestam serviço, espalhados por mais de 10 mil empresas brasileiras. As tabelas apresentadas a seguir mostram que, tanto para o uso como cliente (97% do mercado), como para o uso como servidor (62% do mercado), existe uma forte predominância dos produtos Microsoft no mercado brasileiro. Esta mesma situação é também observada na América Latina como um todo.

Tabela 4:Plataformas instaladas - Clientes

Tabela 5:Plataformas instaladas – Servidores

Sistemas Operacionais para SERVIDOR - Fundação Getú lio Vargas 1999 2000 2001 2002 2003

Windows 53% 56% 57% 60% 62%

Unix 24% 22% 21% 18% 16%

Linux 1% 3% 8% 12% 14%

Novell 18% 15% 11% 7% 5%

Outros 4% 4% 3% 3% 3%Fonte: FGV - 14a. Pesquisa de Administração de Recursos de Informática, Março 2003

Client O/S Installed Base - Fundação Getúlio Vargas 1999 2000 2001 2002 2003

Windows 97% 97% 97% 97% 97%

Unix* 1% 2% 2% 2% 2%

Outros 2% 1% 1% 1% 1%Source: FGV - 14a. IT Resource Administration Survey, March 2004

* Include Linux

55

9.2 AMBIENTE DE DESENVOLVIMENTO

O C++ Builder 6 foi escolhido como ambiente de programação para a ferramenta pois, além de sua complitude funcional, todos os participantes do projeto já tinham experiência na sua utilização. O Interbase Server 6 será utilizado num primeiro momento como servidor local principal para a base de dados . Na etapa final, o Firebird será utilizado para abrigar a base (possui código aberto e extrema compatibilidade com o Interbase).

56

10 Metodologia para levantamento de requisitos

Para a especificação definição de serviços e interfaces do projeto optou-se pelo emprego da metodologia de criação de cenários de utilização (uma derivação de use cases).Um cenário de utilização é uma descrição estruturada de um típico uso da ferramenta para a realização de tarefas ou funções. Os cenários de utilização são tipicamente úteis nas atividades específicas de desenvolvimento de software, proporcionando um ponto de partida para derivar os requisitos do sistema, ou mesmo substituindo o processo de levantamento de requisitos (opção feita pelo projeto de forma a acelerar sua implementação). Na próxima fase os cenários de utilização serão explodidos, promovendo um refinamento dos requisitos, em paralelo às atividades de codificação. Os cenários iniciais são gerais e de alto-nível (designado como primários), sendo que cada um descreve uma categoria de uso do sistema. A parir deste conjunto inicial de cenários são derivados um ou mais cenários específicos (cenários secundários), detalhando os diversos tipos de utilização previstos pelo cenário primário correspondente. 10.1 DESCRIÇÃO DO PROCESSO

A figura 13 apresenta representação gráfica do processo de identificação e captura de requisitos par o projeto AGRIS. Os cenários de utilização são capturadas através de refinamentos sucessivos para elucidar as potenciais aplicações da ferramenta em desenvolvimento. A partir daí, os cenários serão priorizados de forma a garantir que os requisitos emergenciais, e primordiais, serão devidamente capturados.

Figure13: Processo para levantamento de Requisitos

Capturar cenários primários

1

Requisitos operacionais(segurança,

confiabilidade)

Requisitos do sistema

Requisitos funcionais para a ferramenta

AGRIS

Revisão

Cenários &

Requisitos

55

4444

Priorizar cenários primários

22

Priorizar cenários primários

22

Gerar cenários

secundários

33

Gerar cenários

secundários

33

57

10.2 DEFINIÇÕES

Requisitos funcionais: funções que devem ser providas pelo sistema em desenvolvimento. O cenário de utilização é uma descrição estruturada de uma típica utilização do sistema, usado para descrever uma certa função. Requisitos operacionais: requisitos que as funcionalidades do sistema em desenvolvimento devem exibir: segurança, confiabilidade, escalabilidade, etc. Requisitos do sistema: requisitos esperados do sistema de forma a suportar os requisitos funcionais e operacionais.

58

10.3 NOMENCLATURA E FORMATO DE UM CENÁRIO DE UTILIZAÇÃO

ID Identificação única do cenário de utilização no projeto

Título Frase curta, título de alto nível do cenário de utilização

Sumário Descrição em linguagem natural do tipo de utilização coberto por esse cenário (para cenários primários), ou uma exposição em linguagem natural da natureza e do intuito da atividade de um cenário secundário específico

Nível O nível de abrangência deste cenário:

Primário – alto nível

Secundário – um exemplo mais tangível de utilização; deve ser uma instância de um cenário primário, sendo que o número deste deve ser especificado beste campo

Usuários Os principais usuários para este cenário em particular

Pré-condições Quaisquer informações, estados, ferramentas, necessárias antes do início das atividades descritas no cenário

Entradas Dados, sinais, etc., que serão usadas como entrada durante o desenrolar das atividades descritas no cenário

1 Série de estágios que descrevem a essência das atividades descritas neste cenário

2 Indicar loops interativos em alto nível (mínimo detalhe)

3

4

5

6

7

8

Descrição (passos)

9

Saídas Informações, dados, resultados analíticos ou mudança de configurações gerados durante a execução do cenário de utilização.

Pós-condições Garantias sobre o estado do sistema e/ou do ambiente operacional, que são atingidos depois que o cenário for executado integralmente.

59

10.4 CENÁRIOS DE UTILIZAÇÃO PRIMÁRIOS

ID AGRIS01 Título Inicialização Nível Primário Sumário Provê todas as condições necessárias para validação de usuários,

configuração e execução da ferramenta. Usuário ANALISTA/GERENTE Pré-Condições Ferramenta instalada (sem erro)

Login e senha (validação do usuário)

Escopo da aplicação (perfil dos ativos e suas dependências, responsáveis envolvidos no projeto) Tipo de ativo (ambiente, pessoas, sistema operacional., etc)

Tipo de plataforma;

Entradas

Base de dados do sistema;

Valida acesso ao sistema;

Cria ou recupera o escopo da aplicação;

Inicializa configurações;

Verifica a integridade/disponibilidade da base do sistema e novas bases; Carrega os módulos de vulnerabilidades de acordo com o tipo de ativo selecionado; Carrega os controles de acordo com o tipo de ativo selecionado;

Carrega dependências entre vulnerabilidades e controles;

Descrição

Atualização remota da base de dados (opcional);

Acesso autorizado ao sistema;

Informação com erro de acesso;

Log de acesso atualizado;

Escopo de aplicação;

Saídas

Status da base;

Fica no estado inicialização (no caso de erro); Pós-Condições Vai para o estado de processamento/gerência;

60

ID AGRIS02 Título Processamento Nível Primário Sumário Processamento das funcionalidades da ferramenta, sendo a sua

execução customizada para cada cenário através de ajuste feitos pelos usuários.

Usuário Analista/Gerente Ferramenta instalada e inicializada corretamente;

Usuário “logado” com devido permissionamento;

Pré-Condições

Ativo/escopo a serem analisados devidamente recuperados/criados;

Valor do custo hora do analista; Valor da probab. de ocorrência da vulnerabilidade (opcional); Valor do impacto (opcional); Ameaças relacionadas (opcional); Cenário de análise

Entradas

Tipo de relatório Carrega agentes de inspeção necessários;

Verifica as vulnerabilidades/controles existentes;

Executa análise selecionada;

Calcula risco;

Gera gráficos;

Realiza compliance com norma de segurança;

Realiza benckmark;

Gera relatórios técnicos e gerencias;

Mede nível de maturidade de segurança;

Salva contexto do usuário;

Salva os logs atualizados;

Descrição

Calcula custo de implementação dos controles;

Cenário de Risco; Análise de Benckmark; Relatórios técnicos e gerenciais; Nível de maturidade; Lista de Vulnerabilidades existentes e seus controles; Ameaças relacionadas; Custo para implementação dos controles;

Saídas

Plano de ação; Vai para o estado de inicialização Pós-Condições Fica no estado de processamento

61

ID AGRIS03 Título Gerenciamento Nível Primário Sumário Administração das configurações dos controles, vulnerabilidades,

usuários, permissionamentos e do projeto em geral. Usuário Administrador da ferramenta

Ferramenta instalada Pré-Condições Usuário logado no sistema com autorização de administrador Contas novas (login, senha, etc) Entradas Dados de configuração Configurar controles (customização) Customizar entradas/saídas Cadastrar usuários Definir permissão de usuários Inserir ameaças/vulnerabilidades/controles específicos

Descrição

Atualizar logs Base de dados local atualizada Arquivos de contas/senhas atualizados Primitiva s de entradas/saídas atualizadas

Saídas

Logs atualizados Pós-Condições Retorna ao estado de inicialização

62

11 Considerações finais

A análise de risco, processo de avaliação das vulnerabilidades do sistema e das potenciais ameaças, é um componente essencial de qualquer programa de gerência de segurança da informação. O processo de análise identifica as prováveis consequências ou riscos associados com as vulnerabilidades e proporciona a base para estabelecimento de um programa de segurança que seja custo-efetivo.

As ferramentas atuais de análise de riscos de segurança fornecem alguns aspectos importantes na gerência de risco, mas não há nenhuma que ofereça todas as funcionalidades essenciais. A solução proposta neste relatório prevê uma ferramenta que integre a análise de risco e análise de vulnerabilidades, possuindo um conjunto mínimo de características comuns as principais ferramentas:

� classificação de ativos por meio de sua funcionalidade em relação ao negócio; � identificação automática de alterações tecnológicas na empresa; � scanning de vulnerabilidades; � criação de um plano de ação que leve em conta a melhor relação

custo/benefício; � cálculo de risco deve levar em conta a dependência entre ativos; � geração relatórios diversificados (técnico e alta gerência) previstos,

relacionando características diversificadas (Risco x Ativo, Controle x Impacto, etc.).

� justificativa de investimento através do ROI; � customização de gráficos; � verificação de comformidade com diversos padrões do mercado; � verificação do nível de maturidade.

Este relatório descreve também uma nova proposta de cálculo de risco incorporando duas novas colocações:

� estimativa do valor do ativo em relação ao seu papel dentro do negócio do qual o mesmo participa;

� cálculo de risco levando em consideração a dependência entre os ativos (tendo como base o cálculo utilizado pelo método de CRAMM).

Um resultado importante desta primeira fase foi o desenvolvimento de uma ferramenta para criação e manutenção da base de vulnerabilidades/controles da ferramenta AGRIS, juntando os dados oriundos de bases já existentes com as informações definidas por futuros usuários. Na próxima versão da ferramenta, as atualizações feitas nas bases (OVAL, CVE, BugTraq, ...) serão automaticamente incorporadas na base AGRIS. Atualmente o projeto se encontra em fase de programação, envolvendo o detalhamento dos cenários de utilização em paralelo às atividades de codificação.

63

12 Referências

1. Visual Assurance - http://www.kilclare.com/;

2. Compliance Guardian - http://www.eyware.com/?ID=248;

3. Ecora Enterprise Suite - http://www.ecora.com/;

4. Check-up Tool - http://www.checkuptool.com;

5. Bindview - http://www.bindview.com/Products/PolicyComp/ ;

6. Cramm Express - http://www.cramm.com/express/index.htm;

7. Foundstone - http://www.foundstone.com/products/index_products.htm;

8. Método de CRAMM: http://www.gammassl.co.uk – (Outubro/2004)

9. CCTA, “CRAMM User’s Guide”, Agência Central de Computação e

Telecomunicações do Canadá;

10. Josang, A., Bradley D., Knapskog, S.J., “Belief-Based Risk Analysis”, Department of Telematics, Norwegian University of Science and Technology;

11. Método Estatístico - http://www.jseg.net/ed104/radar_104.htm (Outubro/2004);

12. Método Mosler - http://www.jseg.net/ed105/radar_105.htm (Outubro/2004);

13. Método T. Fine - http://www.jseg.net/ed106/radar_106.htm (Outubro/2004);

14. Omar A. Herrera R., Graphical Risk Analysis (GRA), “A Methodology To Aid In

Modeling Systems For Information Security Risk Analysis”;

15. Thomas R. Peltier, “Information Security Risk Analysis”, Segunda edição; Ed. Auerbach publications;

16. Thomas R. Peltier, “Information Security Policies and Procedures: A

Practitioner's Reference”, Segunda edição; Ed. Auerbach publications;

17. Charles Cresson Wood, “ Information Security Policies Made Easy Version 9”, Ed. Information Shield;

18. Christopher Alberts, Audrey Dorofee, “Managing Information Security Risks: The

OCTAVE Approach”, Ed. Addison-Wesley;

19. Harold F. Tipton & Micki Krause, “Information Security Management

64

Handbook”, Quinta edição, Ed. Auerbach publications;

20. Michel Crouhy, Robert Mark, Dan Galai, “Risk Management”, Ed. Mc-Graw-Hill;

21. Carl Pritchard, Carl L. Pritchard, “Risk Management: Concepts and Guidance”,

Ed. ESI International;

22. James J. Finnegan; “Enterprise Compliance Management (ECM): Bringing Influences Together”, Ed. iUniverse;

23. Stephen Northcutt, Leny Zelter, Scott Winters, Karen Kent e Ronald W. Ritchey,

“Desvendando Seguranca em Rede”, Ed. Campus;

24. Andrew Baker, Jay Beale, Brian Caswell, Mike Poore, “Snort 2.1 Intrusion Detection”, Ed. Syngress;

25. Elizabeth D. Zwicky, Simon Cooper, D. Brent Chapman, “Building Internet

Firewalls”, Segunda edição, Ed. O’reilly;

26. Bruce Schneier, “Applied Cryptography Protocols, Algorithms, and Source Code in C”, Segunda edição, Ed. John Wiley & sons.

65

13 Anexo 1 – Cronograma inicial

Projeto AGRIS - Parte 1- Análise de Riscos Duração Início Definição do escopo do projeto 89 days 16/08/04 Levantamento e estudo das ferramentas de Risco 86 days 16/08/04 Estudo dasPlataformas mais usadas UFRJ/Brasil/AL 86 days 16/08/04 Avaliação e escolha da plataforma para o projeto 2 days 13/12/04 Levantamento bibliográfico (Acad., Seg, riscos, ROI) 86 days 16/08/04 Documentação 89 days 16/08/04 Relatório 0 days 16/12/04 Levantamento de controles/vulnerabilidades 95 days 18/10/04 Estudo de ferramentas de vulnerabilidades (Nessus) 40 days 18/10/04 Levantamento de fontes (vulnerabilidades) 50 days 18/10/04 Estudar formatos para automação 5 days 27/12/04 Definir layout do controle 1 wk 04/01/05 Definir nomenclatura de controle 1 wk 11/01/05 Associação de controles 29 days 18/01/05 Documentação 95 days 18/10/04 Relatório 0 days 25/02/05 Cáculo dos Riscos 30 days 12/11/04 Levantamento dos princ métodos de cálculo dos risco 11 days 12/11/04 Proposta e simulação de novo método de cálculo 16 days 29/11/04 Proposta/validação de Método inicial p/ Calc. de Risco 2,2 wks 06/12/04 Documentação 30 days 12/11/04 Relatório e Apresentação 0 days 23/12/04 Análise de Requirements 20 days 03/12/04 Top level Requirements 2 wks 03/12/04 Classificação e detalhamento dos requirements 2 wks 17/12/04 Documentação 20 days 03/12/04 Relatório 0 days 30/12/04 Desenvolv. de modelos e proposta de framework 15 days 31/12/04 Arquiteura de software 1 wk 31/12/04 Modelo de dados 1 wk 07/01/05 Diagramas de sequência 1 wk 14/01/05 Documentação 15 days 31/12/04 Relatório 20/01/05 Programação 120 days 21/01/05 Desenvolvimeto de Interfaces (IHM) 40 days 21/01/05 Banco de dados 40 days 18/03/05 Desenvolvimentos de Módulos 40 days 13/05/05 Documentação 120 days 21/01/05 Relatório 07/07/05 Testes e Avaliação de performance 20 days 08/07/05

66

Testes e medidas 1 mon 08/07/05 Documentação 20 days 08/07/05 Relatório 0 days 04/08/05 Gerência de Projeto e externalização 173 days 15/12/04 Relatório FRIDA parcial 09/02/05 Relatório FRIDA final 04/08/05 Manual de Utilzação 15/08/05 Disponibilização no site da ferramenta 15/08/05