Segurança no Sistemas de Arquivos Linux



Permissões

Resumo do Artigo Beyond Stack Smashing Recent Advances in Exploiting

Jonathan Pincus é pesquisador sênior da Microsoft Research, e Brandon Baker, engenheiro de segurança de desenvolvimento da Microsoft. Neste artigo, eles descrevem três famílias de ataques derivados do estouro de buffers.

O estouro de buffers ocorre quando um programa tenta ler ou escrever além do limite declarado de um array (o referido buffer). Nas linguagens C e C++ não existe nenhum tipo de checagem de extrapolação de limites, ao contrário do que acontece com as linguagens Pascal, Java e C# por exemplo. O estouro de buffer pode ainda ser caracterizado como estouro de buffer da pilha ou estouro de buffer do heap, dependendo do tipo de memória utilizada – no primeiro caso trata-se de variáveis estáticas, localizadas na pilha de execução, ao passo que no segundo caso trata-se de variáveis dinâmicas, localizadas no heap.

A abordagem tradicional do estouro de buffer é o stack smashing: a modificação do endereço de retorno presente na pilha de execução de maneira a alterar o fluxo de execução do programa. Ao invés de apontar para o retorno, o endereço aponta para código malicioso armazenado em determinado local pelo atacante.

No artigo, os autores apresentam 3 novos tipos de ataques desta natureza, afim de que a compreensão do funcionamento dos ataques leve a melhores estratégias de segurança. A seguir, cada um deles é brevemente apresentado.

Arc injection
Este ataque é orientado a dados. Ao invés de também inserir código executável malicioso para que seja desviado o fluxo de execução até ele, um atacante pode apenas fornecer dados tais que quando o programa original operar sobre os mesmos, o objetivo do ataque também será atingido. Um exemplo deste tipo de ataque são comandos de sistema que o programa atacado passa a utilizar para criar novos processos, o que permite a execução arbitrária de código.

Um exemplo deste ataque é o estouro de buffer para desviar o fluxo de execução para uma chamada SYSTEM() presente no código do próprio programa, onde as verificações de integridade dos parâmetros podem ser puladas e o parâmetro é um dado armazenado pelo atacante.

Pointer Subterfuge
Este ataque consiste em alterar o valor de ponteiros. Existem pelo menos quatro versões deste tipo de ataque:

- Function-Pointer Clobbering: Alteração do valor de um ponteiro para um local com código malicioso;

- Data-Pointer Modification: Alteração de locais arbitrários da memória como isca, na expectativa de que tais locais sejam utilizados em alguma atribuição, fazendo com que se obtenha poder também sobre outras áreas da memória que forem fisgadas;

- Exception-Handler Hijacking: Quando um programa lança uma exceção, o Windows examina uma lista encadeada que armazena manipuladores de exceção e invoca um ou mais via ponteiros para o tratamento da exceção. O ataque consiste em alterar tal ponteiro via estouro de buffer, permitindo que ao invés de invocar um manipulador de exceção, o fluxo de execução seja desviado.

- Virtual Pointer (VPTR) Smashing: A maioria dos compiladores C++ implementa funções virtuais através de uma tabela de funções virtuais (VTBL) associada a cada classe. A VTBL é um array de ponteiros para funções utilizados em tempo de execução para implementar o despacho dinâmico. Objetidos individuais apontam para a VTBL apropriada através de ponteiros virtuais (VPTR) armazenado no header do objeto. Substituindo-se o VPTR de um objeto com um ponteiro para código malicioso faz com que o fluxo seja desviado na próxima vez em que uma função virtual for invacada.

Heap Smashing

Ao contrário do que se pensava até recentemente, não são apenas os buffers da pilha de execução vulneráveis a este tipo de ataque. Alocadores de memória dinâmica mantém headers para cada bloco do heap, ligados duplamente em listas encadeadas de blocos alocados e liberados. Tais headers são atualizados a cada operação sobre a memória (alocação e liberação).

Se houverem três blocos de memória contíguos X, Y e Z, e houver estouro de buffer em X de forma que os ponteiros do header de Y sejam modificados, pode ocorrer modificação de uma parte arbitrária da memória quando X, Y e Z forem liberados.

Referência
Pincus, J.; Baker, B. Beyond Stack Smashing: Recent Advances in Exploiting Buffer Overruns. Security & Privacy, IEEE Volume 2, Issue 4, July-Aug. 2004 Page(s): 20 – 27. Disponível em: http://ieeexplore.ieee.org/iel5/9141/29316/01324594.pdf. Acesso em 02 de Junho de 2010.

Reflections on Trusting Trust by Ken Thompson

Ken Thompson recebeu o prêmio Turing pela ACM (Association for Computing Machinery) em 1983 pelo desenvolvimento da teoria de sistemas operacionais e pela implementação do sistema operacional UNIX. O autor se auto-denomina um programador, e em três etapas descreve a criação de um trojan. Um programa que se auto-replica, através de um compilador

Na primeira etapa o autor descreve a criação de um programa que se auto-replique. Na segunda etapa, o autor utiliza o exemplo do compilador C, desenvolvido em liguagem C para demonstrar que existem falhas sobre como compilar em C um novo compilador com instruções diferentes. Haveria inconsistências, uma vez que o compilador original não reconhecerá as novas instruções, o que leva a alterações em mais baixo nível no compilador original, possibilitando que ele seja compilado. Na etapa 3, o autor apresenta a introdução de código malicioso no novo compilador, o qual descompila o comando “login” e o compila novamente para aceitar uma senha mestra, além da senha correta. Se o código malicioso for auto-replicante e atacar o código-fonte de um compilador, é possível utilizar o binário malicioso como original e apagar o código fonte malicioso, não deixando rastros. Desta forma, teríamos um código-fonte limpo e um binário malicioso, que se auto-replicaria a cada compilação.

O autor chega à conclusão de que não se pode confiar em códigos não escritos por você mesmo, não importando o nível de verificação de códigos-fonte podem nos assegurar quando se utiliza códigos não confiáveis. À medida que o nível dos códigos abaixa (compilador, assembler, liguagem de montagem, carregador ou mesmo microcódigo de hardware), mais difícil é a detecção de possíveis “bugs”.

Por fim, o artigo conclui que a segurança fica comprometida quanto mais dependermos de códigos de terceiros. Ken afirma que apenas um código desenvolvido por você mesmo pode ser dito como um código confiável. O autor também enfatiza que o acesso não autorizado a computadores alheios é crime e deve ser levado a sério.

Pontos Principais do Artigo

• Não existe código confiável, exceto o de sua autoria;
• À medida em que o nível dos códigos-fonte diminui, mais difícil é a detecção de código malicioso;
• Ainda no ano de 1984 o autor já alertava sobre as falhas nos códigos penais a respeito de crimes digitais, e ainda alertava sobre a gestação de uma “situação explosiva”.

Referência

[1] Thompson, Ken. Reflections on Trusting Trust.Communications of the ACM, 1984, vol. 27, n. 8, 761-763. Disponível em: http://portal.acm.org/citation.cfm?id=358210.

Criptografia com o uso de curvas elípticas

1. Introdução

Confidencialidade, integridade, autenticidade e não-repúdio são requisitos de segurança desejáveis em sistemas, e a criptografia assimétrica ou de chave pública é uma ferramenta indispensável para prover esses requisitos. 0 método mesmo sendo um pouco lento, é seguro pois utiliza um par de chaves, sendo uma pública e outra privada. A chave privada é conhecida apenas pelo dono da mensagem ao passo que a chave pública é distribuiria livremente para todos. A implementação dos CCE (Criptossistemas de Curvas Elípticas) apresenta alguns desafios, dentre eles o nível de segurança desejada, a qual plataforma a implementação se destina. 0 desempenho da aplicação resultante sofre um grande impacto da escolha feita nesta fase. Este artigo faz um estudo de criptografia com chave pública baseada em curvas elípticas, comparando com outros métodos de criptografia assimétrica e por sua vez com criptografia simétrica, apresentando ao final um exemplo de criptografia com curvas elípticas. (MENDES,2007)

2. Origem

De forma independente, em 1985, N. Koblitz (KOBLITZ, 1987) e V. Miller (MILLER,1986), propuseram utilizar o grupo de pontos de uma curva elíptica sobre um corpo finito para implementar criptossistemas de chave pública. Esses sistemas,denominados criptossistemas de curvas elípticas (CCE), têm sua segurança baseada na suposta intratabilidade do problema do logaritmo discreto no grupo de pontos de uma curva elíptica (PLDCE).

Figura 1 - Ilustação de uma Curva Elíptica e a adição de uma EC (BURNETT, 2002)

