Tag Archive: dicas


Oh Lord! The AVD interface can’t talk to me!!!

AVD

Antes que pareça simples histeria, o espanto no início desta publicação sintetiza a minha perplexidade ao aperceber-me que os nossos amigos foram capazes de conceber uma interface gráfica completamente cínica, sem qualquer tipo de alerta ou informação adicional sobre o facto de não serem permitidos espaços no nome do dispositivo virtual, mergulhando a tela de edição num eterno silêncio com um “Ok” desabilitado e um “Cancel” como única opção de saída. Dilema!

Muito drama descritivo? Talvez sim, indignado por ter que consultar o omnisciente tio Google por um impasse facilmente evitável! Doeu! 😀

Ai, ai, ai User Experience! 😉

Spring-Security-logo

… surge mais um “bug-manhoso“! – categoria de bugs em que incluo também os famigerados ponto e vírgulas e outros elementos “insignificantes” que dão-nos algumas dores de cabeça quando esquecidos algures no emaranhado de códigos.

Neste cenário, o nosso “bug-manhoso” é alimentado pelo Mau Mapeamento das Portas no ficheiro de configuração do applicationContext.xml, impossibilitando o correcto funcionamento da framework de segurança Spring Security 3.1.4 em uso numa aplicação web Java.

Este problema é impulsionado pelo facto de que com alguma frequência  nos  desleixamos e confiamos nas configurações default que acompanham muitos dos  recursos usados nos nossos ambientes.

Server Tree

A configuração em questão é a do servidor de aplicação Glassfish que corre por default nas portas 8080 e 8181 (http e https, respectivamente). Quando os condicionalismos obrigam, o funcionamento em simultâneo de vários servidores só é possível efectuando a alteração das portas default, usando por exemplo as portas 14798 e 14799.

Caso esta alteração não seja acompanhada das devidas alterações subsequentes, poderá provocar um mau funcionamento do Spring Security.

Em dias de sorte, esta falha é alertada pela exibição da mensagem no browser: “Está página Web tem um ciclo de redireccionamento“, com o código de erro: ERR_TOO_MANY_REDIRECTS.

1

Podendo também ser menos explícita tal como apresentado no screenshot abaixo, lançando a excepção com.sun.faces.context.FacesFileNotFoundException e duplicando o nome do sistema na URL.

main

Como Resolução, deve-se alterar as definições de mapeamento de portas no ficheiro applicationContext.xml actualizando para os novos valores dos atributos http e https da tag port-mapping.

applicationContext

portas

Imagem

(…) temos que parar e dar carinho! 🙂

Confesso que muitas vezes subestimo os pequenos alertas de sistema que, pela sua irrelevância, não me impedem de realizar o meu trabalho (Windows abuse side effects 😯 ). Mas normalmente isto acontece até ao dia em que me farto e decido pôr “ordem na casa”. 😀

Desta vez o protagonista foi o Netbeans 7.3 que, após eu ter efectuado uma actualização da versão do JDKresolveu exibir a mensagem de “Invalid jdkhome specified” sempre que eu tivesse que executá-lo, e onde somente a escolha pelo “Sim” era a opção válida para transpor o “pequeno”, porém recorrente, constrangimento.

Esgotada a paciência, recorri à uma resolução básica (já que não há uma opção explícita na IDE) que a descrevo aqui para quem esteja a passar por esta chatice, e também queira cortar o mal pela raiz ;-):

  1. Navegar à pasta C:\Program Files\NetBeans 7.3\etc
  2. Abrir o ficheiro netbeans.conf
  3. Editar a entrada  netbeans_jdkhome inserindo o caminho para a pasta do JDK
    netbeans_conf
  4. Salvar, e final de stress!

24

E foi com este tema que marquei ontem a minha estreia, em modo Speedy Gonzalez :D, nas sessões de apresentações do CAST – Comunidade Angolana de Segurança e Tecnologia.

Com casa cheia, foi bastante gratificante podermos observar o intercâmbio de conhecimento e experiências entre os profissionais da área e os estudantes universitários que pela primeira vez fizeram-se representar em bom número, o que com certeza deixou satisfeito os que têm acompanhado de perto a caminhada da comunidade.

