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.

Creo que hay poca duda sobre lo que compramos hoy en día. Un coche es un ordenador con ruedas y motor. Un frigorífico es un ordenador con una caja cerrada fría y una televisión es un ordenador con una pantalla un poco especial, más grande que las que tienen normalmente los ordenadores. Algunos nos quejaríamos de que sean ordenadores poco potentes, y poco accesibles, pero es lo que hay.

En This Car Runs on Code nos lo recordaban ya desde el título y del párrafo introductorio, donde dice eso de que hacen falta docenas de microprocesadores ejecutando millones de líneas de código para sacar un coche de gama alta a la carretera:

It takes dozens of microprocessors running 100 million lines of code to get a premium car out of the driveway, and this software is only going to get more complex

Además del mensaje tan pontente que nos transmite eso, este artículo me gustó por otras cifras, por ejemplo las relacionadas con diversos ‘aparatos’.

El F-22, F-35, un Boeing 787…

The avionics system in the F-22 Raptor, the current U.S. Air Force frontline jet fighter, consists of about 1.7 million lines of software code. The F-35 Joint Strike Fighter, scheduled to become operational in 2010, will require about 5.7 million lines of code to operate its onboard systems. And Boeing’s new 787 Dreamliner, scheduled to be delivered to customers in 2010, requires about 6.5 million lines of software code to operate its avionics and onboard support systems.

Pero también, algo tan ‘simple’ como el sistema de radio y navegación de un Mercedes clase S:

Alfred Katzenbach, the director of information technology management at Daimler, has reportedly said that the radio and navigation system in the current S-class Mercedes-Benz requires over 20 million lines of code alone …

No sólo eso, claro, sino que se trata de sistemas que deben seguir funcionando en condiciones de poco confort:

… have to be able to operate for years in temperatures ranging from the dead of a freezing Minnesota winter to the blazing heat of an Arizona summer sun.

Respecto, al coste, casi una tercera parte viene de estos sistemas en los coches de gama alta:

For today’s premium cars, ”the cost of software and electronics can reach 35 to 40 percent of the cost of a car,” states Broy, with software development contributing about 13 to 15 percent of that cost.

Y luego, vienen los problemas: fallos de software:

IBM claims that approximately 50 percent of car warranty costs are now related to electronics and their embedded software, costing automakers in the United States around $350 and European automakers 250 per vehicle in 2005.

Dificultad para reparar:

The increased use of software has not only affected car warranty costs but has also made cars harder to repair—so much so that insurance companies increasingly find it cheaper to declare cars damaged in accidents total losses than it is to fix them.

Interesante. Y numerológico.