MONOLITH LAW OFFICE+81-3-6262-3248Días de semana 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

Riesgos y medidas asociadas con el uso de bibliotecas en la construcción de sistemas de negocios

IT

Riesgos y medidas asociadas con el uso de bibliotecas en la construcción de sistemas de negocios

En la actualidad, el uso de “bibliotecas” se ha vuelto esencial en la construcción de sistemas de negocio. Sin embargo, el uso de estas bibliotecas también conlleva riesgos. Utilizarlas sin tener en cuenta los riesgos puede provocar problemas y, en el peor de los casos, puede incluso dar lugar a graves daños como la fuga de información. En este artículo, explicaremos los riesgos asociados con el uso de las bibliotecas y cómo mitigarlos.

¿Qué es una biblioteca?

Al construir un sistema de operaciones, las empresas de sistemas rara vez crean todos los programas necesarios por sí mismas. En su lugar, es común que construyan una base con “componentes de software prefabricados” y creen las partes que faltan por sí mismas. Estos componentes de software prefabricados se llaman “bibliotecas”. Es común desarrollar funciones genéricas utilizando bibliotecas. Genérico se refiere a funciones de alta demanda en cualquier industria y en cualquier sistema de cualquier país, como la función de “iniciar sesión” o la función de “obtener datos de una base de datos”. Existen bibliotecas correspondientes para estas funciones de alta demanda. Por otro lado, para funciones que no son genéricas, como satisfacer las demandas únicas de los clientes, las empresas de sistemas deben crearlas por sí mismas, ya que no existen bibliotecas prefabricadas para estas funciones.

Además, existe una palabra similar a biblioteca, que es “framework”. También existe la palabra OSS (Open Source Software). En el contexto de los sistemas de operaciones, OSS es un componente del sistema y es lo mismo que la biblioteca mencionada en este artículo, pero puede ser una palabra más familiar. Sin embargo, en este artículo, usaremos consistentemente la palabra biblioteca.

Ventajas de la biblioteca: Rápida y segura

Hay dos razones por las que las empresas de sistemas prefieren utilizar bibliotecas en lugar de crearlas por sí mismas.

  • Se pueden crear más rápido que si se hacen a mano
  • Son más seguras que las creadas a mano

Es natural que sean más rápidas al utilizar productos prefabricados, pero una característica importante es que también son superiores en términos de seguridad. Esto se debe a que las bibliotecas famosas están siendo desarrolladas, verificadas y utilizadas en entornos de producción por excelentes ingenieros y empresas de todo el mundo. Por lo tanto, se han tomado medidas contra los métodos de ataque conocidos, y se puede esperar una actualización rápida si se descubre un nuevo método de ataque. Por el contrario, si intentas hacerlo por ti mismo sin usar una biblioteca, puede que tengas que pasar por la revisión de un experto para considerar los problemas de seguridad, lo que puede llevar tiempo. En ese caso, puede que te cueste mejorar la seguridad. Debido a estas circunstancias, el uso de bibliotecas se vuelve importante si quieres desarrollar sistemas de manera más rápida y segura.

Desventajas de las bibliotecas

El uso de bibliotecas puede ser muy beneficioso tanto para los clientes como para las empresas de sistemas, ya que permite crear sistemas de forma rápida y segura. Sin embargo, el uso de bibliotecas también implica ciertos costos. Además, existe un dilema: si no se actualizan, pueden introducirse “vulnerabilidades”, y si se actualizan, existe la posibilidad de que el sistema deje de funcionar.

Si no se actualiza, hay vulnerabilidades

Los criminales que buscan robar información personal, información de tarjetas de crédito y secretos comerciales están constantemente buscando defectos de seguridad en todas las bibliotecas (y en todos los software). Estos defectos de seguridad se denominan “vulnerabilidades” en términos de TI. Hay muchos casos en los que se han explotado las vulnerabilidades ocultas en las bibliotecas utilizadas y se han sufrido daños. Por ejemplo, se atacó una vulnerabilidad en una biblioteca llamada Struts2 que se utilizaba en el sitio de encuestas del Ministerio de Tierra, Infraestructura, Transporte y Turismo de Japón, y se filtró información de aproximadamente 200,000 clientes. También hay un caso en el que se cree que un sitio de venta de entradas que utilizaba Struts2 pudo haber filtrado 32,187 datos de tarjetas de crédito. También puede suceder que se descubran vulnerabilidades en las bibliotecas que eran desconocidas en el momento de la entrega del sistema.

La actualización implica el riesgo de detener el sistema

