Creo que venimos hablando de este tema desde las primeras versiones de este sitio, desde varios puntos de vista:

• Las diferentes industrias que se digitalizan cometen los mismos errores que las que lo hicieron anteriormente y no aprovechan lo que se ha aprendido en estos años. No sólo eso, sino que a pesar de desarrollar nuevas plataformas, no lo hacen con los principios adecuados, que garanticen que se hace bien.
• La industria del automóvil ya ha pasado varias veces por estos problemas (diez años va a cumplir, por ejemplo, este: [PFD] Remote Exploitation of an Unaltered Passenger Vehicle a cargo de Charlie Miller (uno de los primeros en ganar notoriedad con estos temas) y Chris Valasek, también curtido en estas batallas.

Em Hacking Kia: Remotely Controlling Cars With Just a License Plate Sam Curry nos hablan del caso del conocido fabricante Kia y una serie de fallos que permitirían a un atacante controlar algunas funciones importantes del vehículo conociendo su matrícula.

… a set of vulnerabilities in Kia vehicles that allowed remote control over key functions using only a license plate.

Esto incluía, claro, obtener información personal:

Additionally, an attacker could silently obtain personal information, including the victim’s name, phone number, email address, and physical address.

La cuestión es que con instrucciones y métodos muy sencillos era posible realizar los ataques porque casi todo parece estar mal: un identificador que es fácil de conocer, pero también otros fallos de acceso a los sistemas que realizaban las acciones. En el artículo se detallan las ideas principales.

Llevamos mucho tiempo (tal vez demasiado) en el que hacer programas inseguros no era algo que preocupara mucho a nadie. Desde hace algún tiempo venimos escuchando llamadas a la responsabilidad, regulaciones y tímidas amenazas para mejorar el tema. En CISA boss: Makers of insecure software must stop enabling today’s cyber villains Jen Easterly, directora de la Cybersecurity and Infrastructure Security Agency (CISA) de los EEUU ha ido un poco más allá, diciendo que los vendedores son los que están creando problemas, abriendo la puerta a los malos para atacar a sus víctimas.

“The truth is: Technology vendors are the characters who are building problems” into their products, which then “open the doors for villains to attack their victims,” declared Easterly during a Wednesday keynote address at Mandiant’s mWise conference.

Ya puestos, se quejaba también de darles nombres ‘molones’ a los grupos criminales, dándoles aspectos ‘glamourosos’.

Easterly also implored the audience to stop “glamorizing” crime gangs with fancy poetic names. How about “Scrawny Nuisance” or “Evil Ferret,” Easterly suggested.

Y no sólo eso, porque también afirmaba que el nombre de vulnerabilidades de los programas (software vulnerabilities) contribuía a difuminar la responsabilidad y que deberían llamarse defectos de los productos (product defects). No se trata de señalar las víctimas por no actualizar, sino a los autores por desarrollar productos que requieren esas actualizaciones Ya puestos, se quejaba también de darles nombres ‘molones’ a los grupos criminales, dándoles aspectos ‘glamourosos’.

Easterly also implored the audience to stop “glamorizing” crime gangs with fancy poetic names. How about “Scrawny Nuisance” or “Evil Ferret,” Easterly suggested.

Y no sólo eso, porque también afirmaba que el nombre de vulnerabilidades de los programas (software vulnerabilities) contribuía a difuminar la responsabilidad y que deberían llamarse defectos de los productos (product defects). No se trata de señalar las víctimas por no actualizar, sino a los autores por desarrollar productos que requieren esas actualizaciones.

Even calling security holes “software vulnerabilities” is too lenient, she added. This phrase “really diffuses responsibility. We should call them ‘product defects,’” Easterly said. And instead of automatically blaming victims for failing to patch their products quickly enough, “why don’t we ask: Why does software require so many urgent patches? The truth is: We need to demand more of technology vendors.”

Muy interesante.

Modestamente, ese mensaje también lo decíamos en En las Mesas de Debate AICAR ADICAE sobre ciberseguridad , aunque creo que es un mensaje que hay que trasladar cuidadosamente en determinados sitios porque hay gente que tiene comportamientos casi ‘suicidas’ y no deberíamos formentar tampoco eso.

Cuando debemos proteger un sistema normalmente tenemos que decidir a qué prestaremos atención primero. Luego, en qué punto debemos parar porque ya estamos razonablemente protegidos. Sin embargo, son decisiones que no son tan sencillas y en los que las reglas habituales para otros asuntos no siempre tienen sentido. En Why the 80-20 rule no longer works for cybersecurity hablaban justamente de eso.

El principio de Parto nos dice que aproximandamente el 80% de las consecuencias provienen del 20% de los motivos posibles, y esta es una regla que se utiliza en productividad, ventas, aseguramiento de la calidad y gestión de proyectos.

COMMENTARY: We’ve all heard about the Pareto Principle, the idea that approximately 80% of consequences result from 20% of causes. Organizations have long applied this “80-20 rule” to areas such as productivity, sales, quality assurance, and project management.

Esto también sucede en ciberseguridad, afirmando que con vigilar el 80% de los activos puede mitigar el riesgo. En algunos casos, incluso vigilando menos (pero los más importantes) puede ser suficiente:

Cybersecurity is no exception. Over the last 25 years, cybersecurity leaders have leveraged this principle to manage and secure assets, asserting that adequately monitoring 80% of assets can effectively mitigate risks. Some have gone as far as to believe that closely monitoring the crown jewel assets alone, even if they constitute just 1% of the total exposure, might be “good enough.”

Pero claro, la naturaleza de los ataques es tan variada y diversa que descuidar una parte puede ser justo lo que abra la puerta a nuestros problemas.

What does that unexamined 20% mean for these organizations? Most of the risk now gets concentrated in that bracket, which now contains the most attractive and exploitable assets for attackers.

Así que nos toca trabajar un poco más y estar atentos a todo lo que puede pasar, porque los problemas pueden venir por donde menos los esperemos.

Invest in the means to close the coverage gap now to future-proof the organization’s security strategy for the coming years. Leave the 80-20 rule behind.

En este sitio no hemos ido celebrando aniversarios ni nada de eso.Por este mismo motivo no era consciente del tiempo que llevamos aquí, el 6 de noviembre cumplimos diez añazos, así que he pensado que podríamos reflejarlo aquí.

Ni siquiera estamos muy seguros de que alguien lea, como para pensar en los aniversarios. Seguimos, en todo caso, en el espíritu de que al autor le sirve para leer, anotar, comentar…

Todo ha sido al actualizar un poco la plantilla (aprovechando que he tenido algunas sesiones sobre la web he repasado html y esas cosas) y cuando me puse con este sitio me di cuenta casualmente del detalle.

A veces la seguridad se basa en que el servicio es oscuro y utilizado por poca gente, y a la pregunta de ‘¿quién podría intentar atacar esto?’ la respuesta es, efectivamente, ‘nadie’. Pero en algunas ocasiones esta respuesta se transforma en ‘casi nadie’ y eso puede ser un problema.

De un caso de estos nos hablaban en Bypassing airport security via SQL injection donde Ian Carroll y Sam Curry descubren que los sistemas que permiten aligerar el control para algunos de los usuarios más habituales de los aeropuertos (tripulaciones, fundamentalmente) utilizar mecanismos para ahorrarse las verificaciones que sufrimos el resto de los mortales.

El caso es que esto depende de un sistema que la TSA (Transportation Security Agency) subcontrata a otra empresa que no le pone el cariño suficiente a estas cosas y los investigadores descubren que tiene un API que no se preocupa de cosas tan básicas como las comillas en una petición de datos. Tirando del hilo, encuentran la forma de manipular los datos y algunas otros problemas más.

We ended up finding several more serious issues but began the disclosure process immediately after finding the first issue.