Estadísticas de Vulnerabilidad hasta 2017
Cómo es costumbre, cada año publico las estadísticas de vulnerabilidad del año anterior que fueron reportadas y registradas en la National Vulnerability Database (NVD), perteneciente al National Institute of Standrards and Technology (NIST). El NVD es un organismo no gubernamental de los EEUU. Estos datos son registrados y almacenados en una BDD de dominio público. Éste organismo informa cuatrimestralmente permitiendo la automatización de la gestión de seguridad. En ésta base de datos se registran fallas de software relacionados con la seguridad, errores de configuración, nombres de productos y métricas de impacto.
Respeto a la planilla (el link se encuentra al pie de la nota) que publico todos los años, ésta vez, le he incorporado nuevos datos que se pueden visualizar pasando con el mouse sobre algunos campos.
En la 1ra columna, pasando por sobre cada uno de los nombres de los motores, se puede visualizar cual fue su último release realizado. El dato lo presento desde lo informado en Wikipedia, dato que además he chequeado con sus sitios web los cuales coinciden, excepto para los de IBM, DB2 e Informix, sitios de Wikipedia que se encuentran desactualizados. Por ejemplo para Informix figura:
Wikipedia último release: 12.10.xC7 / Junio 15, 2016
cuando sabemos que el último release corresponde a 12.10.XC10 / Diciembre 5, 2017
Pienso que es importante saber esa información al momento de evaluar los defectos del último año y comparar los motores, ya que se contrasta con el ciclo de vida de cada iteración o sprint. No es lo mismo los releases por defectos de vulnerabilidad, los cuales van reportados cada cuarto, que aquellos releases que si bien corrigen defectos en el software, la mayoría no son de vulnerabilidad, y además incorporan nuevas funcionalidades. Si tomamos el año 2017, y analizamos los motores que tuvieron mayor cantidad de defectos de vulnerabilidad, veremos que hicieron una gran cantidad de releases entre Enero 2017 y Enero 2018: MySQL (4), PostgreSQL (5) y DB2 (4), mientras que Informix (2) y SQLServer (3).
En el caso de Oracle, que no se encuentra en ninguno de los extremos, se nota que ha mejorado muchísimo en los últimos años la calidad del software en su ciclo de vida. Si bien libera versiones "base" con poca frecuencia, no deja de lanzar fix patches 4 veces al año.
Otro dato que agregué en la planilla fue el de destacar al 1er y 2do puesto ganadores en cada año. Se puede apreciar a lo largo de los años que si bien en el 2017, SQLServer obtuvo el 1er puesto con un defecto, Informix cae en el 2do puesto con tan solo dos defectos. Luego, si recorremos todos los años subsiguientes a 2017, Informix si no está en 1er lugar, está en el 2do (con excepción de los únicos dos años 2006 y 2004 donde estuvo en el 4to y 3er puesto respectivamente). Incluso en las generales desde el 2004, es el único que se ha mantenido estable sin picos y por debajo de los 10 defectos siempre!, siendo justamente su peor año el 2006 con 9 defectos.
Un último dato que también me pareció interesante comenzar a mostrar en la planilla fue el de la catalogación del defecto en términos de severidad del defecto entre los ganadores del 1er y 2do puesto. Las URLs incluidas como comentarios en los dos primeros puestos, les permitirán acceder al detalle de cada uno de los CVE directamente.
La importancia de destacar este dato es porque en 2017, si bien SQL Server obtuvo el 1er puesto, la calificación del defecto está calificado como "V3: 7.5 ALTO", mientras que los de Informix, quedando en 2do puesto, están calificados como "V3: 6.7 y 6.5 MEDIUM". Entonces es importante contrastar no solamente la cantidad, sino también la severidad entre los ganadores. Este dato se lo agregué solamente a partir del año 2017, como un comentario en cada casilla donde se encuentra la cantidad de defectos. Para las empresas que reciban los boletines de vulnerabilidad, no es lo mismo recibir un defecto ALTO que MEDIO. Según su actividad, sus políticas de seguridad pueden llegar a ser rigurosas, e indicar que haya riesgo o no dependerá de la calificación del defecto.
La calificación del defecto según la política de seguridad definida por consiguiente determinará que haya que patchear el software de manera urgente o no.
Miremos entonces a los dos peores para 2017, justo caen los motores libres de licencias. A continuación, y en ese mismo sentido, de peor a mejor, siguen DB2 y Oracle. Nuevamente aquí si comparamos las calificaciones entre éstos dos últimos motores, Oracle tiene entre los 8 registrados, 4 defectos calificados como "V3: 9.8 CRITICAL" y 2 como "V3: 8.2 y 7.5 HIGH", mientras que Informix tiene los dos únicos defectos calificados como MEDIUM, los cuales detallé más arriba.
Que significa entonces el tema de defectos en el software para empresas a las cuáles les interese la seguridad y deban cumplir con estándares más o menos estrictos?
Simplemente tener más o menos trabajo de soporte dedicado a salvar problemas de vulnerabilidad. Seguramente en empresas interesadas en la seguridad, también incluyan procesos de patcheo y upgrade complejos, imaginémonos entonces la dedicación que nos requerirá un motor que recibe los boletines cuatrimestrales plagados de defectos de vulnerabilidad cada cuarto en el año!!!
El tema entonces es el tiempo que nos llevará preparar los patcheos de manera ordenada y segura, que incluyen el plan de testeo en por lo menos dos entornos previos a producción. En desarrollo testear que sea posible y sin errores ir hacia adelante y hacia atrás, luego en el entorno de QA o Test, que las aplicaciones funcionen correctamente, y por último y según el motor y el negocio, evaluar el costo de interrupción del procesamiento en producción (downtime). En empresas ordenadas, donde existen administración de configuración, administración de control de cambios y administración de control de releases, ayudaría a planificar y organizar las tareas relacionadas con el versionado y pruebas de regresión de las aplicaciones, pero lleva tiempo!. Por otro lado, tendremos la exigencia de probar con una BDD actualizada, tanto en el ambiente de desarrollo como en el de QA, tareas no menores que habrá que coordinar con otros grupos. Para tal efecto, el hecho de tener que refrescar las BDD en dichos entornos en empresas donde se deba cumplir con estándares de seguridad de PCI/PII, al refrescar desde producción, se deberán de enmascarar los datos sensibles.
Ni hablar de aquellos defectos que exigen un upgrade del sistema operativo!. Si bien no son frecuentes, y por lo general no están atados a los fix patches, de todos modos cuando hay cambios por arreglos en el software, estos pueden llegar a exigir cambios a nivel del sistema operativo.
En fin, si se toma cada patcheo seriamente, es decir que se quiera reducir cualquier potencial problema en producción, se deberá seguir un muy largo camino. Todo ese tiempo que nos insumirá preparar y organizar el patcheo, es altamente considerable, tiempo que nos quitará para dedicarnos a temas importantes que se podrían aplicar para desarrollo y crecimiento.
Valga entonces hacer un ejercicio. Tomando los datos actuales para el 2017, de los motores incluidos en la planilla, y en el supuesto caso donde la política de seguridad definida en la empresa indicara que se deben patchear inmediatamente (esto es antes de que arribe el siguiente boletín de vulnerabilidad) aquellos motores donde sus defectos de vulnerabilidad estén calificados por encima de MEDIUM, Informix sería el único motor que no calificaría como tal, ya que sus dos defectos están calificados como MEDIUM.
Entonces no es lo mismo tener que planificar obligadamente un patcheo por cuarto en el año, que planificar un patcheo cuando se encuentre útil incorporar alguna funcionalidad nueva. Por lo general se trata de mantener una versión estable por al menos un año o dos, para permitirnos elaborar una línea base, colectar estadísticas, analizar performance, etc.. De ésta manera solo realizaremos upgrades para evitar la obsolescencia, o no caer fuera de soporte. Es lo que en general sucede con Informix, al tener tan pocos defectos de vulnerabilidad.
Se dice que el tiempo vale oro... entonces es Informix un gasto o una inversión?
Planilla de Estadísticas de Defectos de Vulnerabilidad
-----------------------------------------------------------------
[English version]
As I use to do every year, I publish the vulnerability defects statistics for the last year since 2004, based on the reported and registered data in the National Vulnerability Database (NVD).
The NVD is a non-governmental organization in the United States, that belongs to the National Institute of Standards and Technology (NIST). This data is recorded and stored in a public domain database. This organism reports quarterly allowing the automation of security management. In this database are stored software failures related to security configuration errors, product names and impact metrics.
Regarding the spreadhseet I publish every year, this time, I have included more information that can be visualized hovering the mouse over some fields.
In the 1st column, passing over each of the engine names, you can see when was its last release made. The data I present here was taken from Wikipedia, the one I have also cross-checked with the one on their websites. They match, except for IBM DB2 and Informix, their Wikipedia sites are outdated. For example for Informix:
Wikipedia latest release: 12.10.xC7 / June 15, 2016
Whilst we know that the latest release corresponds to 12.10.XC10 / December 5, 2017
I think it is important to know this information at the time to evaluate the defects of the last year when comparing the engines, as it is contrasted with the life cycle of each iteration or sprint. It is not the same a release for vulnerability defects, which is reported every quarter, than the release that although includes software defects corrections, most of them are not linked to vulnerabilities defects, but to a cycle release to deliver new features. If we analyze the engines that had the most vulnerability defects last year, we will see that they made lots of releases between January 2017 and January 2018: MySQL (4), PostgreSQL (5) and DB2 (4), while Informix (2) and SQLServer (3).
In the case of Oracle, which is not found in any of the categories, we can see that the software quality assurance in its life cycle process has drastically improved in the latest years. Although it releases "base" versions infrequently, it does not stop from releasing fix patches 4 times a year.
Another information that I have added to the spreadhseet is to highlight the 1st and 2nd place winners in the year. It can be observed over the years that in 2017, SQLServer obtained the 1st place with just one defect, whilst Informix falls in the 2nd place with two. Then, if we go back through the years before 2017, Informix if it is not in 1st place, but in the 2nd place (with the exception of the only two years 2006 and 2004 where it was in the 4th and 3rd place respectively). Even in general since 2004, is the only one that has remained stable without peaks and below the 10 defects always!, being 2006 its worst year with 9 defects.
One last information that I have also found interesting to start showing in the spreadsheet, is the cataloging of the defect in terms of the severity of the defect between the winners of the 1st and 2nd place. The URLs are included as comments in the first two positions, these will drive you directly to the CVE details.
The importance of highlighting this information is because in 2017, although SQL Server obtained the 1st place, the rating of the defect is qualified as "V3: 7.5 HIGH", while those for Informix in 2nd place, are qualified as "V3 : 6.7 and 6.5 MEDIUM". So it is important to contrast not only the quantity, but also the severity between the winners. I have added this last information starting from 2017 on, as a comment to the grid where the figure of the defect is found. For companies subscribed to receive vulnerability bulletins every quarter, it is not the same to receive a HIGH than a MEDIUM rated defect. According to its activity, the security policy can be rigorous, and determining whether there is risk or not, will depend on the qualification of the defect. The qualification of the defect according to the defined security policy will therefore determine that the software must be patched urgently or not. Let's look at the two worst ones in 2017, theses correspond to the free of licenses engines. Then, going in that same direction, from worst to best, come DB2 and Oracle. Again here if we compare the ratings between these two engines, Oracle has among the 8 registered, 4 defects rated as "V3: 9.8 CRITICAL" and 2 as "V3: 8.2 and 7.5 HIGH", whilst Informix has the two defects rated as MEDIUM, as I detailed above.
What does then the issue of software defects mean, for companies that are interested in security and must comply with more or less strict standards?
Simply having more or less support work dedicated to sorting vulnerability problems. Surely in companies interested in security, include complex patching and upgrading processes as well. Imagine then the dedication that would require an engine that receives these bulletins plagued by vulnerability defects every quarter of the year!
The issue then is the time it would require to prepare the patches using a safe procedure, which includes the testing plan in at least two environments prior to production. In development, ensuring that it is possible and without errors to rollback the patching, then in the QA or Test environment, the regression application test, and finally and according to the engine capabilities and the business, evaluate the downtime impact in Production. In orderly companies, where there is configuration management, change control management and release control management, would be easier to plan and organize the tasks related to the release versioning and the application regression test, despite that, it takes a precious amount of time anyway to organize everything!. On top of everything, we don't have to forget that we will have the requirement to test with fresh data, most of all in the QA environment, and if possible in DEV as well. For this purpose, the fact of having to refresh the BDD from Production, in companies that are to comply with the security PCI/PII standards, an additional task is required, sensitive data needs to be masked.
Not to mention those patches that require an upgrade of the operating system!. Very likely they are not required, and usually are not tied to fix patches, anyway when there are changes to software fixes, these might require changes at the operating system level as well.
In short, if you take each patching seriously, this is… that you want to reduce any potential problem in production, you must follow a very long way. The time it will take from us to prepare and organize the patching, is highly considerable, it is the time we will spend fixing security flaws, instead of dedicating it to important matters that could be used for development and growth.
Ok then, let's do an exercise. Taking the current data for 2017, from the engines included in the spreadsheet, and in the supposed case where the security policy defined in the company indicates that should be patched immediately (this is before the next vulnerability bulletin arrives) those engines where their vulnerability defects are qualified above MEDIUM, Informix would be the only engine that does not qualify as such, since its two defects are qualified as MEDIUM.
So it is not the same to compulsively have to plan patching every quarter in the year, than to plan patching when it is useful to incorporate some new functionalities. Usually it is about maintaining a stable version for at least a year or two, enough time to allow us to elaborate a good baseline, collect statistics, analyze performance, etc. In this way we will only perform upgrades to avoid obsolescence, or not to fall outside support. It is what happens in general with Informix, having so few vulnerability flaws.
It is said that time is worth gold ... is Informix an expense or an investment?