SUMRIO

INTRODUO....................................................................................................3

OBJETIVO..........................................................................................................4

3 DESENVOLVIMENTO........................................................................................5
3.1 Recursos utilizados em dispositivos mveis........................................................5
3.1.1 Persistncia em aplicativos para dispositivos mveis com J2ME....................5
3.1.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 Excluso mtua com espera ativa....................................................................9
3.3.2 Desativando as Interrupes ...........................................................................9
3.3.3 Variveis de Bloqueio.....................................................................................10
3.3.4 Alternncia Estrita ..........................................................................................10
3.3.5 Soluo de Peterson.......................................................................................10
3.3.6 Deadlock.........................................................................................................11
3.3.7 Starvation....................................................................................................... 11
3.3 Variveis de Bloqueio .......................................................................................10
3.3.4 Alternncia Estrita ..........................................................................................10
3.3.5 Soluo de Peterson...................................................................................... 10
3.3.6 Deadlock ........................................................................................................11
3.3.7 Starvation........................................................................................................11
3.4 USABILIDADE DE INTERFACES PARA DISPOSITIVOS MVEIS ................11
3.4.1 Recomendaes Crticas 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 contedo.........................................................................................12
3.4.1.4 Dar escolhas ao usurio..............................................................................12
3.4.2 Outras prticas importantes que herdamos da usabilidade convencional .13
3.4.2.1 Integridade esttica.....................................................................................13
3.4.2.2 Consistncia................................................................................................13
3.4.2.3 Metforas ....................................................................................................13
3.4.2.4 Contexto do usurio ...................................................................................13
3.4.2.5 Modelo mental.............................................................................................13
3.4.2.6 Navegao...................................................................................................13
3.4.2.7 Interao e feedback....................................................................................14
3.4.2.8 Aparncia e design ......................................................................................14
3.4.2.9 Visualizao de informaes ...................................................................... 14
3.5 JAVA DB E DISPOSITIVOS MVEIS ...............................................................14
4 GESTO E SEGURANA NO SISTEMA DE INFORMAO............................ 17
4.1 ENGENHARIA SOCIAL .....................................................................................17
4.1.1 Evitando a Engenharia Social .........................................................................19
4.2 VULNERABILIDADE ..........................................................................................20
4.2.1 Anlise de Vulnerabilidades ............................................................................20

4.2.2 A origem das Vulnerabilidades ................................................................... .20

4.2.3 Principais Objetivos da Anlise de Vulnerabilidades......................................21
4.3 AMEAAS, ATAQUES E VULNERABILIDADES..............................................21
4.3.1 Alguns Exemplos de Ameaas e Vulnerabilidades .......................................22
4.4 MEDIDAS DE SEGURANA E POLTICA DE SEGURANA .........................25
4.4.1 As causas da Insegurana............................................................................ 26
4.5 AUDITORIA DE SISTEMAS DE INFORMAO ............................................ 26
4.5.1 O Auditor de Sistemas.................................................................................. 28
5 CONCLUSO .................................................................................................... 30
6 REFERNCIAS.................................................................................................. 31

1 INTRODUO
Neste trabalho ser abordada toda a matria do 6 Semestre.Dentro deste contexto
sero apresentados vrios recursos utilizados em dispositivos mveis, como a
persistncia dos dados, threads e sincronia de processos. Ainda contexto dos
sistemas mveis ser mostrado a usabilidade de interfaces para dispositivos mveis,
e podendo com isso trazer benefcios para o usurio, tal como a facilidade de uso,
melhorando assim a forma como as pessoas interagem com estes dispositivos.
Outro tema de suma importncia neste trabalho, fala sobre a gesto e segurana no
sistema de informao, onde sero descritos alguns critrios como engenharia
social, vulnerabilidades, ameaas e ataques, bem como medidas de segurana e
auditoria.
2 OBJETIVO
Nosso objetivo nesta produo textual o aprofundamento dos contedos
estudados durante o semestre, bem como o aperfeioamento nas tcnicas e
conceitos vistos no decorrer das matrias, obtendo insumos para confeco do
Trabalho de Concluso de Curso.
3 DESENVOLVIMENTO
3.1 RECURSOS UTILIZADOS EM DISPOSITIVES MVEIS
3.1.1 PERSISTNCIA EM APLICATIVOS PARA DISPOSITIVOS MVEIS COM
J2ME
A capacidade de persistir dados ou armazenar informaes sem dvida um dos
recursos mais importantes em qualquer linguagem de programao. Armazenar
dados para uma posterior recuperao uma constante na maioria dos ambientes
computacionais, seja para persistncia simples de parmetros de configuraes de
algum sistema ou persistncia de informaes digitadas pelo usurio para alimentar
algum banco de dados. No que diz respeito persistncia 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 mveis. Essas diferenas podem ser observadas tanto do ponto de vista
do usurio (ergonomia de hardware e software), quanto do ponto de vista do
desenvolvedor (ferramentas de software, APIs e recursos). Os telefones celulares
conseguiram alcanar uma popularidade quase to grande quanto a observada na
utilizao de computadores pessoais a partir da dcada de 80. Mas, assim como
todos os dispositivos mveis, eles tambm trazem consigo algumas dificuldades,
como, problemas relacionados ergonomia do teclado, uma interface visual simples
porm limitada e a dependncia de baterias que requerem recarga constante.

