Riscos e medidas associados ao uso de bibliotecas na construção de sistemas de negócios

Na era moderna, a construção de sistemas de negócios requer um componente do sistema chamado ‘biblioteca’. No entanto, o uso de bibliotecas também apresenta riscos. Usá-las sem considerar os riscos pode provocar problemas e, no pior dos casos, pode até resultar em danos graves, como vazamento de informações. Este artigo irá explicar os riscos associados ao uso de bibliotecas e como mitigá-los.

O que é uma biblioteca

Na construção de um sistema de negócios, raramente uma empresa de sistemas cria todos os programas necessários internamente. Em vez disso, é comum criar uma base com “componentes de software pré-fabricados” e preencher as lacunas com criações próprias. Estes componentes de software pré-fabricados são chamados de “bibliotecas”. É comum utilizar bibliotecas para desenvolver funções genéricas. Genérico refere-se a funções com alta demanda em qualquer indústria ou sistema de qualquer país, como “função de login” ou “função de recuperação de dados de um banco de dados”. Para essas funções de alta demanda, existem bibliotecas correspondentes. Por outro lado, para funções não genéricas que atendem a pedidos específicos dos clientes, a empresa de sistemas terá que criar suas próprias, pois não existem bibliotecas pré-fabricadas.

Além disso, existe uma palavra semelhante a biblioteca, que é “framework”. Há também a palavra OSS (Software de Código Aberto). No contexto de um sistema de negócios, OSS é um componente do sistema e é a mesma coisa que a biblioteca mencionada neste artigo, mas pode ser uma palavra mais familiar. No entanto, neste artigo, usaremos consistentemente a palavra biblioteca.

Vantagens da biblioteca: Rápida e segura

Existem duas razões pelas quais as empresas de sistemas preferem usar bibliotecas em vez de criar as suas próprias.

• É mais rápido do que criar do zero
• É mais seguro do que criar do zero

É natural que seja mais rápido usar um produto já feito, mas uma grande característica é que também é superior em termos de segurança. Isto deve-se ao facto de que as bibliotecas famosas estão a ser continuamente desenvolvidas, verificadas e utilizadas em ambientes de produção por engenheiros e empresas excelentes em todo o mundo. Portanto, medidas estão em vigor contra métodos de ataque conhecidos, e atualizações rápidas podem ser esperadas mesmo quando novos métodos de ataque são descobertos. Por outro lado, se tentar criar o seu próprio sistema sem usar uma biblioteca, pode ter que passar pelo incómodo de envolver uma revisão de especialistas para considerar questões de segurança, entre outras coisas. Nesse caso, pode acabar por ter custos para melhorar a segurança. Devido a todas estas circunstâncias, o uso de bibliotecas torna-se importante se quiser desenvolver sistemas de forma mais rápida e segura.

Desvantagens da utilização de bibliotecas

A utilização de bibliotecas pode trazer grandes benefícios tanto para os clientes como para as empresas de sistemas, permitindo a criação de sistemas de forma rápida e segura. No entanto, a utilização de bibliotecas também implica certos custos. Além disso, existe um dilema: se não atualizarmos a biblioteca, podemos introduzir “vulnerabilidades”, mas se a atualizarmos, o sistema pode deixar de funcionar.

Se não atualizar, existem vulnerabilidades

Os criminosos que planeiam roubar informações pessoais, informações de cartões de crédito e segredos comerciais estão constantemente à procura de falhas de segurança em todas as bibliotecas (e em todos os softwares). Estas falhas de segurança são chamadas de “vulnerabilidades” em termos de TI. Existem muitos exemplos de danos causados por vulnerabilidades escondidas nas bibliotecas utilizadas. Por exemplo, o site de inquéritos do Ministério Japonês da Terra, Infraestrutura, Transporte e Turismo foi atacado através de uma vulnerabilidade na biblioteca Struts2 que estava a utilizar, resultando na fuga de informações de cerca de 200.000 clientes. Da mesma forma, acredita-se que um site de venda de bilhetes que utilizava o Struts2 pode ter divulgado informações de 32.187 cartões de crédito. É possível que uma vulnerabilidade desconhecida na biblioteca no momento da entrega do sistema seja descoberta posteriormente.

