El principio del mínimo privilegio consiste esencialmente en conceder a las aplicaciones y usuarios los permisos necesarios para realizar las acciones que tengan que llevar a cabo, pero no más. Esto durante el tiempo necesario.
A tip I often give my clients is to not see accounts as privilege but see privilege as accounts. What I mean by this is an account that is used for backup administration, or an account that is used to create users on a domain should be used as such and not for anything else. If your user’s accounts have these privileges then you have lost control of your network, data and systems and any malicious user or application will eventually exploit this vulnerability.
En Teaching Code in 2014 algo que ya llevamos tiempo diciendo: se sigue enseñando a programar (no a nivel básico, sino incluso después) sin tener en cuenta la seguridad.
Los consejos que da tienen que ver con:
No hay excusa para utilizar ejemplos inseguros
La seguridad debería estar integrada, no añadida
Usando Node.js también hay que tener en cuenta la seguridad
Hay que cambiar la forma de enfrentarse a este problema
En definitiva, hay que enseñar buenas prácticas, incluir ejemplos no sólo correctos desde el punto de vista de la funcionalidad sino también pensando en la seguridad.
Aunque de vez en cuando se anuncia la sustitución de las contraseñas con diversas tecnologías, lo cierto es que parece que vamos a convivir con ellas durante una buena temporada. En Passwords: Real-world issues, tips and alternatives se entrevista a Per Thorsheim y hablan sobre el tema. Se habla de las contraseñas, algunas alternativas, mejorar la facilidad de uso. Thorsheim es el organizador de la PasswordsCon, un encuentro centrado en estas cuestiones.
En 6 Tips for Developing Secure IoT Apps un nuevo recordatorio: los aparatos conectados a la red programables son peligrosos, sobre todo si no se tiene en cuenta que la conectividad cambia el contexto y aparecen nuevos riesgos.
Los consejos: contratar desarrolladores con conocimientos adecuados, utilizar plataformas probadas, comprobar las actualizaciones del firmware de los dispositivos, asegurarse de que los datos están seguros frente a ataques físicos y utilizar componentes de hardware seguros.
It found that every one of 10 popular Internet-connected security systems – which include video cameras and motion detectors – had significant security vulnerabilities which would allow hackers to access the devices and control them remotely.
Sobre esto, suelo emplear una referencia relativa a dispositivos WiFi y Bluetooth, [PDF] CODENOMICON WHITE PAPER. Wireless Security: Past , Present and Future para hacer notar que los fallos de seguridad no sólo aparecen en los programas, sino también en dispositivos. La cantidad de evidencias y casos sigue aumentando.
Las vulnerabilidades y los fallos no son nuevos:
They are well understood, and most of the specific vulnerabilities could probably be easily avoided by following best practices and recommendations for secure coding. The problem, according to Miessler, is that many IoT developers simply don’t follow them.
Las aplicaciones inseguras vienen de los propios fabricantes:
It’s noticeable that many of the insecure IoT applications (such as some of those in HP’s study) come from IoT hardware device vendors who offer software to work with their products.
Ya hemos hablado en el pasado de seguridad y aparatos ‘domésticos’. La internet de las cosas es un nuevo episodio:
Uno de los sucesos más llamativos de seguridad del año pasado fue Heartbleed un fallo en la implementación de OpenSSL que permitiría a un atacante obtener información en conexiones cifradas (desde claves a contenidos).
Aunque en Answering the Critical Question: Can You Get Private SSL Keys Using Heartbleed? tratan de resolver esta pregunta y el mensaje es tranquilizador, lo más interesante es el análisis del código responsable del problema, los detalles de la pila y ese tipo de análisis más técnicos que nos gusta referenciar por aquí.
No se si el año pasado fue el de la aleatoriedad, o que por casualidad yo encontré más lectura sobre el tema. O, a lo mejor, simplemente estaba prestando más atención.
En Myths about /dev/urandom una buena lectura sobre el tema, donde se habla de /dev/urandom, sus parecidos y diferencias con /dev/random y, al final, algunas discusiones sobre “aletaoriedad verdadera”.
I don’t want to dive into that issue too deep, because it quickly gets philosophical. Discussions have been known to unravel fast, because everyone can wax about their favorite model of randomness, without paying attention to anyone else. Or even making himself understood.
Lectura recomendable.
Podemos recomendar también la lectura de How do you know if an RNG is working? donde se aborda justamente ese tema: mucho se habla de números aleatorios y generadores. Pero cuando se piensa en la calidad de lo que se obtiene se dice que hay que medirla y poco más. Aquí da ideas, algún recordatorio interesante y, en definitiva, nos recuerda que el diablo está en (todos) los detalles.
Interesante documento en Are We Shooting Ourselves in the Foot with Stack Overflow? donde se hace un resumen de los problemas con los aceleradores de algunos modelos de Toyota. El fallo se atribuye a un desbordamiento de memoria (concretamente en la pila) y cómo esto podía producir que determinadas variables (del sistema) se vieran alteradas, con consecuencias.
De hecho, parece ser uno de los peores casos de corrupción de variables por desbordamiento de memoria, porque en lugar de manifestarse inmediatamente (en este caso, probablemente a baja velocidad todavía) aparecía algo más tarde con las consecuencias ya conocidas.
Luego propone algunas medidas que podrían mejorar la situacion, tanto desde el punto de vista de la gestión de memoria como del sistema operativo y las pruebas (tests).
En The Toyota Owners Left Holding the Bag podemos leer una descripción que simplemente habla de ‘código espagueti’, algunas consecuencias legales, los seguros…
Actualización (2015-03-01) Nos enlazó Juanjo Navarro fernand0 @ GitHub.io y recursividad y lo agradecemos aquí. Casi seguro que volveremos sobre este enlace acerca de nuestros sesgos y enfoques. Y también que hablaremos alguna vez de lo que Juanjo hable en su sitio. ¡Gracias!
Mantengo una página web con las cosas del trabajo desde hace bastante tiempo (la primera versión que hay en archive.org tiene una página que pone 1996, pero la verdad es que no recuerdo la fecha exacta, podría ser un poco antes).
Se puede ver en Fernando Tricas WWW Homepage.
Entonces no había sistemas de gestión de contenidos ni nada parecido y la manera en que hacíamos las páginas era copiando alguna que nos gustaba y poniendo nuestro contenido.
En algún momento empecé a gestionarla de la siguiente manera: mantenía una copia local donde editaba; cuando estaba satisfecho (o quería ver los cambios) copiaba los ficheros cambiados al servidor (con un programita que busca los ficheros que han sufrido cambios desde la última versión y scp).
El objetivo era doble: evitar editar en el servidor, y tener una copia de seguridad local (que se sumaría a la que nos hacen en el servidor).
En su momento (allá por el 2004) integré un blog con la página (esencialmente publico en la página los titulares de mi blog docente -por cierto, por si alguien le interesa lo mantengo con PyBlosxom-). La página web sigo usándola para información más permanente (aunque tengo compañeros que han dado el salto a blogs o wikis con páginas concretas dedicadas a eso mismo).
Evalué en algún momento manejar la página con un sistema de control de versiones (CVS era lo que se usaba entonces) pero no me decidí. Últimamente estoy re-pensando un poco algunos flujos de trabajo para tener un sistema mejor de copias de seguridad, con control de versiones. Además estoy trabajando bastante con git y he ido añadiendo partes de mi trabajo que están controladas con ese sistema, así que pensé que era el momento de mi página web.
Hice una búsqueda rápida en internet y encontré Using Git to manage a web site. Aunque hay alguna pequeña diferencia, me ha servido como guía.
Lo primero que quería hacer era pasar la copia local de mi ordenador de trabajo (que ya no está encendido tanto tiempo como solía) a otro que actúa como servidor para otras cosas y que siempre suele estar en marcha. Para ello, lo primero es crear un directorio:
En mi caso además hizo falta decirle a git dónde están algunos programas auxiliares de git en el servidor (seguramente esto no es necesario en muchos servidores):
Este paso era para tener la primera versión, que ya estaba en el servidor en la web. Ahora necesitamos un paso más, para que podamos automatizar un poco la subida de los ficheros cuando hagamos cambios. Para ello utilizamos un hook y la variable GIT_WORK_TREE que permite tener la parte de control en el directorio que hemos creado antes y los ficheros en otro directorio diferente: no me gustaba la idea de tener mezclada la parte del control de versiones con los ficheros de la web y esto soluciona ese problema.
O sea, copiamos esas dos líneas en el fichero post-receive y le damos permiso de ejecución.
La idea es que este programita se ejecuta cada vez que hacemos una petición push con los ficheros que hayan cambiado.
Si cambiamos algo, habrá que hacer el correspondiente commit, si añadimos ficheros o directorios habrá que utilizar las instrucciones correspondientes add y luego enviarlas al servidor:
ftricas@localServer:~/Documents$ git push www
Con versiones modernas de git puede ser necesario tener en cuenta que puede ser necesario fijar el comportamiento por defecto del push. Yo elegí:
A partir de este momento, cada vez que editamos en local la web y ya estamos satisfechos (o simplemente queremos subir algo al servidor web para ver cómo queda9 podemos hacer el commit correspondiente y después el push.
La web se irá actualizando, y tendremos las versiones controladas para el caso de que queramos recuperar la evolución de nuestra página web.
Seguimos con las tarjetas.
Ya hemos hablado alguna vez del estándar PCI pero no teníamos muchos datos sobre Europa. En Survey: Just 1 in 3 Euro biz slackers meets card security standards se habla de un informe de Verizon sobre el tema y Europa no sale bien parada. Como dicel titular sólo un tercio de los negocios europeos examinados cumplen el 80 por ciento o más de los requisitos de PCI Data Security Standard (DSS).
Se le echa la culpa a las diferentes regulaciones locales y también a las diferencias culturales.
En Why the US Doesn’t have Chip-and-PIN Credit Cards Yet nos recordaban que la seguridad no sólo se basa en tecnología o en recursos disponibles, sino que muchas veces se trata de una cuestión relacionada con los incentivos, amenazas, riesgos, costes…
Se habla del caso de la utilización de tarjetas con banda magnética en EEUU en lugar de las más modernas (y seguras) tarjetas con chip.
Y también los usos y costumbres de la gente. El ejemplo es Europa (territorios pequeños, con dificultades para perseguir a los defraudadores cuando cruzan la frontera) vs EEUU (un país grande, con ciudadanos que no salen tanto fuera) y las costumbres (y necesidades) de sus ciudadanos, las características de movimientos y viajes…
El principio del mínimo privilegio consiste esencialmente en conceder a las aplicaciones y usuarios los permisos necesarios para realizar las acciones que tengan que llevar a cabo, pero no más. Esto durante el tiempo necesario.