3.1.1.1 J2ME e perfil MIDP

O Java 2 Micro Edition (J2ME) foi desenvolvido para contemplar toda a diversidade
computacional existente nos dispositivos mveis. A tecnologia J2ME conseguiu
abstrair conceitos e tcnicas para homogeneizar o desenvolvimento em dispositivos
mveis de forma completamente transparente. O perfil de informao de dispositivos
mveis, conhecido como MIDP (Mobile Information Device Profile) surgiu como
soluo para diferenciar alguns dispositivos que apesar de possuirem caractersticas
semelhantes, ainda assim so tecnologicamente diferentes. O perfil MIDP contempla
os aparelhos celulares e o responsvel pela
definio das APIs necessrias para a persistncia de dados.
3.1.2 RMS
O conjunto de classes responsveis 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 vrias chamadas de
um MIDlet (aplicao baseada no MIDP). Segundo a especificao MIDP, deve
haver, disponvel no dispositivo, pelo menos 8 kbytes de memria no-voltil (ROM)
para que os aplicativos persistam dados. Exemplos de memria no-voltil seriam
ROM, flash e etc. Em teoria, todo o espao livre na memria ROM, ou flash de um
dispositivo mvel, estaria disponvel aos aplicativos para persistirem seus dados. A
unidade bsica de dados mantida pelo RMS conhecida como RecordStore ou
repositrio 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 sero armazenados. Um RR mantm em sua estrutura um conjunto de
registros que podem ter tamanhos variveis. Um MIDlet um aplicativo executado
em um dispositivo mvel. 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 aplicao 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 atribudos aos RRs
precisam ser nicos. A verso 1.0 do MIDP no permitia o compartilhamento de RRs
entre MIDlets empacotados em diferentes arquivos JAR. A verso 2.0 do MIDP
corrigiu essa limitao, permitindo assim o compartilhamento de um RR por todas os
MIDlets instalados no dispositivo. As APIs do RMS no fornecem recurso para
travamento de registros. A implementao de um RR garante que a operao de
persistncia ser realizada de forma indivisvel e sncrona evitando eventuais
inconsistncias no caso de acessos mltiplos. Se for necessrio que um MIDlet
utilize mltiplas threads para acessar um RR, necessrio toda uma ateno para
manter a consistncia dos dados. Tambm, responsabilidade da implementao no
dispositivo fazer todo o possvel para garantir a integridade e a consistncia dos RRs
durante operaes normais ao seu uso como reinicializao, troca de baterias e etc.
Durante a desinstalao de um MIDlet do dispositivo, os armazns de dados
pertencentes a ele so removidos automaticamente.

3.1.3 Classe RecordStore

Qualquer operao de insero, atualizao e excluso de registros em um RR
provocam a atualizao automtica do seu nmero de verso e da data em que
ocorreu a mudana. O nmero da verso de um RR pode servir como referencial,
por exemplo, para algoritmos de replicao. uma maneira interessante de detectar
quantas vezes um RR foi modificado. Esses dois valores, o nmero da verso e a
data da atualizao, podem ser recuperados atravs do uso dos mtodos
getVersion() e getLastModified() respectivamente.
3.2 THREAD
Para programas "normais" (single thread), tem um nico ponto de execuo dentro
do programa num momento particular, um thread semelhante: tem um incio, uma
sequncia e um fim, como um programa "normal". Tem um nico ponto de execuo
no certo momento dentro de um thread. O thread no um programa, mas executa
dentro de um programa (ver figura). Definio: thread um fluxo nico de controle
sequencial dentro de um programa. A coisa fica mais interessante quando temos
mais de um thread no
mesmo programa.
Alguns autores chamam thread de "contexto de execuo".
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 maneira que
um recurso no seja modificado em simultneo, ou que os processos
no fiquem em espera que o recurso seja libertado. Os processos (aplicativos ou
programas) de um computador compartilham determinados recursos da chamada
regio crtica, que so as variveis globais, as instrues de E/S, algum banco de
dados, etc. Neste compartilhamento podem ocorrer erros. Exemplo: Uma escola
est fazendo sua matrcula apenas pela internet, o nmero de vagas 5, dois
usurios esto fazendo a matrcula no exato momento, finalizam a matrcula .A
operao que o programa usa da regio crtica: matrcula finalizada -1. Se os dois
usurios faze a operao ao memo tempo, quango a matriculate for finalized
subtree-se 1 vagal: Matriculate finalized -1 (5-1)=4 Matriculate finalized -1 (5-1)=4
Quango um Terceira usurio for Fazer seta mesa matrcula,o nmero de vagas ser
expresso como 4, sendo que na verdade deveria ser 3. Isto causar instabilidade e
poder comprometer todo o sistema. A soluo para este tipo de caso a certeza de
excluso mtua, isto , penas um processo pode acessar a regio crtica por vez. Os
mecanismos que implementam a excluso mtua utilizam um protocolo de acesso
regio crtica. Toda vez que um processo for executar sua regio crtica, ele
obrigado a passar por um controle de entrada e outro de sada.
3.3.1 Excluso Mtua Com Espera Ativa
Apenas um processo acessa a regio crtica de cada vez. Espera ativa faz testes
continuos em uma varivel, at que ela seja alterada, causando assim um grande
disperdicio de CPU. Abaixo temos solues para problemas como o mustard acima.

3.3.2 Desativando as Interrupes