O pontapé de saída foi dado por Sérgio Cruz que dissertou sobre “Sistemas Integrados de Gestão Empresarial“, cobrindo os pontos anunciados por altura do lançamento do evento, tais como a importância, factores de decisão técnica e as razões técnicas em que baseou a sua opção. Em jeito de conselho, foi passando informações que considera cruciais para que um processo de adopção de um ERP finalize com sucesso.

Na sequência, coloquei as vestes de evangelizador de segurança, convidando os participantes a uma viagem ao passado, levando-os a compreender a presente necessidade de consciencialização para a adopção de práticas seguras de Engenharia de Software e de Gestão de Projectos de Software nos processos de desenvolvimento e/ou aquisição de soluções. Com certeza, a ocasião proporcionou também a oportunidade para dar a conhecer conceitos pouco disseminados como Software Assurance, ciclo de vida de desenvolvimento de software seguropráticas de segurança, entre outros, relacionados à Segurança em TI.

Para obter mais informações como as apresentações deste e outros eventos passados, é só visitar a página do CAST em www.cast.co.ao e, aproveitando a visitinha, cadastrar-se, abraçando assim a causa. 😉

Isso acontece até nas melhores famílias! 🙂

24

Prezados membros e amigos do CAST,

Encontre abaixo 5 razões pelo qual você deve estar presente num encontro do CAST:

  1.  O objectivo do encontro do CAST é de meramente o de promover a transferência de conhecimento, o que significa dizer que ao participar, todos aprendemos. “Se eu tiver uma maçã e você também, e nós trocarmos as maçãs, continuaremos cada um com uma maçã. Porém, se eu tiver uma idéia e você também, e trocarmos as idéias, passaremos a ter cada um duas idéias”
  2.  “Networking”, ao participar do evento do CAST você estará em contacto com profissionais de diferentes sectores, cada um traz consigo uma bagagem diferente sobre determinado tema, esta interacção pode ser facilmente traduzida em novas parcerias profissionais, oportunidades de negócio, emprego e etc. Com os eventos passados já nos foi possível constatar algumas parcerias entre diferentes representates de empresas do ramo.
  3. Uma forma de promover o nivelamento do sector. Através dos inputs provenientes dos diferentes protagonistas, é possível nivelar o modelo de conhecimento e as formas mais eficientes de tornar o ensino tecnológico numa ferramenta simplificada.
  4. Fazer conhecer os seus ideais à uma comunidade segmentada que em função da qualidade da informação que receber, fará o devido broadcast para o resto do mundo. BroadCAST! That’s what’s all about!
  5. Ajudar o sector acadêmico a ter uma melhor percepção da vida no campo tecnológico, temos tido a participação de estudantes universitários que passam a ter uma nova visão do meio que lhes espera e em função da informação que lhes é transmitida, fazem algumas modificações nos seus planos futuros.

Por CAST Team

 

cast - Março 1

 

Vida de Programador! :)

Enquanto “passeava” pelo DZone, um dos locais favoritos para muitos desenvolvedores e arquitectos de software, a minha curiosidade foi atiçada pelo seguinte anúncio:

Imagem

Apesar do “FREE” ser muito pequeno para deixar aliviado o meu bolso, e de também eu ser um utilizador treinado a não clicar em anúncios “dóceis”, :-), resolvi dar uma espreitadela para matar a curiosidade.

E, como felizmente não sou o gato da história pois a curiosidade não me matou, 🙂 , acabei achando mais um excelente bebedouro de conhecimento denominado Refcardz, onde encontra-se uma série de tutoriais escritos por especialistas líderes da indústria com o objectivo de ajudarem a manter os profissionais da área de engenharia de software actualizados sobre os mais recentes tópicos tecnológicos.

Considero um local de visita obrigatória, não só pela rica qualidade do material à nossa disposição, que até são graficamente apelativos, bem como o pelo vasto universo de tópicos abrangidos. Enjoy It!

