En So you want to work in security (but are too lazy to read Parisa’s excellent essay) algunas ideas interesantes si pensamos que trabajar en ciberseguridad podría ser una opción para nosotros.

1. Ciberseguridad tiene que ver con la discordancia entre el comportamiento real del sistema y lo que esperaban que fuera el comportamiento sus diseñadores.
2. Se trata de una protociencia. Mucha información, que todavía no tenemos bien organizada y en la que algo puede fallar donde menos se espera.
3. La gente podrá confiar en nosotros, pero no hay forma de medir la efectividad de lo que hagamos.
4. Puede que creas que eres más listo que los desarrolladores de software, pero no es así.

Es bien conocida la frase de Groucho Marx: ‘Estos son mis principios. Si no le gustan… tengo otros’. Sin embargo, los principios tiene su interés y utilidad como conceptos o valores que nos guían en el comportamiento: cuando nos enfrentamos a una nueva situación o nos movemos en terreno incierto, los principios nos pueden ayudar a tomar decisiones.

En ese sentido traemos hoy aquí The Security Principles of Saltzer and Schroeder que presentaron sus principios sobre protección de la información en sistemas informáticos. Serían:

• Economía en el mecanismo (tan simple y pequeño como sea posible).
• Fallo en modo seguro por defecto (si algo va mal, el sistema queda en un estado seguro).
• Mediación completa (para cada acceso a un objeto del sistema se debe comprobar la autorización).
• Mínimo privilegio (Cada agente debe tener los permisos necesarios para realizar su tarea, pero no más).
• Mínimo mecanismo común (no compartir estado entre diferentes agentes. Si alguien puede corromperlo, podrá influir en el comportamiento de los que dependan de él).
• Separación de privilegios (separar las acciones de manera que cada una tenga permiso para realizar la parte que sea necesaria para su actividad; evitar hacer una única pieza que tiene permiso para realizar las distintas tareas).
• Diseño abierto (el diseño no debería ser secreto o, al menos, su seguridad no debería depender de la ignorancia de los atacantes sobre sus internalidades).
• Psicológicamente aceptable (si las reglas no son razonables, será difícil que sean aceptadas y seguidas con cierto rigor).

El autor juega con los principios y la saga de ‘Star Wars’ así que puede valer la pena echarle un vistazo, más allá de los principios.

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.