0
0
O mundo digital está cada vez mais em complexidade e interconexão, e isso não é mais aparente do que nas cadeias de suprimentos de software. Nossa capacidade de desenvolver outros componentes de software significa que inovamos mais rapidamente e construímos melhores produtos e serviços para todos. Mas nossa dependência de software de terceiros e código aberto aumenta a complexidade de como devemos defender a infraestrutura digital.
Nossa recente pesquisa com profissionais de segurança cibernética descobriu que um terço dos entrevistados monitora menos de 75% de sua superfície de ataque, e quase 20% acreditam que mais da metade de sua superfície de ataque é desconhecida ou não observável. Log4Shell, Kaseya e SolarWinds expuseram como essas estatísticas podem se manifestar como violações devastadoras com consequências de longo alcance. Os cibercriminosos já sabem que as cadeias de suprimentos são altamente vulneráveis à exploração.
Por que as cadeias de suprimentos de software inseguras são problema de todos
No ano passado, um ator de ameaças explorou uma vulnerabilidade no provedor de Administrador de Sistema Virtual (VSA) Kaseya para injetar o ransomware REvil no código do VSA. A Kaseya apoiou milhares de provedores de serviços gerenciados (MSPs) e empresas, e sua violação comprometeu uma rede crítica dentro de milhares de organizações. Consequentemente, os sistemas internos dessas organizações também foram comprometidos.
O efeito cascata que a Kaseya teve em seus clientes pode acontecer com qualquer organização que use um fornecedor de software de terceiros. A Agência da União Europeia para a Segurança Cibernética (ENISA) analisou 24 ataques recentes à cadeia de suprimentos de software e concluiu que uma forte proteção de segurança não é mais suficiente. O relatório descobriu que os ataques da cadeia de suprimentos aumentaram em número e sofisticação em 2020, continuados em 2021 e, com base nos recentes ataques da Lapsus$, é provável que sejam transferidos até 2022.
Semelhante aos fornecedores de software de terceiros, mas em uma magnitude ainda maior, o código-fonte aberto tem um impacto devastador na função digital se for deixado inseguro – o estrago causado pelo Log4Shell ilustra isso. Essas consequências se devem, em parte, ao fato de o software de código aberto permanecer fundamental para quase toda a infraestrutura digital moderna e para todas as cadeias de suprimentos de software. O aplicativo médio usa mais de 500 componentes de código aberto. No entanto, recursos limitados, treinamento e tempo disponíveis para os mantenedores que apoiam voluntariamente os projetos significam que eles lutam para corrigir as vulnerabilidades. Esses fatores provavelmente contribuíram para que vulnerabilidades de código aberto de alto risco permaneçam no código por anos.
Esta questão exige ação imediata. É por isso que o Instituto Nacional de Padrões e Tecnologia (NIST) divulgou suas diretrizes de segurança em fevereiro. Mas por que ainda somos tão lentos para tentar proteger a cadeia de suprimentos de software de forma eficaz? Porque é difícil saber por onde começar. É um desafio acompanhar as atualizações de segurança para o seu próprio software e novos produtos, muito menos policiar outros fornecedores para garantir que eles correspondam aos padrões da sua organização. Para adicionar mais complexidade, muitos dos componentes de código aberto que sustentam a infraestrutura digital não possuem os recursos adequados para que os mantenedores do projeto mantenham esses componentes totalmente seguros.
Comece
Então, como podemos garantir isso? Tudo parece bastante assustador, mas aqui é por onde você pode começar.
Primeiro, coloque sua casa em ordem e identifique sua lacuna de resistência a ataques – o espaço entre o que as organizações podem defender e o que elas precisam defender. Conheça sua cadeia de suprimentos e implemente estratégias que configurem equipes para o sucesso:
- Exija uma lista de materiais de software (SBOM) e mantenha um inventário preciso das licenças de software da sua organização para saber quais fornecedores, programas e redes podem colocá-lo em risco. Os componentes de software de código aberto são especialmente desafiadores de documentar; a Linux Foundation e a Organização Internacional de Padronização (ISO) têm recursos para ajudar as organizações a determinar uma abordagem para rastrear e identificar código aberto para seus SBOMs.
- Obtenha uma compreensão clara de como seu software (compras atuais ou futuras) suporta ou se relaciona com seus processos críticos. O conhecimento desse relacionamento capacita as equipes de segurança a fazer o caso de negócios para priorizar a segurança e entender melhor quais elementos do negócio serão colocados em risco, dependendo do fornecedor ou componente vulnerável.
- Mude a propriedade da segurança do software para os estágios iniciais de desenvolvimento. Conhecido como “mudança para a esquerda”, isso torna os desenvolvedores cientes dos padrões de segurança, para que as equipes de segurança e desenvolvimento colaborem para criar produtos seguros e reduz a quantidade de patches de produtos inseguros já implantados.
Em seguida, aplique suas estratégias e padrões para manter a segurança da sua organização e a segurança coletiva da Internet:
- Avalie cada fornecedor de software com base na prontidão para incidentes e estabeleça responsabilidade. Incluir um fornecedor em sua cadeia de suprimentos é uma expressão de confiança, e você só deve estender essa confiança quando acreditar que o parceiro é digno. A transparência em toda a sua organização e cadeia de suprimentos é a chave para uma excelente resposta a incidentes. Você também pode usar a linguagem de programas pré-existentes bem-sucedidos para resposta e divulgação de incidentes para informar as diretrizes.
- Adote uma estrutura de integridade clara e um processo detalhado de integração de fornecedores. A estrutura deve incluir documentação de como a licença de software de cada fornecedor suporta sua organização e as ferramentas de segurança que eles alavancam internamente.
- Desenvolva uma estratégia para melhorar a segurança dos componentes de código aberto e contribuir para sua segurança por meio de organizações dedicadas a apoiar a manutenção do projeto. Contribuir para projetos de código aberto reduz o risco para sua organização e para todos que usam código aberto.
A maioria na comunidade de segurança cibernética está familiarizada com a Lei de Murphy: “Tudo o que pode dar errado, vontade” — define a mentalidade de qualquer pessoa que trabalhe neste campo. E se minha experiência neste setor me ensinou alguma coisa, você só precisa fazer o seu melhor para acompanhar o inevitável aumento de desafios, riscos e complexidade da proteção de ativos digitais. Parte de ficar à frente desses desafios é permanecer altamente proativo quando se trata de suas melhores práticas de segurança, e se você ainda não protegeu adequadamente sua cadeia de suprimentos de software, já está atrasado. Mas mesmo que você tenha tido um começo falso, a boa notícia é que nunca é tarde demais para se levantar.
FONTE: DARK READING