Como avaliar a segurança do seu sistema com testes ?

             Recentemente temos visto diversos tipos de ataques hackers a sites e sistemas de governo e até em sistemas de umas das mais renomadas instituição de investigação do mundo, FBI.  Lulzsec, um grupo ativista de hackers que, apesar do curto período de 50 dias de existência,  conseguiu cumprir o seu principal objetivo: Mostrar o quão vulnerável são os sistemas ao nosso redor, inclusive sistemas de pagamentos digitais bastante usados pelo mundo.

Após ler várias reportagens sobre ataques hackers pelo mundo, fiquei curioso sobre o estado da arte de teste na área de segurança e encontrei um organização chamada OWASP, que tem a missão de fazer com que aplicações de segurança sejam visíveis para que pessoas e organizações possam tomar decisões sobre os verdadeiros riscos de segurança de uma aplicação.  A OWASP é uma organização, que qualquer pessoa pode participar e todo material disponibilizado pela mesma esta sob a licença de software aberta.

Como todo bom engenheiro de teste, sabemos que para garantir a qualidade do software, temos que nos preocupar  e procurar se envolver em todas as fases do desenvolvimento do software. Por isso apesar de muitos princípios definidos pela OWASP estarem voltados para as fase iniciais do desenvolvimento dos sistemas, os considero também relevantes para os engenheiros de testes. Estes princípios recomendados pelas OWASP são coleções de propriedades, comportamentos, design e práticas de implementação para reduzir a probabilidade de ataques e também minimizar os impactos quando os ataques acontecem. São eles:

  1. Aplique a defesa-em-profundidade – Este princípio significa a definição de mecanismos de segurança em camadas, ou seja, se em caso de ataque causar uma falha em um mecanismo de segurança, outros mecanismos devem prover a segurança necessária para proteger o sistema.
  2. Utilizar o modelo de segurança positiva – Comumente conhecida com lista branca, pode ser aplicada em diversas áreas de segurança. Em vez de definir uma lista do que é proibido e permitir o resto, o modelo de segurança positiva consiste em definir uma lista do que é permitido e rejeitar qualquer outra coisa.
  3. Falhar com segurança – Como desenvolvedor, você deve considerar que há apenas 3 possibilidades de saídas em um mecanismos de segurança: Permitir a operação;  Não permitir a operação e exceção. E quando um mecanismos de segurança gerar uma exceção, você deve garantir que ela deve seguir o caminho de não permitir a operação, ou seja, métodos comuns como isAutorized(), isAutenticated, e validate() devem retornar sempre falso caso ocorra alguma exceção.
  4. Rodar com privilegio mínimo – Este princípio recomenda que cada conta tenha o mínimo privilegio necessário para realizar seus processos dentro do sistema.
  5. Evitar a segurança por obscuridade – Segurança através da obscuridade é a confiança no sigilo da implementação de um sistema ou componentes de um sistema para mantê-lo seguro.  Um exemplo seria um sistema de criptografia, apenas a chave precisa continuar em segredo, o algoritmo não precisa ficar em segredo.
  6. Mantenha a segurança simples – Modismos de engenharia de software preferem certas abordagens excessivamente complexas para o que seria relativamente simples. Os desenvolvedores devem evitar o uso de negativos duplos e arquiteturas complexas quando uma abordagem mais simples seria mais rápida.
  7. Detecte intrusões – Detectar intrusões requer 3 elementos básicos: Capacidade de registrar eventos relevantes de segurança em logs; Procedimentos que garantem que os logs são monitorados regularmente; Procedimentos para responder adequadamente quando uma intrusão for detectada;
  8. Não confie na infraestrutura – Este principio reforça o primeiro da lista. Cada mecanismo de segurança está sujeito a falhas e por isso não se deve confiar plenamente em alguns desses mecanismos, incluindo os de infraestrutura.
  9. Não confie em serviços – Muitas organizações utilizam capacidade de processamento  de terceiros, que na maioria das vezes possuem políticas de segurança diferentes. Por isso todos os sistemas externos devem ser tratados de forma semelhantes.
  10. Estabeleça padrões de segurança – Há muitas maneiras de entregar uma experiência “fora do comum” para os usuários. No entanto esta experiência deve ser segura, e deve esta nas mãos do usuário decisão de reduzir sua segurança. Por padrão a expiração e complexidade da senha deve estar habilitada. Os usuários poderão ser autorizados a desabilitar estas duas características para simplificar o uso da aplicação e aumentar o seu risco
             Além dos princípios recomendados, a OWASP também desenvolveu um guia de testes de segurança, neste documento ele ensina algumas técnicas e ferramentas mais usadas por hackers para ataques em sistemas web e que devem ser usadas para avaliar a segurança do sistema web em desenvolvimento.  Espero que gostem e aproveitem !!!

