Google Lat Long: Visit before you visit

Google Lat Long: Visit before you visit

Estudo de Usuário

O usuário é de fundamental importância em todos os sistemas informacionais. Para os serviços de bases de dados, o usuário é aquele que interroga essas bases e são considerados especialistas da informação. O usuário tem dois papéis: ele pode ser responsável pela manutenção, existência, atribuição de recursos e pela política da unidade de informação.

O usuário pode e deve interferir na cadeia documental, ajudando a selecionar as aquisições, contribuir na organização de instrumentos de trabalho, pode colaborar na descrição de conteúdos, na formulação de estratégias de busca e avaliar as pesquisas.

Categoria de Usuários

As categorias de usuários, podem ser definidas em dois tipos de critérios: objetivos e os psicossociológicos.

Os critérios objetivos, como a categoria sócio profissional, a especialidade e a natureza da atividade para aqual a informação é procurada.

Os critérios psicossociológicos, como valores e atitudes relativos a informação.

Pode-se destacar três grandes grupos de usuários:

• usuários que ainda não estão na vida ativa (estudantes);
• usuários engajados na vida ativa, quando suas necessiadades de informação se originam da vida profissional.

• o cidadão, em que suas necessidades de informação estão ligadas a sua vida social.

Fonte:

http://estudousuario.wordpress.com/2007/09/20/categorias-de-usuarios/

Uma Ontologia para a Gestão de Vulnerabilidades Técnicas baseada na Web Semântica

Paulo Hideo Ohtoshi

Universidade de Brasília
Faculdade de Ciência da Informação

ohtoshi@unb.com

Abstract. The amount of information about software vulnerabilities, including patches released and distributed over the Internet and the fast dissemination of attack tools and techniques, has overwhelmed the security officer which has to deal with a large amount of information about security, turning the information management into a more complex task. Several tools generate different format of vulnerabilities logs. Most databases and source of information use syntactic format description, without the semantic associated. There is a large volume of information about known vulnerabilities, but the machines are incapable of processing information the way they are structured today. The use of ontologies to formally structure the vulnerability information may solve these problems and allow automatic tools correlate data from different sources of information.

Resumo. A quantidade de informações sobre vulnerabilidades de software, incluindo as correções publicadas e distribuídas pela Internet e a rápida disseminação de técnicas e ferramentas de ataque, sobrecarregam o gestor de segurança que tem de lidar com uma grande quantidade de informações sobre segurança, tornando a tarefa de gestão de segurança muito mais complexa. A maior parte das fontes de informação e bases de dados sobre vulnerabilidades usa o formato de descrição sintática e um padrão próprio, sem nenhuma semântica associada. Há um grande volume de informações acerca das vulnerabilidades conhecidas, mas as máquinas são incapazes de processar a informação da forma como estão estruturadas hoje. O uso de ontologias que estruture formalmente as informações sobre vulnerabilidade pode solucionar esses problemas e permitir que ferramentas automatizadas façam a correlação dos dados de diversas fontes de informação.

1.        Introdução

Antes do advento da Internet e dos computadores pessoais, o impacto das falhas detectadas em programas de computador ficavam restritas aos centros de processamento de dados. Hoje, com a imensa quantidade de máquinas interligadas em rede, um atacante pode explorar essa vulnerabilidade de qualquer lugar do mundo e o impacto causado pela exploração dessa vulnerabilidade pode gerar problemas de grande dimensão como os que seriam causados por eventuais ataques a infraestruturas críticas de um país.

Vulnerabilidades de software são falhas que podem ser causadas durante a fase de projeto, na etapa de implementação ou até mesmo durante a fase configuração. Quanto maiores e mais complexos forem os programas, mais falhas eles apresentam e mais inseguros eles se tornam. Na visão de Stamp (2006), a complexidade do software ultrapassou a capacidade do ser humano de lidar com a complexidade. Pesquisas do NIST[1] estimam cerca de 20 erros por mil linhas de código [DACEY, 2003]. Segundo essa pesquisa, houve um aumento significativo em número de linhas de código dos programas. Exemplo desse fato são os sistemas operacionais: o Windows 2000 contém 35 milhões linhas de código, enquanto o seu antecessor, o Windows 1995, continha 15 milhões de linhas de código. Conforme Stamp (2006), uma das causas para a existência de tantas falhas é a necessidade de lançar o produto o mais rapidamente possível e sem os devidos testes. Essas falhas são corrigidas após o lançamento do produto mediante o uso de correções[2] (patches).