A atualização implica o risco de paragem do sistema

Na prática, pode haver casos em que não é possível atualizar apesar da existência de vulnerabilidades. Isto deve-se ao risco de o sistema parar temporariamente devido à atualização. Como a biblioteca não é um programa escrito pela empresa de sistemas, é praticamente impossível entender completamente o seu conteúdo. Portanto, é inevitável que não se possa eliminar completamente o risco de o sistema parar temporariamente devido a problemas inesperados causados pela atualização. Como cliente, pode sentir-se frustrado com a empresa de sistemas se não entender o conteúdo do sistema entregue. No entanto, a realidade é que nem todas as bibliotecas utilizadas nos sistemas modernos, tanto em termos de qualidade como de quantidade, podem ser geridas por uma única empresa de sistemas. Por exemplo, existe uma biblioteca chamada “React”, que é muito popular para a construção de interfaces de utilizador. Esta biblioteca é um produto altamente sofisticado criado pelos engenheiros da Facebook, e é enorme em termos de quantidade, com 195.486 linhas de código (※1).

Casos em que a vulnerabilidade se tornou um julgamento

Existe uma questão sobre quem é responsável quando ocorrem danos devido a uma vulnerabilidade originada numa biblioteca. Uma referência para isso é a decisão do Tribunal Distrital de Tóquio de 23 de janeiro de 2014 (Heisei 26). O queixoso contratou a empresa de sistemas, a ré, para construir um sistema de vendas. No entanto, após a operação do sistema, as informações do cartão de crédito do utilizador final vazaram devido à vulnerabilidade do sistema, e o queixoso sofreu danos de cerca de 32 milhões de ienes devido a pedidos de desculpas e investigações, o que levou a uma disputa. No contrato celebrado entre o queixoso e a ré, havia uma cláusula de isenção que limitava o montante da indemnização ao montante do contrato se os danos ocorressem por negligência da ré. A questão era se esta cláusula de isenção poderia ser aplicada. A decisão ordenou à ré que indemnizasse um montante superior ao montante do contrato, uma vez que havia negligência grave da ré e a cláusula de isenção não poderia ser aplicada em caso de negligência grave.

A ré, como empresa que realiza o planeamento de sistemas de processamento de informações, a produção de páginas da web, o desenvolvimento de sistemas de negócios, etc., desenvolve negócios utilizando conhecimentos especializados em programação, e forneceu a aplicação web em questão como parte desses negócios. Pode-se inferir que o queixoso celebrou o contrato do sistema em questão confiando nesse conhecimento especializado, e o grau de cuidado exigido da ré é relativamente alto. Como mencionado acima, se não houvesse medidas contra a injeção de SQL, seria possível prever que as informações pessoais poderiam vazar do banco de dados em questão devido a um ataque de injeção de SQL por terceiros, e o Ministério da Economia, Comércio e Indústria e a IPA listaram ataques de injeção de SQL como um método de ataque típico contra aplicações web, (omissão) e estavam alertando para isso, então seria fácil prever que tal situação poderia ocorrer. Além disso, ao usar o mecanismo de ligação ou ao realizar o processamento de escape, o resultado do vazamento em questão poderia ter sido evitado, e não há evidências que sugiram que muito esforço ou custo seria necessário para implementar (omissão: medidas técnicas para evitar o processamento), então seria fácil dizer que o resultado do vazamento em questão poderia ter sido evitado. Portanto, deve-se dizer que a ré tem negligência grave.
Citação: Decisão do Tribunal Distrital de Tóquio, 23 de janeiro de 2014 (Heisei 26)

A descrição do documento da Fundação de Informação de Software, que interpretou este precedente no contexto da vulnerabilidade da biblioteca, é a seguinte.

Com base no pensamento deste precedente, mesmo que ocorram danos ao utilizador devido a um defeito (vulnerabilidade, etc.) do OSS, se for reconhecido que o fornecedor negligenciou a resposta à vulnerabilidade, intencionalmente ou por negligência grave, é provável que a aplicação da cláusula de isenção (cláusula de limitação de responsabilidade) seja limitada, como neste caso, e é provável que não seja possível obter o efeito de isenção. No entanto, se for atacado imediatamente após a publicação das informações de contramedidas para a vulnerabilidade do OSS, é possível que a facilidade de evitar o resultado seja negada, etc., e pode não ser reconhecida negligência grave.

