Definición de una vulnerabilidad de seguridad

19/02/2014

Tiempo de lectura: 7 minutos

¿Qué es una vulnerabilidad de seguridad? Esta es una pregunta que a priori parece fácil de responder, pero en realidad no lo es. En este artículo se trata la definición que utiliza el Centro de respuestas de seguridad de Microsoft (MSRC) para categorizar las diferentes incidencias que examinamos cada día.

De primeras podría parecer que no merece la pena dedicar varias páginas a debatir el significado del término. A fin de cuentas, bastaría con buscar "seguridad" y "vulnerabilidad" en un diccionario para hacernos una idea razonable de lo que quiere decir. Si optáramos por esta opción, podríamos concluir que una vulnerabilidad de seguridad es cualquier circunstancia que ofrezca una potencial vía de ataque contra un sistema. Aquí entrarían, por ejemplo, un malware, un sistema configurado incorrectamente, una contraseña escrita en una nota autoadhesiva, etc. Es cierto que este tipo de elementos efectivamente incrementan el riesgo para un sistema. Sin embargo, esta es una connotación algo más amplia respecto a lo que se suele usar dentro de la comunidad de la seguridad y los aspectos que evaluamos en el MSRC.

En el contexto del sector de la seguridad de software y en el MSRC, una vulnerabilidad es una exposición de la seguridad ocasionada por un punto débil del producto introducido involuntariamente por el desarrollador que debe corregirse una vez detectado. El término adquiere así una especial pertinencia para el MSRC, habida cuenta de que su trabajo consiste en detectar estos puntos débiles en cualquier producto de Microsoft y darles solución. Esta definición ayuda a identificar problemas que pueden y deben solucionarse. Con este artículo entenderá mejor cuáles son los tipos de problema que suelen abordarse en los boletines de seguridad.

Contextualización de la definición

Es importante entender que la definición no es la última palabra sobre si un problema justifica un boletín de seguridad. Más bien, se trataría solo del comienzo. Cada vez que el MSRC recibe una notificación de un posible problema de seguridad, se desencadena una investigación. En caso de que se pueda reproducir el problema, se plantean las dos siguientes preguntas para determinar si se necesita un boletín.

¿El problema responde a la definición de vulnerabilidad de seguridad?

¿Infringe la directiva de seguridad del producto? Es decir, ¿supera el "límite de seguridad" del producto?

Piense en la definición de vulnerabilidad de seguridad como un filtro inicial que se aplica a todos los problemas. Si un problema de seguridad determinado no responde a la definición de una vulnerabilidad de seguridad, es poco probable que justifique un boletín de seguridad. Sin embargo, esto no quiere decir que no se vayan a tomar medidas. Por ejemplo, si se demuestra con una investigación que existe un error pero no una vulnerabilidad de seguridad, MSRC trabaja con el equipo del producto para darle solución, pero la corrección se incluirá en un Service Pack o una versión posterior del producto, y no en una actualización de seguridad y un boletín.

Si el problema responde a la definición de vulnerabilidad, la siguiente pregunta que cabe hacerse es si infringe los límites de seguridad del producto. Todo producto incluye unas suposiciones sobre el modo en que se utilizará, así como unas promesas sobre la seguridad que ofrece siempre y cuando se utilice correctamente. Por ejemplo, el Control de acceso de usuarios (UAC) es una tecnología introducida con Windows Vista que brinda un método para separar los privilegios y tareas de un usuario estándar de aquellas que requieren acceso de administrador. Si el usuario estándar está utilizando el sistema y trata de realizar una acción para la que no está autorizado, aparecerá un aviso de Windows solicitando la contraseña de la cuenta Administrador. Si un administrador está utilizando el sistema y trata de realizar la misma tarea, solo aparecerá una advertencia. Esta solicitud se conoce como "petición de consentimiento" porque al administrador solo se le pide conformidad con la acción antes de continuar. Un punto débil que permitiera omitir la "petición de consentimiento" no se considera una vulnerabilidad de seguridad, ya que no se considera un límite para la seguridad.

La letra pequeña

Un último aspecto antes de entrar en la definición de vulnerabilidad: esta no pretende servir de documento legal. Su conceptualización tiene por objeto principal hacerla sencilla y comprensible, incluso si con este proceso algunos puntos quedan en el terreno de los grises. Es por ello que incluimos aquí una declinación de responsabilidades.

La definición no es una garantía; es una herramienta que ayuda a evaluar si el MSRC debe abordar un problema a través de una actualización de seguridad. Al final, la decisión sobre qué temas justifican los boletines es una cuestión subjetiva que se basa en todo caso en ofrecer a nuestros clientes la mejor protección que podamos. A veces, se desarrollan boletines que, en sentido estricto, quedan fuera de la definición. Del mismo modo, puede ocurrir que un problema en particular responda a la definición estricta pero solo ocurra en condiciones tan raras que brindaríamos un mejor servicio a nuestros clientes centrando nuestros recursos en problemas más frecuentes y con mayor repercusión.

La definición no es un estándar corporativo de Microsoft. Es una definición informal que utiliza el MSRC para clasificar el trabajo por orden de prioridad. No es un requisito del logotipo ni forma parte de ninguna otra norma corporativa.