A forma mais simples de garantir a excluso mtua fazer com que o processo
desabilite as interrupes ao entrar na regio crtica, e antes de sair as
habilite novamente. Com isso a CPU no far um chaveamento no momento em que
o processo estiver na regio crtica, pois o chaveamento vem de uma interrupo
atravs de um relgio.
3.3.3 Variveis de Bloqueio
Quando uma vriavel "lock" estiver como 0, significa que a regio crtica esta livre, e
1 esta ocupada. Assim, antes de entrar cada processo testa o valor da varivel
"lock", se for 0, coloca como 1 e entra na regio crtica, aps sair coloca o valor 0, se
o valor j for 1, aguarda at ser 0.
3.3.4 Alternncia Estrita
Neste metodo, criada uma varivel "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' no fica "preso" no while, e assim executa a
regio crtica, aps terminar, ele seta "turn" para 1 e parte para o resto do cdigo,
caso ocorra um chaveamento e o processo 'b' tente executar a regio crtica antes
que o processo 'a' sete "turn" como 1, ele ficara em um loop, apenas testando a
variavel "turn"(espera ativa).
3.3.5 Soluo de Peterson
Antes do processo entrar na regio crtica ele executa o procedimento
enter_region(), com o seu nmero. E aps sair da regio crtica, 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 no consegue ser atendido, pois
processos com maior prioridade "roubam" sua vez.
3.4 USABILIDADE DE INTERFACES PARA DISPOSITIVOS MVEIS
Um questionamento comum sobre as melhores prticas de front-end / usabilidade
para dispositivos mveis o quanto elas so especficas ao contexto mobile, pois
muitas delas no se distinguem das diretrizes que vm sendo difundidas h 20 anos.
fato que grande parte das diretrizes so semelhantes, mas o que muda a
criticidade quando tratamos de mobile. Algumas recomendaes tornam-se mais
graves e imperdoveis quando no so seguidas no projeto de interfaces para

dispositivos mveis. Como exemplo, podemos usar a questo da densidade

informacional. Em aplicaes que sero visualizadas em dispositivos mveis, os
textos devem ser concisos, eliminando informaes secundrias que podem ser
irrelevantes. Ora, mas isso tambm vale para aplicaes visualizadas em desktop!
, voc pensa. Porm, para mobile, a conciso deve ser ainda maior e informaes
que seriam aceitveis nas aplicaes web/desktop convencionais devem ser
removidas de aplicaes mobile. A diretriz base a mesma: reduzir informao
secundria. O que diferencia o grau de severidade que isto representa neste outro
cenrio.
3.4.1 Recomendaes Crticas Para o Projeto de Interfaces Mobile
Desenvolver sites e aplicaes para mobile requer ateno para alguns critrios que
tem um grande impacto na forma com que as pessoas interagem com estes
dispositivos.
3.4.1.1 Reduzir clicks
Esta parece ser uma recomendao bvia para ambiente mobile. Porm, quem j
desenvolveu para mobile ou utiliza aplicaes nestes dispositivos, pense: voc j
deve ter visto algum site que apresenta uma informao bem limitada na primeira
tela com um link de leia mais, onde voc tem o esforo de clicar e
esperar o carregamento do restante do contedo que voc necessita, que s vezes
poderia ser resumido em apenas uma tela. Se em um projeto usual de interface as
melhores prticas indicam que seria mais adequado disponibilizar toda a informao
necessria em uma nica tela e poupar cliques do usurio, porque esta diferena em
mobile? Por isso, deixar o contedo mais conciso crucial para que a informao
possa ser apresentada de modo objetivo e o menos fragmentada possvel.
3.4.1.2 Reduzir funcionalidades
Restringir a quantidade de funcionalidades, mantendo as que so necessrias ao
ambiente mobile, diminui a chance dos usurios se confundirem diante de todas as
possibilidades e opes oferecidas.
3.4.1.3 Reduzir contedo
Devido ao tamanho das telas, o contedo para mobile exige uma carga cognitiva
maior e, portanto, pode ser at duas vezes mais difcil de compreender. Como a
memria de curto prazo fraca, quanto mais os usurios tiverem que rolar para se
lembrar de um contedo, menos eles o faro.
3.4.1.4 Dar escolhas ao usurio
Textos mais concisos e funcionalidades mais restritas so necessrios. Mas
importante manter um link para a verso convencional do site, caso o usurio
precise acessar algum recurso que no esteja na verso mobile. O usurio deve ter
o direito de escolha sobre como ele deseja visualizar o site.

3.4.2 Outras Prticas Importantes Que Herdamos da Usabilidade Convencional