Coleção de perguntas e respostas sobre problemas legais no uso de OSS na era IoT [PDF][ja] (página 84)

Assim, mesmo que seja uma vulnerabilidade originada numa biblioteca, se for uma vulnerabilidade conhecida e for fácil prever o ataque, é provável que seja tratada como responsabilidade da empresa de sistemas.

Qual é a medida mais realista contra vulnerabilidades?

Se ocorrer uma fuga de informação devido a um ato intencional ou negligência grave de uma empresa de sistemas, é provável que se possa obter uma compensação através de um processo legal. No entanto, do ponto de vista prático, o mais importante é evitar que a fuga ocorra em primeiro lugar. Mesmo que se receba uma compensação através de um processo, a confiança perdida dos utilizadores finais devido à fuga de informação não pode ser recuperada. Para isso, os seguintes dois pontos são importantes:

1. Celebração de um contrato de manutenção, incluindo atualizações de bibliotecas
2. Diagnóstico de vulnerabilidades

Celebração de um contrato de manutenção, incluindo atualizações de bibliotecas

Existem contratos para a construção de sistemas de negócios que envolvem apenas o desenvolvimento ou também a manutenção. Se a sua empresa não tem especialistas capazes de realizar a manutenção, é apropriado celebrar um contrato de manutenção. No contrato, pode-se prevenir problemas ao solicitar à empresa de sistemas medidas contra vulnerabilidades, incluindo atualizações de bibliotecas, e ao esclarecer a obrigação da empresa de sistemas de responder e a obrigação do cliente de pagar em conformidade. Pode-se dizer que é necessário um contrato que obrigue a empresa de sistemas a responder como especialista e que o cliente assuma o custo suficiente para solicitar a um especialista.

Diagnóstico de vulnerabilidades

Enquanto a quantidade de dados tratados pelos sistemas e a demanda por UI estão a aumentar diariamente, o número de novas vulnerabilidades descobertas continua a aumentar. Portanto, existe uma situação em que é difícil para a empresa de sistemas prevenir completamente a introdução de vulnerabilidades. É aqui que entra o diagnóstico de vulnerabilidades. De acordo com a IPA, mais de 50% de todas as empresas e 80% das grandes empresas realizam diagnósticos de vulnerabilidades.

Existem vários tipos de diagnósticos de vulnerabilidades, desde ferramentas gratuitas até diagnósticos manuais caros. Em particular, quando se lida com informações cuja divulgação seria fatal, pode-se dizer que é essencial tomar medidas, atribuindo um custo suficiente e delegando o diagnóstico de vulnerabilidades a uma empresa que se especializa nisso. Além disso, como as vulnerabilidades são descobertas diariamente, é importante realizar continuamente um diagnóstico de vulnerabilidades[ja] (P15) não só no momento da entrega, mas também após a entrega.

Resumo

Neste artigo, explicamos os riscos associados ao uso de bibliotecas e como lidar com eles. As bibliotecas são extremamente úteis, mas também apresentam riscos, como a ocorrência de vulnerabilidades e possíveis danos, como vazamento de informações, se não forem atualizadas. Legalmente, se houver negligência grave por parte da empresa de sistemas, pode ser possível receber compensação por um vazamento de informações. No entanto, na prática, é importante tomar medidas para prevenir o vazamento de informações em primeiro lugar. Para isso, deve-se concordar contratualmente sobre o tempo de trabalho para atualizar a biblioteca e sobre o diagnóstico de vulnerabilidades. Se não usar bibliotecas, é quase impossível atingir o nível necessário de prazo e funcionalidade. Para aproveitar os benefícios das bibliotecas enquanto evita problemas, é necessário chegar a um acordo com a empresa de sistemas sobre o custo da atualização e as medidas contra vulnerabilidades. Para evitar um golpe fatal nos negócios devido a um vazamento de informações, é importante prestar atenção suficiente à segurança, bem como a elementos como funcionalidade, layout da tela e preço, desde o momento do contrato.