Responsabilidad Civil Informática

Este elemento es una profundización de los cursos y guías de Lawi. Ofrece hechos, comentarios y análisis sobre este tema. [aioseo_breadcrumbs]

¿Deben pagar los fabricantes de software?

La broma dice que solo dos industrias se refieren a sus clientes como “usuarios”.Si, Pero: Pero aquí está la verdadera clave: los usuarios de drogas y los usuarios de software tienen la misma probabilidad de recuperar daños por los daños que esas mercancías les causan.

Seamos sinceros. Deslumbrados por lo que el software hace posible, los máximos, hemos incorporado a nuestras vidas un medio tecnológico capaz de poner de rodillas a la sociedad, pero de la que prácticamente no exigimos garantía de calidad. La industria de software estadounidense de 150 mil millones de dólares se ha basado en un mantra que se ha convertido en el orden natural: el usuario tenga cuidado.

Desafortunadamente, las vulnerabilidades del software no solo cuestan a los usuarios finales miles de millones anualmente en productos antivirus. El problema es más grande que eso.Entre las Líneas En 2011, el gobierno de los EE. UU. advirtió a los operadores de infraestructura crítica acerca de una vulnerabilidad que se dirigía a una vulnerabilidad de desbordamiento de pila en el software implementado en las plantas de servicios públicos y de fabricación de todo el mundo.Entre las Líneas En 2012, un investigador descubrió casi dos docenas de vulnerabilidades en el software de sistemas de control industrial (ICS) utilizado en centrales eléctricas, aeropuertos e instalaciones de fabricación. (Tal vez sea de interés más investigación sobre el concepto).Entre las Líneas En su actualización de amenazas de 2013, Symantec, la corporación de software de seguridad más grande del mundo, no sorprendió a nadie cuando anunció que los delincuentes estaban encontrando y explotando nuevas vulnerabilidades más rápido de lo que los proveedores de software estaban demostrando ser capaces de lanzar parches. La ciberseguridad es un conjunto muy grande de problemas, y el software malo es una gran parte del desorden.

¿Cómo llegamos aquí?

La rápida evolución de la tecnología de software y el aumento en el número total de usuarios de computadoras en realidad llevó a los comentaristas tempranos a advertir sobre la creciente exposición de los proveedores de software a las demandas y las consecuencias “catastróficas”.Si, Pero: Pero la historia se ha desarrollado al revés. un “vacío legislativo”, los tribunales han interpretado sistemáticamente las licencias de software de una manera que permite a los proveedores de software renunciar a casi toda la responsabilidad por defectos de software (examine más sobre estas cuestiones en la presente plataforma online de ciencias sociales y humanidades). Bruce Schneier, quizás el decretador más prominente del actual régimen de no responsabilidad para los proveedores de software, lo expresa simplemente: “no hay consecuencias reales por tener una mala seguridad”. El resultado es un mercado abarrotado de código de mala calidad.

Como usuarios, toleramos el software defectuoso porque el software defectuoso funciona la mayor parte del tiempo. Y lo conseguimos mucho más rápido y con muchas características.Entre las Líneas En parte, en respuesta al apetito del consumidor, el lanzamiento oportuno y la aplicación de parches incrementales se han convertido en características clave de la cultura de “arreglarlo más tarde” de la industria. Las compañías de software buscan errores al final del proceso de desarrollo y, a sabiendas, empaquetan y envían software de buggy con impunidad. Mientras tanto, los usuarios finales tardan en reconocer las vulnerabilidades, utilizan parches con poca frecuencia y no implementan oportunamente las actualizaciones publicadas.

Algunos expertos temen que nada menos que un Pearl Harbor digital, un ataque a gran escala que explota los agujeros de seguridad críticos en nuestros sistemas de control industrial, creará el impulso necesario para activar la regulación gubernamental (o, en ocasiones, de la Administración Pública, si tiene competencia) y la inversión privada en el código de calidad.

Si ese es el caso, no será por falta de teorización. (Tal vez sea de interés más investigación sobre el concepto). El código subóptimo ha sido reconocido como un problema durante décadas. Ciertamente, hay defensores del status quo que argumentan que responsabilizar a los proveedores de software por su código aumentaría los costos (o costes, como se emplea mayoritariamente en España) y sofocaría la innovación. (Tal vez sea de interés más investigación sobre el concepto).Si, Pero: Pero los académicos legales han pasado treinta años en desacuerdo con esa propuesta y han ideado esquemas de responsabilidad diseñados para obligar a los proveedores de software a asumir algunos de los costos (o costes, como se emplea mayoritariamente en España) que los usuarios han asumido.

El debate sobre la responsabilidad del software ha mantenido su forma básica a lo largo de los años, pero los daños que dieron lugar al debate han evolucionado claramente en ese tiempo. Las primeras discusiones sobre responsabilidad del software se centraron en el mal funcionamiento del software integrado que provocó lesiones físicas o la muerte. [rtbs name=”muerte”] [rtbs name=”pena-de-muerte”] [rtbs name=”pena-capital”] [rtbs name=”muerte”] Preocupación ampliada a las aplicaciones de software utilizadas para infringir los derechos de autor. Con la explosión de la ciberdelincuencia y el ciberespionaje y el temor creciente del ciberterrorismo, la atención se ha concentrado en las vulnerabilidades que acechan en el código de mala calidad.

El cambio de clase también puede entenderse como un cambio de escala, con el daño del software que se expande al alcance de los usuarios finales que buscan beneficiarse del despliegue de software en particular, a terceros afectados por su uso ilegal y, finalmente, a todos los actores.Entre las Líneas En un ecosistema cibernético cada vez más interconectado y cada vez más inseguro.

Estos cambios son significativos, ya que tiran de la discusión sobre la responsabilidad del software en dos direcciones, lo que nos obliga a comenzar a responsabilizar a los proveedores por lo menos parcialmente por las malas prácticas de desarrollo de software, pero también complica cualquier intento de construir un régimen de responsabilidad coherente. Por ejemplo, la inseguridad del software se puede comparar con una crisis de salud pública. El hecho de que una sola vulnerabilidad puede dar lugar a un número incalculable de computadoras comprometidas y daños que son difíciles de manejar (gestionar) hace que los costos (o costes, como se emplea mayoritariamente en España) de dumping por completo para los usuarios finales sean poco razonables como una cuestión de política. Tomar prestadas las palabras de los profesores de derecho Michael Rustad y Thomas Koenig, el paradigma (modelo, patrón o marco conceptual, o teoría que sirve de modelo a seguir para resolver alguna situación determinada) actual es uno en el que la industria de software tiende a culpar a la ciberdelincuencia, las intrusiones informáticas y los virus a la experiencia y sofisticación de los delincuentes de terceros y a los usuarios descuidados que no implementan la seguridad adecuada, en lugar de reconocer lo obvio riesgos creados por su propia falta de pruebas adecuadas y diseño de software defectuoso. Un sistema más razonable y equilibrado debería ser posible.

Por otro lado, cualquier intento de responsabilizar sistemáticamente a los proveedores por las vulnerabilidades debe incluir restricciones realistas, o el riesgo de exponer a la industria a una responsabilidad aplastante. Los comentaristas que abogan por la responsabilidad del proveedor de software tienen un punto común: la industria del software no debe estar exenta categóricamente de los estándares de seguridad impuestos en otras industrias. Y si bien eso es cierto, existe el peligro de confiar demasiado en las analogías que a menudo se establecen entre el software y otros productos y servicios más convencionales.

La analogía más común es el coche. Y existen paralelismos legítimos entre la crisis de seguridad de los vehículos de la década de 1960 y el problema actual de seguridad del software. Luego, los tribunales estatales y federales se mostraron reacios a aplicar la ley de agravios, incluso cuando las víctimas de accidentes de automóviles afirmaron que sus lesiones se debieron a que los fabricantes no ejercieron un cuidado razonable en el diseño de sus vehículos motorizados.

Puntualización

Sin embargo, durante los siguientes treinta años, los tribunales hicieron un cambio de rumbo: impusieron a los fabricantes de automóviles el deber de tener un cuidado razonable en el diseño de productos para evitar someter a los pasajeros a un riesgo irrazonable de lesiones en caso de una colisión; aplicó una regla de responsabilidad estricta a los vehículos que se encuentran defectuosos y que son injustificadamente peligrosos; y responsabilizó a los fabricantes de automóviles de prevenir y reducir la gravedad de los accidentes.

Sin embargo, insistir en que los defectos de software y los defectos de los automóviles deben regirse por regímenes legales sustancialmente similares es ignorar el hecho de que “software” es una categoría que abarca todo, desde videojuegos hasta sistemas de navegación de aeronaves, y que el tipo y la gravedad de los daños derivados del software Las vulnerabilidades en esos productos varían dramáticamente.

