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.

Alinhando as expectativas (Cont. II)

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. 

Continuando o detalhamento das expectativas, abordaremos nesse post os próximos ambientes e a expectativa sobre eles.
Detalhando as expectativas de segurança
Produção, Baixo Valor

Esses são aqueles sistemas, cuja ausência ou falha nos causa pouco ou nenhum impacto, possui poucos dados ou de pouca relevância, enfim têm pouco valor de fato. Talvez utilizemos esses sistemas porque nós mesmos o concebemos, porque são divertidos, porque simpatizamos com ele, mas podemos viver tranquilamente sem os mesmos. Vejamos o caso do miss simpatia logo ao lado. Tenho certeza que o desenvolvedor adora ele, acha ele o melhor da raça, vai muito além do que o cliente encomendou. Inclusive esse último patch (banho e tosa 2.0) deu um sex appeal todo especial para o produto. Olha com calma que você também vai querer um... Falando sério, tendo isso em mente, vamos analisar nossas expectativas sobre o ambiente e os critérios para esse tipo de sistema.

• Backup

Obviamente não precisamos de um backup muito avançado, provavelmente os ativos aqui envolvidos são pouco relevantes e podemos nos dar ao luxo de correr mais risco quanto ao volume de perda de dados. Isso significa que os backups serão esparsos e de curto período de retenção. Nossa preocupação pode inclusive se limitar a aspectos normativos, como a exigência de logs de acesso ao sistema por auditorias.

• Disponibilidade

Se o dia for ensolarado, tudo deve estar disponível. Para nossos ativos de baixo valor, estar disponível é uma questão de sorte. Se tudo der certo (e em geral da) ele estará lá e acessível. Não teremos nesse caso a exigência de mantermos o ativo acessível a qualquer momento e de qualquer lugar. Longos períodos (1 semana) de indisponibilidade não são um problema para nosso ativo de baixo valor.

• Controle de acesso

Para esse cenário, nosso processo de controle de acesso pode simplesmente formalizar uma solicitação. As solicitações de acesso seriam "pré-aprovadas", ou seja, por principio todos teriam direito de acesso aos ativos, bastando se identificar para acessá-lo. Isso significa que os pedidos de acesso seriam concedidos automaticamente e só seriam revogados mediante revisão periódica dos mesmos.

• Log Server

Sendo nosso controle de acesso pouco efetivo, é aqui que se faz necessário o bom cuidado com os logs, uma vez que serão praticamente a única linha de defesa dos ativos desse ambiente, assim a visão de concentrador de logs se faz ainda mais necessária, uma vez que o concentrador racionaliza o custo e a operação e gerenciamento desses logs. Repare os olhos atentos do nosso amigo ao lado! (Isso mesmo, ele não tem olhos... era sarcasmo... prometo melhorar na próxima)

• Hardening

Para esses ambientes, podemos definir uma expectativa de hardening bem menos agressiva, visto que a operação que mantém e monitora o hardening pode ser custosa. Em termos práticos, assim como no caso do backup, não adianta termos um hardening por pro-forma, mas para atingirmos uma relação de custo benefício aceitável podemos espaçar as inspeções recorrentes que validam a permanência das configurações do hardening no ambiente. Assim, não teremos uma configuração menos segura, mas simplesmente teremos menos inspeções que garantem o respeito a essas configurações ao longo do tempo. 

• Sistemas

Com o caso dos sistemas, assim como nos sistemas destinados a ambientes de médio valor, podemos abrandar ainda mais os requisitos, mantendo os processos importantes que permitem que saibamos o que está instalado em cada ambiente. Entretanto deve ficar claro para todos os stakeholders que não haverá o mesmo nível de garantia de segurança a esses ativos e que eles poderão ser "abusados", atacados etc. Voltando ao nosso exemplo do sistema para eliminação da sede, quando destinado a um ambiente de baixo valor, é cabível esperar que ele seja "abusado" servindo não só para matar a sede do nosso usuário (piriquito amarelo) quanto para matar a sede de quem mais tentar usar o sistema (morcego) uma vez que os controles oferecidos pelo ambiente e a própria segurança da aplicação não oferecem a possibilidade de garantirmos efetivamente a segurança dessas aplicações.

