Boas Práticas de Segurança

Boa Práticas de Segurança

Visão Geral

As ameaças do mundo digital se tornaram uma preocupação expressiva para empresas que utilizam soluções de software.

A CIGAM tem aperfeiçoado o estado de segurança de suas aplicações por meio da implementação das mais modernas técnicas dentro de cada tecnologia utilizada nas diversas camadas que compõe a solução. Cada uma dessas camadas é submetida por uma série de testes a cada release gerada do CIGAM, a fim de assegurar a segurança dos pontos já mapeados bem como mapear novos pontos para que se amplie os testes cada vez mais.

A arquitetura base do sistema sustenta as diretrizes que estruturam o conjunto de boas práticas de segurança para uso do CIGAM, abrangendo uma variedade de recursos e tecnologias que compõem CIGAM.

Como a aplicação do CIGAM pode ser instalada e executada em ambientes construídos sob a responsabilidade de parceiros e clientes, é essencial que estes participem ativamente dessa cultura de segurança, observando sempre o conjunto de boas práticas para a utilização do CIGAM.

A inevitável miscelânia de camadas e tecnologias utilizadas na construção do CIGAM potencializa as necessidades de análise de todas as preocupações com os aspectos de segurança e performance em diversos âmbitos. A partir disso, entende-se que uma das principais ações que deve estar presente nas boas práticas é o frequente processo de atualização dos recursos e tecnologias utilizados, respeitando as recomendações de software e hardware conforme indicado pela CIGAM disponíveis e através da wiki do sistema CIGAM.

É sabido que cada ambiente onde o CIGAM é executado possui suas particularidades, muitas delas devido ao segmento ou tipo de negócio do cliente. Dentro dessa realidade, é sabido que haverá muitos tipos de ambientes com diversas particularidades. Contudo, certas disposições dos recursos são intrinsecamente menos resilientes a incidentes de segurança, como é o caso da arquitetura de servidor único (Figura 1) para ambientes de processamento moderado, em que existe um servidor único para todas as camadas de tecnologias de aplicações.

Figura 1 - Arquitetura de servidor único para todas as camadas.

É importante destacar que vários fatores são considerados no momento em que o ambiente do é montado, como por exemplo os custos de investimento de software e hardware. Essa realidade faz com que quanto menor o investimento no ambiente, menor o nível de segurança. Dessa forma, ao optar por um ambiente com menor nível de segurança devido a qualquer fator, se assume os riscos de segurança que poderiam ser mitigados com um nível maior de segurança.

Já os ambientes com arquitetura segmentada (Figura 2), por distribuir os recursos e tecnologias utilizadas no sistema CIGAM em múltiplos servidores, faz-se mais resiliente a incidentes adversos. Estes incidentes podem ser explorações de vulnerabilidades conhecidas, comprometimento da integridade de arquivos, falhas de hardware, erro humano, entre outros.

Figura 2 - Arquitetura segmentada

É importante destacar que o banco de dados deverá sempre estar num servidor dedicado, tanto em ambientes com processamento moderado quanto ambientes de alto processamento, respectivamente com arquiteturas de servidor único ou segmentada.

Com os problemas referentes à arquitetura em que existe um servidor único para todas as camadas de tecnologias do sistema é possível perceber que incidentes como exploração de vulnerabilidades conhecidas possuem um impacto ao funcionamento do sistema muito maior do que em uma arquitetura segmentada. No caso de um incidente em um recurso ou tecnologia individual do sistema na arquitetura de servidor único, todos os outros recursos ou tecnologias podem ser comprometidos, indisponibilizados ou corrompidos. Além disso, essa arquitetura dificulta os processos de atualização de versão ou troca de recursos e tecnologias, aumentando o risco associado a estes processos.

Reforçando o descrito nos requisitos de hardware, os ambientes de servidor único precisam de uma configuração de hardware melhor pois apenas um servidor será responsável por todo o processamento da aplicação. Já os ambientes de arquitetura segmentada possuem vários servidores, fazendo que cada servidor individualmente possa ter uma configuração de hardware um pouco inferior. Esse ponto é muito importante de ser avaliado pois impacta diretamente o custo do ambiente, performance e segurança.

Entendidos as variações de ambientes conforme visto anteriormente, entende-se como necessário oferecer uma forma de mensurar as condições em que o sistema CIGAM está inserido no ambiente do cliente. Neste sentido, são apresentadas a seguir as formas de medição e escala de maturidade.

Medição

Com base na visão geral da arquitetura do sistema CIGAM e norteado pelo objetivo de auxiliar na implantação e configuração do ambiente de uso do CIGAM, propõe-se a uma forma de mensurar o nível de conformidade em relação às boas práticas recomendadas pela CIGAM quanto a utilização do sistema.