Pormenores

Por el contrario, los defectos de los automóviles son más propensos a sufrir lesiones corporales y daños materiales. Descartar estas distinciones es contribuir a una dicotomía cada vez más artificial, entre quienes ven la singularidad del software como un argumento para eximir a los programas de software de las reglas de responsabilidad tradicionales, y aquellos que enfatizan que el software no es nada especial para afirmar que el camino hacia el software La responsabilidad del vendedor reside en los contratos tradicionales o en los recursos de responsabilidad civil.

Como resultado, con respecto al cambio de paradigma (modelo, patrón o marco conceptual, o teoría que sirve de modelo a seguir para resolver alguna situación determinada) que llevó a la responsabilidad de los fabricantes de automóviles, los tribunales fueron solo uno de los componentes de lo que Ralph Nader ha llamado “un proceso interactivo que involucra tanto a los poderes ejecutivo y legislativo del gobierno como a las fuerzas del mercado ”. Específicamente, en 1966, en respuesta a la creciente presión pública y el impulso político directamente atribuibles a los esfuerzos de defensa del consumidor altamente visibles de Nader, el Congreso aprobó la Ley Nacional de Tráfico y Seguridad de Vehículos Motorizados, que otorgó a una agencia federal el poder de promulgar proactivamente y hacer cumplir las normas de seguridad de la industria.Entre las Líneas En 1987, el profesor de derecho Jerry Mashaw y el abogado David Harfst describieron el estatuto como nada menos que “Revolucionario”:

Abandonando la definición histórica del problema de seguridad del automóvil como uno de evitar accidentes al modificar el comportamiento del conductor, la Ley de 1966 adoptó una perspectiva epidemiológica. Reconstituido, el problema de seguridad se convirtió en cómo modificar el vehículo (entorno) para que la interacción del pasajero (anfitrión) y las fuerzas de desaceleración de los accidentes (agente) produjeran menos trauma.

Reconciliar la seguridad del software es tan necesario hoy como lo fue la reconstitución del problema de seguridad del automóvil de ayer. Y al igual que la impuesta responsabilidad del fabricante de vehículos requería un cambio en nuestro paradigma (modelo, patrón o marco conceptual, o teoría que sirve de modelo a seguir para resolver alguna situación determinada) de seguridad automotriz hace tres décadas, la asignación justa de los costos (o costes, como se emplea mayoritariamente en España) de las deficiencias de software entre los proveedores de software y los usuarios requerirá examinar algunas de nuestras creencias profundas sobre la naturaleza misma de la seguridad del software, como así como cuestionar nuestra adicción a la funcionalidad por encima de la calidad. La recalibración del sistema legal que surgió de esas creencias y dependencias requerirá, a su vez, una acción concertada por parte del Congreso y los tribunales.

Es lo suficientemente común como para prestar atención a la idea de comprometerse con una visión de seguridad cibernética basada en el sistema. Desechamos nuestras discusiones sobre seguridad cibernética con metáforas médicas y ecológicas, y las utilizamos con gran eficacia para defender medidas integrales de vigilancia cibernética y un mayor intercambio de datos público-privado.Si, Pero: Pero la mayoría de las brechas de seguridad son posibles gracias a las vulnerabilidades del software. Entonces la pregunta real es esta: cuando el “cuerpo” se rompe, cuando el “ambiente” falla, ¿pondremos nuestro dinero donde está nuestra boca colectiva? ¿Una visión matizada de las fuerzas interdependientes en juego nos guiará para determinar quién debe pagar cuando las cosas salen mal y quién corre con los riesgos asociados con el software malo?

Durante el próximo mes, en una serie de pagos semanales, exploraré si los proveedores de software serán responsables de la calidad de su código y cómo lo haremos. A lo largo de todo esto, examinaré qué es lo que hace que el software y el software sean diferentes, y evaluaré cómo un régimen que responsabiliza a los proveedores de software de las fallas en su código o las prácticas de codificación podría adaptarse para tener en cuenta estas características.

Autor: Williams

La seguridad del software es difícil — y factible

Es cierto: el software perfectamente seguro es un sueño imposible. Los expertos coinciden en que no podemos crear software de ” tamaño y complejidad no trivial ” sin vulnerabilidades.

Otros Elementos

Además, los consumidores quieren un software potente y rico en funciones y lo quieren rápidamente; y esto tiende a producir un software enorme, voluminoso, mal escrito, lanzado temprano y sin el cuidado adecuado para la seguridad.

Aquellos que se oponen a responsabilizar legalmente a los fabricantes de software por la seguridad de sus productos a menudo sacan a relucir esta realidad como una especie de carta de triunfo.Si, Pero: Pero su conclusión, que no es razonable responsabilizar a los fabricantes de software por la calidad de su código, no se desprende de ello. De hecho, toda la evidencia sugiere que la industria sabe cómo hacer que el software sea más seguro, es decir, para minimizar los riesgos de seguridad en el diseño y la implementación del software, y que necesita una patada legal en los pantalones si es para poner ese conocimiento de manera consistente. práctica.

En términos generales, el término “seguridad del software” se usa para denotar el diseño, la creación, la prueba y el despliegue de software para reducir las vulnerabilidades y garantizar la función adecuada del software cuando se encuentra bajo un ataque malicioso. Las vulnerabilidades son un subconjunto especial de defectos de software que un usuario puede aprovechar contra el software y sus sistemas de soporte. Un error de codificación que no ofrece a un pirata informático la oportunidad de atacar un límite de seguridad no es una vulnerabilidad; Puede afectar la confiabilidad o el rendimiento (véase una definición en el diccionario y más detalles, en la plataforma general, sobre rendimientos) del software, pero no compromete su seguridad. Las vulnerabilidades se pueden introducir en cualquier fase del ciclo de desarrollo del software, de hecho, en el caso de ciertos defectos de diseño, incluso antes de que comience la codificación. (Tal vez sea de interés más investigación sobre el concepto).Entre las Líneas En términos generales, las vulnerabilidades se pueden dividir en dos categorías: Vulnerabilidades a nivel de implementación (errores) y vulnerabilidades a nivel de diseño (fallas).Entre las Líneas En relación con los errores, que suelen ser errores de codificación localizados que pueden ser detectados por herramientas de prueba automatizadas, Los defectos de diseño existen en un nivel arquitectónico más profundo y pueden ser más difíciles de encontrar y corregir.

El caso de que la inseguridad del software es inherente, hasta cierto punto, es fuerte. La seguridad no es un complemento o un complemento que los fabricantes de software pueden simplemente agregar al final del ciclo de desarrollo. Según el fallecido Watts Humphrey, conocido como el ” Padre de la calidad del software “, “Todos los desarrolladores deben ver la calidad como una responsabilidad personal y esforzarse por hacer que cada elemento del producto esté libre de defectos”.

James Whittaker, ex director de ingeniería de Google, ofrece ideas similares en su libro que detalla el proceso mediante el cual el gigante de búsqueda del mundo realiza pruebas: “La calidad no es igual a la prueba. La calidad se logra poniendo el desarrollo y las pruebas en una licuadora y mezclándolas hasta que una no se pueda distinguir de la otra ”. El software responsable, en otras palabras, es un software con seguridad incorporado en cada aspecto de su desarrollo.

Como cuestión general, esperamos que la tecnología mejore en calidad a lo largo del tiempo, medida en funcionalidad y seguridad.Si, Pero: Pero la calidad del software, sostienen los ingenieros informáticos, no ha seguido tal trayectoria. Esto no es totalmente atribuible a la falta de responsabilidad legal de los proveedores de software; El ciclo de penetración y parches que es estándar en la industria del software hoy en día es una pesadilla de seguridad con características propias del software.

Gary McGraw, entre las autoridades más conocidas en el campo, atribuye los crecientes problemas de seguridad del software a lo que denomina la ” trinidad de problemas “: conectividad, extensibilidad y complejidad. A esta lista, agreguemos una cuarta preocupación comúnmente citada, la del “monocultivo” de software. Juntos, todos estos factores ayudan a explicar a nivel sistémico lo que hace que la seguridad del software sea difícil de medir y de lograr. Consideremos cada uno brevemente.

Primero, la conectividad cada vez mayor entre las computadoras hace que todos los sistemas conectados a Internet sean cada vez más vulnerables a los ataques basados ​​en software. McGraw señala que este principio básico se ve agravado por el hecho de que las plataformas antiguas que no fueron diseñadas originalmente para Internet están siendo puestas en línea, a pesar de que no admiten protocolos de seguridad o complementos estándar para la autenticación y autorización.