Para facilitar a tarefa de gestão de segurança, diversas ferramentas foram desenvolvidas para detectar vulnerabilidades dos sistemas computacionais. Essas ferramentas geram informações que são coletadas e armazenadas em formato próprio. As mesmas vulnerabilidades e falhas são reportadas e representadas de forma diferente. Essa falta de padronização e a grande quantidade de informações sobre vulnerabilidades que são descobertas e publicadas diariamente dificultam a tarefa de gerenciamento da vulnerabilidade. Como identificar soluções únicas para problemas aparentemente iguais. A identificação das vulnerabilidades de forma padronizada permite correlacionar os logs[3] e os incidentes associados a essas vulnerabilidades.

Ao longo das últimas décadas, uma significativa quantidade de conhecimento foi acumulada na área de segurança da informação e, em particular, sobre vulnerabilidades e incidentes de segurança. No entanto, muitos dos conceitos sobre vulnerabilidades são vagamente definidos e às vezes com diferentes semânticas, causando mal-entendidos entre as partes interessadas, devido à ambigüidade da linguagem. Por outro lado, a padronização, a concepção e o desenvolvimento de ferramentas de segurança requerem a classificação sistemática e a definição de conceitos e técnicas de gerenciamento de vulnerabilidades. É importante ter um vocabulário claramente definido e uma linguagem padronizada para comunicar de forma precisa as informações sobre as vulnerabilidades e suas respectivas medidas de controle às pessoas envolvidas. A tecnologia semântica, em particular, a ontologia, pode ser uma ferramenta útil para o gerenciamento de vulnerabilidades dos sistemas computacionais.

Este trabalho propõe uma abordagem ontológica para capturar e utilizar os conceitos fundamentais do gerenciamento de vulnerabilidades e de seus relacionamentos para recuperar os dados sobre vulnerabilidades e estabelecer o raciocínio sobre as causas e o impacto das vulnerabilidades. A ontologia de gerenciamento de vulnerabilidades proposta foi povoada com as vulnerabilidades armazenadas em diversas fontes de informação, entre as quais aquelas constantes na base de dados NVD – National Vulnerability Database [NIST, 2010], acrescidas de regras de inferência e formas de representação de conhecimento. O formato padrão para comunicação de vulnerabilidades adotado na ontologia será o proposto pelo CVE - Common Vulnerabilities and Exposures [MITRE, 2010] e as métricas de classificação de vulnerabilidades seguirão as diretrizes constantes no guia de classificação e pontuação de vulnerabilidades CVSS - Common Vulnerabilities Scoring System [MELL; SCARFONE; ROMANOSKY; 2007].

2.        O Projeto CVE

O grande desafio atual é o gerenciamento do volume de dados e informações gerados por mecanismos e ferramentas de segurança e por outras fontes de informação sobre vulnerabilidades. O CVE (MITRE, 2010) é um esquema de padronização de nomes de vulnerabilidades e exposições que permite a identificação de uma determinada vulnerabilidade por diversas ferramentas e o acesso a informação sobre correções constantes em diversos bancos de dados. O Projeto CVE (MITRE, 2010) é o resultado de um esforço internacional envolvendo universidades, desenvolvedores e instituições governamentais para criar mecanismos organizados para identificar, encontrar e corrigir de forma mais rápida e eficiente vulnerabilidades de software.

2.1   CVSS

Vários órgãos e departamentos ligados a segurança da informação como o NIST - National Institute of Standards and Technology, o FIRST - Forum of Incident Response and Security Teams e o CERT - Computer Emergency Response Team, entre outros, uniram-se para criar um padrão para pontuação de vulnerabilidades de software denominado CVSS - Common vulnerabilities Scoring System (MELL, SCARFONE, ROMANOSKY, 2005). O CVSS é um sistema de classificação de vulnerabilidades usado pela base de dados NVD - National Vulnerability Database (NIST, 2010) e integrada ao CVE - Common Vulnerabilities and Exposures (Mell & Grance, 2002). A metodologia do CVSS utiliza uma série de parâmetros e calcula uma pontuação (score) que irá definir o grau de severidade de uma determinada vulnerabilidade.

Critérios qualitativos são utilizados para a caracterização das vulnerabilidades. Esses critérios são divididos em três grupos: métricas básicas, métricas temporais e métricas ambientais. As métricas básicas contêm todas as características que são intrínsecas a determinada vulnerabilidade e que são invariáveis ao longo do tempo e em diferentes ambientes. As métricas temporais contêm as características que podem mudar ao longo do tempo. No grupo das métricas ambientais estão as características que dependem da implementação e do ambiente.

