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!