En segundo lugar, un sistema extensible es uno que admite actualizaciones y extensiones y, por lo tanto, permite que la funcionalidad evolucione de forma incremental. Los navegadores web, por ejemplo, admiten complementos que permiten a los usuarios instalar extensiones para nuevos tipos de documentos. La extensibilidad es atractiva para el propósito de aumentar la funcionalidad, pero también dificulta mantener el sistema en constante adaptación libre de vulnerabilidades de software.

En tercer lugar, un informe de 2009 encargado de identificar y abordar el riesgo asociado (véase qué es, su concepto jurídico; y también su definición como “associate” en derecho anglo-sajón, en inglés) con la creciente complejidad del software de vuelo de la NASA define la complejidad simplemente: ” lo difícil que es entender o verificar ” en todos los niveles, desde el diseño del software hasta el desarrollo del software y las pruebas del software. Los sistemas de software están creciendo exponencialmente en tamaño y complejidad, lo que hace que las vulnerabilidades sean inevitables. El Consorcio de Computación Sostenible CyLab de la Universidad Carnegie Mellon estima que el software comercial contiene entre 20 y 30 errores por cada 1.000 líneas de código, y Windows XP contiene al menos 40 millones de líneas de código.

Los problemas no terminan con las matemáticas alucinantes. La complejidad de los sistemas de software individuales crea problemas potenciales para las interacciones entre muchas aplicaciones diferentes. Por ejemplo, a principios de este año, Microsoft se vio obligado a emitir instrucciones para desinstalar su última actualización de seguridad cuando las interacciones inesperadas entre la actualización y cierto software de terceros hicieron que los equipos de algunos usuarios no pudieran arrancar.

Finalmente, están los peligros asociados con el monocultivo, la noción de que la uniformidad del sistema predispone a los usuarios a ataques catastróficos. Como ejemplos de los peligros del monocultivo, los expertos en seguridad apuntan a la podredumbre que devastó plantas de papa genéticamente idénticas durante la hambruna irlandesa de la papa y la infestación del gorgojo que destruyó los cultivos de algodón en el sur de Estados Unidos a principios del siglo XX. Como señaló Dan Greer en un famoso artículo que, según la tradición, lo despidió de un afiliado de Microsoft: “La situación de seguridad se está deteriorando, y el deterioro se agrava cuando casi todas las computadoras en manos de los usuarios finales dependen de una sola operadora. Sistema sujeto a las mismas vulnerabilidades en todo el mundo “.

En otras palabras, en gran medida, el software es diferente de otros bienes y servicios. Y la noción de software perfectamente seguro es casi ciertamente una ballena blanca.

Pero en lo que se refiere a la discusión de responsabilidad, también es un poco falsa. El software no necesita ser impecable para ser mucho más seguro que el código generado hoy.

Para empezar, no todas las vulnerabilidades de software se crean de la misma manera, y no todas representan el mismo riesgo (examine más sobre estas cuestiones en la presente plataforma online de ciencias sociales y humanidades). Basado en datos de 40 millones de análisis de seguridad, la empresa de seguridad en la nube Qualys descubrió que solo el 10 por ciento de las vulnerabilidades son responsables del 90 por ciento de todas las exposiciones a la ciberseguridad. Algunas vulnerabilidades no solo están haciendo una parte del trabajo de gran tamaño para crear problemas de ciberseguridad, sino que muchas son, desde un punto de vista técnico, inexcusables. Solo la disfunción sistémica puede explicar por qué el desbordamiento del búfer, un error de bajo nivel y totalmente prevenible, se mantiene entre las vulnerabilidades de software más generalizadas y críticas.

La seguridad del software es una tarea inusualmente difícil y la estructura de incentivos actual impide que los fabricantes de software pongan en práctica constantemente lo que saben sobre la seguridad, juntos pesan en favor de responsabilizar a los fabricantes de al menos algunas vulnerabilidades. La ley impone regularmente disciplina en otras industrias que de otra manera serían atraídas hacia prácticas fáciles y lucrativas. Un régimen de responsabilidad inteligente diseñado debe entenderse como una forma de proteger el software de sí mismo.

Irónicamente, el software es más inseguro donde las apuestas son más altas. A pesar de todos los avances que los proveedores de software tradicionales han logrado en la creación de aplicaciones más seguras, los expertos dicen que los fabricantes de dispositivos integrados, responsables de producir todo, desde dispositivos médicos hasta sistemas de control industrial, llevan años atrás en el desarrollo de sistemas seguros.

El problema no es que la industria no haya podido desarrollar un enfoque disciplinado para diseñar software seguro. El problema es que esta disciplina es a menudo opcional.

Por ejemplo, los aviones comerciales están legalmente obligados a cumplir con los rigurosos requisitos de seguridad del software establecidos por la industria de aviónica y descritos en un documento de certificación conocido como DO-178C.

Puntualización

Sin embargo, no todos los sistemas críticos para la vida, de hecho, ni siquiera todos los aviones, están obligados a cumplir con tales líneas de base. El software para vehículos aéreos no tripulados (UAV) no necesita cumplir con el estándar DO-178C. La discrepancia es difícil de justificar. Como Robert Dewar, presidente y director general de la compañía de software comercial AdaCore, lo puso en una entrevista el año pasado: “Todos los ingenieros deben adoptar la actitud de” fracaso no es una opción “que es necesaria para producir software confiable y certificado.. Los UAV requieren al menos tanto cuidado como las aplicaciones de aviónica comercial ”. La historia dice que tiene razón.Entre las Líneas En 2010,una falla en el software causó que los operadores de la Marina de los Estados Unidos perdieran brevemente el control de un avión no tripulado, que se adentró en el espacio aéreo (véase qué es, su definición, o concepto jurídico) restringido de Washington antes de poder recuperar el acceso.

De manera similar, algunos sectores de infraestructura crítica deben cumplir con las normas obligatorias de ciberseguridad según lo define la ley federal, o correr el riesgo de sanciones monetarias civiles.Si, Pero: Pero otros que no están legalmente vinculados son, en cambio, ahogados en la orientación voluntaria de ciberseguridad.Entre las Líneas En 2011, la Oficina de Responsabilidad del Gobierno de EE. UU. analizó la medida en que siete sectores de infraestructura crítica emitieron y se adhirieron a dicha orientación. (Tal vez sea de interés más investigación sobre el concepto). Ese informe se tituló adecuadamente: “La orientación sobre seguridad cibernética está disponible, pero se puede hacer más para promover su uso “.

En 1992, Ward Cunningham, el programador que dio al mundo su primer wiki, introdujo lo que se conocería popularmente como “deuda técnica” para describir los costos (o costes, como se emplea mayoritariamente en España) a largo plazo (véase más detalles en esta plataforma general) de los recortes al desarrollar el código. Él escribió: “Enviar código de primera vez es como endeudarse. Un poco de deuda acelera el desarrollo, siempre que se devuelva rápidamente con una reescritura.

Más Información

Los objetos hacen que el costo (o coste, como se emplea mayoritariamente en España) de esta transacción sea tolerable. El peligro se produce cuando la deuda no se paga. Cada minuto invertido en un código que no es del todo correcto cuenta como interés en esa deuda “.

En 2010, Gartner, la firma de investigación de tecnología de la información con sede en Connecticut, proyectó que la deuda técnica en todo el mundo podría llegar a $ 1 billón en 2015. Ese número es aún más preocupante si se considera el hecho de que la deuda técnica es diferente a la deuda financiera en un sentido crucial: las empresas privadas no están incurriendo en los costos (o costes, como se emplea mayoritariamente en España) y riesgos asociados con sus elecciones.

El objetivo de un nuevo régimen de responsabilidad cibernética debería ser cambiar eso: crear un incentivo para reducir la deuda técnica y, por lo tanto, agregar disciplina a un régimen de incumplimiento confuso, inconsistente y fundamentalmente irracional, bajo el cual los fabricantes de software deciden y los usuarios pagan por ellos.

Autor: Williams

El modelo de Mary Typhoid de la higiene del usuario cibernético

A principios del siglo XX, la fiebre tifoidea atacó principalmente a personas pobres. Así que fue extraño cuando, en el verano de 1906, seis de las once personas en la casa adinerada del presidente del banco Charles Henry Warren se enfermaron con la enfermedad. Contratado para investigar el origen del flagelo, el “ingeniero sanitario” George Soper siguió las migajas de pan a la nueva y recientemente desaparecida cocinera de la familia Warren. Reuniendo su historia, descubrió que los brotes de fiebre tifoidea habían rastreado a Mary Mallon de casa en casa una década.

