Upload
maycon-douglas
View
11
Download
2
Embed Size (px)
DESCRIPTION
Atividade Interdisciplinar Individual Ads 6 sem - 2014
Citation preview
SISTEMA DE ENSINO PRESENCIAL CONECTADOTECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
ATIVIDADE INTERDISCIPLINAR - INDIVIDUAL
ATIVIDADE INTERDISCIPLINAR - INDIVIDUAL
Trabalho apresentado ao Curso de Tecnologia em Análise e Desenvolvimento de Sistemas da Universidade Norte do Paraná – UNOPAR
Professores: Anderson E. M.GonçalvesAdriane LoperMerris MozerVeronice de Freitas
SUMÁRIO
1 INTRODUÇÃO.....................................................................................................3
2 OBJETIVO...........................................................................................................4
3 RECURSOS UTILIZADOS EM DISPOSITIVES MÓVEIS....................................5
3.1 PERSISTÊNCIA EM APLICATIVOS PARA DISPOSITIVOS MÓVEIS COM
J2ME............................................................................................................................5
3.1.1 J2ME e perfil MIDP........................................................................................5
3.1.2 RMS..............................................................................................................6
3.1.3 Classe RecordStore......................................................................................7
3.2 THREAD...............................................................................................................7
3.3 SINCRONIA DE PROCESSOS............................................................................8
3.3.1 Exclusão Mútua Com Espera Ativa...............................................................9
3.3.2 Desativando as Interrupções.........................................................................9
3.3.3 Variáveis de Bloqueio..................................................................................10
3.3.4 Alternância Estrita.......................................................................................10
3.3.5 Solução de Peterson...................................................................................10
3.3.6 Deadlock......................................................................................................11
3.3.7 Starvation....................................................................................................11
3.4 USABILIDADE DE INTERFACES PARA DISPOSITIVOS MÓVEIS..................11
3.4.1 Recomendações Críticas Para o Projeto de Interfaces Mobile...................11
3.4.1.1 Reduzir clicks..............................................................................................12
3.4.1.2 Reduzir funcionalidades..............................................................................12
3.4.1.3 Reduzir conteúdo........................................................................................12
3.4.1.4 Dar escolhas ao usuário..............................................................................12
3.4.2 Outras Práticas Importantes Que Herdamos da Usabilidade
Convenciona
l ....................................................................................................................................1
3
3.4.2.1 Integridade estética.....................................................................................13
3.4.2.2 Consistência................................................................................................13
3.4.2.3 Metáforas.....................................................................................................13
3.4.2.4 Contexto do usuário....................................................................................13
3.4.2.5 Modelo mental.............................................................................................13
3.4.2.6 Navegação..................................................................................................13
3.4.2.7 Interação e feedback...................................................................................14
3.4.2.8 Aparência e design......................................................................................14
3.4.2.9 Visualização de informações.......................................................................14
3.5 JAVA DB E DISPOSITIVOS MÓVEIS................................................................14
4 GESTÃO E SEGURANÇA NO SISTEMA DE INFORMAÇÃO..........................17
4.1 ENGENHARIA SOCIAL......................................................................................17
4.1.1 Evitando a Engenharia Social.....................................................................19
4.2 VULNERABILIDADE..........................................................................................20
4.2.1 Análise de Vulnerabilidades........................................................................20
4.2.2 Aorigem das Vulnerabilidades.....................................................................20
4.2.3 Principais Objetivos da Análise de Vulnerabilidades...................................21
4.3 AMEAÇAS, ATAQUES E VULNERABILIDADES...............................................21
4.3.1 Alguns Exemplos de Ameaças e Vulnerabilidades.....................................22
4.4 MEDIDAS DE SEGURANÇA E POLÍTICA DE SEGURANÇA...........................25
4.4.1 As causas da Insegurança..........................................................................26
4.5 AUDITORIA DE SISTEMAS DE INFORMAÇÃO................................................26
4.5.1 O Auditor de Sistemas.................................................................................28
5 CONCLUSÃO.....................................................................................................30
REFERÊNCIAS.........................................................................................................31
1 INTRODUÇÃO
No trabalho está sendo abordada toda a matéria do 6º Semestre,
dentro do contexto serão apresentados muitos recursos utilizados em dispositivos
móveis, como a persistência dos dados, threads e sincronia de processos.
Ainda no contexto dos sistemas móveis será mostrado à usabilidade
de interfaces para dispositivos móveis, e podendo como isso trazer benefícios para
ousuário, como a facilidade de uso, melhorando assim a forma como as pessoas
interagem com estes dispositivos.
Outro tema de suma importância neste trabalho, fala sobre a gestão
e segurança no sistema de informação, onde serão descritos alguns critérios como
engenharia social, vulnerabilidades, ameaças e ataques, bem como medidas de
segurança e auditoria.
3
2 OBJETIVO
Tem-se como objetivo desta produção textual o aprofundamento dos
conteúdos estudados durante o semestre, bem como o aperfeiçoamento nas
técnicas e conceitos vistos no decorrer das matérias, obtendo insumos para
confecção do Trabalho de Conclusão de Curso.
4
3 RECURSOS UTILIZADOS EM DISPOSITIVES MÓVEIS
3.1 PERSISTÊNCIA EM APLICATIVOS PARA DISPOSITIVOS MÓVEIS COM J2ME
A capacidade de persistir dados ou armazenar informações é sem
dúvida um dos recursos mais importantes em qualquer linguagem de programação.
Armazenar dados para uma posterior recuperação é uma constante na maioria dos
ambientes computacionais, seja para persistência simples de parâmetros de
configurações de algum sistema ou persistência de informações digitadas pelo
usuário para alimentar algum banco de dados.
No que diz respeito à persistência em ambientes computacionais, o
complicador é quando esse mesmo ambiente tem recursos de armazenamento
restrito e, ainda, uma arquitetura de hardware e software bem diferente da
encontrada em desktops ou grandes servidores, como é o caso dos dispositivos
móveis. Essas diferenças podem ser observadas tanto do ponto de vista do usuário
(ergonomia de hardware e software), quanto do ponto de vista do desenvolvedor
(ferramentas de software, APIs e recursos). Os telefones celulares conseguiram
alcançar uma popularidade quase tão grande quanto a observada na utilização de
computadores pessoais a partir da década de 80. Mas, assim como todos os
dispositivos móveis, eles também trazem consigo algumas dificuldades, como,
problemas relacionados à ergonomia do teclado, uma interface visual simples porém
limitada e a dependência de baterias que requerem recarga constante.
3.1.1 J2ME e perfil MIDP
O Java 2 Micro Edition (J2ME) foi desenvolvido para contemplar
toda a diversidade computacional existente nos dispositivos móveis. A tecnologia
J2ME conseguiu abstrair conceitos e técnicas para homogeneizar o
desenvolvimento em dispositivos móveis de forma completamente transparente. O
perfil de informação de dispositivos móveis, conhecido como MIDP (Mobile
InformationDevice Profile) surgiu como solução para diferenciar alguns dispositivos
que apesar de possuirem características semelhantes, ainda assim são
tecnologicamente diferentes. O perfil MIDP contempla os aparelhos celulares e é o
5
responsável pela definição das APIs necessárias para a persistência de dados.
3.1.2 RMS
O conjunto de classes responsáveis por armazenar e recuperar
dados é conhecido como Record Management System (RMS) ou sistema de
gerenciamento de registros. O RMS permite manter os dados persistentes entre
várias chamadas de um MIDlet (aplicação baseada no MIDP). Segundo a
especificação MIDP, deve haver, disponível no dispositivo, pelo menos 8kbytes de
memória não-volátil (ROM) para que os aplicativos persistam dados. Exemplos de
memória não-volátil seriam ROM, flash e etc. Em teoria, todo o espaço livre na
memória ROM, ou flash de um dispositivo móvel, estaria disponível aos aplicativos
para persistirem seus dados.
A unidade básica de dados mantida pelo RMS é conhecida como
RecordStore ou repositório de registro (RR). Um RR pode ser comparado a uma
tabela ou entidade no modelo relacional e é identificado por um nome de até 32
caracteres. Cada registro é composto por um identificador único e um array de
bytes, onde os dados do registro serão armazenados. Um RR mantém em sua
estrutura um conjunto de registros que podem ter tamanhos variáveis.
Um MIDlet é um aplicativo executado em um dispositivo móvel. Para
isso, ele precisa ser empacotado em um arquivo Java (JAR). Um MIDlet pode,
ainda, ser empacotado junto com outros MIDlets em um mesmo arquivo JAR,
formando um conjunto. Tanto um MIDlet quanto um conjunto de MIDlets, formam
uma aplicação J2ME única e completa. Cada conjunto de MIDlets ou um MIDlet,
pode criar e manter diversos RRs, podendo, inclusive, compartilhá-los entre si, com
o detalhe de que os nomes atribuídos aos RRs precisam ser únicos. A versão 1.0 do
MIDP não permitia o compartilhamento de RRs entre MIDlets empacotados em
diferentes arquivos JAR. A versão 2.0 do MIDP corrigiu essa limitação, permitindo
assim o compartilhamento de um RR por todas os MIDlets instalados no dispositivo.
As APIs do RMS não fornecem recurso para travamento de
registros. A implementação de um RR garante que a operação de persistência será
realizada de forma indivisível e síncrona evitando eventuais inconsistências no caso
de acessos múltiplos. Se for necessário que um MIDlet utilize múltiplas threads para
acessar um RR, é necessário toda uma atenção para manter a consistência dos
6
dados. Também, é responsabilidade da implementação no dispositivo fazer todo o
possível para garantir a integridade e a consistência dos RRs durante operações
normais ao seu uso como reinicialização, troca de baterias e etc.
Durante a desinstalação de um MIDlet do dispositivo, os armazéns
de dados pertencentes a ele são removidos automaticamente.
3.1.3 Classe RecordStore
Qualquer operação de inserção, atualização e exclusão de registros
em um RR provocam a atualização automática do seu número de versão e da data
em que ocorreu a mudança. O número da versão de um RR pode servir como
referencial, por exemplo, para algoritmos de replicação. É uma maneira interessante
de detectar quantas vezes um RR foi modificado. Esses dois valores, o número da
versão e a data da atualização, podem ser recuperados através do uso dos métodos
getVersion() e getLastModified() respectivamente.
3.2 THREAD
Para programas "normais" (single thread), tem um único ponto de
execução dentro do programa num momento particular, um thread é semelhante:
tem um início, uma sequência e um fim, como um programa "normal". Tem um único
ponto de execução no certo momento dentro de um thread.
O thread não é um programa, mas executa dentro de um programa
(ver figura).
Definição: thread é um fluxo único de controle sequencial dentro de
um programa.
7
A coisa fica mais interessante quando temos mais de um thread no
mesmo programa (ver figura).
O browser é um exemplo de uma aplicação multithreaded, onde
várias coisas podem ocorrer ao mesmo tempo:
Scroll;
Download de um applet;
Download de uma imagem;
Tocar uma animação;
Tocar um som;
Imprimir uma página em background;
Download de uma nova página;
Olhar 3applets de ordenação trabalhando.
Um thread parece ser um processo mas compartilha o mesmo
"espaço de endereçamento", sendo muito rápido chavear a execução entre threads
mas não entre processos.
O thread recebe alguns recursos próprios durante a execução:
Uma pilha de execução para poder chamar métodos, passar
parâmetros, alocar variáveis locais;
Um "ProgramCounter";
Chamamos isso o "contexto de execução do thread";
Alguns autores chamam thread de "contexto de execução".
3.3 SINCRONIA DE PROCESSOS
A sincronia de processos permite gerenciar o acesso concorrente a
recursos do sistema operacional de forma controlada por parte dos processos, de
8
maneira que um recurso não seja modificado em simultâneo, ou que os processos
não fiquem em espera que o recurso seja libertado.
Os processos (aplicativos ou programas) de um computador
compartilham determinados recursos da chamada região crítica, que são as
variáveis globais, as instruções de E/S, algum banco de dados, etc. Neste
compartilhamento podem ocorrer erros.
Exemplo:
Uma escola está fazendo sua matrícula apenas pela internet, o
número de vagas é 5, dois usuários estão fazendo a matrícula no exato momento,
finalizam a matrícula . A operação que o programa usa da região crítica: matrícula
finalizada -1.
Se os dois usuários fazem a operação ao mesmo tempo, quando a
matricula for finalizada subtrai-se 1 vaga:
Matrícula finalizada -1 (5-1)=4
Matrícula finalizada -1 (5-1)=4
Quando um terceiro usuário for fazer esta mesma matrícula,o
número de vagas será expresso como 4, sendo que na verdade deveria ser 3. Isto
causará instabilidade e poderá comprometer todo o sistema. A solução para este
tipo de caso é a certeza de exclusão mútua, isto é, apenas um processo pode
acessar a região crítica por vez; Os mecanismos que implementam a exclusão
mútua utilizam um protocolo de acesso à região crítica. Toda vez que um processo
for executar sua região crítica, ele é obrigado a passar por um controle de entrada e
outro de saída.
3.3.1 Exclusão Mútua Com Espera Ativa
Apenas um processo acessa a região crítica de cada vez. Espera
ativa faz testes continuos em uma variável, até que ela seja alterada, causando
assim um grande disperdicio de CPU. Abaixo temos soluções para problemas como
o mostrado acima.
3.3.2 Desativando as Interrupções
A forma mais simples de garantir a exclusão mútua é fazer com que
9
o processo desabilite as interrupções ao entrar na região crítica, e antes de sair
ashabilite novamente. Com isso a CPU não fará um chaveamento no momento em
que o processo estiver na região crítica, pois o chaveamento vem de uma
interrupção através de um relógio.
3.3.3 Variáveis de Bloqueio
Quando uma váriavel "lock" estiver como 0, significa que a região
crítica esta livre, e 1 esta ocupada. Assim, antes de entrar cada processo testa o
valor da variável "lock", se for 0, coloca como 1 e entra na região crítica, após sair
coloca o valor 0, se o valor já for 1, aguarda até ser 0.
3.3.4 Alternância Estrita
Neste metodo, é criada uma variável "turn", com valor inicial 0, a
imagem abaixo mostra dois processos 'a' e 'b' utilizando este metodo.
Fonte: http://pt.wikipedia.org/wiki/Sincronia_de_processos
Como "turn" esta como 0, o processo 'a' não fica "preso" no while, e
assim executa a região crítica, após terminar, ele seta "turn" para 1 e parte para o
resto do código, caso ocorra um chaveamento e o processo 'b' tente executar a
região crítica antes que o processo 'a' sete "turn" como 1, ele ficara em um loop,
apenas testando a variavel "turn"(espera ativa).
3.3.5 Solução de Peterson
Antes do processo entrar na região crítica ele executa o
procedimento enter_region(), com o seu número. E após sair da região crítica,
10
executa leave_region().
3.3.6 Deadlock
Dois ou mais processos ficam irreversivelmente bloqueados.
3.3.7 Starvation
Um processo fica sempre no final na fila e não consegue ser
atendido, pois processos com maior prioridade "roubam" sua vez.
3.4 USABILIDADE DE INTERFACES PARA DISPOSITIVOS MÓVEIS
Um questionamento comumsobre as melhores práticas de front-
end / usabilidade para dispositivos móveis é o quanto elas são específicas ao
contexto mobile, pois muitas delas não se distinguem das diretrizes que vêm sendo
difundidas há 20 anos.
É fato que grande parte das diretrizes são semelhantes, mas o que
muda é a criticidade quando tratamos de mobile. Algumas recomendações tornam-
se mais graves e imperdoáveis quando não são seguidas no projeto de interfaces
para dispositivos móveis.
Como exemplo, podemos usar a questão da densidade
informacional. Em aplicações que serão visualizadas em dispositivos móveis, os
textos devem ser concisos, eliminando informações secundárias que podem ser
irrelevantes. “Ora, mas isso também vale para aplicações visualizadas em desktop!”,
você pensa. Porém, para mobile, a concisão deve ser ainda maior e informações
que seriam aceitáveis nas aplicações web/desktop convencionais devem ser
removidas de aplicações mobile. A diretriz base é a mesma: reduzir informação
secundária. O que diferencia é o grau de severidade que isto representa neste outro
cenário.
3.4.1 Recomendações Críticas Para o Projeto de Interfaces Mobile
Desenvolver sites e aplicações para mobile requer atenção para
alguns critérios que tem um grande impacto na forma com que as pessoas
11
interagem com estes dispositivos.
3.4.1.1 Reduzir clicks
Esta parece ser uma recomendação óbvia para ambiente mobile.
Porém, quem já desenvolveu para mobile ou utiliza aplicações nestes dispositivos,
pense: você já deve ter visto algum site que apresenta uma informação bem limitada
na primeira tela com um link de “leia mais”, onde você tem o esforço de clicar e
esperar o carregamento do restante do conteúdo que você necessita, que às vezes
poderia ser resumido em apenas uma tela.
Se em um projeto usual de interface as melhores práticas indicam
que seria mais adequado disponibilizar toda a informação necessária em uma única
tela e poupar cliques do usuário, porque esta diferença em mobile? Por isso, deixar
o conteúdo mais conciso é crucial para que a informação possa ser apresentada de
modo objetivo e o menos fragmentada possível.
3.4.1.2 Reduzir funcionalidades
Restringir a quantidade de funcionalidades, mantendo as que são
necessárias ao ambiente mobile, diminui a chance dos usuários se confundirem
diante de todas as possibilidades e opções oferecidas.
3.4.1.3 Reduzir conteúdo
Devido ao tamanho das telas, o conteúdo para mobile exige uma
carga cognitiva maior e, portanto, pode ser até duas vezes mais difícil de
compreender. Como a memória de curto prazo é fraca, quanto mais os usuários
tiverem que rolar para se lembrar de um conteúdo, menos eles o farão.
3.4.1.4 Dar escolhas ao usuário
Textos mais concisos e funcionalidades mais restritas são
necessários. Mas é importante manter um link para a versão convencional do site,
caso o usuário precise acessar algum recurso que não esteja na versão mobile. O
usuário deve ter o direito de escolha sobre como ele deseja visualizar o site.
12
3.4.2 Outras Práticas Importantes Que Herdamos da Usabilidade Convencional
3.4.2.1 Integridade estética
O quanto o design da sua aplicação se integra com a função da
mesma. É o casamento entre forma e função, interface com boa qualidade estética e
funcional.
3.4.2.2 Consistência
A consistência de interface permite que o usuário transfira seus
conhecimentos e habilidades de uso de uma aplicação para outra. É preciso frisar
que uma aplicação consistente não é aquela que copia outras aplicações. Pelo
contrário, é uma aplicação que tira proveito dos padrões e paradigmas de interface
com os quais as pessoas se sentem mais confortáveis durante a interação.
3.4.2.3 Metáforas
Fácil reconhecimento e memorização de palavras, símbolos e
imagens.
3.4.2.4 Contexto do usuário
Especificação do ambiente do usuário, incluindo também a
modelagem de análise de tarefa e objetivos de negócio.
3.4.2.5 Modelo mental
Organização apropriada de dados, funções, tarefas, papéis e
pessoas de acordo com o modo com que o usuário compreende e reconhece estes
elementos.
3.4.2.6 Navegação
Navegação adequada considerando o modelo mental através de
13
janelas, menus, caixas de diálogos e painéis de controle em formato compreensível.
3.4.2.7 Interação e feedback
Input efetivo e feedback do output de informações para assegurar ao
usuário que uma ação está em processamento.
3.4.2.8 Aparência e design
Qualidade visual e atenção ao design com relação à escala,
proporção, ritmo, simetria e balanceamento de componentes.
3.4.2.9 Visualização de informações
Apresentação de informações por tabelas, gráficos, mapas e
diagramas. Uma vez que a tela destes dispositivos ainda é pequena em comparação
aos computadores comuns (mesmo se tratando de tablets), é preciso se valer de
componentes coringas que são capazes de apresentar uma boa quantidade de
informação de modo compacto, conciso, de fácil visualização e acessível.
3.5 JAVA DB E DISPOSITIVOS MÓVEIS
O número atual de SGBD´s que os desenvolvedores podem usar é
extenso, porém, se filtrarmos por SGBD´s que também possam ser usados no
ambiente móvel, este número cai drasticamente. Neste pequeno texto, iremos falar
brevemente do Java DB, um banco de dados 100% Java que pode ser usado na
plataforma Java SE, Java EE e, inclusive na Java ME. O Java DB começou em
1996, com o projeto Cloudscape, em 2004 foi incorporado ao projeto Apache. Sua
ideia tem muitos pontos em comum com o DB2, tendo limites e características
semelhantes.
Para quem já utiliza a linguagem Java, esta pode ser uma ótima
opção, porque o Java DB é construído 100% Java, além de ser recomendado pela
Sun. Outras características importantes do banco de dados:
Suporte ao JDBC 4;
Simples de embarcar em uma aplicação (basta colocar o
14
derby.jar no classpath de sua aplicação);
Administração zero para dispositivos móveis e muito simples
para uso desktop;
Tamanho médio de 2MB.
E sobre a possibilidade de sua utilização com o Java ME? Porque o
RMS ainda existe? Calma, infelizmente o Java DB ainda não está disponível para a
configuração CLDC, somente para a CDC, versão 1.1. Há alguns pontos importantes
que precisam ser conhecidos. Se a versão do seu Java DB é menor que a 10.1.1,
não existe suporte para a Java ME. Se a versão é maior que a 10.1.1 e menor que a
10.3.1.4, CDC/FP 1.0 também é suportado. O Java DB tem suporte ao perfil
Foundation Profile (FP) da CDC, sendo assim, ela também oferece suporte aos
perfis que são subconjuntos da FP, como o PersonalBasis Profile.
A codificação é mais próxima do uso JDBC no Java SE, do que a
persistência de dados com o Record Management System. Veja este pequeno
trecho de código:
1: EmbeddedSimpleDataSourceds = new EmbeddedSimpleDataSource();2: String dbName = "simpleMobileDB";3: ds.setDatabaseName(dbName);4: ds.setCreateDatabase("create"); 5: 6: Connection conn = null;7: Statement s = null;8: PreparedStatementps = null;9: ResultSetrs = null; 10: 11: try {12: conn = ds.getConnection();13: s = conn.createStatement();14: 15: s.execute("create table streetaddr(numint, addrvarchar(40))");16: 17: s.execute("insert into streetaddr values (1956, 'Dado')");18: 19: ps = conn.prepareStatement("update streetaddr set num=?, addr=?
wherenum=?");20: 21: ps.setInt(1, 180);22: ps.setString(2, "Grand Ave.");23: ps.setInt(3, 1956);24: ps.executeUpdate();
15
25:26: } catch (SQLException e) {}
O uso do Java DB no Java SE permite o uso da classe
java.sql.DriverManager, porém, no Java ME, é necessário utilizar a classe
EmbeddedSimpleDataSource (linha 1). A linha 2 especifica o nome do database, a
linha 3 configura o nome da base de dados que será acessada pelo Java DB. A linha
4 permite que o database seja criado automaticamente se ele não existir.
As linhas seguintes do código servem apenas para mostrar que o
uso do Java DB no ambiente ME se assemelha em muito com o ambiente desktop,
inclusive utilizando chamadas SQL.
Infelizmente, o Java DB ainda não está disponível na configuração
CLDC, então, teremos que conviver com o RMS mais algum tempo, ou, com o
Floggy e outros frameworks que facilitam a persistência de dados. Porém, assim
como o uso de smartphones cresce exponencialmente, a implementação da CDC
pode ser implementada em um número de dispositivos bem maior do que o
atual.Sendo assim, é interessante, como programadores Java ME, conhecermos, ao
menos que a essência, deste banco de dados chamados Java DB.
16
4 GESTÃO E SEGURANÇA NO SISTEMA DE INFORMAÇÃO
4.1 ENGENHARIA SOCIAL
Em Segurança da informação, chama-se Engenharia Socialas
práticas utilizadas para obter acesso a informações importantes ou sigilosas em
organizações ou sistemas por meio da enganação ou exploração da confiança das
pessoas. Para isso, o golpista pode se passar por outra pessoa, assumir outra
personalidade, fingir que é um profissional de determinada área, etc. É uma forma
de entrar em organizações que não necessita da força bruta ou de erros em
máquinas. Explora as falhas de segurança das próprias pessoas que, quando não
treinadas para esses ataques, podem ser facilmente manipuladas.
Engenharia social compreende a inaptidão dos indivíduos
manterem-se atualizados com diversas questões pertinentes a tecnologia da
informação, além de não estarem conscientes do valor da informação que eles
possuem e, portanto, não terem preocupação em proteger essa informação
conscientemente. É importante salientar que, a engenharia social é aplicada em
diversos setores da segurança da informação independente de sistemas
computacionais, software e ou plataforma utilizada, o elemento mais vulnerável de
qualquer sistema de segurança da informação é o ser humano, o qual possui traços
comportamentais e psicológicos que o torna suscetível a ataques de engenharia
social. Dentre essas características, pode-se destacar:
Vaidade pessoal e/ou profissional: O ser humano costuma ser
mais receptivo a avaliação positiva e favorável aos seus objetivos, aceitando
basicamente argumentos favoráveis a sua avaliação pessoal ou profissional ligada
diretamente ao benefício próprio ou coletivo de forma demonstrativa.
Autoconfiança: O ser humano busca transmitir em diálogos
individuais ou coletivos o ato de fazer algo bem, coletivamente ou individualmente,
buscando transmitir segurança, conhecimento, saber e eficiência, buscando criar
uma estrutura base para o início de uma comunicação ou ação favorável a uma
organização ou indivíduo.
Formação profissional: O ser humano busca valorizar sua
formação e suas habilidades adquiridas nesta faculdade, buscando o controle em
uma comunicação, execução ou apresentação seja ela profissional ou pessoal
17
buscando o reconhecimento pessoal inconscientemente em primeiro plano.
Vontade de ser útil: O ser humano, comumente, procura agir com
cortesia, bem como ajudar outros quando necessário.
Busca por novas amizades: O ser humano costuma se agradar e
sentir-se bem quando elogiado, ficando mais vulnerável e aberto a dar informações.
Propagação de responsabilidade: Trata-se da situação na qual o
ser humano considera que ele não é o único responsável por um conjunto de
atividades.
Persuasão: Compreende quase uma arte a capacidade de
persuadir pessoas, onde se busca obter respostas específicas. Isto é possível
porque as pessoas possuem características comportamentais que as tornam
vulneráveis a manipulação.
Exemplos de ataques usando engenharia social:
Exemplo 1: Você recebe um mensagem de recadastramento de
senhas do e-mail institucional, mesmo sabendo que a DGTI nunca faz esse tipo de
solicitação via e-mail.
Exemplo 2: você recebe uma mensagem e-mail, onde o
remetente é o gerente ou alguém em nome do departamento de suporte do seu
banco. Na mensagem ele diz que o serviço de Internet Banking está apresentando
algum problema e que tal problema pode ser corrigido se você executar o aplicativo
que está anexado à mensagem. A execução deste aplicativo apresenta uma tela
análoga àquela que você utiliza para ter acesso a conta bancária, aguardando que
você digite sua senha. Na verdade, este aplicativo está preparado para furtar sua
senha de acesso a conta bancária e enviá-la para o atacante.
Exemplo 3: você recebe uma mensagem de e-mail, dizendo que
seu computador está infectado por um vírus. A mensagem sugere que você instale
uma ferramenta disponível em um site da Internet, para eliminar o vírus de seu
computador. A real função desta ferramenta não é eliminar um vírus, mas sim
permitir que alguém tenha acesso ao seu computador e a todos os dados nele
armazenados.
Exemplo 4: algum desconhecido liga para a sua casa e diz ser do
suporte técnico do seu provedor. Nesta ligação ele diz que sua conexão com a
Internet está apresentando algum problema e, então, pede sua senha para corrigi-la.
Caso você entregue sua senha, este suposto técnico poderá realizar uma infinidade
18
de atividades maliciosas, utilizando a sua conta de acesso à Internet e, portanto,
relacionando tais atividades ao seu nome.
Estes casos mostram ataques típicos de engenharia social, pois os
discursos apresentados nos exemplos procuram induzir o usuário a realizar alguma
tarefa e o sucesso do ataque depende única e exclusivamente da decisão do
usuário em fornecer informações sensíveis ou executar programas.
4.1.1 Evitando a Engenharia Social
Especialistas afirmam que a medida que nossa sociedade torna-se
cada vez mais dependente da informação, a engenharia social tende a crescer e
constituir-se numa das principais ameaças aos sistemas de segurança das
(grandes) organizações. Entretanto, embora as situações apresentadas acima sejam
um tanto indesejáveis e até certo ponto assustadoras, há mecanismos através dos
quais uma organização pode implementar a fim de detectar e prevenir ataques de
engenharia social. Tais medidas visam, principalmente, atenuar a participação do
componente humano. Essas medidas compreendem:
Educação e Treinamento– Importante conscientizar as pessoas
sobre o valor da informação que elas dispõem e manipulam, seja ela de uso pessoal
ou institucional. Informar os usuários sobre como age um engenheiro social.
Segurança Física – Permitir o acesso a dependências de uma
organização apenas às pessoas devidamente autorizadas, bem como dispor de
funcionários de segurança a fim de monitorar as entradas e saídas de locais
estratégicos dentro da organização.
Política de Segurança – Estabelecer procedimentos que
eliminem quaisquer trocas de senhas. Por exemplo, um administrador jamais deve
solicitar a senha e/ou ser capaz de ter acesso a senha de usuários de um sistema.
Estimular o uso de senhas de difícil descoberta, além de remover contas de usuários
que deixaram a instituição.
Controle de Acesso – Os mecanismos de controle de acesso
tem o objetivo de implementar privilégios mínimos a usuários a fim de que estes
possam realizar suas atividades. O controle de acesso pode também evitar que
usuários sem permissão possam criar/remover/alterar contas e instalar softwares
danosos à organização.
19
4.2 VULNERABILIDADE
4.2.1 Análise de Vulnerabilidades
A Análise consiste em identificar e eliminar sistematicamente
vulnerabilidades do sistema. As etapas para detecção, remoção e controle exigem
acompanhamento de profissional qualificado e ferramentas tecnológicas. A
integração desses processos produz maior segurança e proteção para os dados e
sistema da Organização. Todas as ações tomadas devem ser documentadas não só
para controlar futuras ações, como também para consultas periódicas.
Qualquer sistema que manipule dados está sujeito a alguma
vulnerabilidade. A conexão com a Internet representa uma das principais formas de
desestabilização e roubo de informações para qualquer Usuário dentro de uma
Organização. Além da Internet, há outras possibilidades de acesso remoto que
podem comprometer o sistema e a segurança de dados, tais como bluetooth,
infravermelho, etc. Toda essa possível exposição dos dados pode acarretar em
invasão de rede e seus servidores, expondo informações confidenciais e violando a
privacidade garantida por lei.
A cada dia novas vulnerabilidades surgem em decorrência de
brechas em softwares, imperfeições na configuração de aplicativos e falha humana.
A Análise de Vulnerabilidades é responsável por garantir a detecção, remoção e
controle das mesmas.
Visando sempre manter a integridade, confidencialidade e
disponibilidade, a Segurança da Informação enfrenta constantes desafios para
manter usuários e Organizações protegidos de ameaças e falhas que possam
comprometer a normalidade das operações. É essencial a preocupação em manter
dados em sigilo e garantir o bom funcionamento de processos, acompanhando o
avanço e disponibilização de novas tecnologias.
4.2.2 Aorigem das Vulnerabilidades
Erros de programação – Grande parte das vulnerabilidades
surge do erro de tamanho do buffer, uma região da memória reservada para escrita
e leitura dos dados.
20
Má configuração – Aplicativos de segurança, como o firewall,
devem ser corretamente configurados, ou podem ser brechas para ataques
maliciosos.
Falha humana – Execução de arquivos maliciosos
manualmente.
4.2.3 Principais Objetivos da Análise de Vulnerabilidades
Identificar e tratar falhas de softwares que possam comprometer
seu desempenho, funcionalidade e segurança;
Providenciar uma nova solução de segurança como, por
exemplo, o uso de um bom antivírus, com possibilidade de update constante;
Alterar as configurações de softwares a fim de torná-los mais
eficientes e menos suscetíveis a ataques;
Utilizar mecanismos para bloquear ataques automatizados
(worms, bots, entre outros);
Implementar a melhoria constante do controle de segurança;
Documentar os níveis de segurança atingidos para fins de
auditoria e Compliance com leis, regulamentações e políticas.
A Análise de Vulnerabilidades torna a tomada de decisão em relação
à segurança mais fácil, pois reúne informações essenciais que indicam a melhor
estratégia para se manter protegido de falhas, ataques e invasões. Além disso, uma
das facilidades obtidas através da implementação de políticas de segurança é
descobrir e tratar vulnerabilidades com maior rapidez, possibilitando o alinhamento
às normas de compliance.
4.3 AMEAÇAS, ATAQUES E VULNERABILIDADES
Ameaça: Quem pode atacar qual componente, usando qual
recurso, com que objetivo em mente, quando, de onde, porque, e qual é a
probabilidade disso acontecer. Podendo conter aspectos gerais da natureza do
ataque, mas não detalhes, tais como quais medidas de segurança ele deve superar
e quais vulnerabilidades explorará.
Avaliação de Ameaça (TA, do inglês ThreatAssessment):
21
Tentativa de prever as ameaças. Podendo envolver o uso de conhecimentos sobre
incidentes de segurança antigos em uma estrutura semelhante a avaliada. Criar uma
segurança proativa (e não só reativa) para ameaças que ainda não se
materializaram.
Vulnerabilidade: Uma fraqueza na segurança do sistema (ou
falta de medidas de segurança) que pode ser explorada por diferentes adversários
com diferentes interesses.
Avaliação de Vulnerabilidade (VA, do inglês
VulnerabilityAssessment): Tentativa de descobrir (e talvez demonstrar)
vulnerabilidades de segurança que poderiam ser exploradas por um adversário.
Uma boa avaliação de vulnerabilidade normalmente sugere contramedidas viáveis
ou melhorias na segurança para eliminar ou mitigar a vulnerabilidade, também ajuda
na recuperação após um ataque e que não se repita.
Gestão de risco: Tentativa de minimizar as fontes de riscos de
segurança decidindo como implantar, modificar, ou reatribuir recursos de segurança.
Utiliza como entrada para as decisões os resultados da TA, da VA, os ativos a
serem protegidos (informações dos clientes, reputação do sistema, etc.), as
consequências de ataques bem sucedidos, e os recursos (tempo, financiamento,
pessoal) disponível para providenciar segurança.
Ataque: Uma tentativa de causar danos a ativos valiosos,
normalmente tentando explorar uma ou mais vulnerabilidades. O dano pode incluir
roubo de informações, sabotagem (defacement, backdoor, etc.), destruição (apagar
banco de dados, códigos), espionagem, ou adulteração. Para mais exemplos é só
ver as notícias.
4.3.1 Alguns Exemplos de Ameaças e Vulnerabilidades
Ameaça: Adversários podem instalar malware nos
computadores da organização permitindo que eles possam roubar informações
pessoais para fingir ser outra pessoa.
Vulnerabilidade: Os computadores da organização não possuem
as últimas definições do banco de dados de vírus para o software anti-malware.
Ameaça: Cyber Criminosos podem invadir o sistema e roubar o
banco de dados.
22
Vulnerabilidade: A plataforma em que o sistema funciona
permite escalar privilégios.
Ameaça: Um funcionário mal instruído pode revelar informações
confidenciais aos adversários.
Vulnerabilidade: Funcionários não tem um bom entendimento de
qual informação é sensível/confidencial e qual não é, logo eles não podem fazer um
bom trabalho protegendo-as de engenharia social.
Ameaça: Funcionários descontentes podem sabotar o sistema.
Vulnerabilidade: A organização carece de contramedidas
efetivas para ameaças internas como verificação do passado e mitigação de
descontentamento de funcionários (tratamento justo de funcionários, processos
legítimos de resolver reclamações, programas de assistência aos funcionários, não
toleramento de chefes opressores, etc.)
Ameaça: Advancedpersistentthreat(APT) podem tomar o
controle do ambiente corporativo.
Vulnerabilidade: A organização carece de uma defesa
estratégica organizada com potencial de tomar atitudes bem pensadas e
nos momentos certos.
Mitigar uma vulnerabilidade pode não ser relevante para uma
ameaça, pois o adversário pode não perceber uma vulnerabilidade. Vulnerabilidades
não definem ameaças, pois um adversário deseja efetuar um ataque por um motivo
externo.
TAs e VAs são diferentes, e ambas são necessárias para se ter uma
boa gestão de risco, e ambas são dependentes entre si até certo ponto. Hackers
procuram explorar vulnerabilidades, cuja ausência levaria a seu fracasso. Assim
como não teria relevância a existência de vulnerabilidades se não existissem
ameaças. Não existe uma relação de um para um entre vulnerabilidades e ameaças.
Diferentes adversários podem explorar uma mesma vulnerabilidade para diferentes
objetivos, por exemplo, um computador desatualizado. Assim como uma ameaça
pode explorar várias vulnerabilidades diferentes para atingir o seu objetivo.
TA envolve em sua maioria especular sobre pessoas que não estão
em nossa frente, e que podem muito bem não existir, mas que possuem motivações
complexas, objetivos, mentalidades e recursos. Vulnerabilidades, por outro lado, são
mais concretas se formos espertos e criativos o suficiente para vê-las. Elas são
23
descobertas através de uma análise da estrutura e sua segurança, sem
especulações sobre pessoas.
Por esse motivo, o entendimento das vulnerabilidades é
normalmente mais fácil que as ameaças. Algumas pessoas afirmam que os
incidentes anteriores de segurança nos dizem tudo o que precisamos saber sobre as
ameaças, mas isso é ser reativo, não proativo, e deixa escapar raros, mas
catastróficos ataques.
Argumenta-se que o conhecimento das vulnerabilidades é mais
poderoso que o das ameaças. Pois ao pôr um razoável esforço para mitigar as
vulnerabilidades, você provavelmente estará em boa forma para qualquer que seja a
ameaça(que é muito mais fácil de errar). E ser ignorante nas vulnerabilidades
permite aos adversários vários formas de atingir seu objetivo.
Mas em qualquer grande e complexo sistema existe um enorme
número de vulnerabilidades. E encontrar vulnerabilidades exige uma análise
minuciosa e imaginação/criatividade, podendo chegar a um custo altíssimo. Além de
que infelizmente entramos em situações inevitáveis em que não podemos ter
contato com o código fonte de um componente do nosso sistema, nos tornando
dependentes de patchs que podem demorar a chegar.
A avaliação das ameaças, ao contrário, normalmente carece de uma
análise criativa sobre os problemas de segurança caracterizada pelo uso simplório
de listas de verificação, auditorias de conformidade dos logs, diretrizes a serem
seguidas, bases de dados de incidentes de segurança passado e abordagens
generalizadas.
Finalizando, não devemos confundir a intenção de uma TA ou VA.
Não serve para certificar ou medir a segurança, ou como uma técnica para descobrir
se alguém não está fazendo algo direito. O objetivo de uma VA é de melhorar a
segurança. O objetivo de uma TA é nos ajudar a decidir (junto com a gestão de
risco) o que e quanto de segurança nós precisamos. Pois mesmo após as
avaliações, ainda existirá ameaças e vulnerabilidades desconhecidas e não tratadas.
O jeito é encarar que não poderemos ficar completamente protegidos, e utilizar as
avaliações para atingirmos a segurança exigida.
24
4.4 MEDIDAS DE SEGURANÇA E POLÍTICA DE SEGURANÇA
A segurança dos sistemas informáticos limita-se geralmente a
garantir os direitos de acesso aos dados e recursos de um sistema implementando
mecanismos de autenticação e de controlo que permitem garantir que os utilizadores
dos ditos recursos possuem unicamente os direitos que lhes foram concedidos.
Os mecanismos de segurança implementados podem, no entanto
provocar um embaraço a nível dos utilizadores e as instruções e regras tornam-se
cada vez mais complicadas à medida que a rede se estender. Assim, a segurança
informática deve ser estudada de maneira a não impedir os utilizadores de
desenvolver os usos que lhes são necessários, e de fazer de modo a que possam
utilizar o sistema de informação em total confiança.
É a razão pela qual é necessário definir inicialmente uma política de
segurança, cuja implementação se faz de acordo com as quatro etapas seguintes:
Identificar as necessidades em termos de segurança, os riscos
informáticos que pesam sobre a empresa e as suas eventuais consequências;
Elaborar regras e procedimentos a implementar nos diferentes
serviços da organização para os riscos identificados;
Supervisionar e detectar as vulnerabilidades do sistema de
informação e manter-se informado das falhas sobre as aplicações e materiais
utilizados;
Definir as ações a empreender e as pessoas a contatar em caso
de detecção de uma ameaça.
A política de segurança é, por conseguinte o conjunto das
orientações seguidas por uma organização (em sentido lato) em termos de
segurança. A esse respeito ela deve ser elaborada a nível dedireção da organização
interessada, porque se refere a todos os utilizadores do sistema.
A esse respeito, não cabe só aos administradores informáticos
definir os direitos de acesso dos utilizadores, mas aos responsáveis hierárquicos
destes últimos. O papel do administrador informático é, por conseguinte garantir que
os recursos informáticos e os direitos de acesso a estes estão em coerência com a
política de segurança definida pela organização.
Além disso, já que é o único a conhecer perfeitamente o sistema,
cabe-lhe fazer aumentar as informações relativas à segurança à sua direção,
25
eventualmente aconselhar as instâncias de decisão sobre as estratégias a aplicar,
bem como ser o ponto de entrada relativo à comunicação destinada aos utilizadores
sobre os problemas e recomendações em termos de segurança.
A segurança informática da empresa assenta num bom
conhecimento das regras pelos empregados, graças a ações de formação e de
sensibilização junto dos utilizadores, mas deve ir, além disso, e nomeadamente
cobrir os seguintes campos:
Um dispositivo de segurança físico e lógico, adaptado às
necessidades da empresa e aos usos dos utilizadores;
Um procedimento de gestão das atualizações;
Uma estratégia de salvaguardacorretamente planificada;
Um plano de retoma após incidente;
Um sistema documentado atualizado.
4.4.1 As causas da Insegurança
Distinguem-se geralmente dois tipos de insegurança:
O estado ativo de insegurança, ou seja, o não conhecimento pelo
utilizador das funcionalidades do sistema, algumas das quais lhe podem ser
prejudiciais (por exemplo, o fato de não desativar serviços de redes não necessárias
ao utilizador);
O estado passivo de insegurança,ou seja, a ignorância dos meios
de segurança implementados, por exemplo, quando o administrador (ou o utilizador)
de um sistema não conhece os dispositivos de segurança de que dispõe.
4.5 AUDITORIA DE SISTEMAS DE INFORMAÇÃO
De maneira geral, um planejamento de auditoria deve identificar
problemas potenciais de segurança da entidade, com base na legislação vigente,
atividades e transações da empresa de forma a propiciar o cumprimento dos
serviços contratados com entidade dentro dos prazos e de forma segura,
estabelecendo a natureza, oportunidade e extensão dos exames a serem efetuados
em conjunto com os termos constantes na sua proposta de serviços para a
realização do trabalho.
26
A auditoria de sistemas de informação visa verificar a conformidade
não dos aspectos contábeis da organização, mas sim do próprio ambiente
informatizado, garantindo a integridade dos dados manipulados pelo computador.
Assim, ela estabelece e mantém procedimentos documentados para planejamento e
utilização dos recursos computacionais da empresa, verificando aspectos de
segurança e qualidade. O trabalho da auditoria de sistemas acontece com o
estabelecimento de metodologias, objetivos de controle e procedimentos a serem
adotados por todos aqueles que operam ou são responsáveis por equipamentos de
TI e/ou sistemas dentro da organização.
Em uma auditoria os objetivos de controle são estabelecidos com
base nas atividades da entidade, seu tamanho, qualidade de seus sistemas e
controle interno e competência de sua administração. É necessário que o auditor
tenha um modelo normativo de como as atividades devem estar sendo feitas. Assim,
devem-se levar em conta as atividades das pessoas, órgãos e produtos da entidade
de modo que tais atividades não se desviem das normas preestabelecidas pela
organização.
Objetos de controle são metas de controle a serem alcançadas ou
efeitos negativos a serem evitados traduzidos em procedimentos de auditoria. Assim
os objetivos de controle são detalhados conforme o enfoque ao qual está
relacionado. Existem diversas áreas que esses objetivos podem contemplar como
segurança, atendimento às solicitações externas, materialidade, altos custos de
desenvolvimento, grau de envolvimento dos usuários e outsourcing.
Segundo o COBIT, as metas a serem alcançadas em uma auditoria
de Sistemas de Informação se enquadrarão em algum dos itens abaixo:
Estrutura de Gerenciamento de Programa;
Estrutura de Gerenciamento de Projeto;
Abordagem de Gerenciamento de Projeto;
Comprometimento dos Participantes;
Escopo do Projeto;
Fase de Início do Projeto;
Planejamento do Projeto Integrado;
Recursos do Projeto;
Gerenciamento de Riscos do Projeto;
Planejamento do Projeto Integrado;
27
Recursos do Projeto;
Gerenciamento de Riscos do Projeto;
Planejamento da Qualidade do Projeto;
Controle de Mudanças no Projeto;
Métodos de Planejamento de Garantia do Projeto;
Avaliação, Relatórios e Monitoramento do Desempenho do
Projeto;
Conclusão do Projeto.
Por fim, é importante ressaltar que a necessidade de controlar e
auditar os recursos da tecnologia da informação e da comunicação nunca foi tão
grande. Para garantir segurança e qualidade em seus processos e serviços é
necessário verificação e controle constante.
4.5.1 O Auditor de Sistemas
O auditor de sistemas verifica a eficácia dos controles e
procedimentos de segurança existentes, a eficiência dos processos em uso, a
correta utilização dos recursos disponíveis, assessorando a administração na
elaboração de planos e definição de metas, colaborando no aperfeiçoamento dos
controles internos, apontando deficiências e irregularidades que possam
comprometer a segurança e o desempenho organizacional.
Com a larga utilização da tecnologia para o armazenamento das
informações contábeis, financeiras e operacionais, o auditor de sistemas tem de se
aprimorar no campo de atuação (processos) da organização para extrair, analisar
banco de dados envolvidos e suportar decisões das demais áreas de auditoria.
A necessidade global de referências nesse assunto, para o exercício
dessa profissão, promoveram a criação e desenvolvimento de melhores práticas
como COBIT, COSO, ISO 27001 e ITIL.
Atualmente a certificação CISA – CertifiedInformation Systems
Auditor, oferecida pela ISACA – Information Systems andControlAssociation é uma
das mais reconhecidas e avaliadas por organismos internacionais, já que o processo
de seleção consta de uma prova extensa que requer conhecimentos avançados,
além de experiência profissional e a necessidade de manter-se sempre atualizado,
através de uma política de educação continuada (CPE) na qual o portador da
28
certificação deve acumular carga horária de treinamento por período estabelecido.
A formação acadêmica do auditor de sistemas pelos motivos acima
acaba sendo multidisciplinar: análise de sistemas, ciência de computação,
administração com ênfase em TI, advocacia com foco em Direito da informática -
direito digital e correlatos.
29
5 CONCLUSÃO
Através da pesquisa e confecção deste trabalho foram apresentados
vários recursos para dispositivos móveis, tais como a persistência que é a
capacidade de persistir dados ou armazenar informações, bem como, threads,
sincronismo de processos, interface com os usuários e sobre o Java DB, um banco
de dados 100% Java que pode ser usado no ambiente móvel.
Sobre os critérios utilizados para atender a gestão e segurança dos
sistemas de informação, foi observado que a engenharia social é um meio utilizado
para obter acesso a informações importantes ou sigilosas em organizações ou
sistemas por meio da enganação ou exploração da confiança das pessoas. Outros
critérios foram estudados como as vulnerabilidades, ameaças e ataques, as medidas
de segurança e políticas de segurança e auditoria, notando-se que a segurança dos
sistemas informáticos limita-se geralmente a garantir os direitos de acesso aos
dados e recursos de um sistema implementando mecanismos de autenticação e de
controlo que permitem garantir que os utilizadores dos ditos recursos possuem
unicamente os direitos que lhes foram concedidos.
30
REFERÊNCIAS
MORAIS / SOLER, Everson Matias de / Luciano. Projeto Interface Homem-Computador. São Paulo. Editora Pearson, 2010
http://dl.acm.org/citation.cfm?id=2400111Acessado em: 23/09/2013
http://0xmateusbraga.wordpress.com/2011/03/27/gestao-de-risco-ameaca-e-vulnerabilidades-na-seguranca/Acessado em: 23/09/2013
http://www.modulo.com.br/solucoes/gestao-de-riscos-e-vulnerabilidades-de-ti-/o-que-e-e-para-que-serve-a-analise-de-vulnerabilidades-Acessado em: 23/09/2013
http://tableless.com.br/usabilidade-de-interfaces-para-dispositivos-moveis-parte1/#.Ujhf7z8pikpAcessado em: 26/09/2013
http://pt.wikipedia.org/wiki/Sincronia_de_processosAcessado em: 30/09/2013
http://pt.wikipedia.org/wiki/Thread_%28ci%C3%AAncia_da_computa%C3%A7%C3%A3o%29Acessado em: 30/09/2013
http://www.portugal-a-programar.pt/topic/56734-threads/Acessado em: 30/09/2013
http://inf.ufpel.edu.br/site/wp-content/uploads/2012/04/Mecanismos-de-Sincroniza%C3%A7%C3%A3o-em-Ambiente-de-Mem%C3%B3ria-Compartilhada-Uma-abordagem-para-Computa%C3%A7%C3%A3o-Sustent%C3%A1vel.pdfAcessado em: 02/10/2013
http://pt.kioskea.net/contents/623-introducao-a-seguranca-informaticaAcessado em: 02/10//2013
http://www.projetoderedes.com.br/aulas/ugb_auditoria_e_analise/ugb_apoio_auditoria_e_analise_de_seguranca_aula_02.pdfAcessado em: 02/10//2013
http://pt.wikipedia.org/wiki/Auditoria_de_sistemasAcessado em: 02/10//2013
31