Ya hacía tiempo que no hablábamos de aleatoriedad. En esta ocasión es Efficiently Generating a Number in a Range hablan de la eficiencia (que no podemos despreciar) a la hora de generar números aleatorios.

Se hace un análisis de los factores principales de coste,

But, perhaps surprisingly, the performance of your randomized algorithm may hinge not on the generation scheme you chose, but on other factors. In this post (inspired by and building on an excellent recent paper by Daniel Lemire), we’ll explore a common source of overhead in random number generation that frequently outweighs PRNG engine performance.

Aunque sabemos que la generación es costosa, no siempre es el principal motivo:

If your randomized algorithm isn’t running as fast as you’d like and the bottleneck seems to be generating random numbers, somewhat counterintuitively the problem might not be with your random number generator!

Luego siguen algunos métodos y medidas que probablemente solo interesarán a las personas con inclinaciones más técnicas. Aunque, cuidado, modificar este tipo de algoritmos y obtener el resultado deseado (aleatoriedad razonable) es algo que debe hacerse sólo cuando tenemos muy claro lo que tenemos entre manos.

Me gusta mucho leer buenas prácticas aplicadas a diversos cometidos: normalmente las propone gente que ha trabajado un tema, nos pueden servir de recordatorio y, a veces, aprendemos nuevas ideas o enfoques.

En este caso hablamos de 10 GitHub Security Best Practices y las prácticas son:

• Nunca almacenar credenciales en un repositorio (como código o en configuraciones).
• Eliminar datos delicados de nuestros ficheros y la historia del repositorio.
• Reforzar el control de acceso.
• Añadir un fichero SECURITY.md
• Validar las aplicaciones de forma cuidadosa.
• Añadir pruebas (tests) de seguridad.
• Seleccionar la forma adecuada de alojar el código.
• Rotar las claves SSH y los tokens de acceso.
• Crear nuevos proyectos teniendo en cuenta la seguridad.
• Auditar cualquier código que importemos a la plataforma.

Lo han publicado en forma de chuleta, en [PDF] Cheat Sheet: 10 GitHub Security Best Practices.

El mundo de la seguridad informática es inabarcable. Por su extensión, que se amplía continuamente, pero también por su duración: todavía podemos encontrar programas vulnerables con fallos que se conocen desde hace quinquenios. Luego, otras veces olvidamos que aunque nuestro lenguaje favorito no sufra esos problemas directamente, puede que los tenga por la vía de los lenguajes en los que se ha desarrollado la infraestructura subyacente (el propio compilador/intérprete, las bibliotecas, el sistema…).

Por eso nos viene bien leer (y recordarlos) en artículos como Funciones inseguras de un futuro pasado. Habla de las funciones peligrosas a vista de pájaro y sugiere la utilización de las herramientas actuales para detectar y evitar esos fallos.

Pero, seguramente, seguirán apareciendo.

No es el primer artículo que traemos aquí sobre el tema. En esta ocasión se trata de An Introduction to HTTP Response Headers for Security y se describen las cabeceras, sus valores típicos. Algunas nos ayudan a forzar determinados protocolos, otras a evitar ataques como los XSS, algunos aspectos del contenido, los referidos, …

También nos recomienda seguir de cerca el proyecto OWASP Secure Headers Project.

Ya pasó el tiempo en que alguien hacía un gran descubrimiento de seguridad y lo publicaba en algún sitio para ganar fama y notoriedad: aunque pasa de vez en cuando, lo habitual es comunicarlo al interesado para que lo resuelva y luego llevarse el crédito de alguna forma (fama, pero también cobros de los programas de detección de fallos que casi todas las empresas tienen), o ¡ay! tratar de obtener algún tipo de beneficio económico en el mercado negro de vulnerabilidades.

Con eso en mente, vale la pena echarle un ojo a Your TL;DR Summary of The CERT Guide to Coordinated Vulnerability Disclosure donde se comenta sobre la publicación del CERT [PDF] The CERT Guide to Coordinated Vulnerability Disclosure.

Son interesantes los principios: reducir el daño, asumir la benevolencia (del informante), evitar sorpresas, incentivar el comportamiento deseado, tener en cuenta las consideraciones éticas, mejorar el proceso y concentrarse en mejorar las cosas y no en alcanzar la ‘última verdad verdadera’.

Reduce Harm - (Balance) the ability for system defenders to take action while avoiding an increase in attacker advantage.

Presume Benevolence - Assume that any individual who has taken the time and effort to reach out to a vendor or a coordinator to report an issue is likely benevolent and sincerely wishes to reduce the risk posed by the vulnerability.

Avoid Surprise - Clearly communicating expectations across all parties involved in a CVD process.

Incentivize Desired Behavior - Incentives can take many forms…recognition, gifts, money, employment.

Ethical Considerations - The Usenix’ System Administrators’ Code of Ethics includes an ethical responsibility “to make decisions consistent with the safety, privacy, and well-being of my community and the public, and to disclose promptly factors that might pose unexamined risks or dangers.”

Process Improvement - Capture ideas that worked well and note failures. A successful CVD program feeds vulnerability information back into the vendor’s Software Development Lifecycle, (and) helps encourage the search for and reporting of vulnerabilities while minimizing harm to users.

CVD as a Wicked Problem - The goal of a solution is not to find an ultimate truth about the world, rather it is to improve conditions for those who inhabit it.

Interesante.