Mallon era una buena cocinera con un defecto trágico: no se lavó las manos. Esta particular combinación de talento y defecto resultó ser desastrosa para sus muchos clientes, ya que Mallon, más tarde llamada Tifoidea María, era una portadora rara y aparentemente saludable de la bacteria fecal-oral Salmonella typhi. Finalmente, Mallon fue aprehendida, puesta en cuarentena por la fuerza durante tres años y puesta en libertad con la condición de que dejara de preparar la comida.Si, Pero: Pero no convencida de que ella fuera otra cosa que no fuera Hale, tomó una serie de alias y comenzó a cocinar, y sin querer matar, de nuevo.

Para el lector moderno, la negación de la biología de Mallon frente a la evidencia es desconcertante y criminal.Si, Pero: Pero su conducta es menos sorprendente cuando se traduce a otro contexto: Internet.

Nuestro comportamiento colectivo como usuarios de Internet y software es notablemente similar al de Mallon’s. Se sabe que los usuarios finales confían en contraseñas fáciles de adivinar, que ejecutan programas maliciosos sin saberlo y que descuidan la instalación oportuna de parches de software críticos. Hacemos todo esto a pesar de que nos digan que estos comportamientos tienen costos, quizás para nosotros mismos, quizás para otros.

Pero si el código crea riesgos reales para las personas y las empresas, ¿no debería eso generar un mercado para un código más seguro?

Este es el argumento simple y seductor de quienes se oponen a la responsabilidad de los fabricantes de software inseguro: simplemente deje la calidad del código en manos del mercado para determinarlo. El argumento del mercado libre se presenta con frecuencia y con mayor detalle para contrarrestar las propuestas de responsabilidad del proveedor de servicios de Internet, pero su lógica funciona de manera similar a la de responsabilizar a los fabricantes de software por el envío de productos cargados de vulnerabilidad.Entre las Líneas En su punto crucial, esta lógica asume que cuando se trata de las necesidades de ciberseguridad de la sociedad, los usuarios pueden y deben ser los que tiran de las palancas. Aquí es cómo Jim Harper del libertario Cato Institute puso el punto. en 2005: “En el margen, imponer una responsabilidad desproporcionada a los ISP erosionaría el enfoque de los usuarios de Internet en la autoconciencia y la autoayuda”.

Otros Elementos

Además, Harper señaló que tal movimiento “suprimiría” lo que es “un desarrollo bien desarrollado”. Mercado diverso de servicios de higiene en Internet. ”

En el contexto de la seguridad del software, este argumento se reduce a dos partes: primero, que las prácticas de parches y los productos antivirus tienen algún control sobre los problemas de ciberseguridad; y en segundo lugar, el cambio de responsabilidad hacia entidades distintas del usuario interferiría con la capacidad del mercado para generar sus propios recursos. Es un argumento no muy diferente al argumentar que en 1906 el mercado estaba equipado para manejar (gestionar) el riesgo que plantea Mallon, que en lugar de estar en cuarentena, se le debería haber permitido cocinar porque las familias de Nueva York podrían desarrollar buenas técnicas de detección para identificar a los trabajadores de alimentos infectados.

Los expertos en seguridad han escrito tomas sobre por qué los despliegues de parches mensuales y las opciones de antivirus de proliferación constante no constituyen colectivamente una solución de seguridad viable para el problema del código inseguro.Si, Pero: Pero se puede decir más sobre la naturaleza de esta insuficiencia, que se remonta a la insuficiencia de los usuarios. Los consumidores de los “servicios de higiene de Internet” están, en última instancia, tan mal equipados para soportar la carga de configurar el mercado para minimizar los riesgos de seguridad del software como los empleadores de Mallon para controlar la propagación de la fiebre tifoidea. La analogía se aplica en dos niveles, ya que como usuarios desempeñamos el papel de las víctimas, los neoyorquinos que contrataron a la tifoidea Mary, pero en aspectos importantes también desempeñamos el papel de Mary.

Tres características hacen de Typhoid Mary una analogía relevante para el usuario moderno de software, y aclaran por qué depender de los usuarios para tomar decisiones responsables sobre la higiene cibernética no puede ser una política nacional responsable de ciberseguridad.

Primero, hay apatía del usuario. Las compañías que producen el código de buggy no están solas en escapar de las ramificaciones de sus elecciones. Al igual que Mallon, quien se mantuvo saludable incluso cuando sus clientes se enfermaron a su alrededor, los usuarios no están obligados a sufrir las consecuencias de su uso personal de software con errores o sus malas prácticas de seguridad. Este es un problema clásico de lo que los economistas llaman externalidades negativas. Y las externalidades negativas se ven exacerbadas por el hecho de que los creadores de malware se han vuelto más inteligentes al aprovecharlas.

A diferencia de los virus y gusanos de antaño, que normalmente interrumpen el funcionamiento de la máquina infectada de una manera notable, el malware moderno tiende a secretarse en una máquina y usa el host para atacar a terceros. Los expertos estiman que el 10 por ciento de las computadoras de los EE. UU. han sido infectadas y cooptadas para la explotación remota por parte de los pastores de botnets en expansión y que arrojan spam. Las botnets, cada vez más la herramienta elegida por los ciberdelincuentes como consecuencia de su versatilidad inherente, están compuestas por un gran número de computadoras infectadas que, sin el conocimiento de sus dueños, operan en conjunto para distribuir código malicioso, interrumpir el tráfico de Internet o robar datos confidenciales de los usuarios.

En 2010, Microsoft informó que más de 2.2. millones de PC en los Estados Unidos habían sido secuestrados por los pastores de bots.Entre las Líneas En junio de este año, la Unidad de Delitos Digitales de Microsoft trabajó con el FBI y el Servicio de Alguaciles de los EE. UU. Para liberar más de 1,463 computadoras de la botnet Citadel, responsable de infectar a aproximadamente 5 millones de computadoras en todo el mundo y robar $ 500 millones de cuentas bancarias de consumidores y negocios. 18 meses.

Sin embargo, a pesar del aumento continuo de las redes de bots, muchas personas carecen de razones para preocuparse realmente de que sus computadoras estén infectadas, porque ser parte de una red de bots no las perjudica especialmente. De hecho, las personas, en promedio, desconocen cuán ” omnipresente y perniciosa ” es la amenaza de la red de bots y no lo saben cuando sus sistemas han sido cooptados.

Esto nos lleva a una segunda conexión entre Typhoid Mary y el usuario de la computadora: la ignorancia. Los usuarios, comúnmente descritos como el eslabón más débil en la cadena de seguridad, generalmente carecen de la formación técnica necesaria para comprender lo que sucede debajo de los diversos dispositivos de alta tecnología que hacen girar sus mundos. Así que, debido a que la ignorancia de Mallon en cuanto a la ciencia de la propagación de un patógeno hizo que a ella le resultara más fácil saltarse el jabón y continuar cocinando, nuestra falta de comprensión en lo que se refiere a la mecánica de los riesgos cibernéticos se presta a una mala higiene de la ciberseguridad., incluso a medida que nuestra confianza en Internet, y nuestro consiguiente riesgo, aumenta constantemente.

Incluso el conocimiento abstracto de que Internet está lleno de actividades maliciosas no parece traducirse en una conciencia adecuada del riesgo personal.Entre las Líneas En 2011, McAffee realizó un estudio global que mostró que, en promedio, los consumidores colocan sus activos digitales en un valor de $ 37,438, y que más de un tercio de esos consumidores no instituyeron protecciones en todos esos dispositivos.

Más Información

Las investigaciones realizadas en otras industrias sugieren que los consumidores tienden a practicar un tipo de excepcionalidad personal, creyendo que son menos vulnerables a los riesgos y menos propensos a ser dañados por los productos que otros. Como señala un investigador de seguridad, “es lógico que cualquier usuario de computadora tenga la creencia preestablecida de que tiene menos riesgo de ser vulnerable a la computadora que otros”. Y aquí está el truco: los usuarios no necesariamente ejercen una mayor discreción en línea, incluso cuando han experimentado personalmente un evento adverso.

El analfabetismo tecnológico sin duda contribuye a una letanía de malas prácticas de seguridad. Por ejemplo, en 2012, una encuesta comisionada por Skype a unas 350,000 personas reveló que el 40 por ciento de los adultos no actualiza su software cuando se le solicita, y aproximadamente una cuarta parte se saltó las actualizaciones porque no entendieron los beneficios. Los usuarios no aplican parches al software, incluso cuando las empresas hacen que dichos parches estén disponibles de manera oportuna; algo así como el 90 por ciento de las explotaciones exitosas son ataques exitosos en sistemas no parcheados. Podría esperar que los usuarios estuvieran dispuestos a implementar oportunamente al menos las soluciones más urgentes.Si, Pero: Pero no, numerosos estudios han confirmado la creencia generalizada de que los usuarios son extremadamente lentos en la implementación de correcciones de seguridad, incluso en el caso de vulnerabilidades críticas. De hecho, los gusanos y virus más infames han explotado vulnerabilidades para las cuales los parches estaban fácilmente disponibles. Estos incluyen el Code Red worm en el 2000, que causó un daño estimado de $ 1,2 mil millones en la red, y el SQL Slammer en el 2003, un gusano que se extendió aún más rápidamente y que cerró completamente Internet en Corea del Sur y provocó interrupciones y desaceleraciones en toda Asia.

