Por Vanessa Bandeira Lins Teixeira
É comum a busca por práticas de segurança para tornar a vida mais protegida. A percebemos desde a criação de uma senha para a utilização de uma conta até o simples ato de se ativar o alarme de um carro. Todavia, em um ambiente computacional, é necessário compreender que a ação de se proteger virtualmente requer protocolos mais específicos que possam prevenir que o usuário venha a ser atacado ou, pelo menos, mitigar os efeitos associados a esse ataque.
De modo geral, um ambiente com vulnerabilidades permite a um invasor aplicar técnicas que resultem, por exemplo, no acesso a informações confidenciais, resultando na necessidade da adoção de medidas que evitem a ocorrência de incidentes de segurança, tornando os ambientes menos suscetíveis a explorações de vulnerabilidades.
O fato é que as recorrentes violações de segurança a sistemas de informação e comunicação retratam o crescimento gradual das “brechas” de sistemas deixadas pelos usuários, tornando-os alvos de possíveis ataques. Esse fato pode ser ilustrado a partir das 23543 vulnerabilidades divulgadas através dos CVEs pelo National Institute of Standards and Technology – NIST em 2022 (número divulgado até o dia 12 de dezembro de 2022) [9], um aumento de aproximadamente 60% sobre os números verificados em 2017 [12]. Diante desse considerável aumento no número de vulnerabilidades, o usuário se depara com o obstáculo de como priorizar as correções em seus sistemas através de práticas que mitiguem a ocorrência de ataques em sistemas computacionais.
Esses cenários de ambientes vulneráveis fazem parte da realidade vivenciada pelas equipes de segurança, mais especificamente pelos blue teams[9], que trabalham na avaliação diária dos sistemas, a fim de proteger os ativos de vulnerabilidades que afetem dispositivos ou sistemas críticos das empresas. Esse tipo de avaliação de segurança diária faz parte do contexto presente na gestão de vulnerabilidades e conformidades de um ambiente.
Além da identificação das ameaças, é fundamental que as práticas para mitigar as vulnerabilidades do ambiente sejam utilizadas também nos sistemas operacionais, de modo a manter os ambientes das corporações protegidos, tendo em vista que a todo instante alguma vulnerabilidade pode estar sendo explorada por hackers [1].
Uma coisa é certa: novos softwares são desenvolvidos todos os dias e cada um deles pode trazer suas próprias lacunas. Além disso, as configurações desses aplicativos também podem aumentá-las [2]. Com isso, faltam configurações orientadas para a segurança em uma parte significativa dos sistemas operacionais atuais. Esses ativos, que geralmente não são configurados corretamente, considerando os requisitos de segurança, tornam-se alvos fáceis para um número considerado de ataques à segurança [3]. Dessa maneira, torna-se claro que a aplicação de políticas de conformidade nos sistemas operacionais ajuda a preservar o ambiente, por meio de configurações de segurança, resultando em ambientes menos expostos a ataques de usuários mal intencionados.
1. Entendendo políticas de conformidade de segurança para sistemas operacionais
Grande parte das instituições voltadas à segurança cibernética concentram seus esforços no desenvolvimento de práticas de segurança. O Center for Internet Security – CIS é uma organização sem fins lucrativos que tem como missão a defesa cibernética, sendo um dos principais entregáveis, as políticas de conformidade dos sistemas operacionais [6].
Uma política de conformidade é um documento que tem por finalidade garantir que estes sistemas sigam um procedimento com as melhores recomendações de segurança, de modo a apoiar os objetivos de segurança da organização[4]. Ou seja, são recomendações estruturadas em categorias, compostas por itens de configurações de segurança para os ambientes, impactando na redução e mitigação de vulnerabilidades e ameaças. Essas recomendações são revisadas e atualizadas de maneira minuciosa por profissionais de segurança da informação.
2. Metodologia de Segurança de Sistemas Operacionais Considerando Políticas de Conformidade
A importância de se avaliar a segurança de sistemas operacionais se torna ainda mais crítica quando essa análise é feita em sistemas operacionais para servidores. Ameaças envolvendo vulnerabilidades encontradas nestes sistemas operacionais tendem a gerar riscos mais significativos, pois estes sistemas em geral são usados para atividades críticas das empresas.
Com o intuito de servir como prova de conceito para uma avaliação da segurança de sistemas operacionais considerando políticas de conformidade, bem como também servir de base para outros futuros projetos de avaliação de segurança, esta pesquisa propôs a definição de uma metodologia que consiste em um fluxo dividido em 5 processos, conforme apresentado mais abaixo e ilustrado pela Figura 1. Vale ressaltar ainda que a definição desta metodologia considerou um conjunto de requisitos, condições e situações (tais como, analise de conjuntos de SOs disponíveis no mercado, ferramentas de vulnerabilidades mais utilizadas para análise de SOs, pesquisas sobre Gestão de Conformidades disponibilizadas na Academia, principais de centro de segurança sobre Gestão de Vulnerabilidades e Conformidades, entre outros) que foram estudados pela autora, bem como também foi baseada na sua experiência e envolvimento nos projetos de gestão de vulnerabilidades e conformidades em que a mesma vem atuando nos últimos anos na Tempest.
Para a aplicação desta metodologia proposta de avaliação de segurança de sistemas operacionais considerando políticas de conformidade é importante entender o fluxo do processo seguido, de modo a detalhar as atividades necessárias à sua realização. Este processo é disposto da seguinte maneira:
- especificar qual o foco da análise;
- estabelecer as métricas que serão utilizadas;
- selecionar e configurar o ambiente que será alvo da avaliação de segurança;
- descrever os artefatos utilizados, para que a análise de segurança possa ser executada;
- avaliar e apresentar os resultados obtidos, de modo a serem geradas informações e recomendações úteis em relação ao nível de segurança atual do sistema.
A seguir será apresentada uma melhor descrição de cada uma destes processos da metodologia proposta.
2.1. Definir os objetivos da avaliação
Na atividade inicial são definidos os objetivos a serem seguidos dentro da avaliação de segurança. Esses podem incluir, por exemplo: avaliar a segurança de sistemas operacionais móveis considerando políticas de conformidade; analisar os impactos da aplicação de políticas de conformidade perante as vulnerabilidades do sistema ou classificar o nível de segurança dos sistemas operacionais (desktop), observando diferentes tipos de configurações de usuários. Ao definir os objetivos, a avaliação perde o caráter subjetivo e ganha um caráter objetivo/prático. Isso é importante porque não é recomendado afirmar que uma configuração está correta ou não sem que existam objetivos e métricas atrelados.
2.2. Determinar as métricas
Para essa etapa serão definidas as métricas para análise dos resultados, sistematizando a quantificação. Em outras palavras, para a realização de uma avaliação de segurança de sistemas, utilizando políticas de conformidade, é importante definir como será feita a análise desses resultados. Exemplos de métricas incluem: número de vulnerabilidades (quantificação das vulnerabilidades encontradas baseadas nas suas criticidades) e nível de conformidade (número percentual que indica quantos dos controles de segurança estão aderentes com a política de conformidade adotada).
2.3. Selecionar e configurar o ambiente
Essa atividade consiste na definição e configuração dos ativos que farão parte do ambiente. Por exemplo, na atividade se definirá o hardware utilizado (incluindo informações como processamento, armazenamento etc.) e softwares instalados (sistemas operacionais, aplicações do usuário, dentre outras).
Um ponto importante a ser ressaltado está ligado à necessidade de se conhecer o perfil ao qual são destinados os ativos. Por exemplo, os sistemas operacionais voltados ao uso, como servidores, podem ser estruturados com um domínio ou, para os casos de servidores Windows, devem ter as configurações de controlador de domínio. Importante ressaltar que nessa atividade também são detalhadas informações como versão do sistema operacional, pois, a depender dessa versão, a quantidade de vulnerabilidades pode divergir.
Finalmente, vale destacar que, nessa etapa, toda a configuração do ambiente, incluindo aspectos de rede, como definição do endereço IP, deve ser realizada.
2.4. Descrever o projeto e execução da avaliação
Na penúltima fase ocorrerá a definição e a execução da avaliação, seguindo os objetivos e características definidos nas seções anteriores. A descrição do projeto de avaliação proposto é composta, dentre outros artefatos, de arquivos de auditoria do sistema operacional e definição de uma política de verificação do ambiente.
O processo de criação dos arquivos de auditoria, como pode ser observado na Figura 2, parte da iniciativa de verificar se as configurações do sistema operacional estão de acordo com as recomendações de segurança. Mediante os arquivos de auditoria é possível aplicar as políticas de conformidade de maneira a serem interpretadas pelos sistemas operacionais.
A partir disso, a avaliação de conformidade pode ser realizada. Um exemplo de estrutura básica de um item presente em um arquivo de auditoria pode ser observado na figura adiante. Cada item é verificado por meio do marcador custom_item. Esses marcadores são estruturados com palavras chaves que serão interpretadas pela ferramenta de varredura de vulnerabilidades, com o intuito de identificar se o sistema operacional está conforme ou não as recomendações de segurança.
A utilização da ferramenta de varredura de vulnerabilidades é essencial para a coleta de informações relacionadas ao estado do ambiente e na identificação de possíveis não conformidades. Esses dados são obtidos com o uso dos arquivos de auditoria que definem o valor esperado para cada configuração de segurança aplicada aos sistemas operacionais, baseado nas políticas de conformidade desses sistemas. Para isso, é necessário que essa ferramenta receba as configurações necessárias para a sua instalação no ativo que irá hospedá-lo.
A descrição do projeto é instituída com a criação de uma política de verificação do ambiente. Para o procedimento de checagem das configurações de um sistema, atribui-se a ferramenta de varredura de vulnerabilidades às informações de identificação do ativo analisado na rede, como: endereço IP, credenciais de autenticação, arquivo de auditoria do sistema, domínio ao qual pertence a máquina, caso exista, e uma seleção de plugins de auditoria que são disponibilizados pela ferramenta de varredura de vulnerabilidades escolhida. Essas informações são necessárias para que a ferramenta de varredura de vulnerabilidades identifique o ativo que será avaliado.
2.5. Analisar e apresentar os resultados
A etapa final da metodologia compreende a análise dos dados que foram retornados após a execução da avaliação. As informações retornadas pela ferramenta de varredura podem estar estruturadas em arquivos como html, pdf ou csv, contendo as informações relacionadas às configurações que foram verificadas. Esses dados podem ser constituídos por itens de configuração que falharam quando analisados sob a ótica das políticas de conformidade dos sistemas operacionais escolhidos.
É importante que sejam consideradas as métricas determinadas previamente como descrito na subseção 2.2, relacionando-as com os objetivos definidos para a aplicação da metodologia. Essas métricas auxiliarão na filtragem e organização dos dados, como a criação de gráficos que facilitem a visualização e apresentação das informações, com o intuito de se alcançar os objetivos pretendidos e definidos na etapa 2.1.
3. Estudo de Caso para Validação da Metodologia e Análise dos Resultados Obtidos
Como forma de validação da aplicação da metodologia proposta, a pesquisa realizada fez uso de um estudo de caso que é apresentado nesta seção. O estudo de caso adotado visou analisar a segurança de sistemas operacionais voltados para Servidores comumente usados por empresas, já que esses tipos de sistemas operacionais, em sua maioria, hospedam serviços compartilhados e a ocorrência de vulnerabilidades nesses sistemas podem impactar em riscos mais altos. Além disso, esta pesquisa busca incentivar boas práticas capazes de facilitar o entendimento dos usuários perante as vulnerabilidades e ameaças presentes, apresentando as principais alternativas de correção das configurações.
A métrica adotada neste estudo de caso para medir o nível de conformidade é o índice de conformidade, que representa o retorno identificado por cada política de conformidade considerando as configurações dos sistemas operacionais [7]. Essa métrica auxilia na análise e categorização dos resultados. Os valores possíveis para esta métrica são: Aceito, para a configuração que está de acordo com as recomendações de segurança, e Falho, para a configuração que não está de acordo com as recomendações de segurança.
Para a seleção dos sistemas operacionais a serem adotados nesta avaliação, foi utilizada uma listagem publicada pelo CVE Details com as 50 principais versões de sistemas operacionais com mais vulnerabilidades de segurança relacionadas a eles[11].
Dos 50 sistemas operacionais, O Debian 8 foi o sistema operacional que se destacou na listagem analisada. A partir desta seleção configurado um ambiente para a emulação deste sistema nas configurações de fábrica.
A criação dos arquivos de auditoria foi realizada baseada nas políticas de conformidade do Debian 8 fornecidos pela CIS benchmarks, que é uma organização referência em benchmarks de segurança e um dos mais adotados para esta finalidade.
Ao executar a checagem de configurações nos sistemas operacionais, foram levantados dados relevantes para a avaliação de segurança [7]. Esses dados foram extraídos do software de varredura de vulnerabilidades no formato .csv e tratados com o uso da biblioteca dplyr, que permite a manipulação de dados com funções matemáticas e estatísticas na linguagem R.
Para o Debian 8, do total geral de itens verificados e classificados em 6 categorias (Configuração Inicial; Serviços; Configuração de Rede; Registro e Auditoria; Acesso, Autenticação e Autorização; Manutenção do Sistema), 263 retornaram o status de falho e 152 itens foram aceitos. O resultado pode ser observado na Figura 3, que apresenta a quantidade de itens por categorias.
Analisando as categorias de Configuração Inicial, Configuração de Rede, Registro e Auditoria, e Acesso, Autenticação e Autorização, pode-se notar o expressivo número de itens falhos que foram identificados nestas 4 categorias. Para a categoria de Configuração Inicial, 44 itens retornaram o status de falho. Esses itens, de maneira geral, correspondem a configurações de partições separadas, permissionamento de usuários a arquivos e gerenciamento de atualização de software. Já a categoria de Configuração de Rede apresentou 48 itens não conformes que são relacionados às recomendações de configurações de rede, como protocolos e regras de firewall. Por fim, se avalia os itens que demonstraram mais falhas de configuração. Para a categoria de Registro e Auditoria, 121 não conformidades foram detectadas e na categoria de Acesso, Autenticação e Autorização, 41 itens falharam. Esses números podem representar ameaças aos sistemas de registro e auditoria, já que os arquivos pertencentes a essa categoria são responsáveis pelo monitoramento de comportamentos suspeitos no sistema. Nesse sentido, a categoria de Acesso, Autenticação e Autorização configura-se no geral por itens que tratam do gerenciamento de senhas dos usuários, identificação dos usuários e grupos, além dos privilégios de acesso aos recursos do sistema especificados para cada usuário ou grupo. Apesar das categorias descritas por Serviços e Manutenção do Sistema retornarem 7 e 2 itens falhos, respectivamente, nota-se que o impacto delas foi menor quando relacionadas às quantidades de falhas das outras categorias.
Os números extraídos através da avaliação de segurança do sistema operacional possibilitaram a classificação das informações por meio das categorias do sistema que obtiveram mais configurações falhas. Essa classificação pode servir como diretriz na aplicação das boas práticas de segurança aos itens que serão priorizados, sendo ela composta por:
- Políticas relacionadas às senhas dos sistemas: apresentam critérios que devem ser seguidos por todos os usuários, assegurando que a segurança durante o acesso aos sistemas corporativos sejam seguidos.
- Políticas de acesso, autenticação e autorização: essas configurações deveriam ser aplicadas a fim de evitar que usuários mal intencionados acessem a rede interna de uma empresa e tenham permissão para acessar dados importantes de uma organização.
- Políticas de monitoramento das configurações aplicadas por usuários: as políticas de conformidade relacionadas a essa classificação tratam, basicamente, os acessos e instalações de software realizadas pelos usuários. Esse gerenciamento auxilia na identificação de acessos desconhecidos.
- Políticas de configurações de rede: Por meio destas políticas, são feitos os controles de acesso à rede.
4. Conclusão
Mesmo considerando que as configurações de segurança de sistemas operacionais tenham um caráter subjetivo, é possível que, por meio de métricas, seja definido como essas configurações serão avaliadas. Ao analisar o curso seguido pela metodologia proposta nesta pesquisa, chega-se à conclusão de que, cada vez mais, buscar mitigar e solucionar vulnerabilidades de segurança são consideradas tarefas relevantes e complexas. No entanto, analisando o fluxo da lógica proposta pela metodologia, é possível sistematizar o processo de mitigação das vulnerabilidades nos ativos da infraestrutura de TI, por meio de ferramentas e documentações de segurança disponibilizadas no cenário atual. De fato, o que não deve ser deixado de lado é que para toda configuração de segurança deve-se balancear o impacto dela para o ativo versus a ameaça oriunda da sua não aplicação.
Apesar dos relevantes resultados obtidos na aplicação desta metodologia de avaliação proposta nesta pesquisa, a discussão sobre políticas de conformidade nos sistemas operacionais precisa ainda ir além desta metodologia aqui apresentada. Com esta imersão aqui realizada na gestão de conformidades espera-se, então, que outros estudos de casos sejam realizados com a aplicação da metodologia descrita. O propósito desse artigo é incentivar e esclarecer questões de uma área que precisa andar ainda mais em conjunto com a gestão de vulnerabilidades, uma vez que grande parte das vulnerabilidades são originadas de configurações que não condizem com as recomendações de segurança.
Referências
[1] Angraini, R. A. Alias, and Okfalisa, “Information security policy compliance: Systematic literature review”, the Fifth Information Systems International Conference, 23-24 July 2019 – Procedia Computer Science, vol.161, pp. 1216 – 1224, 2019, Surabaya, Indonesia.
[2] A. Gorbenko, A. Romanovsky, O. Tarasyuk, and O. Biloborodov, “Experience report: Study of vulnerabilities of enterprise operating systems “, in 2017 IEEE 28th International Symposium on Software Reliability Engineering (ISSRE), Oct 2017, pp. 205–215.
[3] A. Mounji and B. Le Charlier, “Continuous assessment of a unix configuration: integrating intrusion detection and configuration analysis” in Proceedings of SNDSS ’97: Internet Society 1997 Symposium on Network and Distributed System Security, 1997, pp. 27–35.
[4] A. L. Mesquida and A. Mas, “Implementing information security best practices on software lifecycle processes: The iso/iec 15504 security extension” Computers and Security, vol. 48, pp. 19 – 34, 2015.
[5] C. of Internet Security, “CIS Benchmarks” Oct 2020, Acessado em: 2020-10-24. [Online]. Disponível em: https://www.cisecurity.org/ cis-benchmarks/
[6] C. of Internet Security, “CVE Details”, 2020. Acessado em: 2020-12-19. [Online]. Disponível em: https://www.cvedetails.com/top-50-versions.php
[7]I. Chalvatzis, D. A. Karras, and R. C. Papademetriou, “Evaluation of security vulnerability scanners for small and medium enterprises business networks resilience towards risk assessment” in 2019 IEEE International Conference on Artificial Intelligence and Computer Applications (ICAICA), 2019, pp. 52–58.
[8]I. O. of Standardization, “ISO/IEC 27000:2018 information technology – security techniques – information security management systems – Overview and vocabulary”. Fev 2018. Acesso em 2 de novembro . Disponível em: https://www.iso.org/standard/73906.html.
[9]NIST, “CVEs Received and Processed”. Acesso em 1 de dezembro de 2021. Disponível em: https://nvd.nist.gov/general/nvd-dashboard.
[10] N. Veerasamy, “High-level methodology for carrying out combined red and blue teams”, in 2009 Second International Conference on Computer and Electrical Engineering, vol. 1, 2009, pp. 416–420.
[11] O. H. Alhazmi and Y. K. Malaiya, “Quantitative vulnerability assessment of systems software” in 2005, Annual Reliability and Maintainability Symposium. Proceedings, pp. 615–620.
[12] S. N. Scott Caveza and R. Quinlan, “Tenable’s 2020 threat landscape retrospective”, Tenable Network Security, Jan 2021. [Online]. Disponível em: https://pt-br.tenable.com/cyber-exposure/ 2020-threat-landscape-retrospective