3.4.2.1 Integridade esttica
O quanto o design da sua aplicao se integra com a funo da mesma. o
casamento entre forma e funo, interface com boa qualidade esttica e funcional.
3.4.2.2 Consistncia
A consistncia de interface permite que o usurio transfira seus conhecimentos e
habilidades de uso de uma aplicao para outra. preciso frisar que uma aplicao
consistente no aquela que copia outras aplicaes. Pelo contrrio, uma
aplicao que tira proveito dos padres e paradigmas de interface com os quais as
pessoas se sentem mais confortveis durante a interao.
3.4.2.3 Metforas
Fcil reconhecimento e memorizao de palavras, smbolos e imagens.
3.4.2.4 Contexto do usurio
Especificao do ambiente do usurio, incluindo tambm a modelagem de anlise
de tarefa e objetivos de negcio.
3.4.2.5 Modelo mental
Organizao apropriada de dados, funes, tarefas, papis e pessoas de acordo
com o modo com que o usurio compreende e reconhece estes elementos.
3.4.2.6 Navegao
Navegao adequada considerando o modelo mental atravs de
janelas, menus, caixas de dilogos e painis de controle em formato compreensvel.
3.4.2.7 Interao e feedback
Input efetivo e feedback do output de informaes para assegurar ao usurio que
uma ao est em processamento.
3.4.2.8 Aparncia e design
Qualidade visual e ateno ao design com relao escala, proporo, ritmo,
simetria e balanceamento de componentes.
3.4.2.9 Visualizao de informaes
Apresentao de informaes por tabelas, grficos, mapas e diagramas. Uma vez
que a tela destes dispositivos ainda pequena em comparao aos computadores
comuns (mesmo se tratando de tablets), preciso se valer de componentes coringas

que so capazes de apresentar uma boa quantidade de informao de modo

compacto, conciso, de fcil visualizao e acessvel.
3.5 JAVA DB E DISPOSITIVOS MVEIS
O nmero atual de SGBDs que os desenvolvedores podem usar extenso, porm,
se filtrarmos por SGBDs que tambm possam ser usados no ambiente mvel, este
nmero 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 comeou 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 caractersticas semelhantes. Para
quem j utiliza a linguagem Java, esta pode ser uma tima opo, porque o Java DB
construdo 100% Java, alm de ser recomendado pela Sun.
4 GESTO E SEGURANA NO SISTEMA DE INFORMAO
4.1 ENGENHARIA SOCIAL
Em Segurana da informao, chama-se Engenharia Social as prticas utilizadas
para obter acesso a informaes importantes ou sigilosas em organizaes ou
sistemas por meio da enganao ou explorao da confiana 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
organizaes que no necessita da fora bruta ou de erros em mquinas. Explora as
falhas de segurana das prprias pessoas que, quando no treinadas para esses
ataques, podem ser facilmente manipuladas. Engenharia social compreende a
inaptido dos indivduos manterem-se atualizados com diversas questes
pertinentes a tecnologia da informao, alm de no estarem conscientes do valor
da informao que eles possuem e, portanto, no terem preocupao em proteger
essa informao conscientemente. importante salientar que, a engenharia social
aplicada em diversos setores da segurana da informao independente de
sistemas computacionais, software e ou plataforma utilizada, o elemento mais
vulnervel de qualquer sistema de segurana da informao o ser humano, o qual
possui traos comportamentais e psicolgicos que o torna suscetvel a ataques de
engenharia social. Dentre essas caractersticas, pode-se destacar:
Vaidade pessoal e/ou profissional: O ser humano costuma ser mais receptivo a
avaliao positiva e favorvel aos seus objetivos, aceitando basicamente
argumentos favorveis a sua avaliao pessoal ou profissional ligada diretamente ao
benefcio prprio ou coletivo de forma demonstrativa.
Autoconfiana: O ser humano busca transmitir em dilogos individuais ou coletivos
o ato de fazer algo bem, coletivamente ou individualmente, buscando transmitir
segurana, conhecimento, saber e eficincia, buscando criar uma estrutura base
para o incio de uma comunicao ou ao favorvel a uma organizao ou
indivduo.
Formao profissional: O ser humano busca valorizar sua formao e suas
habilidades adquiridas nesta faculdade, buscando o controle em uma comunicao,