Nada muestra mejor los problemas de deshacerse de la carga de mejorar la ciberseguridad en la parte con menos conocimientos técnicos para lograr esto que el surgimiento de una empresa criminal distinta: un software antivirus falso. La premisa básica de la así llamada aplicación antivirus “maliciosa” es simple: se alimenta del miedo de los usuarios al malware para infectar computadoras con malware. La estafa envía un mensaje de alerta al usuario, ofrece un escaneo gratuito (falso) y exige un número de tarjeta de crédito a cambio de eliminar las supuestas infecciones. Investigadores de Google realizaron recientemente un análisis de 240 millones de páginas web. más de 13 meses y descubrí que el software antivirus falso representa el 15 por ciento de todo el malware en la web y el 50 por ciento del malware distribuido a través de anuncios. El problema está creciendo, tanto en términos absolutos como en relación con otros programas maliciosos.

En pocas palabras: los usuarios somos tontos y los tontos son fáciles de explotar.

Hay un tercer factor que impide que la responsabilidad del usuario final se acerque incluso a la viabilidad como un camino hacia una mejor seguridad del software o una mayor ciberseguridad en general, y ese es el poder limitado del mercado. Una vez más, Typhoid Mary ofrece un análogo útil (examine más sobre estas cuestiones en la presente plataforma online de ciencias sociales y humanidades). Bajo la presión de dejar de manipular alimentos, Mallon intentó brevemente otras ocupaciones: aceptar un trabajo, por ejemplo, como lavandera. Desafortunadamente, nada pagó tan bien para una mujer de su puesto como lo hizo la cocina. Así que cocinó ella lo hizo.

Al igual que Typhoid Mary, los usuarios de software están limitados por los límites de su poder de mercado.Entre las Líneas En una industria estructurada para recompensar el envío rápido y los parches eventuales, los fabricantes de software no enfrentan consecuencias ni siquiera por el envío intencionado de productos cargados de vulnerabilidad. Mientras tanto, los usuarios carecen de la capacidad de determinar la calidad del software propietario hasta que se haya convertido en un estándar. Un comentarista describe la pesadilla simplemente: “El proceso de estandarización interactúa con el desafortunado hecho de que los defectos de seguridad del software latentes tienden a permanecer ocultos hasta después de que el software se haya popularizado, y por lo tanto, dichos defectos no juegan ningún papel en la competencia para establecer estándares”. Piense en ello. Si no está satisfecho con la seguridad de su software, ¿cuáles son sus opciones? ¿Realmente puedes permitirte dejar de cocinar por completo?

Como nación de las tifoideas de hoy en día, representamos una mayor amenaza para el ecosistema cibernético en el que operamos que para nosotros mismos.Si, Pero: Pero a diferencia de Mary, no todos podemos estar en cuarentena en una isla al lado de Rikers. Nuestro destino es justo lo contrario: estar cada vez más interconectados y cada vez más expuestos.

Una Conclusión

Por lo tanto, una política de ciberseguridad inteligente debe ser una que fomente la higiene cibernética entre los usuarios sin confundirla con una alternativa a la creación de una demanda real para una mejor seguridad de los fabricantes de software.

Los fabricantes de software son claramente distintos a Typhoid Mary en que tienen el conocimiento y la capacidad para mejorar el entorno de seguridad. Se parecen a Mallon en un aspecto, y solo en un aspecto: carecen del incentivo adecuado para cambiar sus hábitos y han evitado debidamente los riesgos asociados con el código incorrecto en otros. Un régimen de responsabilidad de software matizado, uno que responsabiliza a los fabricantes de software por productos defectuosos inaceptables, así como su comercialización (vender lo que se produce; véase la comercialización, por ejemplo, de productos) o/y, en muchos casos, marketing, o mercadotecnia (como actividades empresariales que tratan de anticiparse a los requerimientos de su cliente; producir lo que se vende) negligente o imprudente, podría corregir esto. No se necesita un ingeniero sanitario para entender eso.

Autor: Williams

El triste estado de la ley de responsabilidad cibernética

Los acuerdos de licencia de software suelen estar abarrotados de lenguaje repetitivo que libera al proveedor de software de prácticamente todas las formas de responsabilidad, al tiempo que obliga al usuario comercial a restricciones severas de uso. ¿Descontento con eso? Demasiado. Cualquier persona que haya instalado software después de “consentir” los términos de clickwrap, shrinkwrap o browsewrap adjuntos entiende que el usuario descontento tiene exactamente dos opciones cuando se trata de acuerdos de licencia de mercado masivo: lo tomas o lo dejas.

Los proveedores de software generalmente derivan todos los riesgos asociados con sus productos a los usuarios a través de estos acuerdos de licencia, que los tribunales generalmente han tratado como contratos ejecutables. Piense en los contratos como una forma de legislación privada: las partes acuerdan imponerse obligaciones que la ley no dicta de otra manera. Los teóricos frustrados han buscado fuera del ámbito contractual para encontrar maneras de responsabilizar a los proveedores de software por los daños que los usuarios sufren como resultado de un código inseguro. Las leyes de protección al consumidor parecen ofrecer una vía estrecha para la reparación. (Tal vez sea de interés más investigación sobre el concepto). Alternativamente, los usuarios han presentado una demanda de indemnización por daños y perjuicios, alegando negligencia por parte del proveedor de software o el defecto del producto. Reconociendo el continuo incumplimiento de la ley de contratos para proporcionar a los usuarios de software remedios significativos para los daños causados ​​por un código inseguro,El agravio de la habilitación negligente del delito cibernético “.

Los acuerdos de licencia de software se han convertido en una broma tan mala para los usuarios de software que es difícil de creer que una vez, parecía que los usuarios podrían aprovechar los principios de los contratos para su beneficio. Específicamente, los comentaristas especularon que los principios de contratación incorporados en el Código de Comercio Uniforme (UCC), un conjunto de leyes modelo adoptadas al menos parcialmente por todos los estados, se podrían usar para ” perforar [e] la plataforma del proveedor ” y crear una Marco legal que beneficiaría igualmente a proveedores y usuarios, licenciatarios y licenciatarios.

Como declaró un creyente en 1988, “debido a que la imparcialidad y la razonabilidad son fundamentales en el Código, la aplicación del UCC beneficiaría a las partes que no están familiarizadas con sus disposiciones”. Otro comentarista predijo ya en 1985: “Los tribunales tienen medios adecuados para “proteger a los vendedores de software de las disposiciones contractuales no considerables y la UCC hace claros los requisitos para la renuncia efectiva de la garantía, de modo que la UCC proteja adecuadamente a los vendedores de software y no sirva como un vehículo para que los fabricantes limiten su responsabilidad”.

Desafortunadamente, la UCC ha servido para eso: un vehículo de limitación de responsabilidad. Como lo expresó un crítico hace casi dos décadas, tratar las licencias de software como ventas regidas por la UCC ” crea una ficción legal que, contrariamente a la intención general de la UCC, coloca al comprador en una grave desventaja con respecto al vendedor. “Esto se debe a que el UCC se basa en principios de libertad de contratación que asumen un poder de negociación aproximadamente igual entre el comprador y el vendedor. Desde mediados de la década de 1990, aproximadamente, los tribunales aceptaron esa suposición operativa y permitieron a los proveedores de software ceder la responsabilidad por las deficiencias de sus productos.

La adhesión judicial al cumplimiento de los términos del acuerdo de licencia de software estándar ha llevado a Douglas Phillips, consejero general de Promontory Interfinancial Network, a denominarlo ” licencia legislativa “.Entre las Líneas En otras palabras, gracias a una larga línea de decisiones judiciales, “la ley de La licencia de software se ha definido en gran medida por cada licencia de software en sí “.

