Código aberto, um assassino silencioso?

Pat Martlew, IDG Connect em 25/03/2019 no site CIO

Foto: Shutterstock

O software de código aberto é bastante difícil de evitar na TI corporativa hoje. As promessas do modelo open source são simplesmente boas demais para serem ignoradas, permitindo que as organizações armarem seus desenvolvedores com código olhado por milhares de olhos, todos se esforçando para melhorá-lo ou adaptá-lo a casos de uso específicos que qualquer um pode aproveitar. É uma grande promessa que leva a grandes recompensas, e a implementação reduzirá tão cedo .

Por outro lado, os ativos de software de código aberto de uma empresa podem apresentar um campo minado, pois pode ser difícil determinar exatamente de onde os componentes vêm originalmente, e quem já trabalhou neles. Isso representa um desafio também para as vulnerabilidades de segurança (ou seja, existem pontos fracos conhecidos em determinados códigos OSS?) e para questões de Propriedade Intelectual, pois pode ser difícil determinar em quais licenças  open source código se encaixa.

Algumas licenças exigem que qualquer modificação significativa ou utilização do software, de acordo com os princípios open source, também seja disponibilizada publicamente. Isso pode até mesmo se estender aos componentes do software de código aberto usados ​​como pequenos blocos de construção de um aplicativo "proprietário" mais amplo. O que isso significa é que, mesmo que as empresas usem um pequeno código em seus aplicativos internos, elas podem estar sujeitas à obrigação de liberar o código-fonte ou enfrentar uma ação legal por não conformidade.

É por essas questões que o mercado de ferramentas de análise de composição de software (SCA) está ganhando impulso. As ferramentas SCA visam fornecer uma visão de 'diagnóstico' de todos os componentes do software de código aberto existentes dentro de uma empresa e determinam se há ou não uma vulnerabilidade ou um requisito de licenciamento específico a ser considerado. A CAST é um desses fornecedores e acaba de anunciar uma nova aliança com o Software Heritage, com o objetivo de levar a SCA um passo adiante.

Basicamente, a CAST está trabalhando com a Software Heritage, que supervisiona o maior arquivo aberto de código fonte do software, para desenvolver um "índice de proveniência" que permitirá aos usuários vasculhar o arquivo da Heritage Heritage usando o software Highlight SCA da CAST para identificar a ocorrência original de qualquer arquivo fonte, e todas as suas ocorrências subsequentes. O CAST diz que isso permitirá que os usuários avaliem qualquer código-fonte de terceiros dentro da biblioteca do Software Heritage de mais de cinco bilhões de arquivos de código-fonte conhecidos, eliminação e vulnerabilidades e riscos de licenciamento que eles apresentam.

Conversamos com Vincent Delaroche, CEO da CAST, para descobrir um pouco mais sobre o projeto e o que ele poderia oferecer aos usuários.

IDG Connect - Em relação à parceria de indexação de procedência com o Software Heritage, por que a CAST decidiu trabalhar nisso e quais foram os objetivos do projeto?

Vincent Delaroche - A CAST entrou no mercado de SCA (análise de composição de software) em 2018, e percebemos que havia uma grande necessidade de uma solução para verificar e controlar adequadamente a exposição ao risco de Propriedade Intelectual. Mas, para fazê-lo de forma eficaz, é necessário detectar com segurança o componente original que possui a licença inicial, pois é ele quem dirige todos os "descendentes". Isso deve ser feito automaticamente para permitir um processo repetível e sistemático que possa ser replicado em cada projeto (ou seja, não manual).

Como o Software Heritage é o maior banco de dados disponível e eles estão comprometidos com o crescimento do arquivamento, fez muito sentido que fôssemos parceiros deles. Estamos alinhados com a missão do Software Heritage e também sabemos que identificar e arquivar todo o software de código aberto no mundo não pode ser feito por uma única empresa ... é um projeto comunitário, onde todos devem contribuir.

Como o projeto funcionará?

O repositório do Software Heritage já está acessível por meio de uma API aberta. Com o CAST Highlight, os usuários podem automatizar e dimensionar suas pesquisas para extrair uma lista completa de componentes que aparecem em seu código-fonte. Por meio de nosso contrato com o Software Heritage, o CAST também identificará o "ancestral" original desse componente.

Quais riscos de segurança são apresentados a uma organização por código-fonte aberto não identificado?

Quando o código aberto não é gerenciado adequadamente, as organizações podem ser invadidas ou processadas. No caso de um hack, os componentes de código aberto são ótimos para usar, porque eles aceleram o processo de desenvolvimento, mas também significa que os black hats têm acesso a esses mesmos componentes e podem encontrar pontos fracos no código. Se as organizações não rastrearem o uso de código aberto, elas usarão componentes que têm vulnerabilidades conhecidas, facilitando muito a violação ou a invasão da empresa.

