Creo que hace un montón de tiempo que no hablábamos de Fuzzing: esencialmente (aunque últimamente se ha ido sofisticando) enviar basura diversa a las interfaces de entrada de los programas para detectar problemas de seguridad.

En Announcing OSS-Fuzz: Continuous Fuzzing for Open Source Software una iniciativa de Google para poner el sistema de fuzzing como servicio a disposición de desarrolladores de software libre. Ya ha servido para encontrar fallos en algunos proyectos:

OSS-Fuzz has already found 150 bugs in several widely used open source projects (and churns ~4 trillion test cases a week). With your help, we can make fuzzing a standard part of open source development, and work with the broader community of developers and security testers to ensure that bugs in critical open source applications, libraries, and APIs are discovered and fixed.

El proyecto está disponible en oss-fuzz con algo más de información.

Recordemos que Microsoft fue uno de los primeros promotores del fuzzing dentro de su ciclo de vida del desarrollo seguro (por cierto, más recientemente también ha puesto a disposición del público Microsoft opens fuzz testing service to the wider public y también que Coverity Scan es otro proyecto que ofrece sus servicios a los desarrolladores de software libre, desde otra perspectiva.

Cuando todavía no tenemos clara la seguridad en los dispositivos fijos, nos está pasando por encima todos los aparatos móviles que lleva la gente, que se conectan a nuestras redes, a nuestros servidores y donde haga falta. En 10 ways to secure a mobile workforce, utilizando una de las formas más horribles de presentar la información en internet (pase de diapositivas), algunos consejos.

Yo me quedo con un par de ideas, la primera, que no podemos ser excesivamente rígidos o exigentes. Eso se volverá contra nuestras políticas de seguridad de manera inevitable. Las restricciones y las políticas deberían ser realistas:

If you implement policies that are too rigid or out of place with the current maturity of your company’s security program, chances are that your employees are going to subvert or ignore them altogether. If your employees find that the policies are strict, but workable, they will be more open to approaching you with issues or concerns on how they can meet policy and still get their work done.

La segunda, una con la que no solo estoy de acuerdo, sino que creo que todos tratamos de aplicar: cuando haya incidentes, aprovecharlos para recordar las partes relevantes de nuestras políticas de seguridad:

For example, when a well publicized security issue, like the resurfacing of the 2012 LinkedIn hack, it is a perfect opportunity to provide a refresher to personnel on the risk of password reuse and the benefits of strong passwords.

No debemos olvidar a la gente aunque estemos siempre tratando de mejorar la seguridad de nuestras organizaciones.

No todas las noticias que nos llegan de Gran Bretaña son malas. Llevamos una buena temporada escuchando señales de su zona de internet donde se muestra que han decidido apostar por desarrollos abiertos, sostenibles, amigables…

En Open Source Development at the UK Government nos lo contaban y yo me anoté algunas cuestiones, que paso a detallar.

Primero, la voluntad de cambio de gobierno desde la tecnología, y que yo mismo me he apropiado ya en alguna ocasión. Hacer herramientas tan buenas que la gente quiera usarlas:

Our job is to change the way the government works, said Shipman. The UK government wants to provide digital services which are so good that people want to use them; services which are leading to better interaction between the government and citizen.

Además, proporcionar el código a los demás, hacerlo abierto, salvo que haya razones de seguridad para no abrirlo:

The UK government has committed to making code open; new code should be open by default, said Shipman. There might be exceptions for code to do with security or configuration, but even some of this code is becoming open.

Y no sólo proyectos infraestructurales y bibliotecas (que es lo que casi siempre se libera):

And not just libraries either. You can find the code for HMRC’s web frontends and domain-driven microservices that are actually running on gov.uk

Ojalá cunda el ejemplo. Nosotros, modestamente, trataremos de seguirlo.

Una de las cosas que me está preocupando últimamente (sobre todo porque estoy implicado en la toma de decisiones sobre ello) es la de qué aconsejar (y exigir, en su caso) a los usuarios desde el punto de vista de seguridad. Hay una tentación fuerte de poner la normativa y decir que hay que seguirla. Pero, claro, eso muchas veces choca de frente con el usuario normal, que no tiende bien los términos técnicos, las razones detrás de las decisiones.

Por no hablar de que, simplemente, en la mayoría de las ocasiones los usuarios no deberían necesitar tomar decisiones. Ni siquiera ser conscientes de que alguien las tomó por ellos.

Además está acostumbrado a otras cosas que le simplifican la vida, en lugar de complicársela (¿Tienen Amazon o Google una política de contraseñas? Respuesta: no, han añadido sus propios controles y en caso de duda nos hacen ponerla otra vez, o utilizan el doble factor, o lo que sea…). También es fácil pensar que si nosotros lo comprendemos (¿seguro?), cualquiera podría.

En esa línea creo que va el estudio sobre el que se habla en Why asking you to change your password makes it easier to hack the system en el que se nos recuerda que enviar demasiados mensajes con restricciones sobre temas de seguridad hace que los usuarios se relajen y dejen de prestarles atención:

It’s an actual phenomenon, studied by behavioral scientists and computer security experts. It happens when users get bombarded with security warnings and demands for compliance. As a result, the studies show, three-quarters of computer users know how to make strong passwords but don’t practice what they know. It just seems too overwhelming.

También se habla del tema en ‘Security Fatigue’ Can Cause Computer Users to Feel Hopeless and Act Recklessly, New Study Suggests (y en muchos sitios más, la verdad).

Los consejos son simples: limitar el número de decisiones sobre seguridad que tiene que hacer el usuario, hacer que la decisión segura sea la sencilla, y tratar de que las decisiones se tengan que hace de manera consistente:

The data provided evidence for three ways to ease security fatigue and help users maintain secure online habits and behavior. They are:

1. Limit the number of security decisions users need to make;
2. Make it simple for users to choose the right security action; and
3. Design for consistent decision making whenever possible.

No puedo estar más de acuerdo con estos términos y, desde luego, tenemos trabajo por hacer.

El otro día nos preguntábamos por las practicas de seguridad de la gente especializada en seguridad en ¿Se preocupa de la seguridad la gente de seguridad? y la conclusión era que no mucho. Hoy traemos el caso de la gente ‘normal’. Cualquiera que interaccione con temas relacionados con la seguridad y usuarios sabe que son presa fácil. Mensaje de Phishing: alquien caerá (y no por ser poco inteligente, estar poco preparado, o simple ignorancia; vas con prisas, no te fijas y adiós). No instales: alguien lo hará. Actualiza tu sistema (no, es que si lo actualizo deja de funcionarme Y)… Y así.

Pero, a veces, hay gente que se toma la molestia de hacer experimentos. Yo hace años empecé a utilizar unos que hicieron en una conferencia de seguridad muy importante en Londres como ejemplo, pero cada día surgen nuevos datos para mostrar. En esta ocasión, los discos USB: Does dropping malicious USB sticks really work? Yes, worryingly well…. Alguien dejó 300 memorias USB en una universidad y luego comprobó si alguien los había usado. El 98% fueron utilizados y un 45% no sólo fueron utilizados sino que la gente pinchó en los ficheros:

…we dropped nearly 300 USB sticks on the University of Illinois Urbana-Champaign campus and measured who plugged in the drives. And Oh boy how effective that was! Of the drives we dropped, 98% were picked up and for 45% of the drives, someone not only plugged in the drive but also clicked on files.

Luego se preguntaba a los que los abrían si querían responder a una encuesta.

¿Cosas malas que podrían haber pasado? (pero que no pasaron porque era un experimento).

Tal vez poner un ejecutable, o un fichero HTML que descargase cualquier cosa de internet.

The most basic – and simplest to conduct – attack would have seen malicious code placed in the HTML file that would have been automatically activated upon viewing, perhaps downloading further malware from the internet.

Pero el propio dispositivo USB podría haber contenido un simulador de un teclado y hacer lo que el atacante quisiera con la máquina del usuario.

A more sophisticated attack, however, would see the use of a device using HID (Human Interface Device) spoofing to trick a computer into believing that it was in reality a keyboard. As soon as the “USB stick” is plugged in it would inject keystrokes – building a set of commands that could open a reverse shell that could give a hacker remote access to the victim’s computer.

Espeluznante.