Los principios de libertad de contrato de UCC sirven como pretexto por medio de los cuales los tribunales pueden defender las exenciones de responsabilidad y las limitaciones de los recursos que se encuentran en todos los acuerdos de licencia de software comercial.Si, Pero: Pero este no es el final de la historia. Otros factores ayudan a explicar por qué, en un caso de alto perfil tras otro, los usuarios de software que alegan defectos e infracciones de seguridad hacen que sus casos sean expulsados ​​de la corte. Estos factores son importantes en la medida en que ofrecen una visión de cómo los tribunales entienden el código, y sugieren que los motivos por los cuales los tribunales interpretan las normas de la ley de contratos en favor de los proveedores de software anularán igualmente los intentos de los usuarios de imponer responsabilidades a los proveedores a través de las leyes de protección al consumidor existentes oa través de reclamos que suenan en agravio.

Al menos tres factores distintos a los descargos de responsabilidad y limitaciones del acuerdo de licencia estándar impiden que los usuarios busquen una compensación cuando se vean perjudicados por un software defectuoso. Para empezar, mucho software es gratis. Este es un problema bajo la ley de contratos porque los tribunales no responsabilizan a los proveedores de software por los daños y perjuicios ocasionados por productos o servicios para los cuales los usuarios no ofrecieron alguna forma de pago, o lo que los abogados llaman “consideración”. Esta es la regla básica que subyace a Bruce Schneier. observación de que “free” software no estaría bajo un régimen de responsabilidad civil porque el escritor y el usuario no tienen ninguna relación comercial; no son vendedor y comprador. Schneier tiene razón, siempre y cuando estemos hablando de un régimen de pedidos privados. Un marco legal diferente, sin embargo, podría hacer para una regla diferente. Por ejemplo, los proveedores de software libre generan ingresos no extrayendo dinero de los usuarios, sino más bien extrayendo datos que luego pueden monetizar. Un estatuto que impone a los proveedores de software la obligación de establecer salvaguardas para proteger estos datos o restringir su uso podría permitir a los usuarios presentar una demanda en caso de una violación de la seguridad por teorías de negligencia o tergiversación.

Pero en ausencia de tal estatuto, el hecho de que gran parte del software y muchos servicios de Internet sean gratuitos seguirá siendo un punto de conflicto para los usuarios que buscan una compensación por lesiones relacionadas con la seguridad. El año pasado, el servicio de redes sociales LinkedIn recibió una demanda colectiva de alto perfil. después de que los piratas informáticos violaron el servidor de la compañía y publicaron 6,5 millones de hashes correspondientes a las cuentas de LinkedIn en un foro. El sesenta por ciento de estos hashes fueron rajados más tarde.

Informaciones

Los demandantes alegaron que LinkedIn no había utilizado los protocolos y la tecnología estándar de la industria para proteger la información de identificación personal de sus clientes, en violación de su propio Acuerdo de usuario y Política de privacidad. Un tribunal federal de California desestimó el caso esta primavera en parte debido a que la política era la misma para los usuarios de las versiones gratuitas y premium del servicio. Específicamente, el tribunal determinó que la demanda ” no alega suficientemente que los Demandantes realmente consideraron los servicios de seguridad que afirman que no fueron proporcionados “.

El hecho de que las aplicaciones web populares a menudo son gratuitas también ha resultado problemático para los usuarios que intentan presentar una reclamación por daños derivados de una violación de la seguridad en virtud de las leyes vigentes de protección al consumidor.Entre las Líneas En 2011, en juicios presentados contra Facebook y contra Apple por sus políticas de compartir datos de usuarios con terceros, otros dos jueces de tribunales federales en California dictaminaron que las leyes de protección al consumidor no se extendían a los usuarios de servicios gratuitos.Entre las Líneas En su orden de despido del caso de Facebook, el Juez Principal James Ware del Tribunal de Distrito de los Estados Unidos para el Distrito Norte de California escribió: “[Un] demandante que es un consumidor de ciertos servicios (es decir, quién “paga” por esos servicios) puede declarar una reclamación según ciertos estatutos de protección al consumidor de California cuando una compañía, en violación de sus propias políticas, divulga información personal sobre sus consumidores al público…. Aquí, en contraste, los Demandantes no alegan que pagaron honorarios por los servicios del Demandado “.

Aquí hay una segunda razón por la cual los proveedores de software tienden a prevalecer bajo un régimen de ordenamiento privado y permanecen inmunes incluso cuando los usuarios presentan demandas según diversas teorías de responsabilidad extracontractual: los tribunales se resisten a encontrar una garantía implícita de comercialización (vender lo que se produce; véase la comercialización, por ejemplo, de productos) o/y, en muchos casos, marketing, o mercadotecnia (como actividades empresariales que tratan de anticiparse a los requerimientos de su cliente; producir lo que se vende) con respecto a la seguridad de los productos y servicios de software que ellos saben no pueden ser libres de vulnerabilidad. Es decir, los tribunales tienden a tratar ciertas expectativas de seguridad del usuario como inherentemente irrazonables. Por ejemplo, en 2011, varios bancos demandaron a la compañía de transacciones de pago que había estado reteniendo los datos de sus clientes cuando sufrió una violación de seguridad masiva. Un tribunal federal de Texas rechazó la demanda, razonando.”En la medida en que los Demandantes de la Institución Financiera argumenten que las declaraciones y la conducta [de la empresa] equivalían a una garantía de seguridad absoluta de los datos, la confianza en esa declaración no sería razonable como cuestión de ley”. Al rechazar la reclamación de los demandantes, El tribunal se basó en la lógica de otra decisión judicial, que declaró que “en el mundo actual de piratas informáticos sofisticados, robos de datos, fallas de software y virus informáticos, un jurado no puede encontrar razonablemente un compromiso comercial implícito contra cualquier intrusión en cualquier circunstancia.. ”

Tenga en cuenta que esta línea de razonamiento una vez obtuvo tracción en el contexto del automóvil. Evans v. General Motors Corp. fue un caso del Séptimo Circuito en el cual el demandante alegó que General Motors había sido negligente en el diseño de su camioneta Chevrolet 1961 sin los rieles de marco perimetral que se estaban usando en muchos otros autos para proteger a los ocupantes durante un lado. Colisión de impacto. El tribunal de Evans rechazó el reclamo alegando que “[un] fabricante no tiene la obligación de hacer que su automóvil sea a prueba de accidentes o infalible”. Como señaló un comentarista, el tribunal exageró el reclamo del demandante de inmunizar al fabricante de la responsabilidad.

Dos años después, el Octavo Circuito rechazó esta formulación de las reclamaciones en el caso histórico Larsen v. General Motors Corp., en el que el demandante alegó un diseño negligente basado en el desplazamiento del eje de la dirección en el Chevrolet Corvair. Específicamente, el tribunal de Larsen rechazó el intento de General Motors de enmarcar el problema como un contingente para determinar si tenía el deber de producir un auto a prueba de choques, confiando en cambio en la idea de que era posible que General Motors hubiera diseñado un vehículo que Minimizaría el efecto de los accidentes.

Se podrían usar estándares similares basados ​​en las mejores prácticas de la industria para imponer responsabilidad en el contexto del software, si los tribunales conciben el software como un producto que podría diseñarse para minimizar, aunque no eliminar, las vulnerabilidades de seguridad.Si, Pero: Pero la falta de experiencia técnica del poder judicial y la complejidad inherente del software han impedido a los tribunales dar este salto.Entre las Líneas En un caso que se remonta a 1986, un tribunal federal de quiebras se negó a hacer cumplir la garantía implícita de comercialización (vender lo que se produce; véase la comercialización, por ejemplo, de productos) o/y, en muchos casos, marketing, o mercadotecnia (como actividades empresariales que tratan de anticiparse a los requerimientos de su cliente; producir lo que se vende) en la que una computadora basada en DOS que se representaba a sí misma como compatible con Apple no podía ejecutar el software de Apple. Al señalar que Apple vende miles de programas de software, el tribunal declaró: “Simplemente no podemos determinar el alcance de la incompatibilidad y, ante la falta de pruebas, llegamos a la conclusión de que no se ha violado una garantía implícita de comercialización”.conceptualmente indistinguible “agravio reclama por negligencia contra el fabricante de software.

Un tercer factor sugiere que los tribunales continuarán construyendo los acuerdos de licencia de software y, como resulta, las acciones ilícitas, en favor de los proveedores de software: la idea de que los piratas informáticos, no los proveedores, son los únicos responsables de las violaciones de seguridad. El año pasado, un tribunal federal de California rechazó la afirmación de que Sony había tergiversado la calidad de la seguridad de su red donde la política de privacidad de Sony había declarado que su seguridad no era perfecta, y también rechazó las reclamaciones de prácticas comerciales desleales de los demandantes, ya que Sony no se benefició financieramente de la violación de datos de terceros.

Basado en la experiencia de varios autores, mis opiniones, perspectivas y recomendaciones se expresarán a continuación (o en otros lugares de esta plataforma, respecto a las características en 2026 o antes, y el futuro de esta cuestión):