execuo ou apresentao seja ela profissional ou pessoal

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 necessrio.
Busca por novas amizades: O ser humano costuma se agradar e sentir-se bem
quando elogiado, ficando mais vulnervel e aberto a dar informaes.
Propagao de responsabilidade: Trata-se da situao na qual o ser humano
considera que ele no o nico responsvel por um conjunto de atividades.
Persuaso: Compreende quase uma arte a capacidade de persuadir pessoas, onde
se busca obter respostas especficas. Isto possvel porque as pessoas possuem
caractersticas comportamentais que as tornam vulnerveis a manipulao.
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 solicitao via email.
Exemplo 2: voc recebe uma mensagem e-mail, onde o remetente o gerente ou
algum em nome do departamento de suporte do seu banco. Na mensagem ele diz
que o servio de Internet Banking est apresentando algum problema e que tal
problema pode ser corrigido se voc executar o aplicativo que est anexado
mensagem. A execuo deste aplicativo apresenta uma tela anloga quela que
voc utiliza para ter acesso a conta bancria, aguardando que voc digite sua
senha. Na verdade, este aplicativo est preparado para furtar sua senha de acesso
a conta bancria e envi-la para o atacante.
Exemplo 3: voc recebe uma mensagem de e-mail, dizendo que seu computador
est infectado por um vrus. A mensagem sugere que voc instale uma ferramenta
disponvel em um site da Internet, para eliminar o vrus de seu computador. A real
funo desta ferramenta no eliminar um vrus, mas sim permitir que algum 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 tcnico do
seu provedor. Nesta ligao ele diz que sua conexo com a Internet est
apresentando algum problema e, ento, pede sua senha para corrigi-la.
Caso voc entregue sua senha, este suposto tcnico poder realizar uma infinidade
de atividades maliciosas, utilizando a sua conta de acesso Internet e, portanto,
relacionando tais atividades ao seu nome. Estes casos mostram ataques tpicos de
engenharia social, pois os discursos apresentados nos exemplos procuram induzir o
usurio a realizar alguma tarefa e o sucesso do ataque depende nica e
exclusivamente da deciso do usurio em fornecer informaes sensveis 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 informao, a engenharia social tende a crescer e constituir-se numa
das principais ameaas aos sistemas de segurana das (grandes) organizaes.
Entretanto, embora as situaes apresentadas acima sejam um tanto indesejveis e
at certo ponto assustadoras, h mecanismos atravs dos quais uma organizao
pode implementar a fim de detectar e prevenir ataques de engenharia social. Tais
medidas visam, principalmente, atenuar a participao do componente humano.
Essas medidas compreendem:
Educao e Treinamento
Importante conscientizar as pessoas sobre o valor da informao que elas dispem
e manipulam, seja ela de uso pessoal ou institucional. Informar os usurios sobre
como age um engenheiro social.
Segurana Fsica
Permitir o acesso a dependncias de uma organizao apenas s pessoas
devidamente autorizadas, bem como dispor de funcionrios de segurana a fim de
monitorar as entradas e sadas de locais estratgicos dentro da organizao.
Poltica de Segurana
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 usurios de um sistema. Estimular o uso de senhas de difcil
descoberta, alm de remover contas de usurios que deixaram a instituio.
Controle de Acesso
Os mecanismos de controle de acesso tem o objetivo de implementar privilgios
mnimos a usurios a fim de que estes possam realizar suas atividades. O controle
de acesso pode tambm evitar que usurios sem permisso possam
criar/remover/alterar contas e instalar softwares
danosos organizao.
4.2 VULNERABILIDADE
4.2.1 Anlise de Vulnerabilidades
A Anlise consiste em identificar e eliminar sistematicamente vulnerabilidades do
sistema. As etapas para deteco, remoo e controle exigem acompanhamento de
profissional qualificado e ferramentas tecnolgicas. A integrao desses processos
produz maior segurana e proteo para os dados e sistema da Organizao. Todas
as aes tomadas devem ser documentadas no s para controlar futuras aes,
como tambm para consultas peridicas. Qualquer sistema que manipule dados
est sujeito a alguma vulnerabilidade. A conexo com a Internet representa uma das
principais formas de desestabilizao e roubo de informaes para qualquer Usurio
dentro de uma Organizao. Alm da Internet, h outras possibilidades de acesso
remoto que podem comprometer o sistema e a segurana de dados, tais como

bluetooth, infravermelho, etc. Toda essa possvel exposio dos dados pode
acarretar em invaso de rede e seus servidores, expondo informaes confidenciais
e violando a privacidade garantida por lei. A cada dia novas vulnerabilidades
surgem em decorrncia de brechas em softwares, imperfeies na configurao de
aplicativos e falha humana. A Anlise de Vulnerabilidades responsvel por garantir
a deteco, remoo e controle das mesmas. Visando sempre manter a integridade,
confidencialidade e disponibilidade, a Segurana da Informao enfrenta constantes
desafios para manter usurios e Organizaes protegidos de ameaas e falhas que
possam comprometer a normalidade das operaes. essencial a preocupao em
manter dados em sigilo e garantir o bom funcionamento de processos,
acompanhando o avano e disponibilizao de novas tecnologias.
4.2.2 A origem das Vulnerabilidades
Erros de programao
Grande parte das vulnerabilidades
surge do erro de tamanho do buffer, uma regio da memria reservada para escrita
e leitura dos dados.
M configurao
Aplicativos de segurana, como o firewall, devem ser corretamente configurados,
ou podem ser brechas para ataques maliciosos.
Falha humana
Execuo de arquivos maliciosos manualmente.
4.2.3 Principais Objetivos da Anlise de Vulnerabilidades
Identificar e tratar falhas de softwares que possam comprometer seu desempenho,
funcionalidade e segurana;
Providenciar uma nova soluo de segurana como, por exemplo, o uso de um bom
antivrus, com possibilidade de update constante;
Alterar as configuraes de softwares a fim de torn-los mais eficientes e menos
suscetveis a ataques;
Utilizar mecanismos para bloquear ataques automatizados (worms, bots, entre
outros);
Implementar a melhoria constante do controle de segurana;
Documentar os nveis de segurana atingidos para fins de auditoria e Compliance
com leis, regulamentaes e polticas. A Anlise de Vulnerabilidades torna a tomada
de deciso em relao segurana mais fcil, pois rene informaes essenciais
que indicam a melhor estratgia para se manter protegido de falhas, ataques e
invases. Alm disso, uma das facilidades obtidas atravs da implementao de
polticas de segurana descobrir e tratar vulnerabilidades com maior rapidez,
possibilitando o alinhamento s normas de compliance.
4.3 AMEAAS, ATAQUES E VULNERABILIDADES

