Parece que cada vez temos mais portas e janelas por onde os ladrões podem entrar. Se na década de 1980, os ladrões entravam pela porta (o que ainda é possível), com o advento da internet nos anos 1990 tornou-se possível entrar pela rede por um envelope virtual chamado e-mail e, depois, por programas de mensagens. Os riscos continuam aumentando, e nós também continuamos aprendendo a nos proteger.
 
No ano de 2010, como mostra o estudo Charles Henderson de Trustwave, devíamos nos proteger de ataques que chegavam por via física, pela rede, por e-mail, nos aplicativos, via wireless, do client-side, através dos celulares e pelas redes sociais. O estudo conclui, entre outras coisas, que a velhas ameaças nunca desaparecem, que as novas apontam para o usuário e que as ferramentas maliciosas são cada vez mais sofisticadas.
 
Os números que as estatísticas mostram são desastrosos. Pareceria que na área de TI, nós, os profissionais de infraestrutura e desenvolvimento, não sabemos colocar no ar aplicativos seguros o bastante. E não estamos falando de desejar aplicativos sem vulnerabilidades (esses não existem): o Projeto de Estatísticas de Segurança de Aplicativos Web 2008, do Web Application Security Consortium (WASC), entre outras coisas, conclui que a probabilidade de detectar um erro crítico ou urgente em um aplicativo web dinâmico é de 49% escaneando-o automaticamente e 96% depois de uma análise por especialistas.
 
Outro estudo de WhiteHat Security mostra as vulnerabilidades por setor (Bancos, Educação etc.) e também confirma os números. Por que esses problemas não são corrigidos? Essa última análise esforça-se para responder à pergunta: faltam responsáveis para manter o código e evitar vulnerabilidades; e mais: os desenvolvedores não sabem nem entendem de “vulnerabilidades”.
 
A tarefa de garantir a segurança de um aplicativo não é fácil, a arquitetura é cada vez mais complexa. Há que se tomar cuidado no software e no ambiente que este executa. Falemos sobre o software hoje: aplicativos que tem seus dados em algum DBMS, sua lógica de negócios em um servidor de aplicativos, servidores web Java ou .NET, por exemplo, servindo páginas dinâmicas. Entry points[H1]  para páginas, serviços AJAX, serviços REST e SOAP. JavaScript e HTML 5 rodando no browser, nos smart devices aplicativos nativos – ou não – que se conectam a esses serviços.
 
Tudo isso acrescenta aos pontos de acesso – e de vulnerabilidade – existentes nos servidores as vulnerabilidades do tráfego de dados pelo canal, do código executado no dispositivo e dos dados em cache ou armazenados com localmente em momentos distintos. Um banquete para o hacker, uma dor de cabeça, uma noite de insônia e um motivo para árduos estudos em matérias de “segurança” para quem desenvolve.
 
Tentar solucionar isso enquanto desenvolvemos com equipes que implementam manualmente módulos de segurança e equipes que supervisionam manualmente o cumprimento das políticas de segurança é simplesmente uma tarefa entediante e que já demonstrou ser insuficiente, além de pouco eficaz.
 
É mais prático e adequado aplicar a segurança no desenvolvimento de software através de um desenvolvimento de software orientado a modelos (Model driven development*) e, além disso, baseado em conhecimento (Knowledge-based development**), combinado com um ciclo de desenvolvimento seguro. Isso, aliás, ajuda a diminuir os custos de desenvolvimento e manutenção.
 
Nesse tipo de desenvolvimento, abstraímos o conhecimento das intenções do desenvolvedor e centralizamos a necessidade do especialista em segurança que se requer para escrever aplicativos, pois é o responsável pela ferramenta de geração de código e conta com uma equipe de especialistas de segurança de alto nível. Eles se encarregam de que, quando o gerador escrever o código, faça o programa mais seguro e, dessa maneira, os desenvolvedores não terão que ser especialistas em segurança para poder entregar aplicativos robustos.
 
As ferramentas costumam contar com módulos pré-fabricados aos quais os desenvolvedores podem se conectar e que garantirão que quando o aplicativo for gerado apresente todas as rotinas e checagens de segurança que permitam cumprir com as normas básicas de segurança e minimizar as vulnerabilidades a níveis muito menores que se se programasse sem os conhecimentos de segurança adequados.
 
É preciso destacar que não existe um aplicativo 100% seguro, já que sempre existem detalhes que escapam ao modelo, mas com essas facilidades tiramos do desenvolvedor a responsabilidade de ter que ser praticamente um hacker para fazer um aplicativo seguro e deixamos pendente apenas a etapa de supervisão, indispensável no desenvolvimento de qualquer bom aplicativo.
 
Desta maneira, uma ferramenta de desenvolvimento orientado a modelos e baseado em conhecimento fornece uma forma para que aqueles que desenvolvem não tenham que separar recursos para desenvolver módulos de segurança, nem tenham que ter a expertise de um hacker ou ser especialista de segurança para fazer seus aplicativos. Com ele, consegue-se detectar e corrigir as vulnerabilidades durante o próprio ciclo de desenvolvimento em vez de fazê-lo quando o aplicativo é executado.
 
-------------------------------------
* A engenharia orientada a modelos (MDE) é um paradigma de desenvolvimento de software centrado na criação e exploração de modelos de domínio (isso é, representações abstratas dos conhecimentos e atividades que regem um domínio de aplicação particular) mais que em conceitos de informático (ou algoritmos).
http://es.wikipedia.org/wiki/Ingenier%C3%ADa_orientada_a_modelos
 
** No desenvolvimento baseado em conhecimento, trata-se de construir primeiro um robusto modelo de dados e depois descrever as visões dos usuários, para assim abarcar todo o conhecimento dos sistemas e negócios e, a partir desse, projetar, gerar e manter de forma 100% automática os sistemas computacionais de qualquer empresa.
http://www.genexus.com/files/wp-desarrollo-basado-en-el-conocimiento?es
 
* Por Armin Bachmann, coordenador de Suporte de Usuários para GeneXus International