Nos últimos anos, muitos avanços foram feitos na área dos CCE. 0 melhor algoritmo conhecido para o problema do logaritmo discreto em curvas elípticas é de tempo exponencial (POLLARD,1978). Embora existam alguns ataques (algoritmos de tempo sub-exponencial (MENEZES, OKAMATO e VANSTONE, 1993) e polinomial para certos tipos de curvas elípticas, esses ataques podem ser evitados por meio de testes simples, descritos em vários padrões ïndustriais (ANSl,1999).

O fato de não se conhecer um algoritmo geral de tempo sub-exponencial para o PLDCE, possibilita que parâmetros menores sejam usados nos CCE, relativos aos sistemas baseados no PLD. Por exemplo, NIST - National lnstitute of Standards in Technology (Instituto Nacional de Normas em Tecnologia) recomenda o uso de chaves de 3072 bits nos sistemas baseados no PLD e RSA (Rivest, Shamir, Adleman) para se obter um nível de segurança comparável ao fornecido por um algoritmo de chave simétrica de 128 bits. Entretanto, nos CCE são suficientes chaves de 256 bits para se obter o mesmo nível de segurança.

3. Funcionalidade

Na prática, quando se deseja enviar uma mensagem utilizando o algoritmo ECDH, o remetente da mensagem pega a chave pública do destinatário contendo informações suficientes para gerar seu próprio par de chaves temporários de ECDH.

Tanto o destinatário quanto o remetente possuem um par de chaves relacionadas
com as chaves pública e privada. Desta forma o remetente utiliza a sua chave privada e a chave pública do destinatário para gerar um "ponto secreto na curva", utilizando de alguma forma este ponto secreto como uma chave de sessão. Sabendo que um ponto é uma coordenada (x,y), os dois correspondentes terão que decidir antecipadamente quais bits, a partir deste número, devem ser utilizados como chave. A figura 2 ilustra a combinação de chaves entre o remetente e o destinatário da mensagem para obter um ponto secreto.

Para ler a mensagem, o remetente necessita da chave de sessão, que é obtida através da combinação da sua chave privada com a chave pública temporária do remetente, enviada junto com a mensagem criptografada. Caso um invasor tenha acesso á mensagem criptografada, o mesmo teria que possuir uma das duas chaves privadas, pois o fato de conhecer as duas chaves públicas não resolve a questão. o algoritmo ECDH se parece com o algoritmo DH, pois ambos combinam chave pública e privada de maneira especial para gerar um segredo compartilhado. A principal diferença está na matemática subjacente, e isso explica o nome Elliptic Curve Diffie-Hellman (BURNETT, 2002).

Figura 2 - Combinação de chaves entre o remetente e destinatário de uma mensagem para obter um ponto secreto.

4. Vantagens

Algumas vantagens que resultam do fato de se usar pequenos parâmetros nos CCE incluem velocidade, chaves e certificados pequenos. Para certas aplicações, onde a capacidade de processamento, a potência computacional, o espaço de armazenamento e a banda-passante estejam limitados, os CCE superam outros sistemas de chave pública.

Por todas estas razões, os CCE têm tido crescente aceitação,nos setores industriais, como alternativa aos ja estabelecidos RSA protocolo de troca de chaves Diffie-Hellman e DSA.

A criptografia de chave pública, nos últimos anos, se converteu numa das tecnologias básicas para a construção de aplicações muito sensíveis à segurança,tais como correio eletrônico, eleições eletrônicas e comércio eletrônico.

5. Desvantagens

É um método lento porque os algoritmos, pela sua natureza matemática,são computacionalmente intensivos;

Requer uma autoridade de certificação, para que se possa garantir a identidade e ter chaves públicas confiáveis.

6. Considerações Finais


As curvas elípticas é uma opção para aplicações em ambientes computacionais limitados como telefones celulares, cartões inteligentes, pagers entre outros.

A criptografia simétrica não é substituída pela assimétrica. 0 importante é reconhecer e identificar as limitações de cada método, de forma a usá-los de uma maneira complementar para prover a segurança necessária às partes envolvidas, por causa da sua limitação de processamento.

7. Bibliográfia

BURNETT,1997 BURNETT, Steve, PAINE, Stephe, Criptografia e Segurança: O Guia Oficial RSA, Rio de Janeiro, Campus, 2002
KOBLITZ, 1987 Koblitz, N. Elliptic curve cryptosystems, Mathematics of Computation, 48 pp 203-209, 1987
MENDES,2007 Mendes, Aline Venoso, Estudo da Criptografia com chave pública baseadas com chave elípticas, Dissertação de Mestrado, Universidades de Montes Claros,2007
MENEZES,1993 MENEZES, OKAMOTO, T. E VANSTONE. Reducing elliptic curve logarithms to logarithms in a finite fiel. IEEE Transactions on Information Theory, 39 pp 1639-1946, 1993
MILLER,1986 Miller, V., Uses of elliptic curves in cryptography, Advances in Cryptology proceedings of Crypto 85, LNCS pp.417-426 New York. Springer –Verlag,1986
POLLARD,1978 POLLARD, J. Monte Carlo methods for índex computation mod p, Mathematics of Computation, 32, PP 918-924, 1978

Especificação Formal de Protocolos de Segurança

1.INTRODUÇÂO

No presente artigo iremos falar sobre Especificação Formal de Protocolos de Segurança, que visa através da utilização de métodos formais, os quais são um conjunto de técnicas suportadas pela lógica matemática.

A importância do estudo do tema se dá por causa dos serviços realizados pela Internet como compras on-line (e-commerce), transações bancárias, ou mesmo no cotidiano dos brasileiros como a utilização de cartões como MIFARE (PHILIPS, 2010) utilizado em aplicações de sistema de bilhetagem eletrônica como o sistema BOM (Bilhete de Ônibus Metropolitano), cartões de ponto, cartões de crédito, supermercado, estacionamento e outras aplicações, necessitam de um protocolo confiável de comunicação para trafegar os dados com o máximo de segurança. Essas tecnologias facilitam a vida dos seus operadores.

Em contrapartida há um aumento no número de crimes relacionados às telecomunicações intitulados por alguns autores como crimes modernos (ZANIOLO,2007). Por isso, empresas, áreas governamentais, acadêmicas e militares sentem-se vulneráveis quando a segurança das informações é ignorada. Nas redes de comunicação as mensagens são trocadas entre as entidades e como o ambiente móvel é mais suscetível a ataques, já que usam o ar como meio de transmissão, qualquer um com um receptor apropriado pode interceptar as mensagens sem ser detectado. Expondo informações importantes, como senhas e documentos, a não ser que estejam protegidas de alguma forma.

Para garantir a segurança das informações foram desenvolvidos vários protocolos que utilizam técnicas de criptografia para a implementação de serviços de segurança tais como sigilo do conteúdo das mensagens e da identidade do usuário/entidade, autenticação dos participantes na comunicação, integridade dos dados e não-repúdio (SCHNEIER, 1996).

Porém, se o protocolo criptográfico não for projetado corretamente proporcionará a um intruso a oportunidade de ataque por meio dos seguintes processos: substituição, exclusão, alteração ou criação de mensagens, ou pelo ataque aos algoritmos criptográficos utilizados. Por isso, vários métodos formais têm sido propostos a fim de analisar e projetar protocolos criptográficos.

O principal objetivo deste artigo é mostrar para a área acadêmica e comercial a importância do emprego de métodos formais no desenvolvimento de protocolos criptográficos.

O artigo está dividido da seguinte forma: a seção 2 apresenta os Riscos de Senha; na seção 3 são mencionados os tipos de métodos formais encontrados na literatura; na seção 4 é realizada a análise formal de três protocolos de autenticação do ambiente celular (GSM, CDPD e UMTS). E, finalmente, na seção 5 são feitas as considerações finais.

2. RISCO DA SENHA


As senhas são ainda a base sobre os quais muitos sistemas da informação atribuem sua segurança, porque é o principal mecanismo usado para autenticar usuários humanos aos sistemas informáticos. Na forma de PINs, eles também são usados em muitos sistemas embarcados, a partir de máquinas de dinheiro através de sistemas móveis. Eles levantam muitos problemas, tais como a dificuldade das pessoas têm em escolher senhas difíceis de adivinhar, ou lembrar senhas geradas aleatoriamente pelo sistema.

Segundo (Anderson,2001) considera as limitações dos sistemas embarcados que utilizam senhas. A típica aplicação é o controle remoto usado para abrir a garagem ou para desbloquear as portas dos automóveis fabricados até meados da década de 1990. Esses controles remotos primitivos apenas transmitem seu número de série de 16 bits, que também atua como senha.

Um ataque que se tornou comum era usar um grabber "um dispositivo que gravaria um código e jogá-lo novamente mais tarde”. Esses dispositivos, chegou por volta de 1995 em Taiwan, que permitiam ladrões que espreitavam em um estacionamentos para gravar o sinal usado para bloquear uma porta do carro e, em seguida, jogá-lo novamente para desbloquear o carro uma vez que o proprietário havia deixado.

Uma solução na época foi usar códigos separados para bloquear e desbloquear. Mas isso ainda não era o ideal. Primeiro, o ladrão podia esperar fora do estabelecimento de sua casa e gravar o código de desbloqueio. Em segundo lugar, senhas de 16 bits são muito pequenas e fáceis de serem descobertas por grabber. Em meados da década de 1990, surgiram dispositivos que podiam tentar todos os códigos possíveis, um após o outro. Este código poderia ser descoberto, em média, cerca de 215 países, que em 10 combinações, levaria menos de uma hora para serem descobertos.

Um ladrão que atua em um estacionamento com uma centena de veículos, poderá ser recompensado em menos de um minuto com um carro piscando suas luzes.

3. UTILIZANDO UM CANAL SEGURO

Supondo que para transmissão de uma senha seja transmitida em um canal de comunicação seguro. Para canais inseguros e necessários o compartilhamento de chaves.

Vamos estudar pelo caso proposto: Supondo que em um ônibus utiliza-se um sistema de bilhetagem eletrônico através de cartões, onde cada passageiro possua um cartão que irradia para um leitor o número da identificação e a identificação criptografada. O leitor e o cartão possuem chaves em comum. Em notação de protocolos temos:


C -> L: C {C}kcs

onde:

C -> É o cartão
L -> É o leitor

{C}kcs -> chave que sifra o código do cartão. Essa chave é comum para C e L (cartão e Leitora)

O caso em tela tem alguns problemas pois o intruso pode capturar a irradiação da transação e simplesmente repetir essa irradiação. Uma forma para previnir esse tipo de ataque é introduzir um nonce (number used once – Numero usado uma só vez). Neste caso a notação de protocolos fica:

C ->L : C, {C,N}kcs


Onde N pode ser um número aleatório ou seqüencial.

No caso apresentado manda C, manda C e N. O número N tem que ser conhecido por C e S, de tal forma se alguém tentar repetir ele não tem o nunce. É o que o token de banco faz, o nunce e um número aleatório gerado por C e N. L tem que guardar um histórico de nunce. Isso pode ser problemático pois no caso de um erro de comunicação um lado incrementa e outro não ira perder a referencia.

Desafio e Resposta (Challenge – response) Neste caso o NONCE e gerado aleatoriamente pelo servidor e nenhum dos dois atores precisam armazenar estados.


L -> C:N

C ->L: C {C,N}kCs


Onde:

L : leitora

C: Cartão N: numero do Nonce

KCS -> chave de sifra.

Supondo que o cartão passa pelo leitor e recebe um nonce que vai ler L. L recebe C,N cifrado com kCs. Supondo que o desafio seja a função x+1, ou seja se o cartão manda o numero 5 o leitor retorna o número 6 então ele respondeu ao desafio, junto com a chave C, S.
ATAQUE MAN-IN-THE-MIDDLE


Este ataque consiste em um ataque que via um nonce do servidor para o cartão de outro passageiro e retransmite a resposta deste cartão para o servidor.




1. S-> M: N
2. M ->C: N
3. C-> M: C,{C,N}KCS
4. M -> S: C, ,{C,N}KCS


Dado os protocolo acima iremos explicar passo a passo:

1. Um dispositivo criado M ( dispositivo do invasor ) capta o nunce gerado do servidor

2. Passa o nunce gerado para um outro cartão.

3. O cartão responde para o dispositivo do invasor a chave do cartão , o nunce sifrado com a chave KCS.

4. M envia os dados capturados no passo 3 e envia para o servidor.


4. MÉTODOS FORMAIS

Os protocolos estão sujeitos a ocorrência de erros em qualquer fase de seu projeto (especificação, construção e verificação). Por isso não é incomum que sejam descobertas falhas em protocolos publicados e utilizados por vários anos. Como exemplo, protocolo de (NEEDHAM e SCHROEDER, 1978) foi utilizado durante 4 anos até que (DENNING e SACCO, 1981) demonstraram que ele estava sujeito ao ataque do homem no meio e propuseram um protocolo alternativo. Porém, em 1994 Abadi e Needham demonstraram que este protocolo também possuía falhas (BUTTYÁN, 1999).


O emprego de métodos formais na área de criptografia é recente. Grande parte dos trabalhos nesta área são desenvolvidos na década de 90 (MEADOWS, 1995). Estes métodos permitem fazer uma análise completa do protocolo criptográfico e sua função principal é especificar se os objetivos propostos pelos autores são alcançados. Muitas vezes um protocolo é construído para realizar a distribuição segura de uma chave de sessão e quando analisado verifica-se que essa meta não é atingida.


Existem 4 abordagens diferentes para a análise de protocolos criptográficos (RUBIN e HONEYMAN,1993), (MEADOWS, 2000) e (GRITZALIS, SPINELLIS e GEORGIADIS, 1999). A primeira é a menos popular enquanto que a terceira é a mais utilizada:

1. uso de linguagens de especificação e ferramentas de verificação: o objetivo principal desta abordagem é tratar um protocolo criptográfico como qualquer
programa e tentar provar sua corretude. O principal problema é que estes métodos não são específicos para a análise de protocolos de segurança. Dentre os métodos podem ser destacados: LOTOS (Language of Temporal Ordering Specification) e Ina Jo.(VARADHARAJAN, 1990) utilizou LOTOS para analisar alguns protocolos criptográficos, porém não conseguiu demonstrar qualquer resultado. O autor concluiu que essa ferramenta não era adequada para a análise de segurança.


2. uso de sistemas especialistas: nestes métodos a maioria dos protocolos são modelados como máquinas de estado. São exemplos: Interrogator e NRL Protocol Analyzer. Neles o projetista especifica um estado inseguro e através de pesquisas exaustivas, tenta construir um caminho para este estado. Eles obtiveram mais êxito do que os anteriores, porém, possuem como desvantagem a grande quantidade de possíveis eventos que devem ser examinados;

3. uso de modelos baseados em lógicas modais: estas abordagens analisam os conceitos de crença e de conhecimento dos participantes do protocolo criptográfico. São utilizados principalmente para os protocolos de autenticação e de distribuição de chaves. Dentre eles pode-se destacar: as lógicas BAN e GNY. Apesar de serem mais simples e intuitivas do que as outras abordagens, são eficazes. O artigo da lógica BAN encontrou vários erros e redundâncias em protocolos bastante utilizados. Porém, o analista deve ter cuidado, pois suposições incorretas podem conduzir a erros na análise;


4. uso de sistemas algébricos: nesta abordagem o protocolo criptográfico é modelado como um sistema algébrico, associando um estado como se fosse o conhecimento do participante. São complementares aos métodos de lógica modal, pois também realizam uma formalização de problemas por hipóteses e nas propriedades de autenticação. O primeiro trabalho nesta área é o de Dolev-Yao e os outros trabalhos desenvolvidos são versões estendidas desse modelo. O problema desses sistemas é que são restritos para a análise da maioria dos protocolos. Só podem ser utilizados para descobrir fraquezas de segredos e não permitem que os participantes se lembrem de informações de um estado para o próximo.

O custo-benefício em utilizar uma dessas abordagens, antes de publicar o protocolo, é melhor do que ter que fazer alterações posteriores, já que é mais barato usar os métodos no desenvolvimento do protocolo do que fazer o seu replanejamento.

4.1. LÓGICA BAN


A lógica BAN foi desenvolvida por Burrows, Abadi e Needham (por isso o nome) em 1989. É a primeira lógica a analisar formalmente os protocolos criptográficos, principalmente os de autenticação e distribuição de chaves (BURROWS, ABADI e NEEDHAM, 1990). É a lógica mais popular na literatura para a análise de crenças e de conhecimento entre os participantes dos protocolos criptográficos. Apesar das críticas recebidas ela encontrou erros em
vários protocolos, como o de Needham-Schroeder, CCITT X.509, Yahalom e Kerberos. A lógica BAN também é utilizada como validação dos protocolos propostos em (AZIZ e DIFFIE, 1994) que desenvolveram um protocolo de autenticação para o ambiente celular e em (MYRVANG, 2000) que desenvolveu um protocolo de autenticação para redes locais sem fio.

Outras lógicas começaram a ser desenvolvidas estendendo ou aplicando os mesmos conceitos da lógica BAN. A de maior sucesso entre elas é a GNY (GONG, NEEDHAM e YAHALOM, 1990).

A lógica GNY introduziu novos conceitos, como reconhecimento e posse de fórmulas e a expressão “não originada-aqui” que permite aos participantes detectar mensagens que foram enviadas em sessões anteriores.Porém, a lógica GNY é mais complexa, possui muitas regras (mais de 50) que devem ser aplicadas em cada fase do protocolo e mais difícil de ser utilizada. Alguns autores consideram-na impraticável A complexidade é o maior problema das lógicas estendidas da BAN.

Na dissertação de mestrado (SANTOS, 2002) foi realizada uma comparação entre as duas lógicas, chegando-se à conclusão que a lógica GNY, por conter muitas regras, pode tornar a análise mais suscetível a erros e redundâncias. A lógica BAN também consegue chegar nos mesmos resultados finais, além disso, ela é mais simples e mais fácil de aplicar e de empregar seus postulados. Por estes motivos, a autora decidiu utilizar a lógica BAN, para analisar três importantes protocolos de autenticação da rede celular: GSM (Global System for Mobile Communications), CDPD (Cellular Digital Packet Data) e UMTS (Universal Mobile Telecommunications System). Como a lógica BAN possui muitos símbolos, a autora utilizou uma versão mais intuitiva que será mantida neste trabalho. Por exemplo, a expressão: P Q #(X) é substituida por P acredita Q disse novo(X) (lê-se: P acredita que Q, há algum tempo, disse que X é nova).

As principais expressões da lógica BAN são:


1. P acredita X: o participante P acredita na fórmula X ou está autorizado a acreditar em X, isso significa que P pode agir como se X fosse verdadeira;
2. P recebeu X: P recebeu uma mensagem contendo X e P pode obter X da mensagem (normalmente depois de algum deciframento);
3. P disse X: P uma vez disse X. O participante P, há algum tempo, enviou uma mensagem contendo a fórmula X;
4. P controla X: P tem jurisdição sobre X. O participante P é uma autoridade sobre X e deve ser confiado deste modo;
5. novo(X): (lê-se “X é nova”) a fórmula X é nova, ou seja, a fórmula X foi usada numa mensagem anterior à execução atual do protocolo. Os identificadores são gerados com a finalidade de serem novos;
6. P k Q: (lê-se “k é uma chave satisfatória para P e Q”). A chave k nunca será descoberta por qualquer participante, exceto por P, Q ou por alguém em quem eles confiam;
7. {X}K : fórmula X cifrada com a chave K. As mensagens cifradas somente são legíveis e verificáveis pelo possuidor da chave.
A notação abaixo é usada numa troca de mensagem:

Mi A -> B: {X}k

onde i é a iésima mensagem do protocolo: A envia X cifrada com a chave k para B. Em todas estas expressões, X é uma mensagem ou uma fórmula.


5. Considerações Finais

Este trabalho mostrou que é importante a especificação de protocolos e a utilização de métodos formais e qual a importância de um canal seguro e do risco de senhas que podem ser descoberto através de dispositivos eletrônicos construídos para este fim.
A especificação formal de protocolos de segurança propiciam um canal seguro para a comunicação de informações utilizando os métodos formais, porém esta especificação deve ser testada exaustivamente para detecção de falhas antes de serem implementadas.
Este trabalho fez um levantamento na literatura o qual podemos constatar a importância de uma especificação de protocolo, pois várias aplicações poderão utilizar garantindo a privacidade dos dados.

6. Referências Bibliográficas

ANDERSON, 2001 ANDERSON, R. “Security Engineering: A Guide to Building Dependable Distributed Systems”. Wiley, 2001.

AZIZ e DIFFIE, 1994 AZIZ, Ashar e DIFFIE, Whitfield. Privacy and
Authentication for Wireless Local Area Networks.

IEEE Personal Communications. pp. 25-31.1994.
BUTTYAN, 1999 BUTTYÁN, Levente. Formal methods in the design of cryptographic Protocols. http://citeseer.nj.nec.com/context/1960161/0. Technical, Report SSC/. Novembro 1999.
.
DENNING e SACCO, 1981 DENNING, Dorothy E. e SACCO, Giovanni Maria.
Timestamps in Key Distribution Protocols. Communications of the ACM, vol. 24, no 8 pp. 533-536.Agosto 1981.

GRITZALIS, SPINELLIS e GEORGIADIS, 1999 GRITZALIS, S., SPINELLIS, D. e GEORGIADIS, P.
Security protocols over open networks and distributed systems: formal methods for their analysis, design and verification. Computer Communications, vol. 22, no 8, pp. 697-709. Maio 1999.

MAIFARE,2010 http://www.a3m.eu/pt/Cartoes-contactless-Mifare.html, Acessado em Março de 2010

MEADOWS, 1995 MEADOWS, Catherine. Formal verification of
cryptographic protocols: A survey. ASIACRYPT’94 ,
133-150, http://citeseer.nj.nec.com/134868.html. 1995.

MEADOWS, 2000 MEADOWS, Catherine. Open Issues in Formal Methods
for Cryptographic Protocol Analysis. DISCEX 2000:,
v. 1, p. 237-250. IEEE Computer Society Press. Janeiro
2000.

MYRVANG,2000 MYRVANG, Per Harald. An Infrastructure for
Authentication, Authorization and Delegation. 2000.
Tese, Universidade de TromsÆ, Faculdade de Ciência,
www.cs.uit.no/studier/gradseksamen/myrvang.html

NEEDHAM e SCHROEDER, 1978 NEEDHAM, R. M. e SCHROEDER, M. D. Using
Encryption for Authentication in Large Networks of
Computers. Communications of the ACM, 21 p 12.

RUBIN e HONEYMAN,1993 RUBIN, Aviel D. e HONEYMAN, Peter. Formal Methods for the Analysis of Authentication Protocols. Technical Report CITI TR 93-7. Outubro 1993. www.citi.umich.edu/u/honey/papers.html

SANTOS,2002 SANTOS, Myrna C. M dos. Análise Formal de Protocolos de Autenticação para Redes Celulares. Dissertação de Mestrado. Instituto Militar de Engenharia, 2002.

SCHNEIDER,1996 SCHNEIER, Bruce. Applied Cryptography – Protocols,
Algorithms and Source Code in C – 2 a Edição. John Wiley & Sons, Inc. 1996. ISBN 0-471-12845-7.

VARADHARAJAN, 1990 VARADHARAJAN, V. Use a formal description technique in the specification of authentication protocols. Computer Standards and Interfaces, vol. 9,
pp. 203-215. 1990

ZANIOLO,2007 Zaniolo, Pedro Augusto, Crimes Modernos o Impacto da Tecnologia no Direito, Jurua Editora, 2007

Organização com CMMI nível 2

1. CMMI Nível 2

No nível de maturidade 2, uma organização atingiu todas as metas específicas e genéricas das áreas de processos do nível 2 de maturidade. Em outras palavras, os projetos da organização
asseguraram que os requisitos são gerenciados e que os processos são planejados, executados, medidos e controlados.
A disciplina dos processos refletida pelo nível 2 de maturidade ajuda a assegurar que as práticas existentes são mantidas em momentos de stress. Quando estas práticas existem, os projetos são executados e gerenciados de acordo com seus planos documentados.
No nível 2 de maturidade, os requisitos, processos, produtos de trabalho e serviços são gerenciados. A situação dos produtos de trabalho e a entrega dos serviços são visíveis para o gerenciamento em pontos definidos (por exemplo, nos milestones principais e no momento em que as principais tarefas são completadas).
Compromissos são estabelecidos entre os stakeholders relevantes e são revistos conforme necessário. Os produtos de trabalho são revisados com os stakeholders e controlados. Os produtos de trabalho e serviços satisfazem seus requisitos, padrões e objetivos definidos

• As políticas e procedimentos para GERENCIAR o desenvolvimento do software estão definidas e são obedecidas.
• O planejamento de novos projetos é baseado na experiência anterior em projetos semelhantes, de maneira formalizada e não intuitiva.
• Os projetos usam processos que são definidos, documentados, usados, disseminados, medidos, fiscalizados e com rotinas de melhoria
• Os compromissos são assumidos com bases realistas na experiência acumulada e nos requisitos documentados
  
• O desenvolvimento é acompanhado e os planos são revisados de maneira regular quanto aos prazos, custos, estimativas e funcionalidade
• Existem mecanismos formais para a correção de desvios
• A gestão de requisitos formalizada permite um controle do relacionamento com o cliente e
  assegura que o desenvolvimento está obedecendo às suas expectativas
• O relacionamento com eventuais fornecedores subcontratados é controlado e gerenciado
  formalmente
• Toda a definição e estabelecimento dos processos, no nível 2, é feita por projeto, não há necessidade de padronização na organização
• Existe uma clara visibilidade e controle de todos os aspectos GERENCIAIS do desenvolvimento em toda a cadeia gerencial
• Os processos podem ser repetidos com resultados previsíveis
  
• Os processos afetados são puramente gerenciais (não técnicos) e pertencem aos projetos, e não às pessoas

2. Papéis e responsabilidades para os diferentes processos.

A seção seguinte contém todas as áreas de processos que pertencem ao nível de maturidade 2. As áreas de processos do nível de maturidade 2 do CMMI são:

• Gerenciamento de Requisitos (Requirements Management) -REQM
  
• Planejamento do Projeto (Project Planning) - PP
  
• Monitoramento e Controle do Projeto (Project Monitoring and Control) - PMC
  
• Gerenciamento de Acordos com Fornecedores (Supplier Agreement Management) - SAM
  
• Medições e Análises (Measurement and Analysis) - MA
  
• Garantia da Qualidade do Processo e do Produto (Process and Product Quality Assurance) -PPQA
  
• Gerenciamento de Configurações (Configuration Management) - CM
  

Abaixo estão relacionado os processos exigidos no CMMI Nível 2 para cada profissional da organização da área de TI e suas responsabilidades.

Figura 1: Profissionais de TI relacionado

Engenheiro de Processos: O papel engenheiro de processo é responsável pelo processo de desenvolvimento de software. Isso inclui configurar o processo antes da inicialização do projeto e aprimorar o processo regularmente durante o esforço de desenvolvimento. Uma pessoa que atua como engenheiro de processo deve ter vasto conhecimento do desenvolvimento de software. É fundamental que uma pessoa que desempenha este papel tenha boas habilidades de comunicação.

Figura 2 - Artefatos gerados pelo Engenheiro de Processos

Principais Artefatos a Serem Produzidos.

• Avaliação da Organização de Desenvolvimento: A Avaliação da Organização de Desenvolvimento descreve o status atual da empresa de software em termos de atuais processos, ferramentas, competências e atitudes das pessoas, clientes, concorrentes, tendências técnicas, problemas e áreas de melhoria.
• Caso de desenvolvimento:O Caso de Desenvolvimento descreve o processo de desenvolvimento escolhido para ser seguido no projeto.
• Templates Especificos de Projeto: São os templates para relatórios e artefatos de documento usados no projeto. Podem existir também templates para modelos e elementos de modelagem, como o modelo de design.

Gerente de Projeto: O papel gerente de projeto aloca recursos, ajusta as prioridades, coordena interações com clientes e usuários e geralmente mantém a equipe do projeto concentrada na meta certa. O gerente de projeto também estabelece um conjunto de práticas que garantem a integridade e a qualidade dos artefatos do projeto.

As habilidades e a experiência necessárias para desempenhar o papel Gerente de Projeto dependem do tamanho e da complexidade técnica e de gerenciamento do projeto, porém, em graus variados. Para desempenhar o papel Gerente de Projeto conforme definido pelo Rational Unified Process (RUP), você deve:

• ter experiência no domínio do aplicativo e no desenvolvimento de software
• ter habilidades de análise e gerenciamento de riscos, estimativa, planejamento e análise de decisões
• ter habilidades de apresentação, comunicação e negociação
• mostrar capacidade de liderança e de desenvolver o espírito de equipe
• ter boa capacidade de gerenciamento de tempo e triagem e um histórico de decisões acertadas tomadas rapidamente em situações de stress
• ter boas habilidades de relacionamento interpessoal e mostrar opinião sensata na seleção de pessoal
• ser objetivo na definição e avaliação do trabalho, assegurando a participação de toda a equipe
• compartilhar a visão de arquitetura, mas ser pragmático no escopo e na implementação de planos e completamente honesto na avaliação dos resultados
• ter como objetivo agregar valor ao cliente na forma de software que atenda (ou ultrapasse) às expectativas do cliente.

Figura 3 - Artefatos gerados pelo Gerente de Projeto

Principais artefatos a serem produzidos.

• Avaliação de Interação: captura o resultado de uma iteração, até que ponto os critérios de avaliação foram respeitados, as lições aprendidas e as mudanças que devem ser feitas.
• Plano de Interação: Um conjunto de atividades e tarefas divididas por seqüências de tempo, com recursos atribuídos e dependências de tarefas, para a iteração; um plano sofisticado.
• Caso de Negócio: fornece as informações necessárias do ponto de vista de um negócio, para determinar se vale ou não a pena investir no projeto.Para um produto de software comercial, o Caso de Negócio deve incluir um conjunto de suposições sobre o projeto e a ordem de importância do retorno do investimento (ROI) se essas suposições forem verdadeiras. Por exemplo, o retorno do investimento terá importância cinco, se concluído em um ano, dois, se concluído em dois anos, e um número negativo, após esse tempo. Essas suposições são verificadas novamente no fim da fase de Elaboração, quando o escopo e o plano estiverem definidos com mais exatidão.
• Plano de Garantia de Qualidade é um artefato que oferece uma visão clara de como a qualidade do produto, do artefato e do processo será garantida. Ele contém o Plano de Revisão e Auditoria e faz referência a uma série de outros artefatos desenvolvidos durante a fase de Iniciação. Ele é mantido no decorrer do projeto.
• Plano de Desenvolvimento de Software é um artefato composto e abrangente que reúne todas as informações necessárias ao gerenciamento do projeto. Ele inclui vários artefatos separados, desenvolvidos durante a Fase de Iniciação, e é mantido durante todo o projeto.
• Avaliação de Status: Um dos objetivos do processo é assegurar que as expectativas de todas as partes estejam sincronizadas e consistentes. A Avaliação de Status periódica fornece um mecanismo que permite gerenciar as expectativas de cada pessoa durante o ciclo de vida do projeto.
• Ordem de trabalho: é o meio pelo qual o Gerente de Projeto comunica à equipe responsável o que deve ser feito e quando. A ordem passa a ser um contrato interno entre o Gerente de Projeto e aqueles que têm a responsabilidade de cumpri-lo.
  

Principais Repositórios de dados e documentos a serem utilizados pelo projeto

• Métricas de Projeto: O artefato de métricas de projeto é o repositório ativo de dados de métricas do projeto. Ele contém as métricas mais atuais de produto, processo, recursos e projeto no nível primitivo e derivado

Gerente de Controle de Mudanças: O papel gerente de controle de mudança supervisiona o processo de controle de mudanças. Normalmente, este papel é desempenhado por um Comitê de Controle de Configuração (ou Mudança) (CCB), formado por representantes de todas as partes interessadas, incluindo clientes, desenvolvedores e usuários. Em projetos pequenos, um único membro da equipe, como o gerente de projeto ou o arquiteto de software, pode desempenhar esse papel.

Figura 4: Artefatos produzidos pelo gerente de controle de mudanças

Principais artefatos a serem produzidos

• Solicitação de Mudanças: As mudanças nos artefatos de desenvolvimento são propostas através de Solicitações de Mudança (CRs). As Solicitações de Mudança são usadas para documentar e controlar defeitos, solicitações de melhorias e qualquer outro tipo de solicitação de mudança no produto. A vantagem das CRs é que elas fornecem um registro das decisões e, devido a seu processo de avaliação, garantem que os impactos das mudanças sejam entendidos no projeto.

Gerente de Configuração: Disponibiliza o ambiente e a infra-estrutura geral de Gerenciamento de Configuração (CM) para a equipe de desenvolvimento do produto. A função de CM oferece suporte à atividade de desenvolvimento de produtos para que os desenvolvedores e integradores tenham espaços de trabalho adequados para criar e testar seus trabalhos e, dessa forma, permite que todos os artefatos fiquem disponíveis para inclusão na unidade de implantação, conforme necessário. O gerente de configuração também deve assegurar que o ambiente de CM facilite a revisão do produto e as atividades de controle de mudanças e defeitos. O gerente de configuração também é responsável por redigir o Plano CM e relatar estatísticas de andamento com base nas solicitações de mudança.

Figura 5 - Artefatos e repósitorios de responsabilidade do Gerente de Configuração

• Plano CM: O Plano de Gerenciamento de Configuração (CM) descreve todas as atividades do Gerenciamento de Controle de Configuração e Mudança (CCM) que serão executadas durante o ciclo de vida do produto ou do projeto. Ele detalha o cronograma de atividades, as responsabilidades atribuídas e os recursos necessários, como equipes, ferramentas e computadores.
• Registro de Auditoria de Configuração: identifica uma baseline, qualquer artefato necessário ausente e requisitos reprovados ou testados de forma incompleta.

Principais Repositórios de dados e documentos a serem utilizados pelo projeto

• Repositório de Projeto:Local que fica armazenado todas as mudanças de configuração do projeto

Revisor do Projeto: O papel revisor do projeto é responsável por avaliar os artefatos de planejamento e de avaliação do projeto nos principais pontos de revisão do ciclo de vida do projeto. Esses eventos de revisão são importantes porque marcam pontos nos quais o projeto pode ser cancelado se o planejamento for inadequado ou se o andamento se mostrar intoleravelmente improdutivo.

Figura 6 - Artefatos produzidos pelo revisor de projetos

Principais artefatos a serem produzidos

• Registro de revisão: é criado para capturar os resultados da revisão de um artefato de projeto.

Gerente de Teste: tem a responsabilidade geral pelo êxito do esforço de teste. O papel envolve defesa da qualidade e dos testes, planejamento e gerenciamento de recursos e resolução de problemas que representam um obstáculo para o esforço de teste. Isso inclui:

• Negociar a finalidade e os produtos liberados do esforço de teste
• Assegurar o planejamento e o gerenciamento apropriados dos recursos de teste
• Avaliar o andamento e a eficácia do esforço de teste
• Defender o nível apropriado de qualidade mediante a correção de Defeitos importantes
• Defender um nível apropriado de enfoque na testabilidade durante o processo de desenvolvimento de software

Figura 7 - Gerente de Testes

Principais artefatos a serem produzidos

• Lista de problemas: A Lista de Problemas fornece ao Gerente de Projeto uma maneira de registrar e acompanhar problemas, exceções, anormalidades ou outras tarefas incompletas que requeiram atenção em termos de gerenciamento do projeto. Em geral, são itens que não estão sendo acompanhados durante o Gerenciamento de Mudança ou como tarefas no Plano de Projeto ou no Plano de Iteração, embora possam ser provenientes deles.
• Solicitação de Mudanças: As mudanças nos artefatos de desenvolvimento são propostas através de Solicitações de Mudança (CRs). As Solicitações de Mudança são usadas para documentar e controlar defeitos, solicitações de melhorias e qualquer outro tipo de solicitação de mudança no produto. A vantagem das CRs é que elas fornecem um registro das decisões e, devido a seu processo de avaliação, garantem que os impactos das mudanças sejam entendidos no projeto.

Analista de Sistemas: O papel analista de sistemas lidera e coordena a identificação de requisitos e a modelagem de casos de uso, delimitando o sistema e definindo sua funcionalidade; por exemplo, estabelecendo quais são os atores e casos de uso existentes e como eles interagem

Figura 8 - Artefatos e repositórios gerados pelo Analista de Sistemas

Principais Artefatos a serem Produzidos

• Plano de Gerenciamento de Requisitos: Descreve a documentação de requisitos, os tipos de requisitos e seus respectivos atributos de requisitos, especificando as informações e os mecanismos de controle que devem ser coletados e usados para avaliar, relatar e controlar mudanças nos requisitos do produto.
• Guia de modelagem de Casos de Uso: Descreve como modelar os casos de uso.
• Solicitação dos principais envolvidos: Este artefato contém qualquer tipo de solicitação dos principais envolvidos (cliente, usuário final, pessoal de marketing etc.) em relação ao sistema que será desenvolvido. Ele também pode conter referências a qualquer tipo de fonte externa com a qual o sistema deve estar de acordo.
• Visão: A visão que os envolvidos têm do produto a ser desenvolvido, em termos das necessidades e características mais importantes. Por conter uma descrição dos requisitos centrais pretendidos, ela proporciona a base contratual para requisitos técnicos mais detalhados.

Principais Repositórios de dados e documentos a serem utilizados pelo projeto

• Atriburtos de Requisitos: Este artefato contém um repositório de dependências, atributos e requisitos de projeto para controlar a partir de uma perspectiva de gerenciamento de requisitos.

Revisor do Modelo de Negócio: O revisor do modelo de negócios participa das revisões formais do modelo de casos de uso de negócios e do modelo de objetos de negócios.

Figura 9 - Revisor do modelo de negócio

Analista do Processo de Negócio: lidera e coordena a modelagem de casos de uso de negócios, definindo e delimitando a organização que está sendo modelada; por exemplo, estabelecendo quais são os atores de negócios e casos de uso de negócios existentes e como eles interagem.

Figura 10 - Analista do Processo de Negócio

Principais Artefatos a serem Produzidos

• Documento da Arquitetura de negócio: O Documento de Arquitetura de Negócios fornece uma visão geral abrangente do negócio, usando diversas visões arquiteturais diferentes para descrever diferentes aspectos do negócio.
• Guia de modelagem de Negócio: Descreve as diretrizes de modelagem de negócios.
• Avaliação da Organização Alvo: A Avaliação da Organização-alvo descreve o status atual da organização em que o sistema deverá ser implantado. A descrição é em termos de processos atuais, ferramentas, competências de pessoas, atitudes de pessoas, clientes, concorrentes, tendências técnicas, problemas e áreas de melhoria.

Analista de Teste: O papel Analista de Teste é responsável por inicialmente identificar e posteriormente definir os testes necessários, monitorar a abrangência dos testes e avaliar a qualidade geral obtida ao testar os Itens de Teste-alvo. Este papel também envolve a especificação dos Dados de Teste necessários e a avaliação do resultado dos testes conduzidos em cada ciclo de teste. Às vezes, este papel também é denominado Designer de Teste ou considerado parte do papel Testador. Este papel é responsável por:

• Identificar os Itens de Teste-alvo a serem avaliados pelo esforço de teste
• Definir os testes apropriados necessários e quaisquer Dados de Teste associados
• Coletar e gerenciar os Dados de Teste
• Avaliar o resultado de cada ciclo de teste

Figura 11 - Principais artefatos produzidos pelo Analista de Testes

Principais Artefatos a serem Produzidos

• Plano de Testes: A definição das metas e dos objetivos dos testes no escopo da iteração (ou projeto), os itens-alvo, a abordagem adotada, os recursos necessários e os produtos que serão liberados.
• Lista de ideias de teste: É uma lista enumerada de idéias, geralmente formada parcialmente e que identifica possíveis testes úteis a serem conduzidos.
• Caso de testes: É a definição (geralmente formal) de um conjunto específico de inputs de teste, condições de execução e resultados esperados, identificados com a finalidade de avaliar um determinado aspecto de um Item de Teste-alvo.
• Modelo de Analise de Carga de Trabalho: Modelo que identifica um ou mais perfis de carga de trabalho destinados a definir com precisão o estado de interesse de um sistema no qual a avaliação do software e/ou de seu ambiente operacional pode ser realizada. Os perfis de carga de trabalho representam possíveis condições a serem simuladas e comparadas aos Itens de Teste-alvo em uma ou mais Configurações de Ambiente de Teste.

Principais Repositórios de dados e documentos a serem utilizados pelo projeto

• Dados de Testes: A definição (geralmente formal) de um conjunto de valores de entrada de teste que são usados durante a execução de um teste, e os resultados esperados mencionados para fins de comparação durante a execução de um teste.
• Resultados de testes: Um conjunto de informações resumidas determinadas pela análise de um ou mais Registros de Teste e Solicitações de Mudança, que permitem uma avaliação relativamente detalhada da qualidade dos Itens de Teste-alvo e do status de cada esforço de teste. Muitas vezes, é também consultado como um repositório maior de vários Resultados do Teste.

3. Conclusões

A implantação do nível de maturidade CMMI nível 2, exige um time de profissionais com conhecimentos tecnicos e do negócio. Para atingir este nível de maturidade uma serie de artefatos e profissionais são necessários, sendo uma tarefa trabalhosa e que exige que o gerente de projeto mostre os resultados para a alta gerencia para justificar a implementação pois o seu retorno não e imediato.
Uma boa prática e a utilização dos artefados gerados RUP - Rational Unified Process e adapta-los ao CMMI.

Embora RUP cobre 97 por cento das exigências de CMMI para Maturidade Nível 2, e necessário utilizar práticas adicionais. Isso é porque não inclui as duas áreas ed processo do Nível 2 .

O RUP é construído em uma arquitetura extensível que lhe permite adaptar o processo a suas necessidades. Como e o caso dos niveis do CMMI, o qual podemos utilizar os artefatos do RUP
4. Referências

[1] Rational Unified Process, http://www.wthreex.com/rup/index.htm, Acessado em 06/12/2008

[2] CMMI (2008). CMMI Web Site. Disponível em http://www.sei.cmu.edu/cmmi/ . Acesso em: 07/12/08.

[3]Fernandes, Aguinaldo A.; Abreu, Vladimir F. (2008). Implantando a Governança de TI: Estratégia à Gestão dos Processos e Serviços. 2. ed – Rio de Janeiro, Brasport.

[4] A CMMI maturity Level 2 assessment of RUP, Artigo disponivel em http://www.ibm.com/developerworks/rational/library/dec05/grundmann/index.html?S_TACT=105AGX15&S_CMP=EDU

[5] Vivatanavorasin, Vivatanavorasin, A Process Model Designer And Tool Development for Supplient Agreement Management of CMMI: Capability Level 2, Computer Society, 2006

[5] Reaching CMM Levels 2and 3 with the Rational Unified Process, Rational Software White Paper, 2007

Resumo do ITIL e Principais Mudanças da V2 para V3

1. Histórico do Modelo

A ITIL (Information Technology Infrastructure Library) foi desenvolvida pelo (Central Computer and Telecommunications Agency) no final dos anos 80, a de uma encomenda do governo britânico, que não estava satisfeito com o nível de qualidade dos serviços de TI a ele prestado. Neste cenário, foi solicitado o desenvolvimento de uma abordagem de melhores práticas para gerenciar a utililização eficiente e responsável dos recursos de TI, independentemente de fornecedores e aplicável a organizações com necessidades técnicas e de negócio distintas. Em abril de 2001, o CCTA foi incorporado ao OGC47 (Office of Government Commerce) que hoje é o organismo responsável pela evolução e divulgação da ITIL.

2. Objetivos dos modelo

A ITIL é um agrupamento das melhores práticas utilizadas para o gerencia de serviços de tecnologia de informação de alta qualidade, obtidas em consenso após décadas de observação prática, pesquisa e trabalho de profissionais de TI e processamento de dados em todo o mundo. Devido à sua abrangência e profundi­dade, a ITIL tem se firmado continuamente como um padrão mundial de fato para as melhores práticas para o gerenciamento de serviços de TI.

Como um framework, o principal objetivo da ITIL é prover um conjunto de práticas de gerenciamento de serviços de TI testadas e comprovadas no mercado (organiza­das segundo uma lógica de ciclo de vida de serviços), que podem servir como bali­zadoras, tanto para organizações que já possuem operações de TI em andamento e pretendem empreender melhorias, quanto para a criação de novas operações. A adoção das práticas da ITIL pretende levar uma organização a um grau de maturi­dade e qualidade que permita o uso eficaz e eficiente dos seus ativos estratégicos de TI (incluindo sistemas de informação e infra-estrutura de TI), sempre com o foco no alinhamento e na integração com as necessidades dos clientes e usuários.

A ITIL V3 e a sua abordagem de ciclo de vida permite que se tenha uma visão do gerenciamento de serviços pela perspectiva do próprio serviço, em vez de focar em cada processo ou prática por vez. Esta característica realça mais um importante objetivo, que é mensurar e gerenciar o valor que os serviços de TI efetivamente adicionam ao negócio.

3. Visão geral do modelo

A ITIL pode ser considerada uma fonte de boas práticas utilizada pelas organiza­ções para estabelecer e melhorar suas capacitações em gerenciamento de servi­ços, e possui como componentes:

Núcleo da ITIL: Orientações de melhores práticas aplicáveis a todos os tipos de organizações que fornecem serviços para um negócio;

Orientação Complementar à ITIL: Conjunto de publicações complementares destinadas a especializar a implementação e a utilização das práticas do Núcleo para diferentes setores empresariais, tipos de empresas, plataformas tecnológi­cas etc., concebido para ser uma biblioteca dinâmica de conteúdo relacionado, podendo receber contribuições de toda a comunidade.

O Núcleo da ITIL é composto por 5 publicações (conforme mostra a Figura 1 cada uma delas se relacionada a um estágio do ciclo de vida do serviço, contendo orientações para uma abordagem integrada de gerenciamento de serviço.

Figura 1 - O nucleo da ITIL.

Estratégia de Serviço: Orienta sobre como as políticas e processos de gerenciamento de serviço podem ser desenhadas, desenvolvidas e implementada como ativos estratégicos ao longo do ciclo de vida de serviço. Entre os tópicos abordados nesta publicação estão os ativos de serviço, o catálogo de serviço o gerenciamento financeiro, o gerenciamento do portfolio de serviços, o desenvolvimento organizacional, os riscos estratégicos etc.

Desenho de Serviço: Fornece orientação para o desenho e desenvolvimentodos serviços e dos processos de gerenciamento de serviços, detalhando aspectos do gerenciamento do catálogo de serviços, do nível de serviço, da capacidade da disponibilidade, da continuidade, da segurança da informação e dos fornecedores, além de mudanças e melhorias necessárias para manter ou agregar valor aos clientes ao longo do ciclo de vida de serviço.

Transirão de Serviço: Orienta sobre como efetivar a transição de serviços novos e modificados para operações implementadas, detalhando os processos de planejamento e suporte à transição, gerenciamento de mudanças, gerenciamento de mudanças, gerenciamento da configuração e dos ativos de serviço, gerenciamento de liberação,e da distribuição, teste e validação de serviço, avaliação e gerenciamento do conhecimento.

Operação de Serviço: Descreve a fase do ciclo de vida do gerenciamento de serviços que e responsável pelas atividades do dia-a-dia, orientando sobre como garantir a entrega e o suporte a serviços de forma eficiente e eficaz, e detalhando os processos de gerenciamento de eventos, incidentes, problemas, acesso e de execução de requisições.

Melhoria de Servico Continuada: Orienta, através de princípios, práticas e métodos do gerenciamento da qualidade, sobre como fazer sistematicamente melhorias incrementais e de larga escala na qualidade dos serviços, nas metas de eficiência operacional, na continuidade dos serviços etc., com base no modelo PDCA preconizado pela ISO/IEC 20000.

Entre as extensões que a ITIL V3 traz em relação à versão anterior estão estratégias de serviços para modelos de sourcing e de compartilhamento de serviços, abordagens de retorno sobre o investimento (ROI) para serviços, práticas de desenho de serviços, um sistema de gerenciamento de conhecimento sobre os serviços e o gerenciamento de requisições.

Os processos da ITIL V3 encontram-se distribuídos entre os 5 estágios, conforme a Tabela 1 (note que todos os processos de Entrega de Serviços e Suporte a Serviços da versão anterior permanecem no modelo).

Tabela 1 - Processos e Funções do ITIL V3.

4. Diferenças entre o ITIL V2 para V3

Entre as principais mudanças do ITIL V3 esta uma mudança para um serviço de abordagem e orientação mais exigentes. O ITIL V2 delineou o que deveria ser feito para melhorar processos. Já o ITIL V3 explica claramente como é que deve ser feito.

Outro ponto chave ITIL V3 e demonstrar o retorno do investimento para os negócios. Esta foi uma dos pedidos mais freqüentes no setor de consultorias, realizadas como parte do projeto da versão 3.

4.1 Mudanças Estruturais

O ITIL V3 inclui alguma mudanças estruturais significativas. A biblioteca é composta por cinco volumes, estes são:

• Serviço de Estratégia
• Serviço de Designer
• Serviço de Transição
• Serviço de Operação
• Melhoria continua de serviço

A nova biblioteca também inclui informações mais detalhadas sobre os papeis fundamentais, e descreve a responsabilidade de cada um e acompanha com clara incidência a importância da comunicação durante o ciclo de vida. Maior ênfase na utilização de modelos e processos de identificação de todas as partes constituintes e por ultimo a Melhoria Continua de Serviço (CSI), a qual explica a utilização do processo de melhoria e identifica modelos e metricas para apoiar as melhorias.

As revisões feitas no ITIL desde a versão 1 , há duas que se destacam pela sua amplitude: a primeira deu origem à versão dois (ITIL V2) e a segunda deu origem à atual versão três (ITIL V3). A figura 2 mostra um gráfico referente as atuzalições do ITIL.

Figura 2 - Mudança de Versões

Versão 1 (1986-1999): é o ITIL original, baseado em funções de boas práticas, composto por 40 livros, de acordo com a variedade das práticas de TI.

Versão 2 (1999-2006): baseado em processos de boas práticas, é composto por 10 livros. É a versão globalmente aceita como uma estrutura de boas práticas para a gestão de serviços de TI:

• Suporte de Serviços
• Entrega de Serviços
• Planejando para a implementação da gestão de serviços
• Gestão da infra-estrutura TIC
• Perspectivas de negócio Volumes I e II
• Gestão de recursos de software
• Gestão de aplicações
• Gestão de segurança
• ITIL - implementação em pequena escala

Versão 3 (2007-~): baseado em ciclos de vida das boas práticas de serviços, incorpora o melhor do ITIL V1 e V2 e as já testadas melhores práticas para a gestão de serviços de TI. Cinco títulos de ciclo de vida formam o núcleo das práticas do ITIL:

• Estratégias de Serviços
• Desenho de Serviços
• Transição de Serviços
• Operação de Serviços
• Melhoria Contínua de Serviços

5. O esquema do ITIL V3

O núcleo é suportado por uma introdução e orientações de elementos chave, junto com orientações complementares específicas de múltiplos tópicos, e um modelo integrado do ciclo de vida do serviço, incluindo mapas do serviço, mapas organizacionais, e mapas de processos e tecnologias. Esta parte do ITIL V3 foi lançada a partir da Primavera (Européia) de 2007.

A seguir, serão adicionados mais alguns valores, como templates, casos de estudo, sumários de executivos, os quais completarão o portfólio do ITIL V3.

5.1 - O que é "ciclo de vida"

Vamos pensar no exemplo de um serviço qualquer de TI, desde a sua concepção até a sua entrega. A isto chamamos ciclo de vida de gestão do serviço. Há vários indivíduos e várias partes da organização envolvidos no ciclo de vida de um serviço, desde a fase de planejamento, desenho, construção, teste, versionamentos, operação, melhorias, etc. Diferentes níveis da organização e pessoas com papéis diferentes realizam a tomada de decisão, o desenvolvimento e a entrega dos serviços.

Vejamos um exemplo. Se estiver construindo uma casa, trabalhará com uma variedade de indivíduos nas diferentes fases da construção:

Estratégia. Planos do lugar, vendedores e marketing, aprovação da construção…
Desenho. Arquitetos, desenhistas…
Transição. Designers de interior, inspetores verificando a conformidade dos planejamentos, se as coisas estão em conformidade com o regulamento das construções e funcionarão como pretendido, etc.

Cada uma destas equipes desempenhará uma função na construção da casa em vários pontos do processo.

Uma vez construída a casa, ela precisa se manter operacional (através dos recursos tipo eletricistas, bombeiros hidráulicos e serviços como limpeza e pintura). Se a decisão for renovar ou ampliar a casa, então terá que voltar a negociar com os mesmos indivíduos (arquitetos, eletricistas, etc.), mas com vista a melhorar o desenho original e a operação da casa.

A atualização das versões do ITIL reflete a vida dos serviços e apela a um vasto espectro de pessoas que realizam os papéis nos vários estágios no ciclo de vida do serviço.

5.2 - Por que o ciclo de vida ?

Nos últimos 20 anos, a gestão dos serviços de TI mudou dramaticamente. Os conceitos anteriores de negócio e o alinhamento com a TI; a eficácia do valor corrente e os silos de processos operacionais levaram a um pensamento amadurecido sobre a realidade do estado presente da indústria de TI. Aproveitou-se o pensamento existente na V3 e transformou-se a prática anterior em orientações mais relevantes e mais fáceis de utilizar.

Pesquisas confirmaram que existem vários benefícios inerentes à adoção de uma abordagem ao ciclo de vida dos serviços:

• Estabelece a integração das estratégias do negócio com as estratégias dos serviços de TI;
• Permite um desenho detalhado do serviço e do ROI (retorno do investimento);
• Fornece modelos de transição que são desenhados com o propósito de uma variedade de inovações;
• Desmistifica a gestão dos fornecedores;
• Melhora a facilidade de implementação e a gestão de serviços dinâmicos, riscos elevados, e as necessidades de mudança rápida no negócio;
• Melhora a capacidade de medida e de demonstração de valores;
• Identifica os “gatilhos” para a melhoria e a mudança em qualquer ponto do ciclo de vida do serviço;
• Aponta as lacunas e deficiências do ITIL atual.

Foram examinados os desafios enfrentados pela gestão de serviços de TI em todos os níveis e, assim, o ITIL V3 foi desenhado tendo em vista estes desafios, de forma a conseguir as mais elevadas excelências e atender as futuras necessidades da comunidade de gestão de serviços.

5.3 - Evoluções do ITIL versão 2 para a versão 3

Há quatro evoluções importantes identificadas entre a versão 2 para a são elas:

Alinhamento -> Integração

Durante muitos anos, as organizações tem discutido formas de alinhar objetivos empresariais com a TI. Estas discussões observaram que mesmo os negocios e a TI corporativa, compartilhavam a mesma marca, de alguma maneira estavam separados em funções distintas.
A linha entre os processos empresariais e o apoio da tecnologia tem um ponto em que não ha uma necessidade de separá-los. E o caso de uma gestão financeira, apoiando os seus processos de negócio e tecnologia são tão inter-dependentes que se tornaram inseparáveis. Como resultado desta percepção crescente, o termo esta sendo substituido de alinhamento com o conceito de integração.

Alterar Valor de Gestão -> Integração Service Desk

Lendo o Itil Versão 2 você tem a impressão de que a relação de negócios e TI é sempre apoiado por um único fornecedor de serviços de TI interno, porém a relação de entre a prestação de serviços empresariais e de TI é muito mais complexa hoje do que o conceito de um único fornecedor reunindo todas as empresas e suas necessidades.
Temos que considerar que existem funções internas de TI, mas algumas são encontradas dentro de uma unidade de negócio estruturada, onde estão forncecendo um modelo de serviço compartilhados para multiplas unidades empresariais. Com isso podemos utilizar diferentes empresas tercerizadas externas ou elevar o software como um serviço, é como esta referido no ITIL 3, um valor de uma Rede Integrada de Serviços.

Linearizar Serviços de Catálogos -> Serviços de Carteiras Dinâmicas

O ITIL vem sendo referenciado como um Framework de Gerenciamento de Serviços. O principal foco até agora tem sido sobre os 10 Serviços e Apoios de processo. Em versões anteriores do ITIL, o conceito de um "serviço", estava em segundo plano.
Considerando que o ITIL versão 2 no processo de Gerenciamento de nível de Serviço tem como um dos seus muitos resultados um Catalogo de Serviços que pode ser resumido com um cadernos de serviços de TI. A Tecnologia da Informação publica seus serviços prestados com suas caractaristicas e atributos padrão ou em um Catalogo Linear de Serviços.

Processos Integrados -> Gerenciamento de Serviços de Ciclo de Vida

Baseado em informações disponíveis ao público, o ITIL V3 seus livros estão estruturados em torno do Ciclo de Vida do Serviço. Esta nova estrutura organiza os processos ja conhecidos no ITIL versão 2 com conteudo adicional. Com isso destacamos a importancia do Catalogo de Serviços e de ser um dos componentes do Gerenciamento de Nível de Serviço

5.4 - O que há de novo ?

Cada título na biblioteca atual do ITIL foi revisto e foram tomadas decisões sobre os conteúdos que necessitavam de ser trazidos para a V3. Sabe-se que uma grande parte das bibliotecas atuais do ITIL ainda está em uso, ainda são extremamente relevantes e de grande valor e, por isso mesmo, era necessário incluí-las como parte do novo ITIL, desde que permaneçam as melhores práticas globalmente adotadas pela gestão de serviços de TI. Portanto, a este respeito, nada mudou. O ITIL que se usa hoje será parte da V3 amanhã e acompanhará sempre as práticas de gestão de serviços de TI.

O ITIL V3 mostra-se completamente diferente da V2. A seguir enumeramos alguns aspectos básicos que tornam diferente o ITIL V3.

O método do desenvolvimento - foram examinadas minuciosamente várias opiniões em todo o planeta e muitos especialistas fizeram parte da equipe de desenvolvimento da V3. Estas opiniões formaram uma base sólida para os elementos chave do sucesso da V3.

O papel desempenhado pela comunidade de ITSM na V3 - em vez de convidar alguns peritos chave e alguns revisores, foram convidados membros da comunidade para estar ao lado das pessoas e terem um papel ativo no desenvolvimento da V3. O grupo consultivo do ITIL incluiu os mentores, os peritos da matéria, os revisores e os embaixadores do ITIL V3 em quase todo o projeto. Assim, a V3 é inteiramente uma prática desenvolvida por uma comunidade.

Seria preciso um livro para descrever todo o “tudo” que é novo sobre o ITIL V3, mas não há dúvida que o ITIL ruma para um futuro com serviços e produtos inovadores e estimulantes.

O ITIL V3 é parte de um processo para realçar e aperfeiçoar as melhores práticas do ITIL. Ajuda aos fornecedores de serviços a continuarem competitivos e eficazes no fornecimento de valores aos seus clientes. Uma parcela significativa do conteúdo do ITIL V2 é aperfeiçoada e incluída no ITIL V3. A estrutura e os conteúdos do ITIL V3 são baseados em consultas públicas extensivas, contribuições de líderes industriais e partes do ITIL V2 que são ainda extensivamente praticadas e usadas pela comunidade ITSM.

5.5 - Por que a atualização do ITIL ?

A versão dois foi desenvolvida nos anos 90. Desde essa altura, a TI amadureceu a um ritmo elevado, e com os novos modelos de negócio e o desenvolvimento das tecnologias, o que se dizia que eram as melhores práticas, provavelmente agora será “boas práticas”. Com isso, houve a necessidade de atualizar o ITIL, de forma a assegurar que ele vá de encontro às necessidades das comunidades de hoje.

Os processos com que as organizações estão trabalhando atualmente continuarão a fazer parte do novo ITIL. No entanto, os processos de entrega de serviços e suporte a serviços estão integrados num só ciclo de vida de serviços. Isto reflete melhor como a gestão de serviços é aplicada e assim a sua implementação torna-se mais fácil.

Como já se disse anteriormente, uma percentagem significativa do ITIL V2 foi revista e incluída no ITIL V3. Esta percentagem inclui as partes do ITIL que estão sendo amplamente praticadas e utilizadas pela comunidade de gestão de serviços. Existem áreas chave dentro dos processos de entrega de serviços e de suporte a serviços que são diferentes na V3, às quais se deve estar atento ao longo da implementação e transição para a V3.

5.6 - As Ferramentas

Os principais elementos funcionais das ferramentas de gestão de serviços continuarão a ser necessários para a V3, uma vez que os principais elementos dos processos da V2 permanecem. O que se espera, no entanto, é que os fornecedores venham a fazer novos ajustes nas suas ferramentas para poderem aproveitar o poder adicional das novas funções que a V3 introduz.

Pode-se continuar a usar as ferramentas e as práticas baseadas na V2 até se estar preparado para adotar melhorias, ou até se pretender adotar essas melhorias. Naturalmente, a V3 irá seduzir com as novas oportunidades para melhorar as suas práticas de gestão de serviços, mas é aconselhável ser diligente e certificar-se de que esta transição ocorra com facilidade e com tempo.

6. Conclusão

O Gerenciamento de Serviços de Tecnologia da Informação é o instrumento pelo qual a área pode iniciar a ação de uma postura próativa em relação ao entendimento das necessidades da organização, contribuindo para evidenciar a sua participação na geração de valor. O Gerenciamento de Serviços de TI visa alocar adequadamente os recursos disponíveis e gerenciá-los de forma integrada fazendo com que a qualidade do conjunto seja percebida pelos seus clientes e usuários, evitando a ocorrencia de problemas na entrega e na operação dos serviços de Tecnologia da Informação. Para alcançar este objetivo a tatica que vem sendo adotada e o desenho, a implementação e o gerenciamento de processos internos na área de TI de acordo com as práticas reunidas no modelo ITIL.

A ITIL prove um conjunto consistente de melhores práticas para a identificação de projetos na área de TI e o alinhamento dos seus serviços as necessidades da organização promovendo uma abordagem qualitativa para o uso econômico efetivo, eficaz e eficiente da infra-estrutura de TI objetivando obter vantagens para a organização tanto em termo de redução de custos quanto ao incremento da capacidade da organização de gerar receita, permitindo que a área concentre seus esforços em novos projetos.

7. Referências

Magalhães, Ivan Luizio, Gerenciamento de Serviços de TI na Prática, Uma abordagem com base na ITIL, São Paulo, Novatec, 2007

Fernandes, Aguinaldo A.; Abreu, Vladimir F. (2008). Implantando a Governança de TI: Estratégia à Gestão dos Processos e Serviços. 2. ed – Rio de Janeiro, Brasport.

Gartner (2008). Gartner Consulting. Disponível em http://www.gartner.com/ . Acesso em: 20 out. 2008, 17:00:00.

ITIL V.3 (2008). Página oficial do ITIL no site do OGC - Office of Government Commerce. Disponível em http://www.itil.co.uk . Acesso em: 20 out. 2008, 17:00:00.