Ameaa: 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 no
detalhes, tais como quais medidas de segurana ele deve superar
e quais vulnerabilidades explorar.
Avaliao de Ameaa (TA, do ingls Threat Assessment): Tentativa de prever as
ameaas. Podendo envolver o uso de conhecimentos sobre incidentes de segurana
antigos em uma estrutura semelhante a avaliada. Criar uma segurana proativa (e
no s reativa) para ameaas que ainda no se materializaram.
Vulnerabilidade: Uma fraqueza na segurana do sistema (ou falta de medidas de
segurana) que pode ser explorada por diferentes adversrios com diferentes
interesses.
Avaliao de Vulnerabilidade (VA, do ingls Vulnerability Assessment): Tentativa de
descobrir (e talvez demonstrar) vulnerabilidades de segurana que poderiam ser
exploradas por um adversrio. Uma boa avaliao de vulnerabilidade normalmente
sugere contramedidas viveis ou melhorias na segurana para eliminar ou mitigar a
vulnerabilidade, tambm ajuda na recuperao aps um ataque e que no se repita.
Gesto de risco: Tentativa de minimizar as fontes de riscos de segurana decidindo
como implantar, modificar, ou reatribuir recursos de segurana. Utiliza como entrada
para as decises os resultados da TA, da VA, os ativos a serem protegidos
(informaes dos clientes, reputao do sistema, etc.), as consequncias de ataques
bem sucedidos, e os recursos (tempo, financiamento, pessoal) disponvel para
providenciar segurana.
Ataque: Uma tentativa de causar danos a ativos valiosos, normalmente tentando
explorar uma ou mais vulnerabilidades. O dano pode incluir roubo de informaes,
sabotagem (defacement, backdoor, etc.), destruio (apagar banco de dados,
cdigos), espionagem, ou adulterao. Para mais exemplos s ver as notcias.
4.3.1 Alguns Exemplos de Ameaas e Vulnerabilidades
Ameaa: Adversrios podem instalar malware nos computadores da organizao
permitindo que eles possam roubar informaes pessoais para fingir ser outra
pessoa.
Vulnerabilidade: Os computadores da organizao no possuem as ltimas
definies do banco de dados de vrus para o software anti-malware.
Ameaa: Cyber Criminosos podem invadir o sistema e roubar o banco de dados.
Vulnerabilidade: A plataforma em que o sistema funciona permite escalar privilgios.
Ameaa: Um funcionrio mal instrudo pode revelar informaes confidenciais aos
adversrios.
Vulnerabilidade: Funcionrios no tem um bom entendimento de qual informao
sensvel/confidencial e qual no , logo eles no podem fazer um bom trabalho
protegendo-as de engenharia social.
Ameaa: Funcionrios descontentes podem sabotar o sistema.

Vulnerabilidade: A organizao carece de contramedidas efetivas para ameaas

internas como verificao do passado e mitigao de descontentamento de
funcionrios (tratamento justo de funcionrios, processos legtimos de resolver
reclamaes, programas de assistncia aos funcionrios, no toleramento de chefes
opressores, etc.)
Ameaa: Advanced persistent threat (APT) podem tomar o controle do ambiente
corporativo.
Vulnerabilidade: A organizao carece de uma defesa estratgica organizada com
potencial de tomar atitudes bem pensadas e nos momentos certos. Mitigar uma
vulnerabilidade pode no ser relevante para uma ameaa, pois o adversrio pode
no perceber uma vulnerabilidade. Vulnerabilidades no definem ameaas, pois um
adversrio deseja efetuar um ataque por um motivo externo. TAs e VAs so
diferentes, e ambas so necessrias para se ter uma boa gesto de risco, e ambas
so dependentes entre si at certo ponto. Hackers procuram explorar
vulnerabilidades, cuja ausncia levaria a seu fracasso. Assim como no teria
relevncia a existncia de vulnerabilidades se no existissem ameaas. No existe
uma relao de um para um entre vulnerabilidades e ameaas. Diferentes
adversrios podem explorar uma mesma vulnerabilidade para diferentes objetivos,
por exemplo, um computador desatualizado. Assim como uma ameaa pode
explorar vrias vulnerabilidades diferentes para atingir o seu objetivo. TA envolve em
sua maioria especular sobre pessoas que no esto em nossa frente, e que podem
muito bem no existir, mas que possuem motivaes
complexas, objetivos, mentalidades e recursos. Vulnerabilidades, por outro lado, so
mais concretas se formos espertos e criativos o suficiente para v-las. Elas so
descobertas atravs de uma anlise da estrutura e sua segurana, sem
especulaes sobre pessoas. Por esse motivo, o entendimento das vulnerabilidades
normalmente mais fcil que as ameaas. Algumas pessoas afirmam que os
incidentes anteriores de segurana nos dizem tudo o que precisamos saber sobre as
ameaas, mas isso ser reativo, no proativo, e deixa escapar raros, mas
catastrficos ataques. Argumenta-se que o conhecimento das vulnerabilidades
mais poderoso que o das ameaas. Pois ao pr um razovel esforo para mitigar as
vulnerabilidades, voc provavelmente estar em boa forma para qualquer que seja a
ameaa (que muito mais fcil de errar). E ser ignorante nas vulnerabilidades
permite aos adversrios vrios formas de atingir seu objetivo. Mas em qualquer
grande e complexo sistema existe um enorme nmero de vulnerabilidades. E
encontrar vulnerabilidades exige uma anlise minuciosa e imaginao/criatividade,
podendo chegar a um custo altssimo. Alm de que infelizmente entramos em
situaes inevitveis em que no podemos ter contato com o cdigo fonte de um
componente do nosso sistema, nos tornando dependentes de patchs que podem
demorar a chegar. A avaliao das ameaas, ao contrrio, normalmente carece de
uma anlise criativa sobre os problemas de segurana caracterizada pelo uso
simplrio de listas de verificao, auditorias de conformidade dos logs, diretrizes a
serem seguidas, bases de dados de incidentes de segurana passado e abordagens
generalizadas. Finalizando, no devemos confundir a inteno de uma TA ou VA.
No serve para certificar ou medir a segurana, ou como uma tcnica para descobrir
se algum no est fazendo algo direito. O objetivo de uma VA de melhorar a
segurana. O objetivo de uma TA nos ajudar a decidir (junto com a gesto de risco)

