Configurações incorretas de Schrödinger

É quinta-feira à tarde e o senhor está a preparar-se para sair do trabalho um pouco mais cedo porque… pode. Mas eis que o incómodo Entregador de Notificações (também conhecido como Slack) dispara uma nova mensagem no seu canal de alertas de segurança:

Que chatice. Alguém acabou de tornar público um instantâneo de um volume de armazenamento. Trata-se de um ataque? De um erro? De alguém que simplesmente não sabe quais são as políticas?

As configurações incorretas têm três estados de existência

Isto é algo a que comecei a chamar configurações incorretas de Schröedinger porque tenho o mau hábito de recorrer a princípios da mecânica quântica para explicar a segurança da informação. Ficaria espantado se o senhor ainda não conhecesse o Gato de Schröedinger, a famosa experiência mental que Erwin Shröedinger usou para ilustrar o paradoxo da sobreposição quântica a Albert Einstein. A versão muito resumida é a seguinte: se colocar um gato numa caixa com um veneno acionado por decaimento radioativo, o gato não está nem vivo nem morto e encontra-se, portanto, num estado de estar vivo E morto, até que abra a caixa e verifique.

Sim, é absurdo, e era esse o objetivo. Sobretudo para aqueles de nós que têm gatos que NÃO GOSTAM DE FICAR PRESOS EM CAIXAS. Embora pudesse escrever uma série inteira de artigos sobre gatos que entram em caixas por vontade própria mas ficam furiosos quando os metemos em caixas e… estou a divagar.

Voltando à segurança na cloud. O conceito fundamental por trás da experiência mental é que algo existe em vários estados simultâneos até ser observado, e esse ato de observação obriga a uma resposta. Estou, evidentemente, a enviesar e a simplificar para servir os meus propósitos, por isso peço a quem tem formação em física que não me envie e-mails indignados.

A versão cloud deste conceito é a de que qualquer configuração incorreta existe num estado de ser um ataque, um erro ou uma violação de política até que se investigue e determine a causa.

Há 5 características da cloud que sustentam este conceito:

• As equipas de cloud/desenvolvimento tendem a ter mais autonomia para gerir diretamente a sua própria infraestrutura de cloud.
• O plano de gestão da cloud é acessível através da Internet.
• A origem mais comum (atualmente) dos ataques à cloud são as credenciais roubadas.
• Muitas configurações incorretas criam estados idênticos às ações de um atacante (por exemplo, tornar público um instantâneo).
• É fácil criar acidentalmente uma configuração incorreta e, por vezes, são intencionais para dar resposta a uma necessidade, mas quem executa a ação não se apercebe de que se trata de um problema de segurança.

Este conceito é igualmente válido na infraestrutura tradicional, ainda que em muito menor grau, uma vez que as equipas têm menos autonomia. Um programador de uma aplicação não tem, habitualmente, a possibilidade de alterar diretamente regras de firewall e tabelas de encaminhamento. Na cloud, isso é bastante comum, pelo menos em alguns ambientes.

Parta do princípio de que é um ataque até prova em contrário

Um dos princípios mais importantes da resposta a incidentes na cloud é que tem absolutamente de tratar as configurações incorretas como eventos de segurança e de partir do princípio de que são ataques até prova em contrário.

Trata-se de uma mudança de mentalidade, já que a segurança está habituada a pensar em termos de vulnerabilidades e superfície de ataque, mas encaramos essas questões como algo que analisamos periodicamente e tratamos, em larga medida, como problemas a remediar. O que proponho é que, na computação em cloud, elevemos as configurações incorretas detetadas ao mesmo nível de um alerta de IDS ou EDR. Não são meros problemas de conformidade, são potenciais indicadores de comprometimento.

E não, isto não se aplica a todas as configurações incorretas em todos os ambientes. Temos de filtrar e priorizar. Melhor ainda, temos de comunicar, porque normalmente a forma mais simples de perceber se uma configuração incorreta é um ataque malicioso é perguntar a quem fez a alteração se era essa a sua intenção.

Como tenho de sintetizar as coisas para as formações, defini três fontes principais de telemetria de segurança:

• Registos
• Eventos do fornecedor de cloud (por exemplo, eventos do Security Hub)
• Configurações incorretas na cloud, que podem provir da sua ferramenta de CSPM, de scanners OSS ou semelhantes

A maioria das pessoas que trabalham em segurança na cloud já interiorizou este conceito, mas nem sempre o explicamos. Se observar algumas ferramentas de Cloud Detection and Response (CDR), verá que geram alertas para determinadas configurações incorretas. Isto difere do modo de funcionamento predefinido das ferramentas de CSPM, que criam constatações em relatórios e dashboards. Estas são importantes para a conformidade e a higiene geral de segurança mas, uma vez que os atacantes fazem coisas desagradáveis como partilhar imagens de disco com outras contas ou criar acessos ocultos a funções IAM, um subconjunto de configurações incorretas tem realmente de ser tratado como se fossem indicadores de comprometimento até prova em contrário.

Internamente (e na plataforma DisruptOps) tratamos disto com um conjunto de detetores de ameaças em tempo real que acionam avaliações com base em chamadas de API identificadas. Demora cerca de 15-30 segundos a identificar uma configuração incorreta e a enviá-la à equipa de segurança e ao responsável pelo projeto através do Slack (ou do Teams), como pode ver acima. Estes alertas são tratados da mesma forma que uma constatação do GuardDuty ou qualquer outro Indicador de Comprometimento, mas a utilização de ChatOps para validar atividades também nos ajuda a triá-los muito rapidamente, sem termos de realizar uma análise aprofundada de cada vez.

A recomendação em resumo: trate as configurações incorretas críticas da cloud em tempo quase real e considere-as indicadores de comprometimento até prova em contrário.

Nenhum gato foi maltratado durante a redação deste artigo.