No caso de uma ação - a maioria dos componentes de código aberto é regida por uma licença, essencialmente definindo as regras básicas para uso. Algumas licenças são muito abertas e permitem que uma pessoa ou organização use o componente de código aberto de qualquer maneira desejada. Outras licenças são muito mais restritivas, muitas vezes afirmando que qualquer coisa construída ou usando esse componente também deve se tornar open source. Isso pode ser catastrófico para a Propriedade Intelecutal de uma organização, já que pode ser perdido para o mundo de código aberto se os componentes forem usados ​​com licenciamento restritivo.

O projeto de indexação providencial é sobre segurança ou há outros benefícios?

O objetivo da colaboração entre o Software Heritage e a CAST é alavancar as tecnologias patenteadas da CAST para criar um "Índice de Proveniência". O objetivo aqui é ajudar a economizar tempo e dar transparência aos desenvolvedores sobre os componentes de código aberto que eles usam, para que eles possam projetar e codificar softwares mais seguros do ponto de vista legal e de segurança.

Você tem alguma informação ou dados sobre a probabilidade de uma organização ter código vulnerável?

O National Vulnerability Database rastreia mais de 100 mil vulnerabilidades conhecidas. Para organizações que têm mais de um punhado de aplicativos que usam código aberto, há quase 100% de chance de que seu software tenha uma vulnerabilidade conhecida.

O uso de código aberto só aumentará no futuro. As organizações não precisam ter medo disso, elas só precisam catalogar e rastrear seu uso de código aberto.

Usando a análise de composição de software, as organizações podem detectar e gerenciar todos os seus componentes de código aberto e identificar quaisquer vulnerabilidades conhecidas. Se eles tiverem um processo para verificar e corrigir essas vulnerabilidades conhecidas, isso reduzirá drasticamente o risco de usar o software de código aberto

Google Create Faster Storage Encrypition for All Low-End Device

Por Swati Khandelwal em 08/02/2019 no site The Hacker News.

Google has launched a new encryption algorithm that has been built specifically to run on mobile phones and smart IoT devices that don't have the specialized hardware to use current encryption methods to encrypt locally stored data efficiently.

Encryption has already become an integral part of our everyday digital activities.

However, it has long been known that encryption is expensive, as it causes performance issues, especially for low-end devices that don't have hardware support for making the encryption and decryption process faster.

Since data security concerns have recently become very important, not using encryption is no more a wise tradeoff, and at the same time, using a secure but slow device on which apps take much longer to launch is also not a great idea.

Currently Android OS supports AES-128-CBC-ESSIV for full-disk encryption and AES-256-XTS for file-based encryption, and Google has already made it mandatory for device manufacturers to include AES encryption on most devices shipped with Android 6.0 or later.

However, unfortunately, many low-end and other connected devices today available in the market are exempted from using encryption because of poor AES performance (50 MiB/s and below).

Adiantum: Fast Local Storage Encryption for Every Device

To solve this issue, Google has once again stepped forward, this time with "Adiantum," a new form of efficient storage encryption that has been designed to protect local data without slowing down devices that don't support hardware-accelerated cryptography.

"Adiantum allows us to use the ChaCha stream cipher in a length-preserving mode, by adapting ideas from AES-based proposals for length-preserving encryption such as HCTR and HCH," Google said.

"On ARM Cortex-A7, Adiantum encryption and decryption on 4096-byte sectors is about 10.6 cycles per byte, around 5x faster than AES-256-XTS."

For those unaware, the ChaCha stream cipher is extremely secure and much faster than Advanced Encryption Standard (AES) when hardware acceleration is unavailable, as it exclusively relies on operations that all CPUs natively support—additions, rotations, and XORs.

According to Google, Adiantum has primarily been designed to become the next widely accepted alternative that offers maximum security along with sufficient performance on lower-end ARM processors.

"Our hope is that Adiantum will democratize encryption for all devices," Eugene Liderman, Director of Mobile Security Strategy at Android Security and Privacy Team says. "Just like you would not buy a phone without text messaging, there'll be no excuse for compromising security for the sake of device performance."

With Adiantum, Google is looking forward to making the next generation of phones and smart devices more secure than their predecessors by allowing everything—from smartwatches to Internet-connected medical devices—to encrypt users' sensitive data without compromising on the performance.

For more technical details about Adiantum and how it works, you can head on to the Google Security blog post and a white paper (PDF and GitHub) published by the company with more information.