Algo que provavelmente deveria incluir ao criar os seus próximos modelos de ameaças

Estamos a trabalhar nos nossos modelos de ameaças aqui na DisruptOps, por isso decidi atualizar os meus conhecimentos sobre as diferentes abordagens. Uma coisa que rapidamente se destacou é que quase nenhuma das documentações ou ferramentas de modelação de ameaças que vi abrange o pipeline de CI/CD.

Isto. É. Um. Problema. Inclua o seu pipeline nos seus modelos de ameaças.

Nos últimos anos realizei diretamente algumas dezenas de avaliações de segurança na cloud, para além de vários outros trabalhos de consultoria. Incluo sistematicamente os pipelines de desenvolvimento/implementação no âmbito, e é frequentemente aí que encontro alguns dos maiores problemas de segurança. O seu ambiente de cloud ultrasseguro é um pouco como um castelo de cartas se alguém puder modificar infraestrutura fundamental alterando um template algures ou comprometendo chaves armazenadas.

A maioria dos modelos de ameaças começa com um diagrama de fluxo de dados ou uma arquitetura, que pode utilizar para percorrer a sua aplicação modelando ameaças (eu próprio gosto do STRIDE, que vem da Microsoft). Isto abrange a funcionalidade da aplicação, mas não o pipeline.

Ao utilizar o seu modelo de ameaças *du jour* para o pipeline, trate os seus programadores/administradores como utilizadores e trate também o próprio pipeline como um utilizador se este tiver credenciais armazenadas (tendo em conta a forma como se liga ao seu ambiente).

Por exemplo, pode alguém forjar uma chamada de API para o Jenkins e desencadear uma alteração na sua aplicação em produção? (Provavelmente sim, pela forma como o Jenkins é muitas vezes configurado.) E quanto ao repúdio de alterações a jobs versus alterações ao código? Ou à escalada de privilégios no pipeline?

Os pipelines não costumam resistir muito bem a um escrutínio de segurança, pelo que os abordaremos em publicações futuras sobre fundamentos de segurança. Provavelmente não o surpreenderá saber que tendo a recomendar guardrails tanto nas implementações do pipeline como em qualquer infraestrutura associada, para reduzir o risco. Por exemplo, o seu servidor de CI nunca deveria estar publicamente exposto nem ser passível de exposição. Poderia utilizar guardrails de reforço para garantir que está num segmento de rede sem Internet Gateway e que os seus grupos de segurança não permitem acesso público (melhor ainda, garantir também que os servidores de CI estão sempre atrás de elastic load balancers).

Os tempos em que a superfície de ataque de uma aplicação se limitava aos seus componentes já lá vão. Na cloud, a maioria das nossas aplicações é alimentada por pipelines, que têm um enorme potencial para serem o ponto fraco, graças ao acesso profundo e às credenciais armazenadas.