Steve Christey, ingeniero jefe de seguridad informática de Mitre, y Chris Wysopal, director de investigación y desarrollo de la firma de seguridad digital @Stake, han enviado al IETF (Internet Engineering Task Force) una propuesta en la que se perfilan las formas estándares en que los fabricantes e investigadores deben divulgar los fallos de seguridad.
Según estos expertos, es necesario fijar una normativa para codificar las reglas no escritas que sólo conoce la comunidad de expertos en seguridad, por las que se divulgan los fallos, de forma que toda la industria conozca y comprenda dichas normas. Christey y Wysopal están ahora a la espera de comentarios a su propuesta, denominada Responsible Vulnerability Disclosure Process (Proceso responsable de divulgación de vulnerabilidades).
Actualmente no hay acuerdo en cuanto a la forma en que se deben dar a conocer las vulnerabilidades del software. Fabricantes y expertos de seguridad tienen a menudo políticas opuestas al respecto: los fabricantes dicen que se les debe dar tiempo suficiente para arreglar un fallo antes de que sea desvelado, para no alertar a los hackers del fallo; los investigadores quieren que los usuarios tengan la información lo antes posible para presionar a los fabricantes en el desarrollo del correspondiente parche.
La propuesta de Christey y Wysopal exige que, cuando alguien descubra un fallo e informe sobre él, siga una política de “divulgación responsable” que ayude a los fabricantes a eliminar las vulnerabilidades, minimice el riesgo para los usuarios y proporcione a la comunidad de seguridad las herramientas necesarias para identificar los fallos y gestionar la respuesta del fabricante.
Esto significa que, cuando un investigador descubra un fallo, informe al fabricante o a un tercero “fiable” que coordine esta comunicación (generalmente, un miembro de la comunidad de expertos en seguridad). El fabricante, por su parte, debe responder a la notificación en un plazo de siete días. En caso de que la respuesta a la notificación sea automática, debe indicar una fecha -no más de 10 días después- en la que responderá con más destalles a la notificación. Además, el fabricante debe actualizar al investigador cada siete días sobre los avances en el problema y tratar de resolverlo en un plazo de 30 días.
Según la consultora Aberdeen Group, este estándar es necesario, aunque quizá el IETF no sea el mejor lugar al que enviar la propuesta, debido a la lentitud de aprobación que sufren los estándares sometidos a procesos burocráticos.
www.ietf.org 