En la práctica, puede haber casos en los que no se pueda actualizar a pesar de la existencia de vulnerabilidades. Esto se debe a que existe el riesgo de que el sistema deje de funcionar temporalmente debido a la actualización. Dado que las bibliotecas no son programas escritos por la empresa del sistema, es prácticamente imposible entender completamente su contenido. Por lo tanto, es inevitable que no se pueda eliminar completamente el riesgo de que surjan problemas inesperados en el sistema debido a la actualización y que el sistema deje de funcionar temporalmente. Como cliente, puede sentir indignación hacia la empresa del sistema si no entiende el contenido del sistema que se le ha entregado. Sin embargo, la realidad es que las bibliotecas utilizadas en los sistemas modernos, tanto en términos de calidad como de cantidad, son más de lo que una simple empresa de sistemas puede manejar. Por ejemplo, existe una biblioteca llamada “React”, que es extremadamente popular para la construcción de interfaces de usuario. Esta biblioteca es muy avanzada, creada por los ingenieros de Facebook, y en términos de cantidad, tiene un enorme número de líneas de código, 195,486 (※1).

(※1) Medido con cloc versión 1.82, en el master a las 7:57 AM GMT+9 del 23 de junio de 2019.
https://github.com/facebook/react/commit/39b97e8eb87b2b3b0d938660e1ac12223470fdf5

Casos judiciales relacionados con vulnerabilidades

¿Cuál es la responsabilidad por daños en caso de vulnerabilidades en la biblioteca?

Existe un problema sobre quién asume la responsabilidad cuando se producen daños debido a vulnerabilidades originadas en la biblioteca. Un caso de referencia es el fallo del Tribunal de Distrito de Tokio del 23 de enero del año 26 de Heisei (2014). El demandante encargó a la empresa demandada, una empresa de sistemas, la construcción de un sistema de ventas. Sin embargo, después de la puesta en marcha del sistema, la información de las tarjetas de crédito de los usuarios finales se filtró debido a la vulnerabilidad del sistema, y el demandante sufrió daños por alrededor de 32 millones de yenes debido a disculpas e investigaciones, lo que llevó a una disputa. En el contrato firmado por el demandante y el demandado, había una cláusula de exención que limitaba la cantidad de indemnización por daños al monto del contrato en caso de daños causados por negligencia del demandado. La cuestión en disputa era si se podía aplicar esta cláusula de exención. El fallo dictaminó que el demandado tenía una negligencia grave y que no se podía aplicar la cláusula de exención en caso de negligencia grave, y ordenó al demandado que pagara una indemnización que excedía el monto del contrato.

El demandado, como empresa que realiza la planificación de sistemas de procesamiento de información, la producción de páginas web, el desarrollo de sistemas de negocios, etc., ha desarrollado un negocio utilizando conocimientos especializados en programación, y se puede reconocer que el demandante confió en esos conocimientos especializados para firmar el contrato del sistema en cuestión. Dado que el grado de deber de cuidado requerido del demandado es relativamente alto, como se mencionó anteriormente, si no se han tomado medidas contra la inyección de SQL, es previsible para el demandado que la información personal pueda filtrarse de la base de datos en cuestión mediante un ataque de inyección de SQL por parte de un tercero. Además, dado que el Ministerio de Economía, Comercio e Industria y la IPA han señalado los ataques de inyección de SQL como un método de ataque típico contra las aplicaciones web y han emitido advertencias, era fácil prever que tal situación podría ocurrir. Además, se puede decir que era fácil evitar el resultado de la fuga en cuestión mediante el uso del mecanismo de enlace o el procesamiento de escape, y no hay evidencia que sugiera que se requiere un gran esfuerzo o costo para tomar medidas técnicas para evitarlo. Por lo tanto, se debe reconocer que el demandado tiene una negligencia grave.

Fallo del Tribunal de Distrito de Tokio, 23 de enero del año 26 de Heisei (2014)

La siguiente es una interpretación de este precedente en el contexto de las vulnerabilidades de la biblioteca, según lo descrito en el documento de la Fundación General de Información de Software.

Si se asume el razonamiento de este precedente, incluso si se producen daños al usuario debido a un defecto (vulnerabilidad, etc.) en el OSS, si se reconoce que el vendedor ha sido negligente en responder a la vulnerabilidad, es probable que la aplicación de la cláusula de exención (cláusula de limitación de responsabilidad) esté limitada, y es probable que no se pueda obtener el efecto de la exención. Sin embargo, si se recibe un ataque inmediatamente después de que se publique la información de contramedidas para la vulnerabilidad del OSS, es posible que no se reconozca la negligencia grave, como la negación de la facilidad de evitar el resultado.