Definición

Una vulnerabilidad de seguridad es un punto débil de un producto que podría permitir a un atacante poner en riesgo la integridad, la disponibilidad o la confidencialidad de ese producto.

Ahora diseccionemos exactamente lo que significa la definición. En los próximos párrafos se toman de la definición sus palabras y pasajes más pertinentes, se definen con precisión y se explican con ejemplos de aplicación a casos de la vida real.

...un punto débil de un producto...

Punto débil: las vulnerabilidades de seguridad implican puntos débiles que pasan inadvertidos. A veces puede haber puntos débiles en el diseño de un producto, pero estos no se consideran vulnerabilidades de seguridad.

Ejemplos: la elección de implementar un cifrado de 40 bits en un producto no constituiría una vulnerabilidad de seguridad, aunque la protección que proporciona sería inadecuada para algunos fines. En contraste, un error de implementación que provocara que un cifrado de 256 bits descartase la mitad de los bits de la clave sí sería una vulnerabilidad de seguridad.

Producto: las vulnerabilidades de seguridad son consecuencia de un problema en un producto. Los problemas que surgen al seguir estándares imperfectos pero ampliamente aceptados no son vulnerabilidades de seguridad.

Ejemplos: no se consideraría una vulnerabilidad de seguridad un explorador que, al conectarse a un sitio FTP, desarrollase la sesión en texto sin formato, ya que la especificación de FTP requiere sesiones de texto sin formato. Sin embargo, si el explorador desarrollase sesiones SSL en texto sin formato, esto sí constituiría una vulnerabilidad de seguridad, ya que la especificación de SSL requiere sesiones cifradas.

...que podría permitir a un atacante poner en riesgo la integridad...

Integridad: la integridad se refiere a la confiabilidad de un recurso. Un atacante que explote un punto débil de un producto para modificarlo de forma silenciosa y sin autorización está poniendo en riesgo la integridad de ese producto.

Ejemplos: un punto débil que permita a un administrador cambiar los permisos en cualquier archivo de un sistema no sería una vulnerabilidad de seguridad, puesto que un administrador ya tiene esta capacidad. Por el contrario, si una debilidad permitiera que un usuario sin privilegios hiciera lo mismo, estaríamos ante una vulnerabilidad de seguridad.

...disponibilidad...

Disponibilidad: la disponibilidad se refiere a la posibilidad de acceder a un recurso. Un atacante que explote un punto débil de un producto, denegando el acceso a un usuario apropiado, está poniendo en riesgo la disponibilidad de ese producto.

Ejemplos: un punto débil que permita a un atacante provocar el error de un servidor constituiría una vulnerabilidad de seguridad, puesto que el atacante podría regular si el servidor presta servicio o no. Sin embargo, un atacante que enviase un número ingente de solicitudes legítimas a un servidor y monopolizase sus recursos no constituiría una vulnerabilidad de seguridad, ya que el operador del servidor mantendría el control del equipo.

...confidencialidad…

Confidencialidad: la confidencialidad se refiere a limitar el acceso a la información de un recurso a las personas autorizadas. Un atacante que explote un punto débil de un producto para acceder a información no pública está poniendo en riesgo la confidencialidad de ese producto.

Ejemplos: un punto débil de un sitio web que permita a un visitante leer un archivo que no debería leer constituiría una vulnerabilidad de seguridad. Sin embargo, un punto débil que revelara la ubicación física de un archivo no constituiría una vulnerabilidad. Aunque tal punto débil pudiera ser útil para fines de reconocimiento y se pudiera usar junto con una vulnerabilidad de buena fe para poner en riesgo los archivos, no permitiría por sí mismo que un atacante pusiera en riesgo los datos y, por lo tanto, no constituiría una vulnerabilidad de seguridad. (Sin embargo, cabe mencionar que Microsoft, en ocasiones, ha optado por desarrollar parches en tales casos de todos modos).

Como puede ver, la integridad, la disponibilidad y la confidencialidad son los tres principales objetivos para la seguridad. Si falta alguno (o varios) de estos tres elementos, existe una vulnerabilidad de seguridad. Una sola vulnerabilidad de seguridad puede poner en riesgo uno de estos elementos o todos ellos a la vez. Por ejemplo, una vulnerabilidad de divulgación de información podría poner en riesgo la confidencialidad de un producto, mientras que una vulnerabilidad de ejecución de código remoto pondría en riesgo su integridad, disponibilidad y confidencialidad.

Definición en práctica

Como sin duda habrá notado, queda bastante espacio para el juicio en la definición. Además del sentido común y el deseo de proteger a nuestros clientes, evaluamos las vulnerabilidades potenciales recurriendo a nuestra extensa trayectoria práctica en la toma de decisiones respecto de la seguridad, y basta con echar un vistazo rápido a la lista de boletines de seguridad para constatar que se aplica una interpretación bastante amplia de la definición. Si cree que podría haber encontrado una vulnerabilidad de seguridad en un producto de Microsoft, póngalo en conocimiento del Centro de respuestas de seguridad de Microsoft para que se investigue de inmediato. Recibirá una respuesta en la que se le indicará si responde a la definición de vulnerabilidad de seguridad.