#TGIF – A era da revolução científica

Na seção de comentários do meu penúltimo TGIF que fala sobre conceitos, protótipos e ficção científica, recomendei um livro chamado Visões do futuro do fisíco teórico americano Michio Kaku, e no momento que estava procurando informações na internet sobre este autor, encontrei no youtube um vídeo muito interessante da BBC na qual Drº Michio participa como locutor principal, esta matéria é chamada Revolução da inteligência, e parte de uma série da BBC na qual tenho certeza que é baseado nesse livro de Visões do Futuro do Drº Michio Kaku, as outras matérias da série chamam-se respectivamente de revolução biotecnológica e revolução quântica .

Para não estender o post vamos apenas falar sobre a primeira matéria da série (Revolução da inteligência), que já levanta diversos pontos de discussão. Nesta primeira parte, Drº Michio explica como a ciência está avançando tão rapidamente a partir do momento que descobrimos o segredo da matéria (Átomo), revelamos a molécula da vida (DNA) e criamos uma forma de inteligência artificial (Computador). Ele argumenta que a descoberta das leis fundamentais da natureza no século 20, abre portas para um número imensurável de possibilidades no século 21 no qual nós estamos fazendo parte desta transição histórica de uma era de descobertas científicas para uma era de domínio científico.

Inicialmente esta revolução que estar por vir parece um pouco assustadora, mas se pararmos um pouco e voltarmos para mais de 70 anos atrás quando tivemos umas das primeiras cirurgias cardíacas de sucesso feitas pelo Dr. Alfred Blalock em parceria com Vivien Thomas, muito bem contada no filme Quase Deuses, percebemos que todos nós naturalmente resistimos um pouco à uma revolução desse tipo e sempre questionamos qual será o limite para isso tudo.

Para se ter uma idéia do tamanho do impacto social que esta revolução está por fazer, posso destacar alguns questionamentos que os cientistas estão imaginando que possam vir junto com esta revolução:

– Na evolução da realidade virtual e redes sociais virtuais, surge a questão de o que acontecerá se nós começarmos a preferir nossa redes sociais virtuais do que a nossa rede social real ? Isso surge porque hoje já temos mais de 30 milhões de pessoas no mundo que passa em média 20 horas por semana no mundo virtual, por exemplo World of Warcraft.

– Na área de inteligência artificial, onde teremos um evolução tão grande que as máquinas cada vez mais terão a capacidade de agir como a inteligência humana, surge a questão de como nós vamos nos relacionar com estas máquinas ?

– Uma última e intrigante pergunta surge com o avanço das tecnologias biológicas e eletrônicas na qual nos próximos 50 anos poderemos ter máquinas com mais componentes biológicos e pessoas com mais componentes eletrônicos. Daí surge a questão de como vamos categorizar o que é pessoa e o que  é máquina ?

Assistam o vídeo abaixo, tem quase uma hora de duração e infelizmente não está com legendas, e vamos discutir o que vocês que podem acontecer quando esta nova realidade estiver mais próxima ao nosso cotidiano.

No futuro conversaremos sobre as outras matérias da série bastante interessante da BBC.

A série – Thank God It’s Friday ou #TGIF – aborda sempre um conteúdo menos técnico, mas que ainda assim possa contribuir com o seu crescimento pessoal e profissional.

Leia, também, outros artigos já publicados na série:

– Steve Jobs e seu legado

– “Tudo” sobre o iPhone 5

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

Cobertura de código, como ?

No meu ultimo post falei sobre a importância da cobertura de código e o quanto ele é comumente utilizado com critério de saída nas primeiras fases de um projeto de software. Lá eu falei das duas técnicas de medição de cobertura de código mais usadas, são elas a Statement Coverage e Decision Coverage. Agora venho escrever este post para cumprir a promessa que deixei no ultimo post, que é mostrar na prática como utilizar uma ferramenta para fazer a medição da cobertura dos testes, neste exemplo, unitários.

