Alinhando as expectativas (Cont. III)

Você pode tentar ler esse post isoladamente, mas estou escrevendo mantendo uma certa ordem. Recomendo a leitura do post anterior para que esse conteúdo faça mais sentido.


Já sabemos que temos 3 ambientes de produção, cada um correspondendo a uma expectativa de SLA, nível de qualidade e segurança. Com isso temos uma boa visibilidade dos critérios de validação e controle que são necessários para se garantir o nível de qualidade esperado de cada ambiente.

Para que um ativo seja entregue nesses ambientes é preciso que processos de verificação sejam executados. Esses processos visam identificar nos ativos sua capacidade de atender os requisitos de disponibilidade, segurança e qualidade de cada ambiente. Vou me ater especificamente as garantias de segurança daqui em diante.


Pensando especificamente em segurança, todo ativo que será entregue nesse ambiente passará por certo nível verificação, sendo essa composta de três macro atividades: Revisão de Desenho, Revisão de Código e Teste de Segurança. O nível em que cada atividade será aplicada depende da classificação do ativo e do grau de exigência do ambiente a que ele se destina.


Lembando que cada ambiente tem um certo nível de expectativa, e que você almeja entregar algo satisfatório para seu negócio, vale lembrar da seguinte relação que se aplica muito bem nesse caso:

• Revisão de Desenho

Através da modelagem dos componentes da solução (via de regra a granularidade de detalhes dessa modelagem deve caber em uma folha), avalia-se as implicações de segurança do perímetro da solução. 
A partir desse modelo principal da arquitetura, elaboram-se modelos específicos para cada interface do ativo, verificando as questões de segurança pertinentes (o STRIDE pode ajudar a entender como proceder na identificação desses pontos). 
Além disso, avalia-se a aderência aos requisitos de segurança (voltaremos nisso depois, mas existe uma prática que versa sobre requisitos de segurança e que será detalhada em uma outra oportunidade).


Tenha em mente que os principais pontos dessas verificação para cada interface consistem em:

1. Autenticação;
2. Autorização;
3. Validação de entrada;
4. Codificação de saída (output encoding);
5. Tratamento de erros;
6. Registros de logs;
7. Criptografia;
8. Gerenciamento de sessão.

• Revisão de Código

Em níveis iniciais essa disciplina pode ser executada manualmente com apoio de checklist de requisitos de segurança em contrapartida a automação da revisão automatizada de código para níveis mais avançados de utilização. 

Nos níveis iniciais é importante abordar apenas os itens mais críticos para que o processo manual combinado a um extensa lista de checagens não torne o processo de revisão inexequível. Com as abordagens automatizadas podemos expandir tanto o volume de checagens, quanto a cobertura de código, tendencialmente analisando-se o código todo. Indica-se nesse caso que a cada "build" da solução a bateria de testes de código seja executada.


Apenas para nortear melhor as revisões, os principais pontos de interesse são:

1. Módulos de autenticação;
2. Pontos de verificação de permissão de acesso;
3. Esquema de gerenciamento de sessão
4. Interfaces externas;
5. Validadores de entrada;
6. Parsers de dados.

Nota: Existem algumas ferramentas que podem ser aplicadas para ser obter algum grau de automação. O site a seguir disponibiliza uma série delas com referências: http://www.dwheeler.com/flawfinder/#othertools

• Teste de Segurança

Os testes de segurança, assim como as demais atividades de verificação, esta começa por uma abordagem mais manual com test cases de segurança derivados dos requisitos de segurança e da própria lógica da aplicação, bem como de falhas corriqueiras especificas da(s) tecnologia(s) de implementação. A evolução natural endereçando o problema de escala é a busca de ferramentas que automatizem esse processo. Nesse cenário existem muitas ferramentas, uma delas é a nstalker.
Em complemento a essas atividades, recomenda-se estabelecer um critério para que um teste de penetração, ou teste caixa-preta seja efetuado. Por exemplo, a cada "major release" o produto passa por um teste especializado de segurança, visando o estabelecimento de um baseline de segurança para aquela versão, enquanto os "minor releases" passariam apenas pelo processo automatizado.


Aceitação de riscos

Além de todas essas atividades que permeiam o processo de criação das soluções, se faz necessário estabelecer um processo formal de aceite de riscos, uma fez que nem todos os problemas apontados pelas atividades de verificação serão endereçadas. Sempre que um caso desses surgir os responsáveis pelo negócio devem ser notificados nos riscos inerentes as suas soluções para então tomarem a decisão formal de promover a solução com risco para o ambiente produtivo, adiar a a promoção até que todas as falhas sejam endereçadas ou mesmo abortar o projeto por inviabilidade financeira em se lançar o projeto de forma segura.