Conclusão

Esse tipo de ambiente é naturalmente mais "hostil" pela ausência de controles mais rigorosos, assim, trata-se de um ambiente para ativos literalmente de baixo valor, que não tragam impacto caso sejam atacados. Pensando com o paradigma da gestão de risco, não podemos eliminar os atacantes, uma vez que podem ser qualquer pessoa (até mesmo funcionários da própria empresa), estamos abrindo mão das medidas mais rigorosas de controle do ambiente como testes de segurança no processo de gestão de mudança, assim, nossa única chance de termos controle sobre o nível de risco desses ativos é garantindo que nossos atacantes não terão o menor interesse em atacar esse ambiente. Mas sempre tendo em mente que se eles o fizerem, terão uma boa chance de serem bem sucedidos e o resultado pode ser desconfortável para o ativo alvejado. Apenas para ilustrar, esse ativo se sentiria como o fotografo (que Deus o tenha) que retratou essa linda foto de um touro (que pela cara tem meio amigo), sem nenhuma linha de proteção efetiva dependendo apenas do desinteresse do touro para permanecer inteiro! 

Alinhando as expectativas (Cont. I)

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.

Continuando o detalhamento das expectativas, abordaremos nesse post os próximos ambientes e a expectativa sobre eles.

Detalhando as expectativas de segurança

Produção, Médio Valor

• Backup

Nesse tipo de ambiente podemos questionar modelos muito complexos de backup, se você classificou bem seu ativo, a perda parcial de dados não deveria ser algo com o qual não se possa conviver. Entretanto esses dados precisam de um nível mínimo de cuidado, não adianta implementar um esquema de backup simplesmente por pro-forma. Assim, deve-se garantir que o processo de backup e restore sejam tão eficientes quanto o backup de ambientes de alto valor, mas podemos abrir mão da frequência, ou seja, não há necessidade de se executar backups diários. A simples possibilidade de se espaçar os intervalos de backup vai reduzir substancialmente o custo dessa operação, tornando-a mais compatível com o tipo de ativo a que se destina. 


Outra coisa que precisamos levar em conta é que tratando-se de um ativo de médio valor, além de estarmos disposto a aceitar uma certa perda em caso de falha, devemos buscar a possibilidade de utilizar janelas de backup durante as quais o sistema fica congelado para alterações, pois essa é a maneira mais barata de se garantir a integridade do dado que será submetido a mídia de backup. Substituindo a feature do sistema de alto valor, que deve garantir a existência de uma imagem consistente do dado para ser guardado a todo momento, por uma feature mais simples que congela as alterações e só permite novas alterações após o backup terminado.

• Disponibilidade

Alguns sistemas podem se dar ao luxo de não garantir a tão falada disponibilidade de 99.999% (acredite esses três últimos noves custam muito caro). 
Mas tenha certeza de que a indisponibilidade do seu sistema seja realmente algo com que você possa conviver. O nosso amigo ai do lado não ficaria muito feliz com problemas de disponibilidade do sistema dele.
Um artifício de bom custo benefício para melhorar a disponibilidade é a utilização de caches sempre que possível. Diferente de um sistema que garanta alta disponibilidade esses mecanismos vão mitigar indisponibilidades do seu sistema. 

• Controle de acesso

