Da SolarWinds até hoje: lições que ainda não foram aprendidas

Há algumas violações que mudam a forma como o setor encara a segurança. O ataque à SolarWinds foi uma delas.

Não foi só a dimensão ou a sofisticação que o destacou. Foi a constatação de que as atualizações de software que as organizações acreditavam serem seguras podiam tornar-se elas próprias o vetor de ataque. Para muitas organizações, esse momento foi um alerta. Revelou quanta confiança implícita existia nas cadeias de abastecimento de software e quão pouca visibilidade havia assim que o código saía do controlo interno.

Anos depois, a pergunta incómoda continua. O que é que realmente mudou?

Quando a confiança se torna uma vulnerabilidade

No final de 2020, a SolarWinds — um fornecedor de software de gestão de TI muito utilizado — tornou-se o centro de um dos incidentes de ciberespionagem mais significativos da história moderna. Os atacantes conseguiram comprometer o processo de desenvolvimento de software da empresa e inseriram código malicioso nas suas atualizações. Essa atualização foi então descarregada por milhares de organizações como parte da manutenção de rotina, dando, sem saber, aos atacantes acesso aos sistemas internos.

Não foi só a dimensão ou a sofisticação que fez com que esta violação se destacasse. Foi a constatação de que as atualizações de software que as organizações consideravam seguras podiam tornar-se elas próprias o vetor de ataque.

O que mais chamou a atenção nesta violação não foi o facto de os atacantes terem comprometido um fornecedor de software, mas sim o facto de terem conseguido atingir milhares de organizações sem terem de atacar cada uma delas individualmente.

Depois de introduzirem código malicioso no processo de compilação da SolarWinds, os atacantes conseguiram distribuí-lo através de uma atualização de software de confiança que os clientes instalaram como parte da manutenção de rotina. Do ponto de vista das organizações que a receberam, tudo parecia normal. A atualização veio de um fornecedor conhecido, chegou através dos canais oficiais e foi implementada sem levantar suspeitas.

Foi isso que tornou o ataque tão eficaz. Em vez de explorarem uma falha na firewall ou uma vulnerabilidade não corrigida em cada ambiente alvo, os atacantes aproveitaram-se da confiança que as organizações depositavam na sua cadeia de abastecimento de software.

É isso que torna os ataques à cadeia de abastecimento tão difíceis de combater. Os próprios sistemas concebidos para agilizar as atualizações e manter a integridade podem também tornar-se o mecanismo através do qual o risco é introduzido.

O risco no pipeline de compilação

Os fluxos de trabalho de desenvolvimento modernos são concebidos para serem rápidos e eficientes. O código é escrito, testado, integrado e implementado a um ritmo que seria impensável há uma década. Essa rapidez traz consigo complexidade.

Várias ferramentas, ambientes e dependências estão envolvidos no processo, cada um representando um potencial ponto de vulnerabilidade se não for devidamente protegido. Quando os atacantes conseguem aceder a um pipeline de compilação, não estão apenas a comprometer um único sistema, mas a posicionar-se a montante, onde podem influenciar tudo o que passa por ele. É aqui que a assinatura de código se torna importante, mas também potencialmente enganadora. Uma atualização assinada cria uma sensação de segurança, mas apenas confirma que o código veio de uma fonte confiável. Não garante que a fonte não tenha sido comprometida.

Sem controlos rigorosos sobre a forma como o código é compilado, testado e assinado, essa confiança pode ser mal depositada.

O ponto cego em torno das atualizações de software

As atualizações de software são concebidas para melhorar a segurança. É por isso que muitas vezes são implementadas rapidamente, por vezes de forma automática, com um controlo mínimo. O problema é que este processo parte do princípio de que a própria atualização é segura.

No caso da SolarWinds e de outros ataques à cadeia de abastecimento que se seguiram, o mecanismo de atualização tornou-se o meio de distribuição de código malicioso. As organizações aplicaram a atualização como parte da manutenção de rotina, sem saber que estavam a introduzir riscos nos seus próprios ambientes. Isto destaca uma lacuna. Embora haja frequentemente um grande foco na deteção de ameaças externas, é dada menos atenção à monitorização do que acontece depois de o software ser instalado.

Sem uma melhor perceção de como os sistemas se comportam após a atualização, torna-se difícil perceber quando algo não está bem.

Código externo, risco interno

Todas as organizações dependem, de alguma forma, de código externo, seja através de software de terceiros, bibliotecas de código aberto ou serviços integrados. Essa dependência é inevitável, mas cria uma dependência que nem sempre é totalmente compreendida.

Quando o código externo entra num ambiente, é frequentemente considerado como sendo, por natureza, fiável, especialmente se vier de um fornecedor conhecido. Essa suposição pode criar pontos cegos, sobretudo quando os processos de validação internos são limitados ou inconsistentes.

