jueves, 3 de enero de 2019

Cuándo hacer pública una incidencia de seguridad

Esto es un tema importante y que muchas veces no se explica y es tan o más importante que encontrar fallos de seguridad. Y es que cuando encontramos un fallo de seguridad, es muy importante dar un tiempo a la organización hasta hacer público el fallo de seguridad.


Cuando vamos a hacer público un incidente de seguridad, tenemos que dar tiempo a la organización para que lo solucione. Primer se lo tendríamos que reportar a ellos y posteriormente esperar a ver qué hacen. Si lo solucionan, guay, lo hacemos público y listo. Pero si no lo solucionan, dar un tiempo y publicarlo puede ser una buena manera de meter presión.

Y ahí el kit de la cuestión ¿Cuánto tiempo esperar? Eso es lo que vamos a ver.

Lo primero que tenemos que hacer es pensar en la gravedad del fallo y si es fácil o no solucionarlo. Este es el primer paso.Dependiendo de eso, no estaría mal preguntar a la misma empresa qué procedimientos utilizan para solucionar problemas como estos. Yo os voy a hablar de lo que yo utilizo en mi trabajo.

Yo utilizo ServiceNow. ServiceNow es un servicio en la nube que permite a empresas gestionar incidentes y procedimientos para realizar cambios en los servidores. Por ejemplo, si queremos ampliar el espacio de LVM, podríamos lanzar una cosa que es una Change Request.

Las Change Requests tienen varias partes, una es que tienes que especificar si es de Prod o no. Después seleccionas la plantilla, y cada plantilla viene con un Lead Time concreto.


El Lead Time es el tiempo que tiene un equipo para que esa Change Request (CHG o CR) llegue a "Implement State". Por ejemplo, una plantilla o Template  puede tener un Lead Time de 3 días. Eso quiere decir que antes de ese día tiene que estar en Implement. 

Ojo, que si queremos que se implemente el día, por ejemplo 10 de enero, la persona que tiene que hacer que pase de "Scheduled" a "Implement",  como máximo, tiene hasta el día 7. 

Esto que parece fácil no lo es siempre, ya que se hace esto porque se añaden a varios equipos para que analicen la CHG y los pasos que el Change Initiator ha especificado. Se hace esto para cerciorarnos de que todo es correcto y comprobar si hay errores.

Así pues, si descubrimos un fallo hoy día 3 de enero y se lo reportamos al equipo de la organización, podríamos preguntarle por el Lead Time de la CHG que harán el raise y así saber cuándo lo podríamos publicar. Puede que nos lo digan o no, pero si sabemos que se lo hemos reportado el día 3, que es jueves, estarán todo el jueves pensando cómo hacerlo y el viernes posiblemente elaboren la CHG, pero claro, si el Lead Time es de 3 días y no trabajan ni sábados ni domingos, sabemos que el día 9 ó 10 pueden ser precipitados para que se haga el implement del fix por el tema del Lead Time. Y eso como muy pronto.

Así que tendríamos que esperar hasta el 14 mínimo como muy pronto. Es decir, que como mínimo tendríamos que esperar 11 días para poder publicarlo ( a menos que esa CHG la cataloguen como Emergency CHG y se haga en el mismo día, que también puede pasar si el fallo de seguridad es gordo, pero ya digo que siempre se prefiere esperar y realizar un fix correcto).

Yo, por lo general, suelo tratar de tener posts programados para 14 días y así, si descubro un fallo hoy, se que lo puedo publicar en el mismo día pero dejarlo programado sin problema. Pero os hacéis una idea del por qué cuando se publica un fallo de seguridad decimos eso de "se conoce desde el día X" y ese día X puede ser 1 mes perfectamente. No porque nos lo guardemos, no, simplemente para dar tiempo a las empresas, porque esa es otra, si el fallo es a una empresa solamente vale, pero si es a varias, esos 11 días son pocos, muy pocos.

¿Hackeamos el Mundo?

No hay comentarios:

Publicar un comentario

Related Posts Plugin for WordPress, Blogger...

Entrada destacada

El server me sabe a poco.

Soy un fanático del Rock y de Debian . (Creo que voy a inventar Rockbian, que suena bien y todo xD) Llevaba tiempo queriendo unir estos 2 c...