Existem diretrizes gerais que têm aplicabilidade ampla quando se projetam soluções de proteção de sistema que encapsulam boas práticas de projeto para sistemas seguros. As dez diretrizes de projeto que Sommerville (2007) orienta, tem como objetivo tanto de conscientizar os pontos críticos de segurança, como também ser um checklist de revisão que pode ser usada no processo de validação de sistema. Vamos a elas:

Diretriz 1: Basear as decisões de proteção em uma política de proteção explícita

Uma política de proteção deve definir o “que” da proteção, no lugar de “como”. A política não deve definir mecanismos usados para prover e fazer cumprir a proteção. Os projetistas devem, portanto, consultar a política de proteção quando ela provê um framework para tomar e avaliar decisões de projeto.

Diretriz 2: Evitar um ponto único de falha

Num sistema crítico é uma boa prática evitar um ponto único de falha. Pois  uma falha única, numa parte do sistema, pode resultar na falha geral de sistemas. Em termos de proteção, isso significa que você não deve contar com um único mecanismo para assegurar a proteção, mas deve empregar várias técnicas distintas. Pode-se chamar isso de “defesa em profundidade”.

Para proteger a integridade de dados o sistema, você poderia manter um log de todas as mudanças feitas nos dados, de modo que, se ocorrer uma falha, você poderá examinar o log para recriar o conjunto de dados.

Diretriz 3: Falhar de maneira protegida

Nenhuma falha de sistema deve possibilitar a um agressor acesso aos dados que não seria normalmente permitido. Portanto, embora as falhas de sistema sejam inevitáveis, os sistemas críticos de segurança devem sempre falhar de maneira segura (fail-safe) e sistemas críticos de proteção devem sempre falhar de maneira protegida (fail-secure).

Um uso dessa filosofia seria, por exemplo, a técnica de numa aplicação cliente/servidor deixar um pequeno arquivo no computador cliente para facilitar o acesso aos dados. Uma vez utilizado do serviço, esse arquivo é eliminado. No entanto, em caso de falha esse arquivo poderá ficar inseguro. Uma estratégia seria de manter essa mesma técnica, mas com o arquivo criptografado, impossibilitando a leitura desses dados por pessoas não autorizadas.

Diretriz 4: Equilibrar proteção e facilidade de uso

À medida que um sistema aumenta suas características de proteção, é inevitável que ele se torne menos fácil de usar. Um bom exemplo seria os atuais sistemas bancários na Internet. Exigem tantas chaves para acessarmos os dados, que muitas vezes provocam irritação, e perda de tempo.

Portanto, chega-se a um ponto em que é contraproducente manter a adição de novas características de proteção à custa da facilidade de uso. Por exemplo, se você exigir que os usuários insiram várias senhas ou alterem suas senhas com uma constância muito pequena, eles simplesmente escreverão suas senhas em algum lugar. Um agressor poderá, então, encontrar as senhas e obter acesso ao sistema.

Diretriz 5: Estar ciente da possibilidade de Engenharia Social

Em Segurança da informação, chama-se Engenharia Social as práticas utilizadas para obter acesso à informações importantes ou sigilosas em organizações ou sistemas por meio da enganação ou exploração da confiança das pessoas. Para isso, o golpista pode se passar por outra pessoa, assumir outra personalidade, fingir que é um profissional de determinada área, etc. É uma forma de entrar em organizações que não necessita da força bruta ou de erros em máquinas. Explora as falhas de segurança das próprias pessoas que, quando não forem devidamente treinadas para esses ataques, podem ser facilmente manipuladas.

Do ponto de vista de projeto, enfrentar a Engenharia Social é muito difícil. Mecanismos de registro que acompanham a localização e a identificação dos usuários e os programas de análise de registros podem também ser úteis, na medida em que permitem detectar brechas de proteção.

Diretriz 6: Usar redundância e diversidade para reduzir riscos

Redundância significa que você mantém mais de uma versão de software ou de dados no sistema. Diversidade, quando aplicada ao software, significa que versões diferentes não devem ser baseadas na mesma plataforma ou usar as mesmas tecnologias. Portanto, uma vulnerabilidade de plataforma ou de tecnologia não afetará todas versões e, dessa maneira, conduzirá a falhas de modo comum.

Um aplicação dessa diretriz seria utilizar sistemas operacionais diferentes no cliente e no servidor (por exemplo Linux no servidor e Windows no cliente). De modo a assegurar que um ataque baseado na vulnerabilidade de algum desses sistemas operacionais não afete o servidor e o cliente simultaneamente.

Diretriz 7: Validar todas as entradas

Um ataque comum ao sistema envolve o fornecimento de entradas inesperadas ao sistema que causam um comportamento imprevisto.  Pode-se evitar muito desses problemas ao se projetar uma validação de entradas no sistema. Essencialmente, nunca deve-se aceitar nenhuma entrada sem aplicar alguma verificação sobre ela.

Por exemplo, ninguém possui um sobrenome com mais de 70 caracteres e nenhum endereço é maior do que 100 caracteres. Se usar menus para apresentar as entradas permitidas, pode-se evitar alguns dos problemas de validação de entradas.

Diretriz 8: Compartilhar seus ativos

Deve-se organizar a informação no sistema de modo que os usuários somente tenham acesso à informação de que necessitam, no lugar de toda a informação do sistema. Pode-se também precisar de mecanismos no sistema para conceder acessos inesperados. Nessas circunstâncias, pode-se usar um mecanismo de proteção alternativo para ignorar a compartimentalização do sistema.

Diretriz 9: Projetar para implantação

Muitos dos problemas de proteção surgem porque o sistema não está configurado corretamente quando é implantado no seu ambiente operacional. Deve-se, portanto, projetar sempre os sistemas de modo que os recursos sejam incluídos para simplificar a implantação e para verificar erros potenciais de configuração e omissões do sistema implantado.

Diretriz 10: Projetar para capacidade de recuperação

Independentemente de quanto esforço você dispense na manutenção de proteção do sistema, você deve sempre projetar o seu sistema com a hipótese de que uma falha de proteção possa ocorrer. Portanto, você deve pensar em como se recuperar de possíveis falhas e restaurar o sistema para um estado operacional seguro.

Por exemplo, suponhamos um ataque externo aonde uma pessoa não autorizada tenha obtido uma combinação válida de login e senha. Você precisa, portanto, projetar seu sistema para negar acesso a qualquer pessoa até que todos usuários tenham alterado suas senhas e autenticar usuários reais. Uma maneira de fazer isso seria usar um mecanismo do tipo desafio/resposta, no qual os usuários precisam responder a questões para as quais possuam respostas pré-registradas. Isso seria invocado somente quando as senhas fossem alteradas.

Material Engenharia de Software no MBA – Esab

leia também Protegendo seu Servidor de Banco de Dados