Desenvolvimento Seguro. Quem paga o preço?

No cotidiano dos programadores, a pressa é a famosa inimiga da perfeição, e o interesse capitalista das empresas de aumentar seus ganhos acima de tudo, faz com que os produtos não tenham uma qualidade esperada no final, ocorrendo uma séries de problemas decorrentes.
Na faculdade aprendemos que há uma equação para desenvolver sistemas entre:
- Prazo
- Qualidade e
- Custo.

Se o tempo de desenvolvimento tem um prazo curto, o custo digamos também será baixo mas também não terá qualidade. Para manter a qualidade, tem que contratar mais pessoas e aumenta o custo.

Se precisa de mais qualidade, precisa aumentar o prazo, e pode ter um custo maior principalmente no desenvolvimento de sistemas obrigatórios como por exemplo a Nota Fiscal Paulista. Se o sistema não funcionar dentro do prazo, multas são aplicadas.

Estes itens estão relacionados em si, entretanto quando dizemos desenvolvimento seguro, encadeia-se qualidade ao extremo, ou seja, aumenta o prazo e também o custo, mas também podemos garantir uma qualidade e segurança que em outros cases não haveria como chegar.

Um protótipo de sistema pode ser elaborado pelo analista de sistemas dizendo o que tem que ser feito, o software tem que passar por uma etapa à mais que é pelo analista de riscos e levantar os pontos para adicionar controles de segurança, e planejar itens para garantir que o sistema desenvolvido possa ter a qualidade e segurança esperada.

Depois que o software é produzido, o software versão final passa novamente pelo departamento de análise de riscos, e o código é inspecionado, verificando e levantando questões de segurança, suporte e ataques que o código pode sofrer. Qualquer mero erro é devolvido ao programador para gerar conhecimento, apontando o que tem que ser ajustado e os motivos.

Geralmente as empresas colocam toda a responsabilidade no desenvolvimento apenas no programador, e o analista de sistemas apenas diz o que tem que ser feito, e no final apenas faz um simples teste para verificar se o que foi pedido foi realmente feito.

Entretanto, os testes finos como velocidade de leitura/gravação, simulações de múltiplos acessos e simulações de ataques não são realizados, e o sistema pode ser muito vulnerável.

Quando dizemos que um bom sistema ele tem um prazo razoável, temos que pensar e planejar de que precisamos de um tempo para desenvolvimento e um tempo à mais para as melhorias, pois quando fazemos qualquer sistema, o imediatismo é fazer ele funcionar, e não prestamos atenção nos detalhes, e estes por sua vez, são muito perigosos se explorados.

O método coerente seria algo próximo de:
1. Desenvolvimento do sistema até finalizar tudo que é necessário, em seu tempo e seu prazo tradicionais.
2. 20% do tempo gasto com o desenvolvimento para análise em melhorias pelo próprio programador que o fez.

Assim pode garantir pelo menos uma forma de manter a qualidade, e após isto ainda passar pela análise do setor específico e analisar se está seguro de fato, realizando todos os testes possíveis.

Alguns itens que devem ser levantados ao desenvolver de forma segura são:

Aspectos físicos:
1. Quem irá desenvolver. (perfil comportamental ético e moral com relação à segurança das informações).
2. Qual equipamento será usado para o desenvolvimento. (computador, scanner, supercomputador, etc)
3. Quem irá solicitar os pedidos ao programador (pessoalmente, via sistema).
4. Localização da área de desenvolvimento (outro estado?).
5. Levantar os riscos de quem se interessaria pela cópia do sistema desenvolvido, concorrentes, etc.
6. Câmeras de vigilância sobre o equipamento. (para análise de possíveis pessoas não autorizadas no uso do equipamento).

Aspectos lógicos:
1. Conexões do equipamento de uso no desenvolvimento (Internet, CD-ROM, Pen-Drive, Wi-Fi, etc.)
2. Proteção por senha e preferencialmente criptografia do disco rígido.
3. Proteção contra os métodos de ataques mais conhecidos. (SQL Inject, Cross-Browser injection).
4. Teste de desempenho dos mecanismos funcionais do sistema em picos de uso (teste de simulação de várias pessoas usando o sistema ao mesmo tempo).
5. Teste de novos usuários usando o sistema. (Se a interface e orientações na tela são compreendidas para entender a funcionalidade do sistema por si só, ou com conteúdo de suporte e ajuda).
6. Teste de portabilidade - Tem vezes que o software desenvolvido funciona em apenas um equipamento, e em outro requer arquivos adicionais ou atualizações de softwares adicionais. Os testes precisam ser realizados nos mais diversos ambientes e nas mais diversas condições de uso.

Na questão de segurança e portabilidade, o Java tem sido destaque em grandes empresas, pois o código de programação é único e aplicado à uma máquina virtual, chamada de JRE (Java Runtime Engine), que é exatamente um emulador de um computador com seu processador e sua área da memória sobre uma plataforma existente.

Uma das grandes desvantagens do Java atualmente é a falta de suporte da Oracle para os diversos incidentes de segurança que tem aparecido, a baixa velocidade de execução (não tem como comparar à linguagem C por exemplo, que também é por sua vez portável) e o alto custo de hardware e servidores ao usar sistemas baseados em Java para escalonar e integrar sistemas.

Por sua vez, o padrão de qualidade na tipagem da programação Java, força o programador usar certos métodos para conversão de valores, datas, textos, valores com ponto flutuante (com vírgula), e, dos quais, fazem gastar um tempo maior, aumentando automaticamente o prazo.

Um programador inexperiente ao iniciar com a linguagem Java, já se depara com a grande carga de conceitos técnicos da linguagem com relação aos métodos de conversão de valores, que, em outras linguagens como Visual Basic ou .NET, são automaticamente identificadas conforme o uso.

Não significa que a linguagem Java é a única que pode ser segura, de forma alguma. Um desenvolvimento seguro se aplica à qualquer linguagem de programação, incluindo desde as mais simples às mais complexas como linguagens de programação para Inteligência Artificial (que eu creio que tem que ser de extrema segurança).

O desenvolvimento seguro não se inicia na programação do sistema, se inicia na ideia inicial do planejamento dos sistema. Deve-se planejar o sistema e em seguida, planejar seus controles de segurança.

O mais simples controle de segurança que existe é o login e senha, existente em todos os sistemas importantes.

Mas criar uma senha tem que existir critérios, uma política bem estabelecida e não limitada apenas aos critérios de nova senha (quantidade, complexibilidade), mas também de uma conscientização da importância da senha para os funcionários e de mantê-la segura. (Exemplo de deixar a senha escrita em post-it na tela).

Os controles de segurança devem existir e devem ser analisados se realmente correspondem ao padrão de segurança, e não só controles superficiais como também controles de proteção dentro do sistema, e para todos estes itens, sabemos que leva-se tempo.