0
0
Como um dos principais especialistas em segurança de produtos com mais de 15 anos de experiência em engenharia de segurança e 120 patentes de segurança cibernética em seu currículo, Adam Boulton é um dos profissionais de segurança de software mais experientes do setor.
Atualmente vice-presidente sênior de tecnologia e inovação de segurança da Cybellum, o podcast Left to Our Own Devices convidou Adam Boulton para compartilhar sua experiência e suas dicas sobre como criar uma estratégia de segurança de produto.
Adam não esperava que sua carreira o levasse a sistemas embarcados. Durante anos, ele esteve envolvido em sistemas críticos de segurança típicos: aplicativos da web, aplicativos móveis, revisões de código-fonte, sem nenhuma exposição real a dispositivos incorporados.
À medida que se envolveu mais com sistemas embarcados, ele descobriu que, à medida que a indústria amadurecia, as pessoas ficavam muito à vontade com a análise de código-fonte. “É considerado bruxaria, onde você compila software, e é esse código-fonte que entra nessa caixa preta e cospe código executável.”
Embora existam muitas razões pelas quais o software compilado é vantajoso, Adam acha problemático “Quanto tempo é gasto no código-fonte e na revisão dele? Porque não é isso que você está realmente executando ou distribuindo.”
3 limitações de software compilado e análise
Adam compartilhou com o podcast o que ele vê nas três principais limitações da dependência de software e análise compilados:
1. Testar o código-fonte não considera o sistema completo
Embora as empresas possam optar por testar seu código-fonte em seus processos, não pode ser o teste final, pois não é uma representação verdadeira do que será entregue ao usuário final. “Você tem a representação do que aconteceu. Você está desenhando várias fases de tradução e, na verdade, distribui isso para o mercado.”
“Então, por que não se gasta mais tempo com o que você distribui, com o que os usuários finais, com o que os agentes de ameaças terão acesso? O que vai ser executado na plataforma? Alguém verificou os ambientes de construção e todos os scripts e o que realmente seria construído? Muitas vezes você perde isso e é um grande ponto cego.”
2. Muitas verificações não podem ser realizadas no nível da fonte
O código-fonte é apenas um nível de um arranha-céu complexo. Testar a fundação é fundamental, mas os engenheiros também devem verificar cada andar à medida que é desenvolvido para garantir a resistência e a integridade necessárias para executar sua função e, ao mesmo tempo, ser capaz de suportar tudo o que será construído sobre ele.
Além disso, Adam adverte: “Existem toneladas de requisitos não funcionais, como requisitos de proteção que você não pode verificar porque não existem no nível do código-fonte. Existem coisas que o compilador fará e a maneira como você compila o software e fornece essas instruções ao compilador para ajudar a fortalecer o software e torná-lo mais seguro. É impossível fazer isso em uma análise de código-fonte.”
3. As pessoas depositam muita fé em seu compilador
Adam revela que muitas vulnerabilidades surgem da maneira como o compilador foi configurado ou da maneira como os ambientes de construção acabaram de incluir todos os tipos de segredos ou documentos ocultos. Sem uma análise adequada, essas vulnerabilidades permanecem no dispositivo, sendo incorporadas aos dispositivos e enviadas para se tornarem ativas em redes em todo o mundo. Permanecer seguro e ser visto pelos clientes como seguro requer verificações durante todo o processo de desenvolvimento junto com o gerenciamento SBOMpara proteger os dispositivos até o nível do componente, caso uma vulnerabilidade seja descoberta no futuro.
Fornecendo um nível de controle de qualidade semelhante ao da indústria alimentícia ou de construção
Adam expressou que os sistemas embarcados devem aprender com outras indústrias em termos de garantia de qualidade de muitos produtos.
Veja a indústria de alimentos, por exemplo: “Se os chefs verificam ou a equipe de serviço verifica, você gostaria de verificar o que está saindo pela porta. Você sabe, o chef não vai apenas ler sobre os ingredientes”, acrescenta. “O mesmo vale para a construção civil. Um inspetor de construção não apenas revisa as plantas. Eles têm que verificar o que é realmente construído. É construído de acordo com a especificação? O tamanho dessa propriedade?
“A lição que podemos tirar de outras indústrias é verificar o que realmente aconteceu”, conclui.
Desenvolver uma estratégia de segurança de software de qualidade – com métricas e KPIs
Valendo-se de sua experiência, Adam compartilhou estratégias e KPIs que podem ser usados por executivos de nível C para rastrear e medir o ROI da segurança do produto.
“Revirei as estratégias anteriores de segurança de software ao longo dos anos e aquelas com as quais tive que me alinhar como colaborador individual, um pesquisador de segurança. E eles simplesmente não foram medidos. Não havia um tipo claro de KPIs.”
“Você não faz isso na maioria das outras equipes, mas ainda para segurança de software, parece haver essa falta de maturidade em muitas estratégias de segurança de software de produtos para perguntar: Onde estão suas métricas? Como sabemos o nosso ROI? Como vamos melhorar?”
Adam explica que, mesmo com a complexidade das cadeias de suprimentos de software, tudo se resume a visibilidade e metas. As equipes de produto devem desenvolver essa visibilidade e permitir que ela direcione a qualidade. Ele enfatiza a necessidade de usar a tecnologia para organizar ativos e inventário de software e tirar conclusões disso.
“Para produtos grandes, por exemplo, como um sistema de infoentretenimento, um moderno tem mais de 140.000 arquivos, certo? São sistemas grandes e complexos. Por onde começamos? Eu digo que devemos começar com uma estratégia de segurança de software quantificada ou mensurável, onde você pergunta e responde às seguintes perguntas e rastreia essas respostas ao longo do tempo.”
Algumas dessas perguntas são:
- Onde estamos hoje?
- O que queremos ser?
- Onde queremos estar daqui a alguns anos?
- O que estamos tentando alcançar?”
Como as equipes de produto podem garantir um orçamento em 2023
Adam compartilhou algumas dicas práticas sobre como as equipes de produto podem garantir um orçamento em uma economia difícil:
- Entenda o negócio – CEOs não estão interessados em pontuações de CVEs e CVSS, não importa o quão apaixonado você seja. Pergunte a si mesmo, o que eles querem construir? Não o que você quer construir.
- Conheça suas práticas regulatórias – elas são quantificadas quando se trata de negócios e riscos. Todo executivo de nível C será responsabilizado e receberá a penalidade.
- Conheça seus padrões – Mesmo que você não siga as práticas regulatórias, é ótimo ajudar a alinhar-se aos padrões para melhorar a qualidade. Eles são um material de referência muito bom.
- Dê uma boa olhada na estratégia – Antes de construir uma equipe real de segurança do produto, dê uma boa olhada na estratégia. Se você se deparar com problemas grandes e complexos, consulte o inventário do seu software. “Fiz muitas avaliações com grandes organizações e, se você observar as habilidades da equipe de segurança do produto, elas não estão alinhadas com a pilha de tecnologia com o que está sendo desenvolvido. E é aí que o inventário volta a funcionar.”
- Tenha pontos de dados mensuráveis – Os pontos de dados criam credibilidade, especialmente quando você está trabalhando com um CEO. “É por isso que estou sempre tão focado no inventário e nos ativos de software. Fazemos isso com os ingredientes dos alimentos. Fazemos isso com materiais de construção, para gerenciar qualquer coisa que vamos construir e desenvolver.”
Compartilhar pontos de dados com executivos como base para como você planeja usar determinados recursos. Isso requer números e a identificação de tendências internas ao longo do tempo, não apenas com base em um pressentimento. “Porque fazemos isso em todos os lugares. Fazemos isso com os ingredientes dos alimentos. Fazemos isso com materiais de construção. Para gerenciar qualquer coisa que vamos construir e desenvolver. Não precisa ser diferente do software”, diz ele.
No entanto, assim como as indústrias de alimentos e construção, os regulamentos ajudaram a estabelecer padrões de segurança para que possamos confiar em qualquer edifício em que entramos. As empresas devem se perguntar se seu setor pode manter altos padrões de segurança por conta própria ou se os órgãos reguladores precisarão fazer o trabalho pesado no futuro.
FONTE: HELPNET SECURITY