As características são valoradas e processadas para obter uma pontuação final ajustada, que irá representar as ameaças que uma vulnerabilidade apresenta em determinado instante no tempo para um ambiente específico. A pontuação representa um valor entre 0 (sem riscos) e 10 (maior risco). O NIST realiza uma classificação de riscos das vulnerabilidades baseado nesta pontuação: Baixo (valor entre 0 e 3), Médio (valor entre 4 e 7) e Alto (valor acima de 7).

Historicamente, a indústria tem utilizado diversos métodos de pontuação para vulnerabilidades de software (Mell, 2006), geralmente sem o detalhamento dos critérios ou processos, criando um grande problema para os usuários, que precisam encontrar um meio de gerenciar seus sistemas e aplicações. É importante saber que toda vulnerabilidade tem um tempo de vida (Frei, 2006), que deve ser respeitado e seguido para a solução do problema.

2.1.1       Métricas Básicas

O grupo de Métricas Básicas reúne as características que são invariáveis com o tempo e com o ambiente. Esse grupo é composto de seis fatores, conforme a Tabela 2.1. Esses seis fatores estão divididos em dois subgrupos: Impacto e Complexidade. O subgrupo Complexidade é composto pelos fatores Vetor de Acesso, Complexidade de Acesso e Autenticação. O subgrupo do Impacto é composto pelos fatores Impacto na Confidencialidade (C), Impacto na Integridade (I) e Impacto na Disponibilidade (A).

Tabela 2.1- Métricas Básicas

Grupo	Fator	Classificação	Valor
Complexidade	Vetor de Acesso (AV)	Local	0,395
		Rede Adjacente	0,646
		Rede Remota	1,0
	Complexidade de Acesso (AC)	Alta	0,35
		Média	0,61
		Baixa	0,71
	Autenticação (A)	Múltipla	0,45
		Única	0,56
		Desnecessária	0,704
Impacto	Confidencialidade (C)	Nenhum	0
		Parcial	0,275
		Completo	0,660
	Integridade (I)	Nenhum	0
		Parcial	0,275
		Completo	0,660
	Disponibilidade (D)	Nenhum	0
		Parcial	0,275
		Completo	0,660

Fonte: Mitre.org

O Vetor de Acesso (AV) reflete como a vulnerabilidade pode ser explorada, se local ou remotamente. Quanto mais remoto estiver o atacante, mais vulnerável estará o sistema e maior será a pontuação deste parâmetro. Se a vulnerabilidade puder ser explorada tanto localmente, quanto por redes remotas, receberá a classificação Rede Remota (R); se puder ser explorada localmente e por uma rede adjacente, mas não por uma rede remota, receberá a classificação Rede Adjacente (A); ou ainda se exigir acesso físico ou login autenticado no sistema alvo, receberá a classificação Local (L).

A Complexidade de Acesso (AC) mede o esforço necessário para explorar uma vulnerabilidade depois de o atacante ter tido acesso ao sistema-alvo. Se forem necessárias circunstâncias muito específicas ou condições especiais de acesso, a complexidade será considerada Alta. Se somente algumas circunstâncias forem necessárias para a exploração da vulnerabilidade, a complexidade será Média. Se não existirem circunstâncias especiais, a complexidade será Baixa.

A métrica de Autenticação (AU) identifica o número de vezes que o atacante necessita se autenticar na máquina-alvo para explorar a vulnerabilidade. A métrica pode ser classificada como: Múltipla, se o atacante precisar se autenticar mais de uma vez; Única, se precisar se autenticar uma única vez; Desnecessária, se não for necessário se autenticar.

As métricas de Impacto na Confidencialidade (C), Impacto na Integridade (I) e Impacto na Disponibilidade (A) medem o grau de impacto em cada um destes requisitos de segurança, caso a vulnerabilidade seja explorada. O impacto pode ser Completo se houver comprometimento total do requisito. Pode ser Parcial, se houver danos consideráveis sem que haja controle total do que foi obtido, modificado ou totalmente interrompido. O impacto também pode ser Nenhum, se não houver nenhum tipo de comprometimento.

Cálculo do Impacto

O Impacto é calculado de acordo com a seguinte fórmula:

Impacto = 10,41 * (1 - (1 - C) * (1 - I) * (1 - A))

Cálculo da Complexidade

A Complexidade é calculada de acordo com a seguinte fórmula:

Complexidade = 20 * AC * AU * AV

Cálculo da Pontuação Básica

Para calcular a pontuação, é utilizada a seguinte fórmula sobre os valores atribuídos a cada vulnerabilidade, de acordo com suas características:

Pontuação Básica = (0,6 * Impacto + 0,4 * Complexidade - 1,5 ) * f(Impacto)

O Fator de Impacto, f(Impacto), terá o valor 0 (zero) se o Impacto for igual a zero. Caso contrário, receberá o valor 1,176.