A ferramenta que utilizei para exemplificar as duas técnicas acima foi um plugin para o Eclipse chamada CodeCover.
CodeCover é uma ferramenta de teste glass-box grátis e desenvolvido em 2007 na Universidade do Stuttgart.

Para iniciarmos o exemplo, vou mostrar uma classe (Example.java) com dois métodos bastante simples para facilitar o entendimento das técnicas utilizadas.

public class Example {

	public void firstExample(int a, int b) {
		int c =  a + (2*b);
		if (c>50){
			System.out.println(c);
		}
		System.out.println("Fim 1");
	}
}

Abaixo temos os primeiros testes unitários escritos na classe ExampleTest.java para verificar o funcionamento do método firstExample(int a, int b).

	@Test
	public void testFirstExample() {
		try {
			ex.firstExample(20, 15);
		} catch (final Exception e) {
			Assert.fail();
		}
		Assert.assertTrue(true);
	}

	@Test
	public void testFirstExample1() {
		try {
			ex.firstExample(20, 25);
		} catch (final Exception e) {
			Assert.fail();
		}
		Assert.assertTrue(true);
	}

Para medir a cobertura dos testes acima apenas precisamos marcar as classes Example e ExampleTest para ser usado pela ferramenta de Medição de Cobertura ( Figura 1)

Tela 1 - Clique para ampliar

Após marcar as classes envolvidas (classe de teste e classe a ser testada), iniciamos a execução dos testes no modo CodeCover para JUnit. Ao finalizar a execução dos testes, aparecerá uma aba chamada Test Sessions, no qual podemos marcar os teste unitários executados e visualizar as linhas de código da classe testada que foram exercitado pelo teste. Na tela 2 abaixo podemos ver que o teste testFirstExample exercitou apenas 3 linhas de código de um método que possue 4 linhas de código.

Tela 2 – Clique para ampliar
Tela 3 – Clique para ampliar

Na tela 3, quando marcamos apenas o teste testFirstExample1, verificamos que o mesmo possui uma cobertura completa do método firtExample(int a, int b). Isso quer dizer que apenas o segundo teste (testFirstExample1) é suficiente para se ter 100% de Statement Coverage, ou seja todas as linhas de código foram exercitadas.

