Consejos sobre seguridad para trabajadores en movilidad

Telefonía móvil 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.

Innovación informática en el Gobierno de Gran Bretaña

Cuando celebrábamos el día del software libre 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.

Seguridad y tranquilidad para los usuarios

Consejos de seguridad 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.

Inseguridad social

USB 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.

¿Se preocupa de la seguridad la gente de seguridad?

Candados La pregunta es una pequeña provocación y además ya hemos comentado en vidas anteriores que no siempre es así. En esta ocasión traemos Las CONs de Seguridad españolas suspenden en la configuración del SSL/TLS: En casa del herrero cuchara de palo donde se llega a la conclusión de que no.

Se trata de un análisis de la información en las páginas web (y la configuración del servidor correspondiente) de las CONs (conferencias de seguridad) españolas, comprobando los siguientes parámtros:

a) Autenticación

a.1.- Certificado del servidor

a.2.- Certificados adicionales

a.3.- Cadena de certificación

b) Configuración

b.1.- Protocolos

b.2.- Cifrados empleados

b.3.- Simulación de handshakes

b.4.- Detalles del protocolo

b.5.- Misceláneo

La conclusión es que los resultados no son lo que deberían. Es cierto que todos sabemos que la web de un congreso o actividad no tiene por qué ser lo más importante y que su configuración no afecta a lo que los organizadores saben/piensan, o que tal vez la ha hecho alguien que no es de la organización, … Pero hay una componente de ejemplo que no se debería descuidar:

Como conclusión y a la vista de los resultados, podemos decir que son muy mejorables en general las medidas de seguridad mínimas en cuanto a la implementación de protocolos empleadas en sus servidores. Por tanto, se da muy bien organizar todo tipo de CONs pero no tanto dedicar algo de tiempo a ser los primeros en dar ejemplo y tener los servidores correctamente configurados …

Seguridad en internet de las cosas

Cosas conectadas En How to Engineer Secure Things: Past Mistakes and Future Advice nos hablan de las cosas conectadas a internet y las seguridad.

Se centra en estos puntos: las actualizaciones (que deben realizarse, y debe hacerse de forma segura), la utilización insegura de la criptografía (con algunos consejos), diseño inseguro (para obtener aplicaciones seguras hay que diseñar pensando en la seguridad, no es algo que se pueda añadir después).

Probablemente la más propia (porque las otras dos se ven habitualmente en todo tipo de aplicaciones) sea la de las actualizaciones que creo que es el gran olvidado en los aparatitos conectables a internet a pesar del tiempo que ha pasado y lo que ha costado resolver (o, al menos, tener la infraestructura adecuada) el problema en los sistemas tradicionales.

Los nombres y la seguridad. El caso de Python y PyPI

Libro sobre Python Cada vez pasa menos tiempo desde que alguien describe un problema de seguridad hasta que alguien lo aplica de manera (más o menos) efectiva. Hace algún tiempo podíamos leer Typosquatting programming language package managers donde se hablaba de la posibilidad de utilizar los errores de tecleo de los usuarios para suplantar algunos paquetes bien conocidos de sitio PyPi, que es un repositorio público para alojar paquetes desarrollados en Python que luego pueden instalarse de forma muy sencilla.

En este caso el experimento consistió en crear 200 paquetes y subirlos al repositorio:

All in all, I created over 200 such packages and equipped them with a small program and uploaded them over the course of several months. The idea is to add some code to the packages that is executed whenever the package is downloaded with the installing user rights.

Estos paquetes contenían un cierto código que ‘llamaba a casa’ e informaba de su instalación.

El resultado fue interesante puesto que 17289 computadores instalaron estos programas:

In two empirical phases, exactly 45334 HTTP requests by 17289 unique hosts (distinct IP addresses) were gathered. This means that 17289 distinct hosts executed the program above and sent the data to the webserver which was analyzed in the thesis.

No sólo eso, sino que al menos 43.6% de esas IPs ejecutaron el programa de notificación con privilegios de administrador:

At least 43.6% of the 17289 unique IP addresses executed the notification program with administrative rights. From the 19603 distinct interactions, 8614 machines used Linux as an operation system, 6174 used Windows and 4758 computers were running OS X. Only 57 hosts (or 0.29%) could not be mapped to one of these three major operating systems.

Cuando lo estuve leyendo me pareció un trabajo muy interesante y supuse que los administradores de PyPI lo tendrían en cuenta y tomarían algún tipo de medida.

La sorpresa ha sido ver que no sólo no se han tomado medidas, sino que parece haber habido un ataque real: Ten Malicious Libraries Found on PyPI - Python Package Index. Se trataba de utilizar nombres similares e incluir código malicioso en ellos:

NBU experts say attackers used a technique known as typosquatting to upload Python libraries with names similar to legitimate packages — e.g.: “urlib” instead of “urllib.”

Se puede leer el aviso ‘oficial’ en http://www.nbu.gov.sk/skcsirt-sa-20170909-pypi/index.html. Allí también recuerdan la forma de detectar si hemos instalado alguno de estos paquetes:

pip list --format=legacy | egrep '^(acqusition|apidev-coop|bzip|crypt|django-server|pwd|setup-tools|telnet|urlib3|urllib) '

Y luego podríamos utilzar el pip uninstall <paquete> si es que tenemos alguno de esos.

Aleatoriedad y juegos interesantes

Dados

Volvemos a hablar de aletoriedad. En esta ocasión How Stellaris fails to solve strategy gaming’s “bad luck” problem habla de juegos y del compromiso entre hacerlo suficientemente interesante, a la vez que impredecible:

Designing a game that’s both random and consistently engaging is a problem I thought about constantly during my recent time with Stellaris, Paradox’s latest epic space strategy game.

Porque, claro, una cosa es que sea aleatorio (soprendente, impredecible, …) y a la vez las decisiones que haya que tomar (o que se puedan tomar) hagan que el juego mantena el interés:

Developers should be expected to ensure that most (if not all) of their “randomized” strategy campaigns at least encourage the players to make interesting choices.

Lectura interesante.

¿Cómo son las preguntas de seguridad?

Puerta

Las preguntas de seguridad son esas que algunos proveedores utilizan para tratar de asegurarse de que somos nosotros cuando tratamos de reactivar nuestra contraseña principal olvidada. Es un método bastante denostado (Ver, por ejemplo Recuperación de contraseñas con preguntas personales aunque también tienen sus defensores (sobre todo, en condiciones adecuadas: Las claves).

En todo caso, traemos hoy aquí una nota sobre Estudio de contraseñas cognitivas en la filtración de datos del Banco Nacional de Catar (QNB) donde los usuarios podían elegir las preguntas. Aquí llaman preguntas cognitivas a esas preguntas de seguridad.

La ¿sorpresa?:

Si les dan a elegir, repiten los patrones impuestos desde siempre por los servicios en la red… el nombre de soltera de la madre, mascotas, gustos, lugar de nacimiento… todos datos muy fácilmente deducibles o con un rango de error muy pequeño con fuerza bruta (¿cuál es tu color favorito?). Muy pocos echan mano de la imaginación.

Al menos para los usuarios VIP. Aunque el resto de clientes tampoco parece echarle mucha imaginación.

Según Sergio de los Santos:

La solución es mentir si nos obligan a usar esas contraseñas cognitivas, empleando cadenas aleatorias a modo de contraseñas que, junto con la real del servicio, serán almacenadas en un buen gestor de contraseñas (sabiendo que, si se almacena bien la real, ni siquiera se necesitarán las cognitivas).

Si no usamos el gestor, como decían en uno de los artículos enlazados arriba, tendremos problemas.