Este tema aparece por aquí de vez en cuando: en este caso, desde el punto de vista del atacado ¿son las empresas responsables de los ataques que sufren?. En 90% of directors believe regulators should hold firms liable for hacks dicen que sí.

El matiz es que se haya prestado la debida atención (‘due care’) o no:

Nine out of 10 of those surveyed believe regulators such as the FTC should hold businesses liable for cyber breaches if due care has not been followed

También es cierto que se trata de responsables concienciados, que están tomando medidas o piensan tomarlas próximamente:

While 94 percent of respondents have increased or are planning to increase their security assessments to address liability concerns, two-thirds of respondents say they have also begun or are planning to insert liability clauses into contracts with their third-party providers.

La última vez que hablamos de este tema fue en Seguridad y aseguradoras

Siempre me ha parecido sugerente la idea de un sitio generado de manera estática. Por eso me gustó experimentar con pyblosxom (que no está demasiado activo, la verdad) y me decidí a migrar desde Wordpress aquí (aunque lo estático de este sitio se podría poner en duda de muchas formas porque cualquiera sabe, al final, lo que realmente hay por detrás). Contábamos el traslado en Cuarta etapa.

Con todas las ventajas de los gestores de contenidos disponibles por ahí uno se quedaba tranquilo con encontrar una solución que se adapte a sus rarezas y olvida el tema. Hasta que descubre que algunos dicen que este tipo de gestores que nos gustan son ‘la próxima gran cosa’ (en su contexto, imagino). Al menos eso es lo que decían en Why Static Website Generators Are The Next Big Thing.

Tampoco vamos a volvernos locos. Asumimos que este tipo de sistemas tienen sus ventajas para unos cuantos, es bueno que existan y ya nos viene bien. Pero no me imagino que vayan a ser mayoritarios.

Si alguien está interesado en el tema se habla de StaticGen, un directorio de este tipo de generadores y el artículo también habla de los típicos sitios más-o-menos-importantes que utilizan una aproximación de este tipo.

En realidad, no deja de ser una locura para determinadas páginas web utilizar esos gestores de contenidos tan complejos y con tantas posibilidades de que algo vaya mal. Pero de ahí a pensar que la web va a volver a ser más estática, hay un pequeño trecho que no se si mucha gente recorrerá.

Habla de sitios dinámicos con frontales estáticos (caches) y otras cuestiones técnicas relacionadas. Me gustó leerlo, y por eso lo traigo aquí.

Para mi es una lectura imprescindible el [PDF] Reflections on Trusting Trust de Ken Thompson y ya hemos hablado del mismo tema en alguna ocasión, por ejemplo en Un compilador que infecta los binarios donde aquellas ideas pasaban de la teoría a la práctica.

Más recientemente podíamos leer sobre XcodeGhost, que realizaba el ataque contra el compilador Xcode de Apple para iOS y OS X:

XcodeGhost is an example of compiler malware. Instead of trying to create a malicious app and get it approved in the App Store, XcodeGhost’s creator(s) targeted Apple’s legitimate iOS/OSX app development tool called Xcode to distribute the malicious code in legitimate apps.

Los ‘malos’ habrían ‘adaptado’ el compilador para sus objetivos y habrían colgado el enlace en distintos foros para que la gente se lo bajase y lo utilizase, produciendo un buen número de infecciones en diversos programas que terminaron en la AppStore.

Nótese que es un problema muy fácil de evitar, simplemente bajándose las herramientas de sitios confiables y no escuchando los cantos de sirenas de los foros y sitios de noticias. Pero aún así, algunos desarrolladores cayeron e infectaron a sus usuarios.

La seguridad absoluta no existe. Además no tiene sentido protegerse contra problemas que no tenemos, u olvidarse de los que tenemos porque no salen en los libros o en las listas de consejos. Por eso nos centramos en riesgos y cómo evitarlos/mitigarlos. Para ello podemos usar el modelado de amenazas para nuestro producto y tratar de determinar qué es lo importante aquí y cómo puede afectarnos, para tomar las decisiones adecuadas.