El rechazo por parte de la corte de la reclamación de prácticas comerciales desleales es notable en el sentido de que sugiere una visión estrecha de lo que constituye un beneficio financiero. Es decir, la corte razona que los proveedores de software no ganen nada cuando los actores maliciosos provoquen brechas de seguridad, por lo que se niegan a tener una visión amplia de las ganancias que los proveedores de software (injustamente) obtienen al participar en prácticas de envío y desarrollo de software sencillas y de mala calidad que a su vez Contribuir a las vulnerabilidades de seguridad y violaciones de seguridad.

Este enfoque reducido en el rol del pirata informático en la ejecución del exploit y la negativa a considerar el rol del fabricante de software en la creación de un entorno susceptible de ser explotado también presenta un desafío para cualquier intento de presentar reclamos por daños básicos. La negligencia es motivo de una demanda civil en la que el demandante puede establecer que el demandado debía un deber, incumplió ese deber, causó daños como resultado y debería pagar los daños para que Humpty Dumpty vuelva a estar completo. Establecer el elemento causal en esa cadena es difícil, si no imposible, siempre que los tribunales elijan fijarse en el pirata informático, no en el creador del entorno, al evaluar quién provocó la lesión en cuestión.

En resumen, es significativo que reforzar la interpretación de los acuerdos de licencia de software por parte de los tribunales sea una idea que, de manera similar, plantea problemas para que los proveedores de software sean responsables según los estatutos de protección del consumidor o las teorías de responsabilidad extracontractual.Si, Pero: Pero la idea de que, en ausencia de una legislación o regulación especial, el agravio podría ser una vía viable para perseguir la responsabilidad de los proveedores de software se enfrenta a un problema de umbral mucho mayor. Esa es la doctrina de la pérdida económica.Entre las Líneas En términos generales, la doctrina restringe la responsabilidad extracontractual a los casos que involucran lesiones corporales o daños a otros bienes. Este es un problema especial para reclamaciones de daños relacionados con vulnerabilidades de software, ya que la mayoría de las brechas de seguridad dan lugar a pérdidas puramente económicas o compromisos de datos.

Gracias a la regla de pérdida económica, los tribunales han evitado durante mucho tiempo la incómoda tarea de declarar que los proveedores de software no tienen el deber de establecer medidas razonables para desarrollar y mantener un software seguro. Por ejemplo, en el año 2000, la compañía de gas y petróleo Hou-Tex, Inc. alegó que una compañía de programas de software había incumplido su deber de informar a su cliente sobre un error en el software y su deber de solucionar el problema.Si, Pero: Pero el tribunal estatal de Texas sostuvo que la regla de pérdida económica excluía las demandas por negligencia de Hou-Tex contra la compañía de software.Entre las Líneas En un caso de 2010, un juez federal de Nueva York no hizo mención de un posible deber y, en cambio, simplemente lo despidió. las demandas de negligencia, estricta responsabilidad y negligencia grave de los demandantes por daños derivados de defectos en el software contratado, tal como lo prohíbe la doctrina de pérdidas económicas de Nueva York.

La doctrina de la pérdida económica tiene raíces en la política pública. Como lo explicó la Corte Suprema en su decisión histórica de East River Steamship Corp. v. Transamerica Delaval, Inc., 1986, la ley de agravios es el vehículo apropiado para tratar productos defectuosos y inesperadamente peligrosos, ya que en el caso de lesiones personales inesperadas o daños a la propiedad, el El fabricante está mejor posicionado para soportar el costo (o coste, como se emplea mayoritariamente en España) y el precio del producto para distribuir la pérdida.

Puntualización

Sin embargo, la pérdida financiera pura es el dominio de la ley de contratos, particularmente la ley de garantía, porque la regla obliga a las partes a establecer los términos de la negociación. (Tal vez sea de interés más investigación sobre el concepto). Cuando el consumidor acuerda pagar menos, el fabricante puede restringir su responsabilidad renunciando a las garantías o limitando los recursos.

En resumen, la doctrina de la pérdida económica se basa en la idea de que, según lo declarado por el tribunal de East River Steamship, “una situación comercial generalmente no implica grandes disparidades en el poder de negociación… [por lo tanto] no vemos ninguna razón para entrometerse en la asignación del riesgo por parte de las partes ”.Entre las Líneas En otras palabras, la regla no tiene en cuenta el poder de negociación asimétrico entre los proveedores de software y los usuarios finales, lo cual es bastante vasto.

Y así, después de recorrer brevemente algunos de los problemas con el actual régimen de ordenamiento privado y haber aprendido (en parte) por qué la ley de agravios tampoco funcionará, regresamos, completando el círculo, a las deficiencias del derecho contractual y la UCC en Asignación de responsabilidad entre proveedores de software y usuarios.

El hecho de que los usuarios de software no prevalezcan bajo los esquemas de protección contractual, extracontractual o de los consumidores cuando se trata de obtener una compensación por un código incorrecto sugiere que, en ausencia de una legislación o regulación específica, por ejemplo, restringir la capacidad de los proveedores de software para confiar en los descargos de responsabilidad generales. Los usuarios de software tendrán poco éxito en responsabilizar a los proveedores por las vulnerabilidades.

En pocas palabras, las leyes en los libros deben cambiar, o la calidad de nuestro software no cambiará.

Autor: Williams

La responsabilidad del software es una máquina compleja, no un gran botón rojo

El destacado experto en seguridad informática Daniel Geer cree que debería asumir los costos (o costes, como se emplea mayoritariamente en España) del código inseguro que utiliza. No es nada personal. Reconoce que responsabilizar al usuario final de ser el “cómplice involuntario de un crimen constante” está lejos de ser una estrategia perfecta de ciberseguridad.Si, Pero: Pero concluye que, por el momento, es la opción menos “peor”:

Si dice que es responsabilidad de los proveedores de servicios de Internet (ISP, por sus siglas en inglés) ese argumento de “tuberías limpias”, entonces está renunciando rotundamente a que su tráfico no sea inspeccionado con un buen nivel de detalle. Si dice que es responsabilidad del fabricante del software, pronto necesitaremos el equivalente digital de la Administración de Alimentos y Medicamentos para establecer estándares de eficacia y seguridad. Si dice que es responsabilidad del gobierno, pronto deberá seguir la mítica Licencia de Conducir de la Autopista de la Información. (Tal vez sea de interés más investigación sobre el concepto).Entre las Líneas En mi opinión, la responsabilidad personal por la seguridad en Internet es la peor opción, a excepción de todas las demás.

La preocupación de Geer está bien fundada: imponer responsabilidades de seguridad en entidades distintas del usuario final sin duda abrogará parte de la libertad y la funcionalidad que los usuarios finales disfrutan actualmente como consumidores. Esto es cierto tanto con respecto al software y al acceso a Internet específicamente como con respecto a los sistemas de información de computadora en general.

Pero las conclusiones de Geer son innecesariamente crudas, en parte porque asumen que la seguridad es un pastel que no se puede compartir inteligentemente, una conclusión que, se debe tener en cuenta, nunca estaríamos inclinados a aceptar en nuestras vidas fuera de línea. Nuestra seguridad física puede ser nuestra carga, pero esperamos que las cadenas de comida rápida no nos envenenen, que la policía local haga sus rondas y que nuestros vecinos llamen al 9-1-1 si ven una actividad sospechosa. Algunas redes invisibles de leyes, obligaciones profesionales y normas comunitarias confluyen en todo momento para mantenernos vivos y nuestra propiedad en nuestra posesión.

Sería de carencia ISP con circunscritos seguridad responsabilidades, tales como responder a la grabación o patrones de tráfico altamente inusuales que sugieren un DDoS en curso ataque a requerir a los usuarios finales “de plano” renunciar a la privacidad de datos? Muchos ISP ya implementan mecanismos de seguridad limitados, y las restricciones de intercambio de datos público-privadas cuidadosamente diseñadas podrían ayudar en gran medida a abordar las preocupaciones sobre el uso inadecuado de la información del suscriptor.

Del mismo modo, responsabilizar a los proveedores de software por su código no implica que los proveedores de software queden expuestos a demandas por cualquiera y todas las vulnerabilidades encontradas en sus productos. Los críticos de responsabilidad luchan contra un hombre de paja cuando hacen argumentos como este, de la autoridad de seguridad informática Roger Grimes: “Si todo el software es imperfecto y tiene errores de seguridad, eso significa que todos los proveedores de software, desde tiendas unipersonales hasta corporaciones conglomeradas globales, ser responsable de los errores involuntarios “.

