Não há sistemas operacionais sem vulnerabilidades - a única questão é a eficácia com que os desenvolvedores os identificam e fecham. Nosso sistema operacional Astra Linux Special Edition não é exceção: constantemente verificamos e testamos o código em busca de erros, violações de lógica e outros bugs e os corrigimos rapidamente. Caso contrário, o FSTEC da Rússia dificilmente teria certificado o Astra Linux para processar dados que constituem segredos de estado. Mas falaremos sobre certificação em mais detalhes em outro post. Neste artigo, falaremos sobre como as vulnerabilidades do Astra Linux são organizadas e como as ameaças à segurança da informação são interagidas com o banco de dados doméstico.
Foto: Leonhard Foeger / ReutersA primeira abordagem, arquitetônica
Para melhorar a segurança do sistema operacional, usamos duas abordagens. A primeira,
arquitetônica , é que desenvolvemos e implementamos várias ferramentas de proteção de informações no estágio de design. Essas ferramentas formam um
complexo de equipamentos de proteção (KSZ) , que implementa funções de segurança. Com a ajuda da KSZ, estamos tentando garantir que o sistema já minimize o risco de possíveis ameaças por padrão.
Arquitetura do Astra LInux Special Edition Security SuiteUm elemento chave do KSZ é
o monitor de chamadas , projetado para impedir o acesso não autorizado e a alteração de componentes protegidos do sistema. O monitor fornece controle de acesso discricionário, baseado em função e obrigatório, além de monitoramento obrigatório da integridade.
O que é
monitoramento obrigatório de integridade ? Vamos ilustrar com um exemplo. Um componente chave do sistema operacional é o kernel. Portanto, somos obrigados a fornecer o tempo de execução mais seguro no próprio sistema operacional, a fim de reduzir o número de métodos possíveis de ataque ao kernel.
Para fazer isso, implementamos o monitoramento obrigatório da integridade no sistema operacional, devido ao qual segmentamos o sistema operacional por vários subsistemas para que a quebra de um subsistema não afete o desempenho de outros. Se um usuário não privilegiado do SO (nível de integridade 0) ou de um subsistema de rede (nível de integridade 1), sistema de virtualização (nível de integridade 2), uma interface gráfica (nível de integridade 8) ou outro componente for invadido, isso não implicará em desacreditar todo o KSZ (nível de integridade) 63)
Note-se que esses níveis não são hierárquicos, ou seja, não estão localizados um acima do outro e são completamente isolados um do outro em termos da possibilidade de direitos de gravação. O monitor de acesso determina o acessório de um objeto para um ou outro nível de integridade pela máscara de bits.
Para que os níveis de integridade não sejam percebidos como hierárquicos - ou seja, "o nível 8 tem mais direitos que o nível 2", o que está errado - cada um dos níveis recebe seu nome. Por exemplo, o oitavo nível de integridade é chamado "Servidor Gráfico", o nível máximo possível de integridade do administrador no sistema é "Alto" e o nível zero de integridade (usuário) é "Baixo".
O monitor de chamadas, descrito em nosso
artigo anterior, controla e elimina a possibilidade de influenciar processos entre si com rótulos de diferentes níveis de integridade.
Portanto, o sistema operacional recebe um conjunto de regras sobre como isolar os processos do sistema e agora entende quais processos, mesmo aqueles iniciados por um usuário com altos privilégios, não têm o direito de gravar em outros processos ou arquivos.
Portanto, se como resultado da exploração de uma vulnerabilidade (incluindo dia zero), um invasor obtém controle sobre um processo no sistema e aumenta sua autoridade para um usuário privilegiado (por exemplo, raiz), sua marca de integridade permanecerá a mesma e, portanto, ele não receberá a capacidade de influenciar processos do sistema, alterar configurações ou ocultar sua presença no sistema.
Princípio de operação de níveis de integridade isoladosPortanto, nem todo o sistema operacional se torna um alvo significativo para um invasor, mas apenas o núcleo reforçado e o monitor de acesso mais compacto, o que já reduz significativamente a superfície de ataque.
Além do obrigatório, há também um controle de integridade dinâmico e regulatório. Eles são usados para excluir o lançamento e o uso de software não confiável ou de terceiros, bem como verificações periódicas da integridade do sistema.
O controle dinâmico calcula e verifica a assinatura digital eletrônica de arquivos executáveis no momento do seu lançamento. Se não houver EDS ou estiver incorreto, o lançamento dos programas será negado. Até certo ponto, essa é uma implementação do conceito de lista de permissões, mas através do uso de uma hierarquia de chaves emitida para desenvolvedores de software.
Trabalhar com controle dinâmico de integridadeO controle de rotina verifica a integridade e a imutabilidade dos arquivos-chave de um sistema, comparando suas somas de verificação com os valores de referência. Pode ser arquivos de configuração ou qualquer outro.
Assim, o sistema operacional usa proteção em camadas contra vulnerabilidades nos aplicativos e sua substituição, minimizando os danos causados por ameaças à segurança, incluindo aqueles que usam vulnerabilidades de dia zero.
A segunda abordagem de processo
Juntamente com a arquitetura, usamos simultaneamente a abordagem do
processo : identificamos e coletamos constantemente informações sobre vulnerabilidades, trabalhamos com essas informações e transferimos os resultados para o banco de dados de vulnerabilidades da FSTEC na Rússia. Por isso, preparamos e lançamos atualizações agendadas e operacionais do sistema operacional. Estamos procurando vulnerabilidades tanto em fontes abertas quanto independentes - especialmente nas partes do software que desenvolvemos por nós mesmos. Recebemos muitas informações de parceiros envolvidos em pesquisas semelhantes - testando e estudando a segurança dos sistemas operacionais.
Gerenciamento de vulnerabilidadesOs estudos de segurança são realizados principalmente em relação aos componentes que fazem parte do Astra Linux Special Edition (Smolensk). Ao mesmo tempo, as vulnerabilidades também são fechadas para o Astra Linux Common Edition, como parte de atualizações de segurança e como parte de uma atualização agendada dos componentes do sistema.
Assim que recebemos informações sobre a vulnerabilidade, verificamos quão relevante é para nossos usuários.
Se a vulnerabilidade não for crítica, descreveremos na próxima edição do boletim de segurança no site oficial. As notificações sobre a questão das cédulas são enviadas ao usuário por e-mail, cujo endereço é necessariamente indicado no contrato de licença.
Para vulnerabilidades críticas, as diretrizes são emitidas por vários dias : como você pode corrigi-lo por conta própria sem aguardar uma atualização de segurança cumulativa. Na
lista de boletins
de segurança, eles são marcados com as letras MD (direção metódica).
Uma vulnerabilidade é um bom exemplo aqui, informações sobre as quais foram
publicadas aqui no Habré. A propósito, o autor deste artigo não entrou em contato conosco com antecedência e não notificou preliminarmente que havia identificado essa vulnerabilidade e estava preparando material. Como ilustração, decidimos citar o momento do trabalho sobre a vulnerabilidade a partir do momento em que o texto foi publicado no recurso.
Então, à noite, às 04:00, em 9 de julho de 2019, o próprio artigo foi publicado, que ao manipular o tamanho da tela de uma máquina virtual, você pode ver as janelas sob o bloqueio da tela.
É importante notar que, para explorar a vulnerabilidade demonstrada no vídeo, é necessário executar várias etapas adicionais: você deve primeiro instalar pacotes adicionais na máquina virtual Astra Linux e, em seguida, na máquina convidada, responsáveis por alterar a resolução da máquina virtual em tempo real, mas não fazem parte de um sistema operacional certificado.
Em 10 de julho de 2019, as informações de vulnerabilidade foram
publicadas no FSTEC BDU. A severidade da vulnerabilidade foi definida como média (a pontuação base para a métrica CVSS 2.0 foi de 4,9, para a métrica CVSS 3.0 - 4).
Em 12 de julho, publicamos o boletim de segurança nº
20190712SE16MD para Astra Linux Special Edition versão 1.6 e o boletim de segurança
2019 20191212SE15MD para Astra Linux Special Edition versão 1.5. Uma atualização de segurança semelhante foi recebida pelo Astra Linux Common Edition.
Portanto, menos de quatro dias se passaram desde a publicação de informações sobre a vulnerabilidade de nível médio ao lançamento do patch para todas as versões do Astra Linux (onde a virtualização é possível).
Esquema de atualizações ao vivo para o Astra LinuxPelo menos uma vez por trimestre, lançamos atualizações de segurança - atualizações
operacionais que eliminam vulnerabilidades desconhecidas anteriormente, incluindo software de aplicativo, bibliotecas e funções de SO que não implementam requisitos de segurança. Se as ameaças de segurança implementadas usando a vulnerabilidade não puderem ser descartadas com medidas compensatórias, está em andamento o trabalho para finalizar o sistema operacional. Após a conclusão do desenvolvimento e teste da atualização de segurança, o site também publica o boletim e a própria atualização. Nos primeiros seis meses de 2019, duas atualizações cumulativas para o Astra Linux Special Edition versão 1.6 foram lançadas, cobrindo centenas de vulnerabilidades diferentes. Agora o terceiro está sendo preparado para o lançamento.
Por fim, estamos interagindo ativamente com a comunidade de desenvolvedores:
- Informamos nos rastreadores de erros do projeto sobre erros detectados;
- transferimos para os projetos as correções prontas das deficiências que fechamos;
- apelamos à comunidade para ajudar na eliminação de deficiências - o conhecimento da lógica do programa permite que você obtenha uma ordem de magnitude de correção mais rápida do que a engenharia reversa realizada por conta própria;
- Usamos e incluímos em nossas atualizações todas as correções emitidas pela comunidade. Entendemos isso melhorando assim a qualidade do produto. Ao mesmo tempo, aplicamos os métodos de controle e construção de confiança, descritos no artigo anterior .
A abertura é importante
Como nosso sistema operacional é certificado pelo FSTEC da Rússia, primeiro adicionamos informações sobre as vulnerabilidades encontradas no banco de dados de ameaças à segurança da informação (DBU) da FSTEC para publicação oficial: se você for ao
DBU , encontrará informações sobre mais de 350 vulnerabilidades corrigidas em diferentes versões do Astra Linux bem como informações detalhadas sobre eles.
Assim, garantimos abertura no trabalho. Graças a isso, os usuários - incluindo o regulador - podem, em certa medida, confiar que a segurança está realmente sob controle. Não é o suficiente para obter uma atualização, você precisa entender quais vulnerabilidades específicas foram fechadas.
Até o momento, nossa abordagem arquitetônica e de processo para manter a segurança do SO é totalmente justificada - mantemos com êxito um alto nível de segurança para sistemas de informação com o sistema operacional Astra Linux Special Edition. E o acesso aberto a informações sobre vulnerabilidades por meio do painel de controle do FSTEC aumenta o nível de confiança em nosso produto.
Teremos o maior prazer em responder a perguntas sobre a segurança do nosso sistema nos comentários. Além disso, se você estiver interessado em aprender algo novo sobre o sistema, deixe seus desejos - nós os levaremos em consideração ao continuar trabalhando com o blog.