FacesMessage facesMsg = new FacesMessage(FacesMessage.SEVERITY_INFO, “Faça Antes de” +”Codificar!”, “Pois Queremos Alicerces Seguros Nos Nossos Sistemas!!!”);

Na primeira parte desta matéria procuro dar a conhecer toda a envolvente teórica, retirada e adaptada do material disponibilizado pela SAFECode, sobre um dos temas que é transversal a qualquer metodologia que possa ser adoptada pela sua equipa para garantir a Segurança no Desenvolvimento de Software.

No percurso para o desenvolvimento de um software que cumpra com os critérios fundamentais para ser considerado resultado de um Ciclo de Desenvolvimento de Software Seguro, encontramos a  Modelação de Ameaça, considerada como a principal actividade de segurança na fase de design do software.

Modelo de Ameaças - Diagrama de Contexto

O Conceito

Basicamente, a Modelação de Ameaça (Threat Modeling)  é um exercício conceitual feito no período de design do software, onde o fluxo de dados de um sistema é analisado para encontrar vulnerabilidades de segurança e identificar as formas que as mesmas possam ser exploradas.

Com a adopção deste procedimento, agrega-se valor ao produto final pois garante-se a prevenção de potenciais problemas de design, na  lógica de negócio ou fluxos de trabalho inseguros, que não são normalmente encontrados usando outras técnicas, como revisões e análise estática do código fonte. Em essência, a modelação de ameaça identifica problemas antes do código ser escrito, para que eles possam ser evitados ou mitigados tão cedo quanto possível no ciclo de desenvolvimento do software.

Ao contrário das Ferramentas de Análise de Vulnerabilidades que só permitem a identificação de vulnerabilidades após o código ser implementado, a actividade de modelação de ameaça permite uma identificação ainda em tempo de design. Com esta abordagem é possível traçar estratégias de desenvolvimento que permitam controlar os riscos numa fase prematura do desenvolvimento.

Pela sua natureza, as correcções de ordem arquitectónicas são mais dispendiosas quando realizadas nos estágios mais avançados de desenvolvimento. Assim, a modelação de ameaça pode ser considerada uma actividade que privilegia a contenção de despesas pois a resolução de problemas logo no início do processo pode ser tão fácil como a simples tarefa de alterar um diagrama para ilustrar uma solução ainda a ser codificada.

Contudo, tentar identificar todas as ameaças possíveis e procurar mitigá-las logo no início do processo de desenvolvimento pode ser difícil de alcançar, então o foco deve ser sobre as questões de alto risco que podem ser identificados em tempo de design.

A Actividade

A modelação de ameaça pode ser feita a qualquer momento no ciclo de vida de desenvolvimento do sistema, mas para maximizar a eficácia esta actividade deve ser realizada o mais cedo possível.

Esta actividade começa com a identificação das ameaças possíveis e mais recorrentes. Nesta ordem, são usadas diferentes estratégias:

• “STRIDE” – esta metodologia classifica as ameaças em 6 grupos: Spoofing, Tampering, Repudiation, Information disclosure, Denial of Service e Elevation of Privilege. A Modelação de ameaça é executada, olhando para cada componente do sistema e determinando se existem algumas ameaças, pertencente a uma das categorias, que recaia sobre o componente e/ou à sua relação com o resto do sistema.

STRIDE
• “Caso de uso incorrecto” – o emprego de caso de uso incorrecto ajuda a clarificar como um atacante pode comprometer o sistema. Estes casos devem ser criados a partir dos requisitos funcionais do sistema, e ilustram como as medidas de protecção podem ser contornada e as áreas onde não existem nenhuma.
• “Brainstorming” – se uma organização não tem experiência na construção de modelos de ameaça, uma discussão orientada à segurança onde os arquitectos avaliam o sistema ajuda a colmatar esta deficiência. Tal “brainstorming” não devem ser considerados uma solução completa, e só devem servir como um trampolim para um exercício de modelação mais robusto.
• “Biblioteca de ameaças” – é um meio que torna o processo de identificação de ameaças mais acessível para os profissionais não especializados em segurança. Como bibliotecas públicas temos: CWE (Common Weakness Enumeration – um dicionário de tipos vulnerabilidades comuns em softwares), OWASP Top Ten e CAPEC (Common Attack Pattern Enumeration and Classification – que descreve métodos comuns de ataques).