o que e quanto de segurana ns precisamos. Pois mesmo aps as avaliaes,

ainda existir ameaas e vulnerabilidades desconhecidas e no tratadas. O jeito
encarar que no poderemos ficar completamente protegidos, e utilizar as avaliaes
para atingirmos a segurana exigida.
4.4 MEDIDAS DE SEGURANA E POLTICA DE SEGURANA
A segurana dos sistemas informticos limita-se geralmente a garantir os direitos de
acesso aos dados e recursos de um sistema implementando mecanismos de
autenticao e de controlo que permitem garantir que os utilizadores dos ditos
recursos possuem unicamente os direitos que lhes foram concedidos. Os
mecanismos de segurana implementados podem, no entanto provocar um
embarao a nvel dos utilizadores e as instrues e regras tornam-se cada vez mais
complicadas medida que a rede se estender. Assim, a segurana informtica deve
ser estudada de maneira a no impedir os utilizadores de desenvolver os usos que
lhes so necessrios, e de fazer de modo a que possam utilizar o sistema de
informao em total confiana. a razo pela qual necessrio definir inicialmente
uma poltica de segurana, cuja implementao se faz de acordo com as quatro
etapas seguintes:
Identificar as necessidades em termos de segurana, os riscos informticos que
pesam sobre a empresa e as suas eventuais consequncias;
Elaborar regras e procedimentos a implementar nos diferentes servios da
organizao para os riscos identificados;
Supervisionar e detectar as vulnerabilidades do sistema de informao e manter-se
informado das falhas sobre as aplicaes e materiais utilizados;
Definir as aes a empreender e as pessoas a contatar em caso de deteco de
uma ameaa. A poltica de segurana , por conseguinte o conjunto das orientaes
seguidas por uma organizao (em sentido lato) em termos de segurana. A esse
respeito ela deve ser elaborada a nvel de direo da organizao interessada,
porque se refere a todos os utilizadores do sistema. A esse respeito, no cabe s
aos administradores informticos definir os direitos de acesso dos utilizadores, mas
aos responsveis hierrquicos destes ltimos. O papel do administrador informtico
, por conseguinte garantir que os recursos informticos e os direitos de acesso a
estes esto em coerncia com a poltica de segurana definida pela organizao.
Alm disso, j que o nico a conhecer perfeitamente o sistema, cabe-lhe fazer
aumentar as informaes relativas segurana sua direo,
eventualmente aconselhar as instncias de deciso sobre as estratgias a aplicar,
bem como ser o ponto de entrada relativo comunicao destinada aos utilizadores
sobre os problemas e recomendaes em termos de segurana. A segurana
informtica da empresa assenta num bom conhecimento das regras pelos
empregados, graas a aes de formao e de sensibilizao junto dos utilizadores,
mas deve ir, alm disso, e nomeadamente cobrir os seguintes campos:
Um dispositivo de segurana fsico e lgico, adaptado s necessidades da empresa
e aos usos dos utilizadores;
Um procedimento de gesto das atualizaes;
Uma estratgia de salvaguarda corretamente planificada;

Um plano de retoma aps incidente;

Um sistema documentado atualizado.
4.4.1 As causas da Insegurana
Distinguem-se geralmente dois tipos de insegurana:
O estado ativo de insegurana, ou seja, o no conhecimento pelo utilizador das
funcionalidades do sistema, algumas das quais lhe podem ser prejudiciais (por
exemplo, o fato de no desativar servios de redes no necessrias ao utilizador);
O estado passivo de insegurana, ou seja, a ignorncia dos meios de segurana
implementados, por exemplo, quando o administrador (ou o utilizador) de um
sistema no conhece os dispositivos de segurana de que dispe.
4.5 AUDITORIA DE SISTEMAS DE INFORMAO
De maneira geral, um planejamento de auditoria deve identificar problemas
potenciais de segurana da entidade, com base na legislao vigente, atividades e
transaes da empresa de forma a propiciar o cumprimento dos servios
contratados com entidade dentro dos prazos e de forma segura, estabelecendo a
natureza, oportunidade e extenso dos exames a serem efetuados em conjunto com
os termos constantes na sua proposta de servios para a realizao do trabalho.
A auditoria de sistemas de informao visa verificar a conformidade no dos
aspectos contbeis da organizao, mas sim do prprio ambiente informatizado,
garantindo a integridade dos dados manipulados pelo computador. Assim, ela
estabelece e mantm procedimentos documentados para planejamento e utilizao
dos recursos computacionais da empresa, verificando aspectos de segurana 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 so responsveis por equipamentos de TI e/ou sistemas
dentro da organizao. Em uma auditoria os objetivos de controle so estabelecidos
com base nas atividades da entidade, seu tamanho, qualidade de seus sistemas e
controle interno e competncia de sua administrao. necessrio 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, rgos e produtos da entidade
de modo que tais atividades no se desviem das normas preestabelecidas pela
organizao. Objetos de controle so metas de controle a serem alcanadas ou
efeitos negativos a serem evitados traduzidos em procedimentos de auditoria. Assim
os objetivos de controle so detalhados conforme o enfoque ao qual est
relacionado. Existed diversos areas que eases Objetivos pode contemplar como
segurana, atendimento s solicitaes externas, materialidade, altos custos de
desenvolvimento, grau de envolvimento dos usurios e outsourcing. Segundo o
COBIT, as metas a serem alcanadas em uma auditoria de Sistemas de Informao
se enquadraro 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 Incio do Projeto;
Planejamento do Projeto Integrado;

