domingo, 15 de setembro de 2013

A culpa é sua!!!!

Tony Bradley, principal analista da Bradley Strategy group (veja seu perfil em http://blogs.csoonline.com/user/tbradley), escreveu artigo recente sobre segurança da informação intitulado A culpa é sua ((http://goo.gl/Ugn9CJ), falando sobre o fato da agencia nacional de segurança dos EUA (NSA) ter quebrado vários código de criptografia ao redor do mundo com o claro objetivo de espionagem.

Sinceramente, isso não é surpresa para mim. Aliás, demorou para que esse assunto viesse à tona e consequentemente, desencadeasse várias discussões do tipo:

- “Meus dados estão seguros?”;
- “Será que existe alguém me espionado?”;
- “Minha criptografia é segura?” etc..

O que mais me chama a atenção nesse artigo, não é o fato dos EUA ter tecnologia para efetuar esse tipo de operação (quebrar mensagem criptografadas), pois como já dito antes, isso não me surpreende. O que realmente me chama a atenção é o título do artigo, ou seja, meus dados que são espionados, meu código que é quebrado e a culpa é minha?

Sinto muito dizer, mas a resposta é sim! A culpa é minha, sua... nossa!!!!

Segundo recentes documentos da NSA, a agencia tem um budget de aproximadamente $250 milhões de dólares para construir supercomputadores para quebrar e interceptar mensagens criptografadas ou mesmo efetuar um ataque de força bruta no alvo que eles desejarem.

Agora vem o mais interessante. Apesar desse dinheiro todo, foi constatado também que os códigos quebrados possuíam um mau gerenciamento de criptografia, ou seja, chaves de criptografia fracas, senhas muito curtas, além de senhas ridículas e já “manjadas”.


Lição a ser aprendida: A criptografia de dados não oferece segurança suficiente para suas mensagens e dados, quando implementada sozinha. Para uma segurança forte, deve ser levado em conta outros fatores combinados com a criptografia de dados. Isso inclui não somente tecnologia, mas sim processos bem feitos, pessoas bem treinadas e com a devida ciência do quão importante e sensíveis são os dados manipulados.

Outra lição: Se a NSA pode quebrar sua criptografia, seu concorrente também pode (e vai) quebrá-la!!!

domingo, 1 de setembro de 2013

Termos e significados

Estou colocando aqui, alguns termos que mencionamos diariamente, porém nem sempre sabemos exatamente os real significado e mais, não sabemos também o quanto esses termos podem influir em nosso cotidiano.

Tentei explicar da maneira mais simples possível para um fácil entendimento. 

Segue:

Adware=> Do Inglês Advertising Software. Software especificamente projetado para apresentar propagandas. Muito comum aparecerem na hora de instalar um programa. Sua inclusão tem como objetivo o lucro através da divulgação.

Bot=> É um programa que, além de incluir funcionalidades de worms, sendo capaz de se propagar automaticamente através da exploração de vulnerabilidades existentes ou falhas na configuração de softwares instalados em um computador, dispõe de mecanismos de comunicação com o invasor, permitindo que o programa seja controlado remotamente. O invasor, ao se comunicar com o Bot, pode orientá-lo a desferir ataques contra outros computadores, furtar dados, enviar spam, etc.

Backdoor=> É um programa que permite a um invasor retornar a um computador comprometido. Normalmente este programa é colocado de forma a não ser notado.

Cross-site Scripting=> é um tipo de vulnerabilidade do sistema de segurança de um computador, encontrado normalmente em aplicações web que ativam ataques maliciosos ao injetarem client side script (scripts que rodam no lado do usuário o qual um script rodado no servidor não possui alcance) dentro das páginas web vistas por outros usuários. Um script de exploração de vulnerabilidade cross-site pode ser usado pelos atacantes para escapar aos controles de acesso que usam a política de mesma origem.

CyberWarfare=> Ciberguerra, também conhecida por guerra cibernética, é uma modalidade de guerra onde a conflitualidade não ocorre com armas físicas, mas através da confrontação com meios eletrônicos e informáticos no chamado ciberespaço.

Exploits=> É um programa malicioso projetado para explorar uma vulnerabilidade existente em um software de computador. São geralmente elaborados por hackers como programas de demonstração das vulnerabilidades, a fim de que as falhas sejam corrigidas, ou por crackers a fim de ganhar acesso não autorizado a sistemas.

Hacker=> Hackers são necessariamente programadores habilidosos (mas não necessariamente disciplinados) que se dedicam com intensidade incomum, a conhecer e modificar os aspectos mais internos de dispositivos, programas e redes de computadores. Graças a esses conhecimentos, um hacker frequentemente consegue obter soluções e efeitos extraordinários, que extrapolam os limites do funcionamento "normal" dos sistemas como previstos pelos seus criadores; incluindo, por exemplo, contornar as barreiras que supostamente deveriam impedir o controle de certos sistemas e acesso a certos dados.

Hacktivismo=> Uso de cyber ataques baseado em motivações políticas para promover uma causa especifica. Com intenção oposta de hackers que tem a intenção de roubo de dados industriais, o hacktivismo não é motivado por dinheiro, mas suas motivações são vingança, política, ideologia, protesto e o desejo de humilhar suas vitimas. Algumas técnicas usadas são: deformação de web sites e DDoS.

Hashes=> Um hash (ou escrutínio) é uma sequência de bits geradas por um algoritmo de dispersão, em geral representada em base hexadecimal, que permite a visualização em letras e números (0 a 9 e A a F), representando um nibble cada. O conceito teórico diz que "hash é a transformação de uma grande quantidade de dados em uma pequena quantidade de informações".

Keylogger=> É um programa capaz de capturar e armazenar as teclas digitadas pelo usuário no teclado de um computador. Normalmente, a ativação do keylogger é condicionada a uma ação prévia do usuário, como, por exemplo, após o acesso a um site de comércio eletrônico ou Internet Banking, para a captura de senhas bancárias ou números de cartões de crédito.

Malware=> é um software destinado a se infiltrar em um sistema de computador alheio de forma ilícita, com o intuito de causar alguns danos, alterações ou roubo de informações (confidenciais ou não). Vírus de computador, worms, trojan horses (cavalos de Tróia) e spywares são considerados malwares. Também pode ser considerado malware uma aplicação legal que por uma falha de programação (intencional ou não) execute funções que se enquadrem na definição supracitada.

Nibble => Sucessão de quatro cifras binárias (bits). 1 Nibble = 4 bits, 2 Nibble = 1 Byte = 8 bits, 4 Nibble = 1 Word = 2 Bytes = 16 bits. A sua importância deve-se ao fato que 4 é o número mínimo de dígitos binários necessários para representar uma cifra decimal. Os nibbles são, portanto, a base do sistema de codificação BCD, que representam números decimais como sucessões de nibbles que representam as cifras destes.

Port Scanners=> é usado para efetuar varreduras em redes de computadores, com o intuito de identificar quais computadores estão ativos e quais serviços estão sendo disponibilizados por eles. Amplamente usados por atacantes para identificar potenciais alvos, pois permite associar possíveis vulnerabilidades aos serviços habilitados em um computador.

Rootkit=> É um conjunto de programas que tem como fim esconder e assegurar a presença de um invasor em um computador comprometido. É importante ressaltar que o nome rootkit não indica que as ferramentas que o compõe são usadas para obter acesso privilegiado (root ou Administrator) em um computador, mas sim para manter o acesso privilegiado em um computador previamente comprometido.

Screenlogger=> É a forma avançada de keylogger, capaz de armazenar a posição do cursor e a tela apresentada no monitor, nos momentos em que o mouse é clicado, ou armazenar a região que circunda a posição onde o mouse é clicado.

Sniffers=> É usado para capturar e armazenar dados trafegando em uma rede de computadores. Pode ser usado por um invasor para capturar informações sensíveis (como senhas de usuários), em casos onde esteja sendo utilizadas conexões inseguras, ou seja, sem criptografia. Deixa a placa de rede em modo promíscuo.

Spyware=> É a palavra usada para se referir a uma grande categoria de software que tem o objetivo de monitorar atividades de um sistema e enviar as informações coletadas para terceiros. Podem ser usadas de forma legítimas, mas, geralmente são usadas de forma dissimulada, não autorizada e maliciosa. Tem com principal ferramenta o uso de uma URL falsa.

SQL (Structure Query Language)=> Linguagem de consulta estruturada, padrão no gerenciamento de dados que interage com os principais bancos de dados baseados no modelo relacional.

Trojan=> É um programa que se passa por um "presente" (por exemplo, cartões virtuais, álbum de fotos, protetor de tela, jogo, etc.) que além de executar funções para as quais foi aparentemente projetado, também executa outras funções normalmente maliciosas e sem o conhecimento do usuário.

Vírus=>É um programa de computador malicioso que se propaga infectando, ou seja, inserindo cópias de si mesmo e se tornando parte de outros programas e arquivos de um computador. O vírus depende da execução dos arquivos hospedeiros para que possa se tornar ativo e continuar o processo infecção.

Worm=> É um programa capaz de se propagar automaticamente através de redes, enviando cópias de si mesmo de computador para computador. Diferente do vírus, um worm não embute cópias de si mesmo em outros programas ou arquivos e não necessita ser explicitamente executado para se propagar. Sua propagação se dá através da exploração de vulnerabilidades existentes ou falhas na configuração de softwares instalados em computadores.


Espero que tenha ajudado a entender um pouco mais dos termos usados não somente no mundo de segurança, mas sim no dia a dia da área de informática.

Um grande abraço a todos!

terça-feira, 13 de agosto de 2013

11 dicas para avaliar riscos em um projeto de TI – 11 – Economia na formação


Não sei dizer quantos lideres de projeto irão descontar do orçamento de treinamento quando tiverem de encarar custos extras. Ou quantos líderes presunçosos alegam que o sistema é tão simples que os usuários não precisam de treinamento. Caso você escute, “treinaremos parte

da equipe com metade das aulas e assim eles poderão treinar os outros”, ou “nossos usuários são muito bons em aprender, eles podem compreender este novo sistema em apenas alguns dias”, você saberá que está a caminho do fracasso. Não são apenas os usuários que precisam de treinamento, mas os lideres de projeto, os solucionadores de problemas e a equipe de funcionários do suporte. Esteja preparado para atrasar o projeto caso o treinamento apropriado não seja dado.

11 dicas para avaliar riscos em um projeto de TI – 10 – As expectativas não foram definidas


Quando um novo sistema está substituindo um sistema antigo, é útil para todos compreender as novas expectativas. Como o novo sistema irá se comportar? O que mudou nas transações e nos tempos de transação? Para quem os usuários finais devem ligar caso encontrem problemas? Quando tempo a equipe de solução de problemas estará presente durante o lançamento? Um novo sistema sempre irá frustrar as pessoas, mas, caso você defina expectativas realistas e dê para as pessoas opções de suporte acelerado, os problemas tendem a sumir de modo mais rápido e você termina com clientes mais satisfeitos em pouco tempo.

11 dicas para avaliar riscos em um projeto de TI – 9 – A data de lançamento é em um final de semana ou feriado


Muitos líderes de projeto planejam eventos de lançamento para finais de semana ou feriados, devido as menores chances de interrupção de serviço para funcionários ou clientes. Enquanto louváveis, essas oportunidades também tendem a ser os momentos em que o suporte

tecnológico é mais difícil de ser contatado. Você pode ter seu fornecedor primário no local, mas o suporte tecnológico terceiro pode estar fechado ou ocupado (e pode não estar retornando ligações em tempo hábil), e o mesmo pode ocorrer com sua equipe.

Conversar com o especialista em base de dados pelo telefone enquanto ele está de férias com sua família nunca é a melhor opção.

11 dicas para avaliar riscos em um projeto de TI – 8 – As recomendações dos especialistas foram rejeitadas


Existem pessoas que pedem por conselhos de especialistas e não dão ouvidos a eles, e então escolhem um caminho diferente – sempre. E depois reclamam quando algo não funciona corretamente.
 
Não seja essa pessoa. Não deixe que essa pessoa tome grandes decisões em sua equipe. Está tudo bem pedir por conselhos de especialistas e depois fazer algo diferente. Isso faz parte da natureza humana, e é muitas vezes o sinal de um bom líder. Apenas não o faça compulsivamente. Mais importante ainda, se você for contra as recomendações e o resultado não funcionar, não culpe o consultor. 

Desviar das recomendações do fornecedor ou consultor significa testar os resultados de sua mudança antes de lançar o projeto. Até mesmo caso o fornecedor ou consultor concorde com seu desvio da recomendação deles, certifique-se de que a mudança seja testada. Muitos projetos falharam depois dos lideres de projeto “realizarem algumas pequenas mudanças” que deixaram os fornecedores e consultores profundamente contrariados. Você ficaria surpreso com quantos especialistas permanecem em silêncio em frente de clientes que parecem saber mais do que os experientes consultores. Todo mundo quer ser amigo. Todo mundo espera que funcione.

Não tenha esperanças. Teste. E dê ouvidos a seus especialistas na maioria das vezes.

terça-feira, 30 de julho de 2013

11 dicas para avaliar riscos em um projeto de TI – 7 – Não existe um plano de recuperação no caso de falhas



Apesar de nossos melhores esforços, os planos nem sempre ocorrem como esperado. Todo líder de projeto precisa saber qual será a aparência do resultado final – e quando será a hora de admitir a falha e começar novamente. Todo projeto deve ter um plano secundário de lançamento caso o fracasso se torne a única opção.

Muitos eventos de lançamento são orientados pela crença de que “nada pode dar errado”. Os lideres desses projetos muitas vezes falham em garantir que boas cópias de segurança sejam feitas e verificadas. Eles não desenvolvem protocolos para definir o sucesso, e nem esboçam antecipadamente qual seria a aparência de uma falha. Eles não preparam a equipe para o que fazer diante de um erro no lançamento. Muitos projetos completamente novos alcançam um obstáculo fatal apenas para descobrir que não podem voltar atrás, graças a um planejamento pobre.

Com algumas exceções, os projetos devem ter planos para falhas, e, quando o fracasso for grande demais, devem permitir o retorno para o sistema anterior. Claro, falhar é vergonhoso e ninguém quer ter planos para tal acontecimento. Mas não ser capaz de recuperar-se durante uma falha de serviço acaba com uma carreira.

Tornar a diretoria ciente de que você possuía um plano secundário e que seguiu ele até sua meta quando o fracasso ocorreu é uma forma de ganhar elogios. Deixar que um evento de inatividade perdure por muito tempo à medida que você explica para a administração que não existe uma forma de voltar e que o caminho à frente não tem uma aparência muito boa é uma conversa completamente diferente. Planeje obter sucesso, mas também possua um plano para o caso de um fracasso.

Algumas boas dicas para se ter um plano de recuperação de falhas podem ser encontradas dando um lida nos livros de boas práticas ITIL,  normas da família ISSO 27000, COBIT, PMI entre outros.

segunda-feira, 15 de julho de 2013

11 dicas para avaliar riscos em um projeto de TI – 6 – Não foi dada a devida importância aos testes.


Os testes, tão importantes porém, muitas vezes desprezados pelos gerentes de projeto.
 
Não precisa!!!!
Tenho certeza que está tudo funcionando corretamente!!!
Não vai dar tempo...vamos que vamos!!!!!
Ninguém vai notar se sair alguma “coisinha errada”.....
Depois corrigimos a falha!!!!!

Daria um livro se eu fosse colocar todas as desculpas que já ouvi para não serem efetuados testes antes da implantação de um novo projeto: seja atualização do sistema operacional nas máquinas dos usuários como a implantação de um novo ERP na empresa.
Um modo muito útil e com um retorno fantástico é escolher usuários chaves em alguns departamentos. Pode ser até aquele usuário crítico para TI, pois além dele se sentir ouvido ele vai perceber que os resultados obtidos com os testes feitos por ele, serão ouvidos e de grande valia para minimizar os problemas na hora da implantação.
Veja: os problemas serão minimizados, pois com certeza haverá problemas, haverá imprevistos, porém colocando os usuários do seu lado, a resolução desses por menores serão mais tranquilas e a pressão em cima da equipe bem menor.






 
 
 
 
 
 
 
 

11 dicas para avaliar riscos em um projeto de TI – 5 – O projeto usa as especificações mínimas de hardware


Uma das coisas que podem acabar com um projeto é adquirir as especificações mínimas de hardware. Com a justificativa de não elevar os custos do projeto, muitos gerentes adquirem as configurações mínimas de hardware.
Só um detalhe: o nome já diz “Configuração mínima de hardware”, ou seja, configuração para rodar o aplicativo, pronto! Simples assim!

Imagina adquirir o mínimo de hardware para rodar um servidor Windows. Você instala o software no hardware recém adquirido com sucesso e sem problemas.
Após uma semana, com o servidor funcionando no ambiente de produção, a performance começa a cair, pois não foram considerados “pequenos detalhes” como:

- Quantidade de usuários acessando o servidor simultaneamente;

- Quantidade de compartilhamentos;

-Aplicativos rodando no servidor,

-Instalação de um firewall, entre outros.

Hoje em dia, o hardware não é tão custoso como há 30 anos atrás, onde uma placa mãe chegava a custas mais de R$5000,00 (moeda referente a época, claro).
Nas empresas que trabalhei, sempre sugeri o dobro dos requisitos mínimos de hardware, justamente para não correr o risco de não conseguir rodar o aplicativo por problemas de hardware, ou então esperar uma eternidade para efetuar determinadas configurações, devido a limitação de hardware.

Um teste bem simples comprova o que acabei de escrever: adquira um computador (desktop ou notebook), com as configurações mínimas para a instalação do Windows. E mais, tente instalar e rodar o Office nessa mesma máquina.
E vocês, qual a estratégia usada para não cair nessa armadilha?

segunda-feira, 1 de julho de 2013

11 dicas para avaliar riscos em um projeto de TI – 4 – Os usuários tiveram pouco ou nenhum envolvimento


É de extrema importância envolver os usuários no dia a dia do projeto. Uma ótimo forma de efetuar tal ação é eleger usuários chaves de diferente departamentos e solicitar o uso da nova ferramenta, aplicativo ou software, com o objetivo de fornecer um feedback periódico do que precisa ser melhorado, do que está rodando de acordo ou mesmo fornecer uma ideia que não tinha sido levado em conta, por não conhecer detalhes das tarefas daquele determinado departamento.

Envolver o usuário tem outras vantagens, por exemplo, uma aceitação mais rápida das pessoas da empresa, por ver que uma pessoa chave de seu departamento aceitou essas mudanças.

Também em caso de algum problema, a resolução é mais fácil e menos estressante, pois você terá a ajuda e o empenho dos usuários para a resolução desse contratempo.

Em um projeto de grande porte, ter o usuário a favor é de grande valia, porém, tê-los contra é uma tremenda desvantagem.

terça-feira, 25 de junho de 2013

11 dicas para avaliar riscos em um projeto de TI – 3 - Reuniões foram agendadas sem preocupação com a disponibilidade dos membros da equipe.



Trabalhei em um lugar e passamos um período, onde estávamos com sérios problemas com a logística de peças e componentes de informática.

Uma filial localizada no Ceará necessitava de uma peça para efetuar a troca da mesma em um computador. Muitas vezes a filial de Pernambuco possuía essa peça em estoque, porém a mesma era solicitada para a matriz em São Paulo, gerando custos muito altos.

Tendo esse cenário foi agendada uma reunião com a equipe envolvida no processo referente a envio de peças para as filiais, juntamente com os responsáveis pela logística na empresa. Foi enviado o convite para a reunião e todos aceitaram, com exceção do diretor de logisitica da empresa, pois o mesmo estava de férias e estava fora do país.

Resultado: O problema foi postergado por mais um bom tempo antes de ser resolvido e mesmo assim, foi resolvido após ordem direta do CEO da empresa.

Nem preciso dizer que foi um stress desnecessário.

11 dicas para avaliar riscos em um projeto de TI – 2 - Não existe um plano detalhado do projeto




Sim, é trabalhoso, mas é extremamente importante existir um plano para um novo projeto ou mudança de um projeto.

Quando se existe um projeto sem cronograma, escopo, requisitos, partes envolvidas, riscos do projeto entre outros, a probabilidade do projeto dar errado é muito grande.

Tudo bem, você recebeu a incumbência de coordenar um projeto que não possui um plano ou um mínimo de informações sobre o mesmo. A solução para isso é extremamente simples: desenvolva e formalize um plano o mais detalhado possível para esse projeto, de cada fase. Desse modo, você poderá ter uma visão de quem será responsável por cada tarefa do projeto e toda equipe deverá cumprir suas obrigações dentro de cada fase do projeto, sem pular etapas, que muitas vezes não é dado o devido valor.

Como li num artigo recente: “Falhar ao planejar é planejar para falhar”.