O objetivo desta escala é fornecer uma métrica de posicionamento em relação a este conjunto de boas práticas. Quanto maior for a pontuação do ambiente, maior a resiliência contra incidentes e eficiência em sua performance. O instrumento utilizado para a verificação do nível de conformidade é apresentado no Anexo A - Escala de Maturidade de Segurança.

Indicar uma forma de mensurar o nível de conformidade em relação às boas práticas também significa contribuir com os processos internos na CIGAM. Do ponto de vista de gestão de processos relacionados à segurança da informação, podemos considerar alguns impactos relevantes:

• Horas técnicas utilizadas: a maior parte dos incidentes relacionados às versões, atualizações e infraestrutura associa uma demanda de abertura de chamados. A utilização de horas de trabalho dos técnicos, que são responsáveis por responder a um chamado que sabidamente não pode ser solucionado por eles, acaba onerando o tempo disponível no mês com demais chamados.
• Danos de reputação: quando as recomendações feitas pela CIGAM e sua equipe não são devidamente seguidas, problemas com o sistema tendem a ocorrer com maior frequência. Isso pode implicar em frustrações com o sistema CIGAM por parte dos colaboradores da empresa cliente, que irão deparar-se com performance reduzida na utilização do sistema.
• Perda de produtividade/eficiência: devido a performance inadequada do sistema em virtude da não aderência às recomendações de hardware e software providas pela CIGAM, as atividades de trabalho dos colaboradores usuários do sistema CIGAM serão prejudicadas.

Riscos e preocupações

Este conjunto de boas práticas tem por objetivo melhorar a experiência de uso do CIGAM, proporcionando maior segurança e eficiência bem como proteger os dados e infraestrutura utilizados por seus clientes. Sendo assim, não seguí-las expõe o cliente a riscos à segurança dos dados utilizados no sistema, além de comprometer a performance do sistema, reduzindo a eficiência na utilização.

A partir do detalhamento de cada um dos recursos e tecnologias presentes CIGAM, é feito periodicamente uma verificação das vulnerabilidades conhecidas de forma individual. Muito desse trabalho é feito com base no catálogo de vulnerabilidades disposto pela MITRE, denominado CVE (Common Vulnerabilities and Exposures).

Sendo assim, o impacto individual de cada vulnerabilidade é potencializado ou não dependendo da forma que o ambiente foi montado e quais versões de software estão sendo utilizadas. Neste sentido, o aspecto da infraestrutura originalmente comprometida torna-se um novo vetor de ataque, aumentando o impacto da exploração original onde o atacante tem uma maior superfície de ataque.

Ao optar por arquiteturas de servidor único, conforme mencionado previamente neste documento, alguns riscos específicos podem surgir. Nesse sentido, o uso de um modelo de infraestrutura segmentada pode mitigar substancialmente alguns desses riscos. Exemplos destes são:

• Maior vulnerabilidade da pilha de recursos e tecnologias caso algum recurso ou tecnologia individual dela seja comprometido;
• Menor resiliência contra incidentes de falha de hardware;
• Menor resiliência contra incidentes de conexão;
• Maior dificuldade em efetuar atualizações de versão e correções de desempenho e segurança;

Uma alternativa que pode ser considerada é a utilização de uma infraestrutura parcialmente segmentada. Como consequência, há um menor grau de resiliência a incidentes em comparação a arquitetura totalmente segmentada. Cabe considerar, a respeito da resiliência a incidentes, que a utilização de protocolos de comunicação seguros entre os diferentes recursos e tecnologias contribuem para uma melhor condição do ponto de vista de segurança.

Por se tratar de uma pilha de tecnologias e recursos que constituem o sistema CIGAM, naturalmente surgirão versões de um ou mais itens que deixarão de ser suportadas com o passar do tempo. Devemos entender como “não mais suportados” todas as tecnologias que não estão dentro do período de suporte do próprio fabricante. Alguns fabricantes disponibilizam um período de suporte estendido após o término do período de suporte regular, mas esse período de suporte estendido deve ser considerado como um período para testes, homologação e aquisição da nova versão e não como uma extensão do período de suporte regular.

Geralmente nas versões não mais suportadas os principais problemas relatados estão relacionados à performance, segurança e compatibilidade. Esses problemas comprometem o bom funcionamento do sistema e entende-se que os riscos associados a elas são considerados grandes o suficiente para desencorajar a sua utilização.

Assim, compreende-se que essas versões não mais suportadas são incapazes de sustentar o sistema apropriadamente.