O Centro Nacional de Cibersegurança do governo do Reino Unido publicou recentemente um documento sobre os seis padrões de design que devemos evitar ao projetar sistemas computacionais.
O primeiro padrão é a 'navegação' para administração. Isso significa que administramos um sistema a partir de um computador/terminal menos confiável que o próprio sistema. Essencialmente, o computador administrador é o elo mais fraco e pode ser um alvo mais fácil nos ataques. Uma abordagem melhor para evitar isso é o conceito de "mínima navegação", mantendo os computadores limpos usando sistemas e mecanismos como, por exemplo, não navegar na web ou abrir anexos de email.
Um segundo padrão que deve ser evitado são as defesas em camadas de atalho em uma rede através do acesso de gerenciamento. Isso pode ser identificado quando, por exemplo, o usuário precisa passar por um Web Application Firewall, pelo servidor de aplicações e por alguma lógica para acessar o banco de dados, enquanto o acesso de gerenciamento concede ao administrador acesso direto ao banco de dados, ignorando todas as camadas intermediárias. A solução recomendada neste caso seria usar defesas em camadas semelhantes a interface de gerenciamento usadas para o acesso de usuários.
Outro padrão a ser evitado é ter vários firewalls consecutivos para o mesmo conjunto de controles. O motivo por trás do uso de vários firewalls para os mesmos controles (geralmente de fornecedores diferentes) é que um ataque em um deles interromperia o invasor no segundo. O contra-argumento do NCSC é que um ataque em um firewall raramente seria resultado da carga de dados, mas provavelmente seria devido a uma vulnerabilidade na interface de administração, que não deveria estar conectada à Internet pública de qualquer maneira. Além disso, a aplicação de patches eficazes significaria que apenas ataques de 0 dias poderiam ser usados pelo invasor. Por fim, o design adequado da defesa em profundidade da rede deve minimizar os efeitos dessa violação de qualquer maneira. A recomendação do NCSC é fazer isso uma vez e fazer bem, mantendo ativamente tanto o firewall como a sua configuração.
Subir e mudar uma solução "local" para a nuvem é outro padrão a ser evitado. Isso geralmente significa que os componentes da infraestrutura local são replicados na nuvem, sem o design adequado da arquitetura, se ainda são os melhores componentes a serem utilizados. Por exemplo, mudar uma instância do EC2, apenas para instalar um banco de dados SQL de código aberto e usá-lo como servidor de banco de dados, terá que ser ponderado com o uso da solução nativa da AWS RDS. Em geral, o uso de funções de ordem superior pode liberar recursos da aplicação de patches e atualização desses sistemas, resultando em sistemas mais seguros.
Ter acesso de terceiros que não é controlado e/ou monitorado é outro padrão a ser evitado. Isso pode resultar desde o suporte à terceirização para uma organização de terceiros. Esse terceiro pode ter acesso direto a um sistema, um acesso que ignora muitas camadas de segurança. Evitar esse antipadrão necessita seguir os princípios mencionados nos padrões anteriormente citados, permitindo o acesso com base no princípio do menor privilégio, garantir que tenhamos uma trilha de auditoria para todas as ações do sistema e escolher terceiros com muito cuidado.
O último padrão a ser evitado é o "sistema não detectável". Os sistemas que precisam estar operacionais 24 horas por dia, 7 dias por semana e que só podem ser corrigidos com o tempo de inatividade medido em horas, ou mesmo dias, são essencialmente difíceis de corrigir. Geralmente, esses são sistemas que não têm redundância nos subsistemas. Os sistemas devem sempre ser projetados para facilitar a manutenção, e a aplicação de patches deve ser instantânea, contínua e ter tempo zero de inatividade.
O documento em si se esforça bastante para sugerir leituras adicionais para cada um dos pontos descritos.