Las voces que se alzaron recientemente contra Oracle empiezan a tambalearse. Y si no, véase lo que le ha pasado a Argeniss, que muy recientemente anunció una iniciativa a bombo y platillo, en la que planeaban imitar el Month of Browser Bugs y el Month of Kernel Bugs.
Finalmente, rebajaron sus pretensiones mensuales para plantear la semana de los bugs de Oracle (se ve que el mes les venía grande). Pues al final, ni eso: No habrá The Week of Oracle Database Bugs. Lo más gracioso es leer en su texto original:
Why not the Month of Oracle Database Bugs?
We could do the Year of Oracle Database Bugs but we think a week is enough to show how flawed Oracle software is, also we don’t want to give away all our 0days:), anyways if you want to contribute send your Oracle 0days so this can be extended for another week or more.
Yo no sé vosotros, pero al leer eso creo que la razón para que se cancele la semana de Oracle no es otra que la incapacidad para generar ni un sólo 0day para Oracle. Y es que abrir la boca es fácil, pero mantenerla abierta, cuesta más trabajo. Quizás otros investigadores sí sean capaces de hacerlo, pero éstos han pinchando en su primera tentativa.
Sobre las críticas a Oracle que se están viendo últimamente, y me refiero especialmente al informe de David Litchfield, yo tengo mi punto de vista al respecto, y ayer lo dejaba entrever en los comentarios que intercambiaba con Sergio de los Santos, donde comento que medir la seguridad de un producto exclusivamente por el número de vulnerabilidades es muchas veces irreal, especialmente cuando el producto analizado requiere de un deployment medianamente serio, más allá de una instalación rápida como la que podemos hacer para cualquier aplicación doméstica.
Admito que el número de vulnerabilidades es un rasero adecuado si pretendemos comparar la seguridad de dos aplicativos que están listos para ser usados tal y como los entrega el fabricante. Ese estado de entrega es el estado de arranque para la seguridad, ya que usaremos el producto nada más abrir la caja e instalarlo.
Pero ese razonamiento hace aguas cuando el producto requiere un proceso de implementación multivariable, en el que se transforman las cualidades del producto que sale de la caja, ya que la personalización mitiga muchas veces riesgos y vulnerabilidades. Es el caso de Oracle, es el caso de SQL Server, es el caso de Sybase, es el caso de DB2, y en general, es el caso de los motores que están pensados para ser desplegados tras un proceso consultivo y de adecuación a las necesidades del despliegue.
Os pongo un ejemplo. Según el estudio de Litchfield, Oracle es menos seguro porque sufre más vulnerabilidades que SQL Server. La pregunta que me hago yo es muy sencilla. ¿Qué pasa si ese Oracle no está expuesto a tráfico remoto? ¿Qué pasa si ese Oracle está encapsulado en una red aislada de producción que en ningún caso tiene trato directo ni con el exterior, ni tan siquiera con los usuarios de esa red interna? ¿Qué pasa si tengo una versión de Oracle con 200 vulnerabilidades pero NINGUNA puede ser explotada porque los únicos usuarios que pueden tocar la BBDD son operadores y administradores sujetos a normativa de seguridad corporativa y/o a directiva de auditoría del propio motor de la BBDD? El ejemplo me vale para cualquier gestor profesional de los que he citado antes, incluído SQL Server. No hay distinciones.
En definitiva, soy de los que opina que ese informe está sesgado y que no representa ni tan siquiera la realidad, ya que se está dando por supuesto que Oracle está siempre expuesto a la explotación de vulnerabilidades, y eso no siempre es así. Como tampoco está siempre expuesto SQL Server. Para mí, en un SQL Server sin parchear 5 años, que no tiene trato con usuarios (un agregador de información, una interfase de un aplicativo corporativo, etc.) y que no es manipulable ni por sus inputs ni sus outputs, no es prioritaria la política de parcheado, y sin embargo sí lo es la política de funcionalidad. Yo consideraré ese SQL Server como seguro frente a explotación de vulnerabilidades, y centraré mis esfuerzos en verificar que no cumplir con la política de parcheado no está generado problemas de funcionalidad colaterales.
Oracle no hace las cosas a la perfección. Su ciclo de parches podría ser más rápido, pero no menos cierto es que parchear Oracle tiene su miga, y que muchas veces ni en un trimestre entero se puede gestionar, repito, gestionar la seguridad de un motor de BBDD del que pende un negocio. Y es que gestionar y planificar la seguridad no significa lo mismo que parchear.
También podemos ciriticar a Oracle, y en general a la mayoría de fabricantes, por otras causas, ya que sus esfuerzos en investigación proactiva de seguridad podrían ser más concienzudos, y no dar lugar a la aparición de tantos problemas de seguridad que sí pueden ser críticos en ciertos despliegues. Pero tenemos que huír de la crítica sesgada, porque esa ni es constructiva, ni aporta nada.
A NGSS hay que entenderlos, ya que venden productos de seguridad para SQL Server, y venden productos de seguridad para Oracle. Para ellos la seguridad sólo va a girar en torno a la seguridad desde el punto de vista técnico, y no van a mirar mucho más allá. Sobre el hecho de que entre sus clientes destacados esté Microsoft y no esté Oracle no comentaré nada, pero no ayuda mucho a valorar como plenamente neutral el informe de Litchfield.
Hay un ejemplo muy espartano que ilustra claramente que la seguridad no depende de un sólo parámetro. Volvo es, según dicen muchos expertos, uno de los fabricantes de vehículos más seguros que hay. ¿Es más seguro un Volvo que un Seat Panda? Mal haríamos en decir rápidamente que sí, porque la seguridad de un vehículo no depende sólamente de las propiedades de ese vehículo tal y como sale de la cadena de montaje. ¿O es que siempre es más seguro un Volvo con las ruedas desgastadas sin líquido de frenos, con las pastillas cristalizadas y en mal estado de amortiguación que un Seat Panda en perfecto estado de mantenimiento? ¿Es más seguro ese Volvo con las cerraduras abiertas aparcado en un descampado que el Panda aparcado en un garage, con las cerraduras cerradas?
Moralejas:
- Gestionar la seguridad no equivale a parchear.
- De lo anterior se deduce que evaluar la seguridad no equivale a evaluar el estado de explotación de vulnerabilidades.
- En productos complejos, la seguridad es una cualidad que depende de muchas variables y no sólo de la cantidad de vulnerabilidades conocidas.
- Los productos que requieren personalización no presentan las mismas cualidades de seguridad que el producto que nos facilita el fabricante. Existe una transformación.
- Durante el funcionamiento y la progresiva parametrización de un gestor de base de datos, se transforman muchas de las cualidades y comportamientos del mismo, modificándose su seguridad.
- Es un error considerar a la seguridad como la única cualidad determinante para optar por una solución u otra.
- Las comparativas en rara ocasión recogen todas las casuísticas posibles, y por tanto, en rara ocasión son aconsejables para evaluar la seguridad de un producto.
- De lo anterior se deduce que las únicas comparativas válidas son aquellas en las que se comparan dos o más productos operando en las mismas condiciones y en el mismo ámbito. Comparar productos complejos en distintos ámbitos, o lo que es peor, sin estar en operación, es algo total y absolutamente carente de utilidad.
- Si te vas a comprar un coche, no hagas ningún caso a mi ejemplo del Volvo y el Panda :)
Un saludo :)
Es indudable que hay que tener en cuenta otros factores Sergio. Siguiendo con el ejemplo de los coches, está claro que un Volvo es más seguro que un Panda tal y como salen de la fábrica pero luego hay que tener en cuenta no sólo el estado en el que estén los vehículos sino también a quien los conduce. De eso no hay ninguna duda.
Pero de lo que tampoco cabe duda después de leer el texto de Litchfield es de que el código de SQL Server es más seguro que el de Oracle que es realmente a lo que el se refiere: no el producto sino el código: «SQL Server code is just more secure than Oracle code.»
Se trata de un analísis cuantitativo y que debe de interpretarse como tal, es cierto, pero también que es totalmente objetivo y que no cabe subjetividad alguna en su interpretación independientemente de que Microsoft sea cliente de NGSS. El hecho de que un producto tan «vigilado» como SQL Server lleve más de un año sin vulnerabilidades descubiertas debería de decirnos algo. Luego ya si miramos disponibilidad (que, a fin de cuentas, también es seguridad) y otros factores seguramente llegaremos a resultados diferentes pero, al menos para mi, la interpretación del paper de Litchfield es muy, muy clara.
Respecto a este tema, la seguridad de los productos software existe una norma ISO, la 15408 conocida vulgarmente como «Common Criteria» que establece el nivel de seguridad que un producto alcanza.
Esta norma no es más que un conjunto de requisitos de seguridad clasificados en dos tipos: funcionales (lo que el producto hace o implementa como funciones de seguridad) y de garantias (lo que al producto jamás podrá pasarle).
Bajo esta norma se pueden elaborar dos tipos de documentación: PP y ST.
Protection Profile (PP), una especificación generica de seguridad en base a los requisitos deseables, como por ejemplo, un PP para firewalls, o un PP para PKI.
Security Target (ST) es una especificación de requisitos concreta para un producto concreto y sobre un PP concreto en donde un laboratorio acreditado realiza una verficación y a asignar el nivel de seguridad según las pruebas realizadas y el nivel demostrado.
Ambos documentos son siempre públicos y están consultables en la Web de Common Criteria.( http://www.commoncriteriaportal.org/).
Por tanto, los niveles de seguridad obtenidos son luego garantizables por el administrador de turno, dado que puede ver la documentación sobre cómo instalar el producto para lograrlos.
Más transparencia creo que no es posible. Respecto a la capacidad de los laboratorios acreditados, son organismos de máxino nivel y de supuesta objetividad y neutralidad tecnologica. De hecho, las certificaciones técnicas exigidas por los organismos oficiales atienden a este criterio. Evidentemente estos son estudios caros que el fabricante debe pagar para demostrar la calidad, en materia de seguridad de su producto.
En España, tenemos como productos «made in spain» certificados el KeyOne de Safelayer. Los productos certificados, agrupados por categorías están consultables en http://www.commoncriteriaportal.org/public/consumer/index.php
Hola JM ;)
Mi comentario no iba orientado a criticar a SQL Server. Yo jamás lo usaría, pero eso no quita que como bien dices, al menos en cuestión de vulnerabilidades, se está portando decentemente. Repito que jamás sería mi elección, y lo argumentaría en función a costes, escalabilidad y rendimiento global. Pero ese es otro tema, ya que yo no quiero ni quería cargar contra SQL Server.
Yo sólo pretendía duda de la credibilidad de un informe en el que se tilda a algo más seguro que otra cosa sólo por el número de vulnerabilidades.
Sobre la declaración del código “SQL Server code is just more secure than Oracle code.”, mejor ni opino, ya que yo no tengo acceso al código de SQL Server, ni tengo acceso al código de Oracle. Se ve que este señor es un privilegiado, y sí tiene acceso a ese código para poder decir tan rotundamente eso que dice :)
Para mí el análisis tiene una interpretación muy muy clara también, y esa no es otra que decir públicamente que la seguridad no es un factor que dependa sólo del número de vulnerabilidades documentadas, al menos, en productos que requieren una personalización severa, como es el caso :)
Un abrazo :)
Javier,
Como bien sabes me fío poco de Common Criteria, pero ya que hablamos de este tipo de certificación, comentar que todas las versiones certificadas de Oracle son EAL4 o EAL4+
SQL no figura como producto sometido a Common Criteria. Tengo entendido que están preparando la certificación de SQL Server 2005.
Por comparar que no quede:
http://www.microsoft.com/sql/prodinfo/compare/ibm/default.mspx
(Se comparan con IBM DB2, cada cual que extraiga sus propias conclusiones)
Borremos por un monento la existencia de otras alternativas (MySQL, PostgreSQL, etc.). Si yo tuviera que elegir entre Oracle y SQL Server no me cerraría tanto… No siempre hay que implementar la base de datos de clientes de Telefónica, hay aplicaciones a las que Oracle se le queda muy, muy grande y la gestión y administración de un servidor Oracle requiere más preparación que la de un servidor de SQL Server.
En cuanto a la observación del código, en las pruebas de software existen tanto las de caja blanca (que requieren del conocimiento del código) como las de caja negra (que no lo requieren). En este caso, ante igualdad de condiciones (no está disponible el código de ninguno de ambos) y a la vista de los resultados de las pruebas a mi si me parece suficientemente probado que el código de SQL Server es más seguro que el de Oracle. Al menos hasta que no se demuestre lo contrario.