Assim como todos os demais aspectos, o controle de acesso pode ser menos regrado. Por exemplo, em situações extremas, uma solicitação de acesso a um ativo de alto valor ficaria parada até que todas as etapas do fluxo de autorização do acesso fossem cumpridas, em contrapartida, para ativos de médio valor, o acesso temporário poderia ser concedido desde que aprovado em primeira instância, podendo ser removido o acesso caso não autorizado em última instância pelo owner no ativo. Mas garanta que seu ativo realmente não requer um controle rigoroso de acesso. Utilizar a estratégia errada pode comprometer a segurança. Não é por ser de médio valor que o ativo tem que seguir todas as políticas desse nível, alguns aspectos do nível superior podem ser seguidos, sendo esse o principal deles.

• Log Server

Mesmo para os ativos de médio valor, deve-se avaliar a questão dos logs. Existem informações de acesso que podem ser requisitadas para atividades de investigação, ou mesmo por auditorias e a centralização dessas informações facilita o acesso as mesmas. Sem mencionar que a operação é feita de forma centralizada, muito mais simples de ser gerida (monitoração do espaço em disco ocupado, gerenciamento do backup, acesso as informações de execução das aplicações para viabilizar aos desenvolvedores a identificação mais clara dos eventos e falhas do sistema em produção que por ventura eles estiverem depurando etc.)

Em contrapartida, cada ativo pode optar por gerar e gerenciar seus logs localmente, mas esse tipo de estratégia para empresas com muitos ativos implica em um esforço muito grande para manter o controle da quantidade de disco disponível por exemplo. Conceder acesso de leitura para os desenvolvedores nesse cenário pode se tornar um tremendo desafio pois os acessos ficaram literalmente espalhados por todos os ativos. Isso enfraquece substancialmente a segurança e potencializa em muito a existência de acessos não autorizados aos ambientes pela dificuldade que se apresentará em se verificar todos os acesso em todos os ambientes contra os diversos processos de solicitação de acesso.

• Hardening

Se para os ativos de alto valor você deve ter uma meta em termos de hardening bastante agressiva, para os ativos de médio valor basta garantir que os itens mais óbvios como configurações default, senhas padrão, falha ou falta de controle de acesso não existam no ambiente. Não havendo um grande interesse por parte dos atacantes (ativos de médio valor) seu ambiente não será extremamente alvejado pelos mesmos. Havendo um nível adequado de dificuldade para invadir o ambiente, é bastante lógico esperar que os atacantes procurarão alvos mais promissores ou mais fáceis de serem atingidos.

• Sistemas

Para os sistemas ainda devemos ter o controle do processo de Gestão de Mudança, entretanto, sendo o ativo destinado a um ambiente com menos critérios (ou critérios mais amenos) de promoção a produção, ele necessitará de um menor nível de controle, por exemplo: um sistema destinado a um ambiente para ativos de alto valor que não seja capaz de suportar o controle de acesso adequado, ou o nível de backup exigido, ou tenha vulnerabilidades de baixo a médio impacto conhecidas que não podem ser corrigidas, teria sua entrada em produção barrada. Esse mesmo sistema com as mesmas características poderia ser promovido a produção se destinado a ambientes com menor nível de exigência, como ambiente de médio valor. A expectativa sobre o nível do sistema tem apenas que ser compatível com a expectativa de operação do mesmo.


Por exemplo, no sistema de eliminação da sede (primeira ilustração desse tópico), nosso usuário (piriquito amarelo) entende como aceitável o bug que quase o afoga quando ele comete um erro na "entrada de dados" (abertura da torneira) e já está posicionado o bico na "saída" do sistema. Como mitigação durante o treinamento, o usuário foi alertado para não colocar o "bico" no dispositivo de saída antes de regular apropriadamente a saída, mas não há como proteger o usuário de um erro operacional. Para ser aceito no ambiente de alto valor a solução teria que ser completamente remodelada, conforme vemos ao lado.


Conclusão
Vencemos mais uma etapa. Agora entendemos que a segurança orientada a negócios tem uma visão bastante prática e não preza nem pelo controle total, nem pela ausência de controles, mas simplesmente pelo nível de controle adequado as necessidades e anseios do negócio.