La responsabilidad es un arma mucho más matizada de lo que creen sus críticos. Geer y Grimes ven la responsabilidad como un gran botón rojo, un tipo de opción nuclear, que debe evitarse a toda costa. Mientras tanto, los proponentes entienden la responsabilidad como una máquina compleja idealmente equipada con una serie de palancas inteligentes.

Considere: las funciones del software varían de triviales a críticas; los estándares de seguridad pueden imponerse en la etapa de desarrollo o prueba, en forma de prácticas de parcheo responsables o mediante obligaciones para la divulgación oportuna de vulnerabilidades o violaciones; El código en sí puede ser de código abierto o propietario o, en cualquier caso, gratis. Un régimen de responsabilidad efectivo es aquel que tiene en cuenta estos muchos factores cuando se trata de diseñar reglas, crear obligaciones o imponer normas.

Para empezar, no tendría sentido hacer que todos los proveedores de software tengan el mismo deber de cuidado y la misma responsabilidad por el incumplimiento de ese deber, independientemente del uso previsto del software y los daños asociados. Como observó Bruce Schneier en 2005, “No todo el software debe construirse bajo la descripción general de un ingeniero de software con licencia… [pero] el software de control de vuelo de aeronaves comerciales claramente requiere la certificación del ingeniero responsable “. Todo el software integrado en sistemas críticos para la vida o infraestructura crítica debe estar sujeto a estándares más rigurosos que el software comercial estándar, y los fabricantes deben ser responsables. por daños causados ​​por productos que se desvían de esos estándares, o por fallas que no son remediadas oportunamente.

Imponer este tipo de responsabilidad requerirá restringir las exenciones de responsabilidad de la garantía y las limitaciones de los recursos que se encuentran en los acuerdos de licencia de software estándar.Entre las Líneas En cuanto a las recomendaciones, esta es una repetición familiar.Entre las Líneas En un informe de 2007, el Comité de Ciencia y Tecnología de la Cámara de los Lores recomendó que la Unión Europea instituya “un marco integral de responsabilidad del vendedor y protección del consumidor”, que impone la responsabilidad a los fabricantes de software y hardware “a pesar de los acuerdos de licencia de usuario final, en circunstancias donde La negligencia puede ser demostrada “.

La parte difícil, por supuesto, es establecer un sistema a través del cual se pueda demostrar de manera confiable la negligencia. Como principio general, en la medida en que la seguridad puede entenderse como un proceso, en lugar de un fin, la negligencia debe evaluarse basándose en el incumplimiento de ciertos estándares de seguridad en lugar de en absolutos, como la cantidad de vulnerabilidades en el propio software. De hecho, los números podrían revelar más sobre la popularidad del software que su inseguridad inherente. Cualquier vulnerabilidad en particular puede no demostrar que un programa de software sea inaceptablemente defectuoso, sino un examen de los procesos generales y las precauciones a través de las cuales se produjo el software.

Las leyes que se limitan a establecer deberes modestos por parte de los fabricantes de software, y someterlos a una demanda privada o una multa del gobierno en caso de daños resultantes de una violación, podrían ayudar a la industria a desarrollar e implementar las mejores prácticas. Estas prácticas podrían a su vez constituir una defensa afirmativa contra reclamaciones por negligencia. Las mejores prácticas pueden abarcar desde auditorías de seguridad independientes periódicas hasta la participación en lo que David Rice, director global de seguridad de Apple, describe como un sistema de calificación para la seguridad del software, un análogo al sistema de calificación de la Administración Nacional de Seguridad del Tráfico en Carreteras para la seguridad del automóvil.

La legislación ya existente que penaliza a las empresas por no proteger la información confidencial de los usuarios ofrece un modelo útil para imponer deberes de seguridad estrechamente limitados a los proveedores de software. Por ejemplo, en 2006, la legislatura de Indiana promulgó un estatuto que exige que el propietario de cualquier base de datos que contenga datos electrónicos personales revele una violación a la seguridad de los consumidores potencialmente afectados, pero no requiere ningún otro acto afirmativo. Los términos del estatuto son decididamente restringidos: le otorgan al fiscal general del estado poderes de ejecución, pero no le otorgan al cliente afectado ningún derecho privado de acción contra el propietario de la base de datos e impone la obligación de compensar a las personas afectadas por inconvenientes o posibles daños relacionados con el crédito. de la brecha.

Hay otros factores a considerar en la calibración de un sistema de responsabilidad. La exposición a la responsabilidad debe estar en cierta medida supeditada, por ejemplo, a la disponibilidad del código fuente. Es difícil imaginar, por ejemplo, un buen argumento para que los contribuyentes de un proyecto de software de código abierto sean responsables de su código. Ya sea que crea o no que el proceso por el cual evoluciona el software de código abierto en realidad constituye su propio mecanismo de seguridad, la Ley de Linus (“dado que hay suficientes ojos, todos los errores son superficiales”), el hecho es que el software de código abierto ofrece a los usuarios tanto El pastel y la receta. Los usuarios tienen libertad para examinar la receta y modificarla a voluntad. Al ofrecer a los usuarios acceso al código fuente, el software de código abierto hace que los usuarios sean responsables del código fuente, y no puedan recuperarse de los daños.

Imponer responsabilidad en el software de código abierto no solo es una propuesta incoherente, sino que también tiene implicaciones problemáticas de la Primera Enmienda. El código es, después de todo, más que un bien o servicio. También es un lenguaje y un medio. Y las reglas de responsabilidad impuestas de manera torpe podrían poner cargas significativas e inaceptables en el software de voz y la innovación a nivel de aplicación.

En su libro sobre la relación entre la arquitectura de Internet y la innovación, Barbara van Schewick nos da una idea de por qué deberíamos desconfiar de crear leyes de responsabilidad asfixiantes con su descripción del nexo entre las aplicaciones de software y el gran potencial humano:

La importancia de la innovación en las aplicaciones va más allá de su papel en el fomento del crecimiento económico. La Internet, como tecnología de uso general… crea valor al permitir a los usuarios hacer las cosas que quieren o necesitan hacer.

Pormenores

Las aplicaciones son las herramientas que permiten a los usuarios darse cuenta de este valor. Por ejemplo, el potencial político, social o cultural de Internet, su potencial para mejorar el discurso democrático, facilitar la acción y la organización política o proporcionar un entorno descentralizado para la interacción social y cultural en el que cualquiera puede participar, está estrechamente vinculado a las aplicaciones que ayudan Los individuos, grupos u organizaciones hacen más cosas o las hacen más eficientemente, y no solo en contextos económicos, sino también en contextos sociales, culturales o políticos.

Todo esto se aplica, por supuesto, a las aplicaciones propietarias, pero el cálculo de responsabilidad para el software de código cerrado debería ser un poco diferente. Cuando se trata de aplicaciones propietarias, la seguridad del código no recae en los usuarios, sino que queda totalmente bajo el control de una entidad comercial. El hecho de que gran parte del software propietario sea “gratuito” no debe excluir la responsabilidad: una regla de responsabilidad estrechamente adaptada podría establecer que cuando los usuarios están “pagando” un producto o servicio de software con sus datos, una violación de datos que cause daños podría ser motivo de gobierno. -las multas impuestas o, en la medida en que cause que los individuos sufran daños, daños privados.

Esto no es, de ninguna manera, una visión general de todos los enfoques posibles para construir un régimen de responsabilidad de software. Es más bien un vistazo a algunas de las muchas palancas que podemos empujar y jalar para convertir la seguridad de una idea de último momento en una prioridad para los fabricantes de software. Tal cambio vendrá con costos, impuestos a los fabricantes de software y redistribuidos a nosotros, los usuarios.Si, Pero: Pero debemos tener en cuenta que lo que paguemos en costos (o costes, como se emplea mayoritariamente en España) preventivos hoy en día son bajos en comparación con lo que podríamos pagar en costos (o costes, como se emplea mayoritariamente en España) de seguridad correctivos mañana.

Como una cuestión de rutina, aceptamos inconvenientes, costos (o costes, como se emplea mayoritariamente en España) y redistribución de riesgos en otras áreas de nuestras vidas. Se requiere que las drogas se sometan a pruebas clínicas, se inspeccionan los alimentos y, ocasionalmente, se ” detienen administrativamente “, y las vacunas se gravan para compensar a la pequeña fracción de receptores que sufrirán una reacción adversa. Las medidas restringidas para el software de la policía también pueden entenderse como parte de un intercambio de sentido común entre lo que es barato y funcional y lo que es seguro.

Autor: Williams

▷ Esperamos que haya sido de utilidad. Si conoces a alguien que pueda estar interesado en este tema, por favor comparte con él/ella este contenido. Es la mejor forma de ayudar al Proyecto Lawi.