Mas se prestar atenção na tela 3 a linha de código numero 8 da classe: if (c>50) {”  está pintada de amarelo, isto quer dizer que essa linha de código não está completamente exercitada, ou seja, esta estrutura condicional ainda precisa ser estimulada por mais teste para que outro fluxo seja tomado, e isso a gente consegue garantir quando testamos esse método com os dois teste anteriores. Olhando para tela 4 abaixo, percebemos que quando marcamos os dois testes (testFirstExample e testFirstExample1), temos 100% de cobertura  de Decision Coverage, pois ambos os teste exercitaram a linha 8 para que o fluxo fosse tomado tando para que C fosse maior que 50 e C fosse menor que 50, exercitando assim a estrutura condicional (if) pode completo.

Tela 4 – Clique para ampliar

Analisando direitinho, podemos perceber que toda suíte de teste que cobre 100% de decision coverage, também cobre 100% de statement coverage, no entanto o inverso nem sempre  é verdade.

Espero ter esclarecido melhor o conceito de Statement e Decision coverage com os exemplos acima. O que vocês acharam ? Caso tenham dúvidas relacionadas a este tema, por favor utilizem o espaço de comentário para que possamos discutir mais sobre o assunto.

Obrigado e até breve !!!

#TGIF – Steve Jobs e seu legado

O TGIF de hoje não poderia ser indiferente ao triste acontecimento que ocorreu essa semana. O mundo perdeu um dos maiores visionários da história, muitos já o comparam com da Vinci, Henry Ford, Thomas Edison entre outras personalidades importantes da história da humanidade.

Para conhecer um pouco mais desse cara que foi um ícone de algumas gerações, existem alguns livros e filme que de um forma ou de outra falam de sua vida e sua personalidade. São eles:

A segunda vinda de Steve Jobs – Sinopse: Baseado em dezenas de relatos de pessoas que conviveram com o executivo nas últimas três décadas, este livro é a biografia do personagem que melhor representa o sonho americano de Silicon Valley. Autor de perfis para as revistas Vanity Fair e GQ e correspondente da Fortune, o jornalista Alan Deutschman inicia a narrativa em 1985, no momento em que Jobs sai da Apple acusado de roubar segredos da   empresa. Seguem-se a ascensão e queda de sua própria empresa, a Next, o enorme sucesso de seu estúdio de animação, a Pixar, produtor dos filmes Toy Story e Vida de inseto, e, no final dos anos 90, seu retorno triunfal à empresa que o    havia demitido. O livro tem como fio condutor os altos e baixos da vida profissional de Jobs, mas mostra também o          lado reservado do empresário – a relação de amor e ódio com Bill Gates, as negociações com Michael Eisner e Jeffrey Katzenberg, da  Disney, seus métodos de administração e seu contato com a imprensa.

A Cabeça de Steve Jobs – Sinopse: É difícil acreditar que um homem revolucionou os computadores nos anos 1970 e 1980, o cinema deanimação e a música digital nos anos 1990. Por outro lado, são lendárias as histórias de seus repentinos acessos de raiva, revelando o verdadeiro Steve Jobs. Então, o que há, realmente, dentro do cérebro de Steve? Segundo o autor, é um feixe de contradições. O autor destila os princípios que guiam Jobs ao lançar produtos arrasadores, ao atrair compradores fiéis e ao administrar a sua empresa. O resultado é este livro sobre Steve Jobs que é, ao mesmo tempo, uma biografia e um guia sobre liderança.

Steve Jobs – Sinopse: Este livro, baseado em mais de quarenta entrevistas com Steve Jobs e entrevistas com familiares, amigos, colegas, adversários e concorrentes -, narra a vida deste empresário, cuja paixão pela perfeição e cuja energia contribuíram para seis indústrias – a computação pessoal, o cinema de animação, a música, a telefonia celular, a computação em tablet e a edição digital.

Também existe um filme clássico chamado Piratas do Vale do Silício, que fala basicamente sobre a história dos dois principais personagens da tecnologia do mundo: Bill Gates e Steve Jobs na década de 70 e início da década de 80.

Vamos deixar aqui um vídeo nesse post, que com certeza esta sendo visto milhares de vezes nos últimos dias, uma palesta famosa que o próprio fala um pouco de sua vida na formatura de uma turma da universidade de Standford. Isto é para deixar registrado em mais um lugar na grande rede a importância que esse cara representa para toda a nossa geração.  Descanse em paz Steve.

A série – Thank God It’s Friday ou #TGIF – aborda sempre um conteúdo menos técnico, mas que ainda assim possa contribuir com o seu crescimento pessoal e profissional.

Leia, também, outros artigos já publicados na série:

– “Tudo” sobre o iPhone 5

– Conceitos, protótipos e ficção científica – Os primeiros passos para evolução.

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

#TGIF – Conceitos, protótipos e ficção científica – Os primeiros passos para evolução.

Qualquer semelhança é uma mera coincidência 🙂

O TGIF de hoje vai falar sobre a importância de conceitos, protótipos e porque não Ficção Científica. Muita gente não dá a devida importância para estes temas, mas é bom ter em mente que se não houvessem pessoas que trabalhassem com isto, com certeza que a nossa evolução não seria tão rápida quanto vemos. Exemplos clássicos estão a nossa volta como a famosa saga de Star Trek que inspirou na criação de vários dispositivos que hoje utilizamos largamente no nosso dia a dia como celulares e iPods.

Como diz o cantor Jorge dü Peixe da Nação Zumbi: “Ficção Científica é a nossa grande literatura de idéias.” E é a partir dessa literatura criadas por diversos “professores pardal” no mundo.
Segue um video de um conceito que nos tempos de hoje podemos dizer que é antigo mas que ainda surpreende muita gente. O nome dela é GINA.
GINA é um conceito da BMW que teve inicio em 2001 e que foi exibido apenas em junho de 2008 no qual o carro não possui uma “lataria” e sim uma roupa. Isso mesmo, um carro revestido por uma “pele” super resistente feita de poliuretano, que deixa o mesmo completamente flexível e elegante. O resultado é que GINA não foi apenas um protótipo, foi uma mudança de paradigma. Este projeto mudou drasticamente a forma como nós olhamos para um carro. Chris Bangle,diretor de design da BMW, disse no video: GINA “humanizou” o carro e mudou a forma de pensar como desenvolver um. A filosofia de GINA em poucas palavras é tudo sobre ser flexível, contexto sobre o dogma.

Já imaginou um carro “piscando o olho” pra você ? A GINA faz. Vejam o video abaixo :

A série – Thank God It’s Friday ou #TGIF – aborda sempre um conteúdo menos técnico, mas que ainda assim possa contribuir com o seu crescimento pessoal e profissional.

Leia, também, outros artigos já publicados na série:

– A brilhante [última] palestra de Randy Pausch 

– Por que você deve investir em UX

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

Código: cobrir ou não cobrir, como e quando?

Em todo projeto bem planejado sempre se tem alguns critérios definidos em cada fase do projeto. Basicamente são os critérios de entrada, que define o que e como deve estar os artefatos/situações/infra que estão diretamente ligados aquela fase para que a mesma possa ser iniciada, e os critérios de saída que são os critérios que definem que uma determinada fase esta pronta para ser finalizada. Lembrando que nem sempre os critérios de saída de uma fase do projeto são também critérios de entrada de outra fase, principalmente nos dias atuais no qual o tempo é um fator crucial e os projetos raramente utilizam modelo de desenvolvimento em cascata para desenvolver o software e as fases de um projeto muitas vezes acontecem em paralelo.

Um dos critérios mais comuns em qualquer fase de um projeto de teste é a cobertura. Geralmente quando a conversa é com o cliente, se discute cobertura das funcionalidades e quando a conversa é com uma equipe de desenvolvedor, a conversa muitas vezes muda de escopo e passa a ser cobertura de código. Principalmente quando estamos falando num dos primeiros momentos em que teste dinâmico (Necessita de execução de código) se envolve em um projeto de desenvolvimento de software, que são com testes unitários. E um dos critérios de saída mais conhecidos na fase de desenvolvimento dos testes unitários são os de cobertura de código. Mas antes de conseguirmos calcular a porcentagem de cobertura dos testes unitários em relação ao software ou módulo deste software, precisamos definir qual a menor parte de código é considerada no projeto (linha de código, método, classe, etc.) e depois de implementarmos os testes unitários para exercitar esta menor parte de código é que podemos partir para próxima etapa. Ou o contrário se caso o projeto utilizar o processo de TDD (test driven development) no qual inicialmente temos apenas as assinaturas dos método e iniciamos primeiramente a implementação dos testes unitários para depois implementarmos o código do software. Geralmente os projetos que utilizam o TDD corretamente, possuem uma cobertura de código muito boa.

Para medirmos cobertura de código, além da definição da menor parte do software, a próxima estapa é definir a dimensão que nossos testes vão ser medidos,  pois as técnicas de cobertura apenas medem uma dimensão de um software por vez. Isso quer dizer que: Temos que ter cuidado quando falamos de 100% de cobertura. Podemos sim dizer que temos 100% de código coberto mas isso não a obrigatoriedade de termos 100% do código testado. Um exemplos disso  é:  Dois valores distintos de entrada podem exercitar as mesmas linhas de códigos mas uma pode encontrar um erro e a outra não.

Falando um pouco sobre as técnicas de medição de cobertura de código, as duas mais conhecidas são: Statement Coverage e Decision Coverage. A primeira nada mais é que a quantidade de números de linhas de código exercitados pelos testes, dividido pela quantidade total de linhas de código. Isso significa que se eu tenho um método com 10 linhas de código e um conjunto de testes que juntos executam 8 linhas de código daquele método, então posso dizer que a cobertura dos meus testes em relação ao método é de 80%. Quando falamos de decision coverage, a coisa não fica tão trivial assim. Decision coverage leva em conta se todas as linhas de códigos que possibilitam um ou mais caminhos de fluxo, foram completamente exercitados. Isso quer dizer que, estruturas de condição como: IF, CASE e estruturas de repetição como: DO-WHILE, REPEAT-UNTIL foram completamente exercitados pelos testes.

Complicado né ? Não se preocupem, no meu próximo post vou mostrar na prática como utilizar uma ferramenta, free obviamente, para medir a cobertura de código utilizando essas duas técnicas de medição.

Abracos e até a próxima.