En Threat Modeling 101: Ten Common Traps Not to Fall Into hablan del modelado de amenazas (‘threat modelling’) y algunos trampas en las que se puede caer y que conviene tener en cuenta:

• Usar nuestros sentimientos

Está bien que conozcamos el negocio y todo eso, pero nuestras sensaciones no son suficientes para justificar decisiones. Sobre todo por lo que podemos dejarnos en el camino.

• Nunca terminas de hacer modelado de amenazas.

Puede ser cierto, siempre hay más cuestiones que considerar. Sugieren seguir los pasos: modelar, identificar amenazas, mitigar, validar.

• La forma de hacer modelado de amenazas es X

Como casi siempre, la forma perfecta de hacer las cosas no existe, depende del contexto, de quién lo hace, los medios disponibles,…

• Se trata de una capacidad (‘skill’)

En realidad se trata de un conjunto de técncias y herramientas para mejorar en nuestra habilidad de llevar a cabo el trabajo. También la lectura y formación adecuadas.

• El modelado de amenazas se sabe, no se aprende

Como todo, se trata de aprender, practicar, perfeccionar…

• Foco incorrecto

A veces se piensa que el objetivo es encontrar amenazas cuando en realidad se trata de mitigarlas y/o solucionarlas.

• El modelado de amenazas es para especialistas.

En realidad cualquier desarrollador debería incluir en su proceso de desarollo estas ideas, para hacer sus programas mejores.

• El modelado de amenazas de manera aislada.

En realidad puede ser otra forma más de ayudar a comunicar a los distintos agenets en el procseo.

• Excesivo foco en las amenazas.

En realidad los ataques, elementos de mitigación y requisitos van de la mano. Unos pueden ayudar a comprender mejor los otros e incluso pueden obligar a tener que adaptarlos.

• Modelado de amenazas en el momento incorrecto.

Como siempre, pensar en la seguridad al final del proceso es la receta segura para que haya cosas que ya no tengan remedio.

Se puede ver una retransmisión de la charla en Threat Modeling: Lessons from Star Wars - Adam Shostack aunque a lo mejor con las ideas principales ya nos parece suficiente.

Ya hacía tiempo que no hablábamos de copyright y coches. En Draconian US copyright rules made it easier for Volkswagen to cheat reúnen el tema de las restricciones sobre el acceso a la información de nuestros vehículos y un escándalo tan sonado como es el engaño por parte del fabricante Volskwagen con respecto a las emisiones de sus vehículos.

El titular lo dice todo y no hay mucho más que añadir: puesto que ni siquiera los propietarios de los vehículos tienen acceso a sus interioridades, es bastante difícil que esa parte de la auditoría que vendría del público interesado sea realizada. Recordemos que el fraude vendría porque los parámetros del vehículo podían cambiar de la mano de algunos programas instalados que serían capaces de determinar en que circunstancias se encontraba el mismo y, en particular, cuando estuviese siendo sometidos a las pruebas de emisiones.

In the case of Volkswagen, cars with diesel engines were equipped with software that determined when they were undergoing Environmental Protection Agency testing for carbon emissions. During a test, the software would turn off mechanisms that increased engine performance, thus decreasing emissions; under normal driving conditions, the performance enhancement would be turned on and emissions were higher.

Como nota lateral, también nos alerta contra los procedimientos excesivamente fijos y automatizados que permiten que un programa pueda detectarlos y modificar este comportamiento. Un buen probador debería tener un guión, pero también debería poder incluir actividades ‘no programadas’ e imprevistas que puedan consegui saltarse el guión previsto por el que realizó el producto. Porque conviene no olvidar que esos ojos mirando podrían haber encontrado el problema, pero también podría haber ocurrido que nadie mirase en el lugar adecuado (Más fallos con una larga historia).