Recursos do Projeto;
Gerenciamento de Riscos do Projeto;
Planejamento do Projeto Integrado;
Recursos do Projeto;
Gerenciamento de Riscos do Projeto;
Planejamento da Qualidade do Projeto;
Controle de Mudanas no Projeto;
Mtodos de Planejamento de Garantia do Projeto;
Avaliao, Relatrios e Monitoramento do Desempenho do Projeto;
Concluso do Projeto.
Por fim, importante ressaltar que a necessidade de controlar e auditar os recursos
da tecnologia da informao e da comunicao nunca foi to grande. Para garantir
segurana e qualidade em seus processos e servios necessrio verificao e
controle constante.
4.5.1 O Auditor de Sistemas
O auditor de sistemas verifica a eficcia dos controles e procedimentos de
segurana existentes, a eficincia dos processos em uso, a correta utilizao dos
recursos disponveis, assessorando a administrao na elaborao de planos e
definio de metas, colaborando no aperfeioamento dos controles internos,
apontando deficincias e irregularidades que possam comprometer a segurana e o
desempenho organizacional. Com a larga utilizao da tecnologia para o
armazenamento das informaes contbeis, financeiras e operacionais, o auditor de
sistemas tem de se aprimorar no campo de atuao (processos) da organizao
para extrair, analisar banco de dados envolvidos e suportar decises das demais
reas de auditoria. A necessidade global de referncias nesse assunto, para o
exerccio dessa profisso, promoveram a criao e desenvolvimento de melhores
prticas como COBIT, COSO, ISO 27001 e ITIL. Atualmente a certificao CISA
Certified Information Systems Auditor, oferecida pela ISACA
Information Systems and Control Association uma das mais reconhecidas e
avaliadas por organismos internacionais, j que o processo de seleo consta de
uma prova extensa que requer conhecimentos avanados, alm de experincia
profissional e a necessidade de manter-se sempre atualizado, atravs de uma
poltica de educao continuada (CPE) na qual o portador da certificao deve
acumular carga horria de treinamento por perodo estabelecido. A formao
acadmica do auditor de sistemas pelos motivos acima acaba sendo multidisciplinar:
anlise de sistemas, cincia de computao, administrao com nfase em TI,
advocacia com foco em Direito da informtica - direito digital e correlatos.
5 CONCLUSO
Atravs da pesquisa e confeco deste trabalho foram apresentados vrios
recursos para dispositivos mveis, tais como a persistncia que a capacidade de
persistir dados ou armazenar informaes, bem como, threads, sincronismo de
processos, interface com os usurios e sobre o Java DB, um banco de dados 100%
Java que pode ser usado no ambiente mvel. Sobre os critrios utilizados para
atender a gesto e segurana dos sistemas de informao, foi observado que a

engenharia social um meio utilizado para obter acesso a informaes importantes

ou sigilosas em organizaes ou sistemas por meio da enganao ou explorao da
confiana das pessoas. Outros critrios foram estudados como as vulnerabilidades,
ameaas e ataques, as medidas de segurana e polticas de segurana e auditoria,
notando-se que a segurana dos sistemas informticos limita-se geralmente a
garantir os direitos de acesso aos dados e recursos de um sistema implementando
mecanismos de autenticao e de controlo que permitem garantir que os utilizadores
dos ditos recursos possuem unicamente os direitos que lhes foram concedidos.
REFERNCIAS
MORAIS / SOLER, Everson Matias de / Luciano. Projeto Interface HomemComputador.So Paulo. Editora Pearson, 2010
http://dl.acm.org/citation.cfm?id=2400111
http://0xmateusbraga.wordpress.com/2011/03/27/gestao-de-risco-ameaca-evulnerabilidades-na-seguranca/
http://www.modulo.com.br/solucoes/gestao-de-riscos-e-vulnerabilidades-de-ti-/o-quee-e-para-que-serve-a-analise-de-vulnerabilidadeshttp://tableless.com.br/usabilidade-de-interfaces-para-dispositivos-moveisparte1/#.Ujhf7z8pikp
http://pt.wikipedia.org/wiki/Sincronia_de_processos
http://pt.wikipedia.org/wiki/Thread_%28ci%C3%AAncia_da_computa%C3%A7%C3%
A3o%29
http://www.portugal-a-programar.pt/topic/56734-threads/
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- Umaabordagem-para-Computa%C3%A7%C3%A3o-Sustent%C3%A1vel.pdf
http://pt.kioskea.net/contents/623-introducao-a-seguranca-informatica
http://www.projetoderedes.com.br/aulas/ugb_auditoria_e_analise/ugb_apoio_auditori
a_e_analise_de_seguranca_aula_02.pdf
http://pt.wikipedia.org/wiki/Auditoria_de_sistemas