2.1.2        Métricas Temporais

O grupo de métricas temporais é formado por três variáveis: Explorabilidade (EX), o Nível de Remediação (RL) e o Confiança nos Relatórios (RC). A Tabela 2.2 ilustra esses fatores e os seus possíveis valores.

A Explorabilidade indica se é ou não possível explorar a vulnerabilidade. Esse fator pode ser classificado como: Não Comprovada, se não há uma técnica de exploração conhecida; Prova de Conceito, se foi criada uma prova da vulnerabilidade; Funcional, quando há uma técnica de exploração desenvolvida; ou Alta, se há relatos de exploração.

O Nível de Remediação informa se há tratamentos conhecidos para a vulnerabilidade. Esses tratamentos podem ser: uma Correção Oficial do fabricante; uma Correção Temporária fornecida pelo fabricante; um Contorno do Problema; ou Sem Solução disponível.

A Confiança no Relatório reflete o nível de confiança e de credibilidades dos relatórios de divulgação de vulnerabilidade e uma medida da confiança na existência da vulnerabilidade reportada. Essa confiança pode ser representada como Não Confirmada, quando há um único relato; Não Corroborada, quando há vários relatos não oficiais; ou Confirmada, quando é reconhecida pelo próprio fabricante.

Pontuação Temporal

Caso alguma métrica temporal não seja incluída no cálculo, deve ser classificada como Não Definida.

O cálculo do risco temporal é medido pela seguinte fórmula:

Pontuação Temporal = Pontuação Básica * EX * RL * RC

Tabela 2.2: Grupo de Métricas Temporais

Fator	Classificação	Valor
Explorabilidade	Não Comprovada	0,85
	Prova de Conceito	0,90
	Funcional	0,95
	Alta	1,00
	Não Definida	1,00
Nível de Remediação	Correção Oficial	0,87
	Correção Temporária	0,90
	Contorno	0,95
	Sem Solução	1,00
	Não Definida	1,00
Confiança nos Relatórios	Não Confirmada	0,90
	Não Corroborada	0,95
	Confirmada	1,00
	Não Definida	1,00

Fonte: Mitre.org

2.1.3        Métricas Ambientais

Nem todas as vulnerabilidades de software são potencialmente perigosas para um sistema computacional. Para identificar possíveis riscos, é necessário verificar se a tecnologia vulnerável é adotada e quais os possíveis danos que a exploração dessa vulnerabilidade pode causar. As métricas ambientais têm por objetivo calcular o impacto da vulnerabilidade no ambiente da organização. A Tabela 2.3 ilustra as variáveis ambientais e seus pesos.

A primeira métrica ambiental Potencial Dano Colateral (PCD) mede os danos físicos a ativos ou a perda de vidas resultante da exploração da vulnerabilidade. Os danos são classificados em cinco níveis, podendo ser: Nenhum, se não ocorrem danos; Baixo, se há danos físicos, perda leve de lucros ou de produtividade; de Baixo a Médio, com danos físicos, perda de lucros ou de produtividade moderados; de Médio a Alto, se houver danos físicos, perda significativa de lucros ou de produtividade; Alto, quando há a possibilidade de danos físicos, perda catastrófica de lucros ou de produtividade.

A segunda métrica indica a Distribuição dos Alvos (TD) que podem ser afetados, em termos percentuais, no ambiente organizacional, de acordo com a seguinte classificação: Baixo, entre 1% e 25%; Média, entre 26% e 75%; Alta, acima de 75%; e Nenhum, se não houver sistemas suscetíveis à vulnerabilidade ou se eles estão restritos a ambientes muito específicos (por exemplo: laboratórios).

Há ainda outras três métricas, que customizam os cálculos, de acordo com a importância para a organização, dos ativos afetados, em relação aos Requisitos de Segurança. Essa importância é medida em termos do Requisito de Confidencialidade (CR), do Requisito de Integridade (IR) e do Requisito de Disponibilidade (AR). O impacto da perda de cada um dos requisitos pode ser classificado como Baixo, Médio ou Alto.

Tabela 2.3: Grupo de Métricas Ambientais

Fator	Classificação	Valor
Potencial Dano Colateral	Nenhum	0
	Baixo	0,1
	Baixo a Médio	0,3
	Médio a Alto	0,4
	Alto	0,5
	Não Definido	1,0
Distribuição dos Alvos	Nenhum	0
	1% a 25%	0,25
	26% a 75%	0,75
	Acima de 75%	1,0
	Não definida	1,0
Requisitos de Segurança	Baixa	0,5
	Média	1,0
	Alta	1,51
	Não definida	1,0