CE-281 Segurança Lógica em Software

22/05/2023, 13:24 CE-281 Segurança Lógica em Software
mais Criar um blog Login
CE-281 Segurança Lógica em

Software
ITA - INSTITUTO TECNOLÓGICO DE AERONÁUTICA FRETZ SIEVERS JUNIOR
DOMINGO, 3 DE NOVEMBRO DE 2019
Segurança no Sistemas de Arquivos Linux
Permissões
ARQUIVO DO BLOG
▼ 2019 (1)
▼ novembro (1)
Segurança no Sistemas de
Arquivos Linux Permiss...
► 2010 (4)
► 2008 (6)
QUEM SOU EU
FRETZ SIEVERS JUNI OR
VER MEU PERFIL COMPLE T O
POSTADO POR FRETZ SIEVERS JUNIOR ÀS 10:38

NENHUM COMENTÁRIO:
SEXTA-FEIRA, 2 DE JULHO DE 2010
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
fretzsievers.blogspot.com 1/37
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.

NENHUM COMENTÁRIO:
QUINTA-FEIRA, 1 DE JULHO 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.

NENHUM COMENTÁRIO:
QUARTA-FEIRA, 28 DE ABRIL DE 2010
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

NENHUM COMENTÁRIO:
SEGUNDA-FEIRA, 5 DE ABRIL DE 2010
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

NENHUM COMENTÁRIO:
SÁBADO, 8 DE NOVEMBRO DE 2008
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: supervisiona o processo de

controle de mudanças. 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.

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
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
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.

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
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
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.
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/grundm
ann/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

NENHUM COMENTÁRIO:
QUARTA-FEIRA, 22 DE OUTUBRO DE 2008
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 profundidade, 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 (organizadas segundo uma lógica de ciclo
de vida de serviços), que podem servir como balizadoras, 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 maturidade 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ógicas 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.
NENHUM COMENTÁRIO:
Página inicial Postagens mais antigas
Assinar: Postagens (Atom)

CE-281 Segurança Lógica em Software

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

CE-281 Segurança Lógica em Software

Enviado por

Direitos autorais:

Formatos disponíveis

22/05/2023, 13:24 CE-281 Segurança Lógica em Software

mais Criar um blog Login

CE-281 Segurança Lógica em

DOMINGO, 3 DE NOVEMBRO DE 2019

Segurança no Sistemas de Arquivos Linux

VER MEU PERFIL COMPLE T O

POSTADO POR FRETZ SIEVERS JUNIOR ÀS 10:38

SEXTA-FEIRA, 2 DE JULHO DE 2010

Resumo do Artigo Beyond Stack Smashing

O estouro de buffers ocorre quando um programa tenta ler ou escrever

A abordagem tradicional do estouro de buffer é o stack smashing: a

No artigo, os autores apresentam 3 novos tipos de ataques desta

Um exemplo deste ataque é o estouro de buffer para desviar o fluxo de

- Function-Pointer Clobbering: Alteração do valor de um ponteiro

- Data-Pointer Modification: Alteração de locais arbitrários da

- Exception-Handler Hijacking: Quando um programa lança uma

- Virtual Pointer (VPTR) Smashing: A maioria dos compiladores

a VTBL apropriada através de ponteiros virtuais (VPTR) armazenado

Se houverem três blocos de memória contíguos X, Y e Z, e houver

POSTADO POR FRETZ SIEVERS JUNIOR ÀS 07:43

QUINTA-FEIRA, 1 DE JULHO DE 2010

Reflections on Trusting Trust by Ken Thompson

Ken Thompson recebeu o prêmio Turing pela ACM (Association for

Na primeira etapa o autor descreve a criação de um programa que se

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

Por fim, o artigo conclui que a segurança fica comprometida quanto

Pontos Principais do Artigo

Não existe código confiável, exceto o de sua autoria;

[1] Thompson, Ken. Reflections on Trusting Trust.Communications of

POSTADO POR FRETZ SIEVERS JUNIOR ÀS 19:18

QUARTA-FEIRA, 28 DE ABRIL DE 2010

Criptografia com o uso de curvas elípticas

Confidencialidade, integridade, autenticidade e não-repúdio são

apresentando ao final um exemplo de criptografia com curvas elípticas.

De forma independente, em 1985, N. Koblitz (KOBLITZ, 1987) e V.

Figura 1 - Ilustação de uma Curva Elíptica e a adição de uma EC

O fato de não se conhecer um algoritmo geral de tempo sub-

Na prática, quando se deseja enviar uma mensagem utilizando o

Tanto o destinatário quanto o remetente possuem um par de chaves

Para ler a mensagem, o remetente necessita da chave de sessão, que é

Figura 2 - Combinação de chaves entre o remetente e destinatário de

Algumas vantagens que resultam do fato de se usar pequenos

Por todas estas razões, os CCE têm tido crescente aceitação,nos

A criptografia de chave pública, nos últimos anos, se converteu numa

É um método lento porque os algoritmos, pela sua natureza

Requer uma autoridade de certificação, para que se possa garantir a

As curvas elípticas é uma opção para aplicações em ambientes

A criptografia simétrica não é substituída pela assimétrica. 0

BURNETT,1997 BURNETT, Steve, PAINE, Stephe, Criptografia e

MILLER,1986 Miller, V., Uses of elliptic curves in cryptography,

POSTADO POR FRETZ SIEVERS JUNIOR ÀS 10:27

SEGUNDA-FEIRA, 5 DE ABRIL DE 2010

Especificação Formal de Protocolos de

No presente artigo iremos falar sobre Especificação Formal de

A importância do estudo do tema se dá por causa dos serviços

Em contrapartida há um aumento no número de crimes relacionados

Para garantir a segurança das informações foram desenvolvidos vários

Porém, se o protocolo criptográfico não for projetado corretamente

O principal objetivo deste artigo é mostrar para a área acadêmica e

O artigo está dividido da seguinte forma: a seção 2 apresenta os

As senhas são ainda a base sobre os quais muitos sistemas da

Segundo (Anderson,2001) considera as limitações dos sistemas

Um ataque que se tornou comum era usar um grabber "um dispositivo