Validar código externo não significa desconfiar de todos os fornecedores. Significa reconhecer que o risco não desaparece só porque a fonte é conhecida. A violação da SolarWinds demonstrou como até mesmo fornecedores de renome podem tornar-se parte da cadeia de ataque.

Por que é que o Zero Trust ainda parece estar fora do nosso alcance

O modelo «zero trust» tornou-se um conceito amplamente debatido nos anos que se seguiram ao ataque à SolarWinds. A ideia de verificar continuamente os utilizadores, os sistemas e os acessos, em vez de confiar numa confiança implícita, faz sentido, em princípio. Na prática, a sua adoção tem sido mais lenta do que muitos esperavam.

Parte do desafio reside na dimensão da mudança necessária. A transição para um modelo de confiança zero implica repensar a forma como o acesso é concedido, como os sistemas interagem e como a confiança é estabelecida em toda a organização.

Para muitas equipas, isto parece uma mudança significativa em relação às formas de trabalho habituais e exige coordenação entre funções e a vontade de questionar pressupostos de longa data. Como resultado, o progresso é muitas vezes gradual. Podem ser introduzidos elementos do modelo «zero trust», mas raramente de uma forma que aborde plenamente os riscos expostos pelos ataques à cadeia de abastecimento.

As decisões humanas por trás da tecnologia

Embora os ataques à cadeia de abastecimento sejam frequentemente discutidos em termos altamente técnicos, são as decisões humanas que os determinam em todas as fases. As escolhas relativas à rapidez com que as atualizações são implementadas, ao rigor com que o código é revisto e ao nível de visibilidade mantido entre os sistemas influenciam, todas elas, o nível de risco.

Essas decisões raramente são tomadas isoladamente. São influenciadas por prazos e pressões operacionais e, nesse contexto, a confiança torna-se uma necessidade prática, em vez de um risco deliberado. O desafio é que os atacantes compreendem essa dinâmica. Não precisam de contornar todos os controlos se conseguirem encontrar uma forma de agir no meio do fluxo normal das atividades.

Por que é que as lições ainda não foram totalmente assimiladas

A violação da SolarWinds pôs em evidência uma série de problemas sistémicos, mas resolver esses problemas exige mais do que apenas sensibilização. É preciso agir de forma consistente em várias áreas, desde proteger os pipelines de compilação até melhorar a visibilidade do comportamento do software, passando pelo reforço dos processos de validação e pela reformulação dos modelos de confiança.

Não se trata de soluções rápidas. Implicam mudanças na forma como as organizações desenvolvem, implementam e gerem a tecnologia a um nível fundamental. É por isso que o progresso pode parecer lento. As lições são compreendidas, mas traduzi-las na prática quotidiana é muito mais complexo.

Seguir em frente sem confiança cega

Reduzir o risco na cadeia de abastecimento não significa eliminar totalmente a confiança. Significa ser mais criterioso quanto a onde se deposita essa confiança e como ela é verificada. Isso implica reforçar os controlos em torno dos fluxos de desenvolvimento, melhorar a monitorização do comportamento do software e garantir que o código externo seja submetido a níveis adequados de análise. Significa também reconhecer que a confiança não deve ser estática. O que era considerado seguro em determinado momento pode deixar de o ser à medida que os ambientes evoluem.

Uma abordagem mais resiliente centra-se na validação contínua, em que as hipóteses são regularmente testadas, em vez de serem dadas como certas.

Como é que o MetaCompliance pode ajudar

Na MetaCompliance, focamo-nos nos comportamentos que estão na origem de riscos de segurança complexos, incluindo aqueles revelados por ataques à cadeia de abastecimento.

As lições a tirar de incidentes como o da SolarWinds não são apenas técnicas. Elas mostram como as decisões do dia a dia, desde a implementação de atualizações até à gestão das relações com terceiros, podem representar um risco se não forem bem compreendidas.

A nossa abordagem combina formação específica em sensibilização para a segurança com análises comportamentais, ajudando as organizações a perceber como os riscos associados ao OWASP Top 10 e às vulnerabilidades da cadeia de abastecimento se manifestam em cenários reais. Isto inclui compreender como se estabelece a confiança, onde esta pode quebrar-se e como responder de forma mais eficaz.

Ao apoiar as equipas com orientações práticas e contextualizadas, ajudamos as organizações a ir além de respostas reativas e a desenvolver uma abordagem mais consistente e informada à gestão de riscos.

À medida que as cadeias de abastecimento se tornam cada vez mais complexas, a capacidade de questionar pressupostos e tomar melhores decisões torna-se cada vez mais importante.

Entra em contacto com a nossa equipa ainda hoje para saberes mais.