Vladislav Kochelaevs - Fotolia

Evaluar Conozca los pros y contras de las tecnologías, productos y proyectos que está considerando.

¿Quién es responsable por las debilidades en el software?

Los defectos o debilidades en el software, que pueden causar graves consecuencias por algún ataque, no son responsabilidad de su fabricante. ¿Por qué?

Si una constructora edifica un inmueble con defectos y este se derrumba, seguramente habrá consecuencias para quien lo construyó. Lo mismo pasa con un automóvil. ¿Pero con el software? No, con el software no pasa nada.

Parece que a las debilidades informáticas de los programas no se les da el trato de “defecto”, aunque en mi opinión sí lo sean. Más de una licencia de software establece que no hay responsabilidad del fabricante por este tipo de “carencias”, que son vulnerabilidades que pueden permitir a un atacante alterar el funcionamiento del software o al menos hacer que deje de operar.

Tomen el ejemplo de su sistema operativo, el cual seguramente está siendo parchado frecuentemente para solucionar problemas de seguridad. Si bien el fabricante envía estos parches para solucionar los problemas, no hay responsabilidad alguna por cualquier consecuencia que el cliente puede haber sufrido a causa de este defecto. ¿El atacante logró robar dinero, enviar spam, tomar control de una cuenta de red social o espiar comunicaciones supuestamente protegidas? Ese es problema del cliente; que él lidie con eso.

Así que repito: no hay responsabilidad por las consecuencias o impactos sufridos por cualquier defecto en el software. Quizás el fabricante se disculpe; seguramente lo corregirá con un parche; pero no pagará monto alguno por las consecuencias de que un atacante haya explotado la debilidad exitosamente. Aunado a esto, probablemente no haga nada (o poco) para introducir seguridad en su metodología de desarrollo de software, y no solamente por falta de voluntad, sino porque cuesta dinero hacerlo. Pero las consecuencias de las debilidades en el software pueden ser más serias que solo adueñarse de cuentas de redes sociales.

En la conferencia de BlackHat 2015, acaban de demostrar cómo es posible atacar un Jeep de manera remota, y esa la última muestra de ataques similares (hace poco hubo una noticia de un supuesto intento de hackeo a un avión). Me parece que estas industrias, si bien han existido por décadas (la automotriz y la aeronáutica, entre otras) y tienen una larga –y creo que exitosa– evolución en materia de seguridad física de sus productos (autos y aviones), todavía están en pañales en cuestión de seguridad informática. Es apenas que estos fabricantes han introducido software en sus productos y la carencia de experiencia en este rubro es evidente. Seguramente, seguiremos recibiendo noticias de ataques informáticos hacia ellos, porque la tendencia es tener más software y conectividad a la red en autos y aviones.

Pero este problema no se detiene ahí. Hay software por todos lados. Ahí está el llamado Internet de las Cosas (IoT, por sus siglas en inglés) y programas tipo SCADA para controlar plantas eléctricas, de agua y similares. Gracias a ello, hay software corriendo en productos de menor importancia, que también controlan autos, aviones y plantas nucleares. ¿Quién se va a responsabilizar por las consecuencias de ataques a debilidades informáticas en ese tipo de software crítico?

Cuando toqué el tema por Twitter, me contestaron: “Creo que será imposible de implementar. Es una utopía y elevaría los costos de producción”. Mi respuesta ante esto es que, al menos el software que involucre vidas, debería de:

  1. Tener regulación para obligar a los fabricantes a introducir el tema de seguridad en su metodología de desarrollo de software.
  2. También por regulación, obligar a los fabricantes a ejecutar herramientas de seguridad que evalúen la seguridad de su código (caja blanca) y de sus aplicativos (caja negra) antes de ponerlos en producción.
  3. Establecer legalmente la responsabilidad de los fabricantes de software por las consecuencias sufridas por un cliente, debido el hecho de haber recibido software inseguro. Esto será un motivador poderoso para que, ahora sí, los fabricantes introduzcan seguridad en sus programas.

¿Estas acciones elevarán los costos? Sí, claro que lo harán, pero vale la pena. Una cosa es que alguien nos ataque y controle el refrigerador inteligente de nuestra casa, y otra que puedan desactivar los frenos de nuestro auto mientras lo estamos conduciendo, que puedan causar una anormalidad en la operación de una planta nuclear (recuerdan a StuxNet?) o que sean capaces de causar un accidente aéreo.

No creo que esto sea una utopía, sino que me parece algo factible y un tema digno de poner en la mesa de discusión. ¿Aplicará para todo el software? Tal vez no, pero sí para el que esté hecho para controlar sistemas críticos de los que dependen vidas.

Dudo que los fabricantes de software empujen este tipo de iniciativas; de hecho, son los primeros en poner el grito en el cielo y en negarse rotundamente a hacerse responsables. Pero, mientras tanto, debemos tener cuidado pues estamos dependiendo, en cada vez más cosas, de software con dudosa seguridad.

Próximos pasos

Para leer más sobre vulnerabilidades, revise:

Black Hat 2014: Investigador revela vulnerabilidades en la nube de Amazon

Vulnerabilidad en router de hogar expone 12 millones de dispositivos

Teléfonos IP de Cisco vulnerables a espionaje; aún no hay parche

Este artículo se actualizó por última vez en agosto 2015

Profundice más

PRO+

Contenido

Encuentre más contenido PRO+ y otras ofertas exclusivas para miembros, aquí.

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Enviando esta solicitud usted acepta recibir correos electrónicos de TechTarget y sus socios. Si usted reside afuera de Estados Unidos, esta dando autorización para que transfiramos y procesemos su información personal en Estados Unidos.Privacidad

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close