0
0
Com uma imagem mais completa da matriz de ameaças Kubernetes, as equipes de segurança podem começar a implementar estratégias de mitigação para proteger seu cluster contra ameaças.
A matriz de ameaças MITRE ATT&CK é uma ferramenta valiosa para os profissionais de segurança entenderem as várias táticas e técnicas empregadas pelos adversários para explorar softwares e redes, desde o acesso inicial ao impacto. A matriz abrange os vários estágios comumente envolvidos em um ataque cibernético, e as táticas exploradas pelos atacantes em cada estágio. As organizações podem usar a matriz para entender sua superfície de ataque e garantir que elas cubram todas as suas bases.
Em abril, o Microsoft Azure Security Center lançou uma matriz de ameaças baseada no modelo MITRE ATT&CK que identifica táticas e ameaças exclusivas de ambientes em execução em Kubernetes, a plataforma de orquestração de contêineres mais popular usada por construtores de aplicativos nativos da nuvem hoje.
A matriz Azure Kubernetes adapta e traduz as táticas encontradas na estrutura original mitre ATT&CK para os desafios de Kubernetes. Por exemplo, na matriz MITRE ATT&CK, o “acesso inicial ao computador” se traduz em “acesso inicial ao cluster” na matriz Azure, refletindo as diferentes tecnologias envolvidas nesse acesso. A matriz do Azure é um marco importante na captura da diferença entre a segurança tradicional de TI e a segurança nativa da nuvem e a expansão da segurança à esquerda e à direita.
No entanto, engenheiros de plataforma e equipes de operações de segurança não devem confiar apenas na matriz de ameaças Kubernetes do Azure. Embora a matriz do Azure permita que as equipes de segurança pensem na segurança da Kubernetes da mesma forma que fazem para a segurança genérica de TI corporativa, existem construções específicas para Kubernetes que não existem em ambientes tradicionais de TI. Em última análise, a estrutura do Azure é nova, e os pesquisadores de segurança ainda estão descobrindo vulnerabilidades em Kubernetes.
Por exemplo, as técnicas usadas na ameaça recentemente descoberta CVE-2020-8555 não foram capturadas na matriz de ameaça Azure MITRE ATT&CK para Kubernetes. Essa vulnerabilidade permite que os invasores aumentem o acesso do plano de controle Kubernetes ao ambiente de nuvem de hospedagem, potencialmente ganhando acesso a dados confidenciais de serviços conectados ao ambiente de hospedagem.
Para aplicações em Kubernetes, os vetores de ameaça e risco podem ser divididos em duas áreas principais:
● Ameaças e riscos de nível de aplicação
Este deve ser um território familiar, mas com uma diferença distinta das aplicações monolíticas tradicionais. Os aplicativos projetados para serem executados em Kubernetes são distribuídos e consistem em várias partes móveis efêmeras que têm perfis de risco e ameaças variados, e geralmente são feitos a partir de uma combinação de componentes e ferramentas de terceiros e de primeira e de terceiros.
● Ameaças e riscos de operações de cluster kubernetes
Esses riscos e ameaças estão associados a:
- Os riscos relacionados à cadeia de fornecimento de software, construção e integração contínua (CI) e as cadeias de ferramentas de automação de entrega e entrega contínua (CD) usadas para implantar no cluster. O CI e o CD representam pontos de acesso iniciais na cadeia de fornecimento de software, onde ameaças podem ser introduzidas no cluster.
- Ferramentas de automação de infraestrutura kubernetes, como monitoramento de aplicativos e infraestrutura e controladores autônomos de ciclo de vida.
- Operadores humanos (DevOps/equipe de engenharia de confiabilidade do local) que têm privilégios de executar ações dentro do cluster.
Com isso em mente, vamos desempacotar elementos importantes de segurança que faltam da matriz de ameaças Kubernetes do Azure. Na matriz editada abaixo, os itens em negrito representam ameaças notáveis não encontradas na matriz Azure:
Um componente notável que a matriz de ameaças do Azure deixa de fora é a categoria de ameaça “Comando e Controle” (C2), que foi encontrada na matriz MITRE ATT&CK original. Como se vê, o C2 ainda deve ser uma preocupação para os usuários de Kubernetes, e deve fazer parte de uma matriz de ameaças Kubernetes.
Kubernetes depende fortemente do DNS como sua infraestrutura crítica para a descoberta de serviços. Uma prática comum para estabelecer canais secretos é explorar fraquezas inerentes na troca de mensagens de protocolo DNS. Por essa razão, é importante monitorar a atividade de DNS dentro do seu cluster Kubernetes para detectar e potencialmente impedir que canais C2 estabeleçam canais secretos.
A Matriz Azure também tem lacunas em torno da escalada de privilégios. Os CVEs recentes mostraram que os privilégios podem ser escalados do nó para todo o cluster, ou do cluster para o ambiente de nuvem de hospedagem. Os controladores de admissão e os operadores kubernetes também podem ser comprometidos, e não devem ser uma reflexão posterior quando se trata de segurança.
Outra lacuna na Matriz Azure está na persistência da ameaça kubernetes. Os atacantes podem girar contêineres diretamente no nó, que não seria gerenciado por Kubernetes e seria um ponto cego para DevOps. Se os atacantes comprometerem um controlador de admissão, eles também podem injetar recipientes de sidecar maliciosos em qualquer pod de seu desejo. Por fim, os atacantes podem executar e persistir ataques conectando scripts nos ganchos do ciclo de vida do contêiner, um mecanismo Kubernetes para executar scripts em pontos predeterminados no tempo.
Com uma imagem mais completa da matriz de ameaças Kubernetes, as equipes de segurança podem começar a implementar estratégias de mitigação para proteger seu cluster contra ameaças. Felizmente, uma forte higiene da segurança pode percorrer um longo caminho para enfrentar ameaças em toda a matriz em Kubernetes. Mas novas ameaças e vulnerabilidades vêm à tona todos os meses, e as equipes de segurança precisam permanecer vigilantes no monitoramento de seus clusters Kubernetes e do cenário de ameaças mais amplo.
FONTE: DARK READING