En Half of U.S. Enterprise Employees Reuse Work-Related Passwords nos recuerdan uno de los problemas más importantes en la seguridad de las empresas: la falta de preocupación por parte de la gente que trabaja en ellas.

Se basa en una encuesta entre más de 1000 empleados de empresas en EEUU de los que casi la mitad afirmaban que re-utilizaban las contraseñas para cuentas relacionadas con el trabajo. La noticia no es negativa del todo porque en el caso de las contraseñas personales la re-utilización sube a las 2/3 partes.

A recent Ping Identity survey of more than 1,000 enterprise employees in the U.S. has found that almost half of respondents admit that they’re likely to reuse passwords for work-related accounts, and almost two-thirds reuse passwords for personal accounts.

Un 66% afirman que no las darían a cambio de nada, pero hay alrededor de un 20% que las cambiarían por dinero para la hipoteca, préstamos de estudios y otras necesidades.

And while 66 percent of respondents said they wouldn’t trade their personal email login credentials for anything, 20 percent said they would trade them for a paid mortgage or rent for one year, and 19 percent would trade them to pay off student loans or higher education tuition.

Hace algún tiempo hablábamos de encuestas similares donde la preocupación de los empleados no es suficiente cuando se trata de las contraseñas utilizadas en el trabajo (y las personales, según este estudio, todavía peor).

En Uncle Bob Proposes an Oath to Programmers justamente eso. Robert C. Martin, conocido como Uncle Bob (tío Bob) propone (traducción aproximada):

1. No produciré código dañino
2. El código que produzca será siempre el mejor posible. No entregaré a sabiendsas código defectuoso en su comportamiento o en su estructura.
3. Realizaré en cada entrega una comprobación segura y repetible de que cada elemento del código hace lo que debería.
4. Haré entregas pequeñas y frecuentes, para no obstaculizar el trabajo de otras personas.
5. Mejoraré el código sin temor y sin descanso cada vez que sea posible. Nunca empeoraré el código.
6. Haré todo lo posible para mantener mi productividad y la de otras personas tan alta como sea posible. No haré nada que reduzca esa productividad.
7. Me aseguraré de forma continua que otros pueden cubrir mi trabajo y que yo puedo cubrir el suyo.
8. Produciré estimaciones que son honestas tanto en magnitud como en precisión. No haré promesas sin certidumbre.
9. Nunca dejaré de aprender ni de mejorar mis habilidades.

El original del juramento se puede leer en The Programmer’s Oath.

En la entrada se añden algunos comentarios recibidos en su momento en Twitter después de la publicación del juramento y se recuerda el manifiesto del software robusto The rugged manifesto sobre el que comentamos en su momento en Manifiesto del software robusto.

Si los dispositivos no son seguros Estudio sobre vulnerabilidades en el firmware de dispositivos, ¿qué podría hacernos pensar que los dispositivos que se incluyen en los juguetes lo serán?.

En When children are breached – inside the massive VTech hack nos hablan con cierto detalle de las vulnerabilidades encontradas en esos ordenadorcitos parecidos a tabletas que están pensados para los niños pequeños:

Inyección de SQL:

Why they’re returning a SQL statement is absolutely beyond me. Lorenzo was told by the person that provided him with the data that the initial point of compromise was due to a SQL injection attack and even without seeing the behaviour above, I would have agreed that was the most likely attack vector. On seeing the haphazard way that internal database objects and queries are returned to the user, I’ve no doubt in my mind that SQL injection flaws would be rampant.

Desarrollo poco cuidadoso (sobre todo teniendo en cuenta quién va a utilizar el producto):

But what really disappoints me is the total lack of care shown by VTech in securing this data. It’s taken me not much more than a cursory review of publicly observable behaviours to identify serious shortcomings that not only appear as though they could be easily exploited, evidently have been.

Si los ‘juguetes’ de los mayores se actualizan poco, ¿quién actualizará los de los niños?

Esta entrada no será muy novedosa para casi nadie pero viene bien recordarla aquí. En The Problem with Patch Management: All the Humans hablan de las actualizaciones y de los problemas que nos causan: tenemos muchas cosas de las que ocuparnos, no es fácil siempre determinar si realmente nos afectan o no, tampoco es sencillo saber si afectarán a otros de nuestros procesos…

Necesitaríamos una forma de conocer las actualizaciones disponibles para nuestros dispositivos y sistemas y que pudieran ser aplicadas de forma que el impacto fuera mínimo:

What’s needed is a way to detect available updates across every operating system and all firmware on physical devices. All verified updates need to be applied in a way that minimizes or eliminates downtime. The updates must be introspectable, auditable, and repeatable. The process should minimize human interaction and required expertise.

Las actualizaciones deberían integrarse bien en los procesos modernos de integración continua:

Modern practices such as continuous delivery make this practical by constantly ensuring incoming change results in the desired behavior. Software updates should be treated as just another incoming change.

Esta es casi una continuación de la entrada anterior. En Many embedded devices ship without adequate security tests, analysis shows hablan del análisis realizado al firmware de un montón de dispositivos y las vulnerabilidades encontradas. Se analizaron 1925 dispositivos de más de 50 fabricantes.

De ellos sólo consiguieron arrancar alrededor de 250 servidores web:

The researchers started out with a collection of 1,925 Linux-based firmware images for embedded devices from 54 manufacturers, but they only managed to start the Web server on 246 of them. They believe that with additional work and tweaks to their platform that number could increase.

Intentaban encontrar problemas en las interfaces web de los dispositivos. Las encontraron, pero también en el código PHP utilizado en algunos dispositivos, inyecciones de SQL, cross-site scripting,… O sea, lo típico que suele encontrarse en cualquier sistema de complejidad mediana.

Y un aviso (más) a los usuarios/gestores/administradores que utilizan estos dispositivos.