Colección de preguntas y respuestas sobre problemas legales en el uso de OSS en la era de IoT [PDF][ja] (página 84)

Por lo tanto, incluso si se trata de una vulnerabilidad originada en la biblioteca, si se reconoce que es una vulnerabilidad conocida y es fácil prever el ataque, es probable que se trate como la responsabilidad de la empresa del sistema.

¿Cuál es la medida más realista contra la vulnerabilidad?

La clave para la gestión de vulnerabilidades es la firma de un contrato de mantenimiento y la realización de diagnósticos de vulnerabilidad.

Si se produce una fuga de información debido a la intención o negligencia grave de una empresa de sistemas, se espera que se pueda obtener una compensación a través de una demanda legal. Sin embargo, desde el punto de vista práctico, lo más importante es evitar la fuga de información en primer lugar. Incluso si se recibe una compensación a través de una demanda, la confianza perdida de los usuarios finales debido a la fuga de información no puede ser recuperada. Para ello, los siguientes dos puntos son importantes:

  1. Firma de un contrato de mantenimiento que incluya actualizaciones de la biblioteca
  2. Diagnóstico de vulnerabilidad

Firma de un contrato de mantenimiento que incluya actualizaciones de la biblioteca

En los contratos para la construcción de sistemas de negocios, hay casos en los que sólo se encarga el desarrollo y casos en los que también se encarga el mantenimiento. Si su empresa no cuenta con expertos capaces de realizar el mantenimiento, es apropiado firmar un contrato de mantenimiento. En el contrato, se puede prevenir problemas solicitando a la empresa de sistemas que tome medidas contra la vulnerabilidad, incluyendo la actualización de la biblioteca, y aclarando la obligación de la empresa de sistemas de responder y la obligación del cliente de pagar en consecuencia. Se puede decir que es necesario tener un contrato en el que, mientras se obliga a la empresa de sistemas a responder como expertos, el cliente también asume el costo suficiente para solicitar a un experto.

Diagnóstico de vulnerabilidad

La cantidad de datos que maneja el sistema y la demanda de la interfaz de usuario están aumentando día a día, mientras que el número de vulnerabilidades descubiertas está aumentando. Por lo tanto, es difícil para la empresa de sistemas prevenir completamente la introducción de vulnerabilidades. Aquí es donde entra en juego el diagnóstico de vulnerabilidad. Según el IPA (Instituto de Promoción de la Informática de Japón), más del 50% de todas las empresas y el 80% de las grandes empresas están realizando diagnósticos de vulnerabilidad.

Los diagnósticos de vulnerabilidad varían desde herramientas gratuitas hasta diagnósticos manuales costosos. En particular, cuando se maneja información cuya fuga sería fatal, es esencial asignar un costo suficiente y tomar medidas al encargar el diagnóstico de vulnerabilidad a una empresa que se especializa en ello. Además, dado que las vulnerabilidades se descubren todos los días, es importante realizar diagnósticos de vulnerabilidad de manera continua, no sólo en el momento de la entrega, sino también después de la entrega. Puede encontrar más información en el siguiente enlace: Diagnóstico de vulnerabilidad[ja] (P15).

Resumen

En este artículo, hemos explicado los riesgos asociados con el uso de bibliotecas y cómo manejarlos. Las bibliotecas son muy útiles, pero también presentan riesgos, como la aparición de vulnerabilidades y la posible pérdida de información si no se actualizan. Legalmente, si una empresa de sistemas es gravemente negligente, puede haber una posibilidad de recibir compensación por la pérdida de información. Sin embargo, en la práctica, es importante tomar medidas para prevenir la pérdida de información en primer lugar. Para ello, se debería acordar en el contrato el tiempo de trabajo para la actualización de la biblioteca y el diagnóstico de vulnerabilidades. Si no se utiliza una biblioteca, es casi imposible alcanzar el nivel requerido tanto en términos de plazo de entrega como de funcionalidad. Para disfrutar de los beneficios de las bibliotecas evitando problemas, se considera necesario llegar a un acuerdo con la empresa de sistemas sobre el costo de las actualizaciones y las medidas contra las vulnerabilidades. Para evitar un golpe fatal a su negocio debido a la pérdida de información, se considera importante prestar suficiente atención a la seguridad desde el momento del contrato, no solo a elementos como la funcionalidad, el diseño de la pantalla y el precio.

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

Volver arriba