Todos trabalhos de ADS Unopar

Prévia do material em texto

29
Sistema de Ensino Presencial Conectado
Tecnologia em Análise e Desenvolvimento de Sistemas
ANA CAROLINA TEIXEIRA DOS SANTOS
Atividade Interdisciplinar - Individual
Gurupi - TO
2014
ANA CAROLINA TEIXEIRA DOS SANTOS
Atividade Interdisciplinar - Individual
Trabalho apresentado ao Curso de Tecnologia em Análise e Desenvolvimento de Sistemas da Universidade Norte do Paraná – UNOPAR
Professores:	Anderson Gonçalves
Adriane Loper
Marco Ikuro Hisatomi
Paulo K. Nishitani
Veronice de Freitas
Gurupi - TO
2014
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 Convencional ....................................................................................................................................13
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	A origem 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
INTRODUÇÃO
Neste trabalho será abordada toda a matéria do 6º Semestre, dentro deste contexto serão apresentados vários recursos utilizados em dispositivos móveis, como a persistência dos dados, threads e sincronia de processos.
Ainda contexto dos sistemas móveis será mostrado à usabilidade de interfaces para dispositivos móveis, e podendo como isso trazer benefícios para o usuá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.
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.
 RECURSOS UTILIZADOS EM DISPOSITIVES MÓVEIS
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. 
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 Information Device 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 responsável pela definição das APIs necessárias para a persistência de dados.
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 8 kbytes 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 dados. Também, é responsabilidade da implementação no dispositivo fazer todo o possível para garantir a integridadee 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.
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.
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.
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 3 applets 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 "Program Counter";
Chamamos isso o "contexto de execução do thread";
Alguns autores chamam thread de "contexto de execução".
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 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.
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.
Desativando as Interrupções
A forma mais simples de garantir a exclusão mútua é fazer com que o processo desabilite as interrupções ao entrar na região crítica, e antes de sair as habilite 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.
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.
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).
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, executa leave_region().
Deadlock
Dois ou mais processos ficam irreversivelmente bloqueados.
Starvation
Um processo fica sempre no final na fila e não consegue ser atendido, pois processos com maior prioridade "roubam" sua vez.
Usabilidade de interfaces para dispositivos móveis
Um questionamento comum sobre 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.
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 interagem com estes dispositivos.
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.
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.
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.
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.
Outras Práticas Importantes Que Herdamos da Usabilidade Convencional
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.
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.
Metáforas
Fácil reconhecimento e memorização de palavras, símbolos e imagens.
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.
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.
Navegação
Navegação adequada considerando o modelo mental através de janelas, menus, caixas de diálogos e painéis de controle em formato compreensível.
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.
Aparência e design
Qualidade visual e atenção ao design com relação à escala, proporção, ritmo, simetria e balanceamento de componentes.
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.
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 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 Personal Basis 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: EmbeddedSimpleDataSource ds = new EmbeddedSimpleDataSource();
2: String dbName = "simpleMobileDB";
3: ds.setDatabaseName(dbName);
4: ds.setCreateDatabase("create"); 
5:         
6: Connection conn = null;
7: Statement s = null;
8: PreparedStatement ps = null;
9: ResultSet rs = null;    
10: 
11: try {
12:     conn = ds.getConnection();
13:     s = conn.createStatement();
14: 
15:     s.execute("create table streetaddr(num int, addr varchar(40))");
16:          
17:     s.execute("insert into streetaddr values (1956, 'Dado')");
18:                       
19:     ps = conn.prepareStatement("update streetaddr set num=?, addr=? 
             where num=?");
20:            
21:     ps.setInt(1, 180);
22:     ps.setString(2, "Grand Ave.");
23:     ps.setInt(3, 1956);
24:     ps.executeUpdate();
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.
Gestão e segurança no sistema de informação
engenharia social
Em Segurança da informação, chama-se Engenharia Social as 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 valorizarsua 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 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 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.
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.
vulnerabilidade
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.
A origem 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.
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.
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.
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, doinglês Threat Assessment): 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 Vulnerability Assessment): 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.
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.
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: Advanced persistent threat (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 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.
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 de direçã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, 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 salvaguarda corretamente planificada;
Um plano de retoma após incidente;
Um sistema documentado atualizado.
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.
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.
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;
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.
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 – 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 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 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.
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.
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=2400111
Acessado em: 23/09/2014
http://0xmateusbraga.wordpress.com/2011/03/27/gestao-de-risco-ameaca-e-vulnerabilidades-na-seguranca/
Acessado em: 23/09/2014
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/2014http://tableless.com.br/usabilidade-de-interfaces-para-dispositivos-moveis-parte1/#.Ujhf7z8pikp
Acessado em: 26/09/2014
http://pt.wikipedia.org/wiki/Sincronia_de_processos
Acessado em: 30/09/2014
http://pt.wikipedia.org/wiki/Thread_%28ci%C3%AAncia_da_computa%C3%A7%C3%A3o%29
Acessado em: 30/09/2014
http://www.portugal-a-programar.pt/topic/56734-threads/
Acessado em: 30/09/2014
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.pdf
Acessado em: 02/10/2014
http://pt.kioskea.net/contents/623-introducao-a-seguranca-informatica
Acessado em: 02/10//2014
http://www.projetoderedes.com.br/aulas/ugb_auditoria_e_analise/ugb_apoio_auditoria_e_analise_de_seguranca_aula_02.pdf
Acessado em: 02/10//2014
http://pt.wikipedia.org/wiki/Auditoria_de_sistemas Acessado em: 02/10//2014