Uma vez identificados, cada ameaça deve ser avaliada e mitigada de acordo com o risco associado, os recursos disponíveis, o caso de negócio e os requisitos do sistema. Isto irá ajudar a priorizar a ordem em que as ameaças devem ser abordadas durante o desenvolvimento, bem como os custos envolvidos na mitigação. Às vezes, isso irá conduzir à mudanças no design para permitir mitigações menos dispendiosas.

O Resultado

De uma actividade de Modelação de Ameaça certamente resulta o  Modelo de Ameaças do sistema a ser implementado, com o seu conjunto de diagramas, bem como uma Lista das Ameaças Associadas, mitigadas ou não.

Tem sido observado que a modelação de ameaça como parte das actividades recorrentes no ciclo de vida de desenvolvimento do software ajuda a enraizar uma cultura que aceita a segurança como um aspecto integral do design de software.

Para a segunda parte desta matéria está reservada uma simulação de um processo de Modelação de Ameaças, onde procurarei espelhar toda a dinâmica da sua opção num processo de desenvolvimento Ágil,  aplicando os conceitos aqui descritos e citando ferramentas que suportam a actividade com a análise automatizada de projectos e sugestões para possíveis mitigações e acompanhamento de questões de integração e comunicação relacionadas com o processo.

É evidente que muitos softwares acabam por ser a peça chave na qual empresas, governos e proprietários de infraestruturas críticas confiam as suas operações mais vitais. Por essa razão, clientes corporativos estão legitimamente preocupados com a segurança do software e o potencial para sua exploração por aqueles que procuram perturbar maliciosamente as suas operações.

No campo da segurança no desenvolvimento de software, alguns desenvolvedores focalizam as suas acções somente em um limitado conjunto de procedimentos de codificação segura, levando-os a um estado de aparente esquecimento de que o raio de acção dos malfeitores em busca de vulnerabilidades nos seus produtos é bastante amplo.

Como consequência desta constatação, tenho focalizado parte do meu esforço profissional no aprimoramento do conjunto de práticas de segurança aplicáveis durante as distintas etapas do ciclo de vida de desenvolvimento de um software. E foi neste caminhar que esbarrei-me com um conceito que eleva a essência da segurança no desenvolvimento de software: Software Assurance, podendo ser definido como:

“O nível de confiança de que o software está livre de vulnerabilidades, quer sejam intencionais ou acidentalmente inseridas em qualquer momento durante seu ciclo de vida; e de que o software funciona da maneira pretendida.”

O poder deste conceito reside no facto de que na prática, o Software Assurance envolve uma responsabilidade partilhada entre os fornecedores,  provedores de serviços e soluções, e clientes; responsabilidade esta que é  sustentada por três pilares:   

  • Segurança: As ameaças à segurança são antecipadas e tratadas na altura da análise, desenvolvimento e testes do software. Isto requer uma atenção em ambos os aspectos de qualidade (por exemplo, ”livre de buffer overflow ”) e requisitos funcionais (por exemplo, ”os números de passaporte devem ser encriptados na base de dados ”).
  • Autenticidade: O software não é falsificado e os clientes são capazes de confirmar que eles têm os componentes reais.
  • Integridade: Os processos para codificação, criação e entrega de software contenham controles para aumentar a confiança de que o software funciona como o fornecedor pretende.

Tendo agora a autenticidade  e a integridade como parceiras da segurança, ganha-se a noção de que o trabalho dos profissionais encarregues de manterem imaculada a cadeia de fornecimento de software possuí uma dimensão que ultrapassa as habituais linhas de códigos.

E é com o intuito de massificar a criação de softwares seguros, aplicando procedimentos de Engenharia de Software e de Gestão de Projectos de Software que asseguram um produto final livre de falhas de concepção lógica e técnica, que dedicarei um espaço privilegiado neste blog na esperança de que este singelo processo de consciencialização surta o efeito desejado.

%d bloggers like this: