Un aparcamiento indiscreto

En la naturaleza, los animales y las plantas siempre han conservado su vida protegiéndose del entorno hostil. Evitando ser mordido, ramoneado, masticado, cazado y devorado.
La mejor forma de sobrevivir es pasar desapercibido a los sentidos altamente especializados de los otros seres.

Siguiendo el ejemplo, hace tiempo que los Centros de Datos tratan de protegerse siendo discretos. Cuanto menos se sepa de su localización, tamaño o distribución tanto mejor. Sedes con accesos tan restringidos que no se enseñan ni a los socios colaboradores ni a los potenciales clientes.

Excepto cuando lo importante es reservar las plazas de aparcamiento exclusivamente para los técnicos y administradores del propio centro de datos, como muestra esta fotografía.

Cuando giré la esquina descubrí en nombre de la empresa, pude conocer su actividad y además dónde tiene su CPD.

L.F. Real

Cuando la Calidad empieza con un lápiz y un papel

Recuerdo una reunión donde asistimos el recién llegado grupo de ingeniería y los directivos de la compañía que nos iba a acoger. Externalizados, proveníamos del mundo de la ingeniería para la fabricación de equipos de redes de datos y aterrizábamos en otro completamente diferente y ajeno a nuestras experiencias, el mundo de la consultoría.
Entre la cortés bienvenida y las edulcorados halagos pronunció un breve discurso el Director de Calidad. Eran unos años donde este tipo departamento, además de tener entidad propia, eran dirigidos por un gerente prevalente.
Como decía, el director de calidad dejó la siguiente frase al final de su discurso, como recomendación o tendencia exigente para conseguir un trabajo de calidad:

"Escribe lo que vas hacer y haz lo que has escrito".

Contrariamente al mensaje, el hecho de escribir, documentar, no es una de las tareas a ejercer en el trabajo del día a día.

Pero analicemos la frase detenidamente y qué relación tiene con la consecución de tan deseada calidad.

"Escribe lo que vas hacer" Esta frase esconde que, tras la acción de teclear un fichero txt o garabatear un papel, lo que realmente se hace es reflexionar y desarrollar la propia planificación del proyecto. Línea tras línea se enumeran y desglosan las diversas tareas, se organizan y ordenan en el tiempo. Los esquemas y diagramas visualizan relaciones entre ellas, afloran las dificultades y se pueden prever los escollos. El poyecto, aunque sea brevemente perfilado en unas notas, hace que pueda ser mejor compartido con otros colaboradores, comunicado y discutido con ellos.

Las segunda frase complementa la primera. "Haz lo que has escrito" cierra el trabajo. Es una forma de garantizar que el proyecto se ha ejecutado según se planificó. Si se han realizado cambios y modificaciones se puede contrastar con la idea original. Establecer diferencias, evaluar el resultado de los cambios y en definitiva, aprender de la experiencia.

En cualquier caso, esta sentencia del director trata de evitar la improvisación, o al menos, está forma de resolver los problemas debe ser una situación excepcional y nunca la forma habitual de trabajar.

Después de aquella tarde no volvimos a saber más de aquel director ni su departamento.

Luis. F. Real

Lectura de verano: "Alan M. Turing. Más que un enigma" de Sara Turing

El paseo anual por la Feria del Libro en el Parque del Retiro de Madrid me deparó esta sorpresa. Adquirí la lectura para los dias estivales, otra biografía de Alan Turing que añadir a mi colección.  Esta vez, la autora es su madre, Sara Turing. A la obra se suma unos capítulos finales escritos por el hermano mayor.
Evidentemente, los hechos narrados tienen el sesgo maternal. A esa falta de objetividad responde John, el hermano, puntualizando algunos hechos y vivencias llevándolos hacia el otro extremo. A veces destila cierto resentimiento, posiblemente por la tergiversación de las historias que cuenta su madre. Pero no hay que verter reproches a Sara por la deformación de los recuerdos. Por el contrario, hay que ponerse en su lugar, y tratar de comprender, como madre, cómo tuvo que afrontar el luctuoso desenlace de su hijo.
La obra se suma como una pieza mas al puzle de la enigmática personalidad del matemático; sabiendo además, que nunca seremos capaces de completar.

L.F. Real

El Tribunal Constitucional sentencia contra los datos recopilados por partidos políticos

Este 22 de mayo, como no podía ser de otro modo, el Tribunal Constitucional ha sentenciado que el artículo 58.1 bis de la Ley Orgánica de Régimen Electoral General que se incluyó a través de la aprobación de Ley Orgánica de Protección de Datos Personal y Garantías de Derechos Digitales es inconstitucional y nulo.

En entradas anteriores dedicamos breves líneas al significado de dicho artículo y por qué no tenía cabidaen la protección de datos personales.
Consultar La polémica nueva Ley de Protección de Datos Personales


Las Notas de prensa del Tribunal:

Nota informativa

Recurso de inconstitucionalidad interpuesto por el Defensor del Pueblo

Excursión al Mundo Hacker

Aquel día, el refrán "en abril aguas mil" cumplia su pronóstico. Fue un dia muy lluvioso y el resguardo para el día estavo en el centro de ocio y cines Kinépolis, donde se celebró Mundo Hacker.

Por hacer un resumen como recordatorio, estas fueron las intervenciones.

Bienvenida a los asistentes. Desirée Rodriguez & Víctor Aznar

KEYNOTE: Power Nap y vamonos!. Antonio Ramos

De Verano a primavera en los servicios de Red Team. Mildrey Carbonell Castro, Head of Audit Department S21sec

Lo que Europa está dispuesta a hacer por la ciberseguridad. ¿Y tu?. Juan Zafra,
Director Análisis, Inteligencia y Comunicación. Consultoría estratégica

KEYNOTE: Utilizando metodología de Password Cracking para algoritmos rápidos como NTLM y MD5. Pedro Alexander Garcia.

APTs en la cadena de suministro: cuando la logística se te vuelve en contra. Dani Creus
Senior Security Researcher (GReAT – Kaspersky Lab)

Democracia hackeada: Ciberseguridad, redes sociales y manipulación de procesos electorales en la nueva era digital
Ofelia Tejerina, Abogada. Premio LegalTech 2019 – Confilegal. Secretaria General Asociación Internautas
Borja Adsuara, Abogado Experto en Derecho Digital
Antonio Vargas, Public Policy Manager en Google
Carlos Loureiro, Hacker y Criminólogo
Modera: Daniel de Blas, periodista GlobbTV

Enlace a Mundo Hacker Day
Y no hay que perderse el canal GlobbTV Globbsecurity

L. F. R.

Circular de la AEPD sobre el tratamiento de datos por los partidos políticos

Tal como recogimos en un artículo anterior, la nueva Ley Orgánica de Protección de Datos y Garantías de Derechos Digitales se estrenaba con una gran polémica. Dicha ley añade el artículo 58bis a la Ley Orgánica de Régimen Electoral General.

(para recordar la polémica 3 Temas TIC: "La polémica nueva Ley de Protección de Datos Personales")

Con el fin de aclara ciertas dudas y aportar tranquilidad a los ciudadanos, la Agencia Española de Protección de Datos se ha visto obligada a redactar una Circular. La Circular 1/2019 trata de esclarecer criterios sobre cómo debe ser aplicado el artículo 58bis. Esta es la nota de prensa de la propia Agencia al respecto:

La AEPD publica la Circular sobre el tratamiento de datos personales relativos a opiniones políticas por los partidos

La circular publicada en el BOE:

Circular 1/2019 de la Agencia Española de Protección de Datos

Tal como hice en la entrada anterior, dejo los comentarios que los expertos han matizado sobre la Circular. Ellos realizan un análisis más lúcido del que pueda realizar yo.

Se publica la circular de la AEPD respecto del tratamiento de opiniones políticas sobre los partidos políticos

Este polémico artículo 58bis en la ley de Régimen Electoral General y la injerencia de los partidos políticos en los datos personales no ha hecho nada más que empezar. En los próximos meses podemos comprobar como se manifiesta en los procesos electorales.

L. F. Real

La Política de Actualización del Software (y V)

En esta parte voy a dedicar unas líneas a explicar los contenidos más importantes que deben figurar en el documento de política de actualización del software. Algunos son imprescindibles pero otros serán solo informativos.

Información para el documento

Disponemos de la siguiente información.

• Inventario de las aplicaciones informáticas de la organización, sus funciones importancia para el negocio.
• Los ciclos de vida que los fabricantes dan a sus productos, el calendario (roadmap) de lanzamientos y la duración de la fase de mantenimiento.
• Las restricciones que impone el tipo de negocio a los cambios del software.
• Los contratos de mantenimiento con terceras empresas y sus implicaciones en estos cometidos.

Con la información anterior construiremos las directrices de la política. Ésta, por un lado, será la base para desarrollar los procedimientos técnicos, escenarios de pruebas, test de verificación, etc. Por otro lado, será el proceso de la gestión del cambio quien asuma la acción dentro de la gestión del servicio y cómo afecta a éste (sirva como referente lo que recomienda ITIL al respecto).

Contenido destacado en el documento

En el documento se incluirá los siguientes apartados principales.

• El alcance del documento. Enumera qué software, equipos y sistemas son los destinatarios de la política descrita en el documento. La compañía selecciona según su funcionamiento conjunto, modelo de equipos, servicios en los que interviene, etc.
• Se dedicará un apartado a explicar las reglas que rigen la nomenclatura y numeración de las versiones que se utiliza en el documento. Estas normas son comunes en toda la compañía y están autorizadas y aprobadas por la dirección. Es conveniente explicar la relación entre ésta y la utilizada por los fabricantes para evitar la confusión.
• Es interesante recoger una una breve explicación del ciclo de vida del pruducto. Puede añadirse en un anexo al final del documento los enlaces a las páginas web de los fabricantes.
• Destacar la situación actual del software de la compañía con respecto a su ciclo de vida.
• Lista de tareas previas que deben ser verificadas (“checklist”) antes de iniciar la propia   actualización. Todas tendrán sus procedimientos descritos para ejecutarlas. Por ejemplo:

         o    Verificación de los requisitos hardware y software necesarios para la correcta instalación.
         o    Backup de todo firmware, sistemas operativos, programas, aplicaciones y sus respectivas configuraciones que puedan verse afectadas.
         o    Documentos de los fabricantes de los procedimientos de actualización de sus productos. Disponibles para su consulta.
         o    Comprobación de equipamiento adicional: comunicación, servidores, acceso remoto, copias de seguridad. Aquí quisiera hacer un inciso importante. Si un equipo remoto está en un acceso difícil habrá que considerar el posible desplazamiento de técnicos para solucionar problemas in situ.
         o    Procedimientos de vuelta atrás en caso de poder realizarse la instalación o recuperar las funcionalidades.
         o    Otras considereaciones dependientes de cada sistema.

Estos dos últimos apartados los voy a dedicar en las siguientes secciones dada su importancia en la política, puesto que es la razón de ser de la misma, el motivo por el cual se redacta.

-    Criterios para autorizar la actualización de versiones.
-    Proyecto de actualización

Criterios para autorizar la actualización

Para autorizar la actualización del software se realizará teniendo en cuenta una serie de criterios. Los criterios más destacados son los siguientes:

• Consecuencia del seguimiento de la versión lanzada por el fabricante:

         - Aparición de nuevas funciones que desee implantar la compañía.
         - Determinados equipos se actualizan periódicamente, y esta versión es una de ellas.

• La versión aporta corrección de errores que afectan a las configuraciones usadas.
• El fabricante impone un cambio de versión que es imprescindible:

         - Actualización de Urgencia para la corrección de errores graves.
         - Eliminación de una versión cuando alcanza el fin del ciclo (End of Live).
         - División de una versión en dos líneas diferentes con evolución divergente.

Podemos comprobar que todos son impuestos por el fabricante excepto el primero. Se deja la opción de no actualizar a una versión lanzada. Puede ocurrir que en futuras versiones haya que instalar todas las anteriores. La decisión de actualizar o no una versión, un paquete o un parche, será asumida por la propia compañía, estará justificada y autorizada.

Proyecto de actualización

El proceso de actualización se tratará como un proyecto, más o menos complejo, de la compañía. Como tal, debe cubrir todos los requisitos para su realización. Depederá del tipo de software, sus características e importancia. El proyecto no será el mismo para la instalación de un parche en un sistema operativo en unos pocos ordenadores que la renovación de una aplicación crítica e insustituible, que será clave en la pervivencia del negocio.

El proceso debe superar una serie de fases hasta que la nueva versión alcance la funcionalidad completa sobre todos los equipos y sistemas del entorno de producción que la deban incorporar. Las fases de un despliegue de una actualización las podemos resumir en las siguientes.

1. Elección de la versión que se va actualizar. La primera tarea es la lectura de los manuales o boletines sobre las características de la versión lanzada. La segunda será la consulta de las dudas no resueltas con los fabricantes y los proveedores. Debemos obtener la información suficiente para saber si debemos afrontar o no la actualización de una nueva versión. En esta fase se analizan los criterios expuestos anteriormente. El resultado será un informe motivado con la autorización o no de la nueva versión.
2. Pruebas de validación. Esta fase se realiza en un entorno de pruebas. La ejecución de un Plan de Pruebas verificará la instalación y el correcto funcionamiento. Esta fase podrá incorporar pruebas de rendimiento, carga de trabajo, estrés, etc. y todas aquellas que se consideren oportunas para comprobar la solidez del software. El resultado de esta fase es la homologación de la nueva versión; es decir, que ésta se podrá trasladar a los equipos y sistemas del entorno de producción con los cambios de configuración o ajustes necesarios.
3. Instalación de la versión homologada en equipos de producción de acuerdo con una Prueba Piloto. Habrá que tener en cuenta los periodos de mantenimiento para actuar sin afectar a los servicios. La Prueba Piloto seleccionará los primeros equipos sobre los que se probará. Tendrá encuenta los escenarios más variados y complejos. La prueba realizará una monitorización exhaustiva de los equipos y sistemas. Determinará sobre que parámetros se efectuará, los rangos de las medidas y los umbrales para la detección de anomalías. Este seguimiento se realizará durante un tiempo: dias, semanas, meses ...
4. La versión actualizada se Certifica que funciona en el entorno de producción.
5. Despliegue de la versión certificada en todos los equipos. La Prueba Piloto puede exigir una monitorización similar a otros equipos o sistemas durante otro periodo.

Próximos pasos y final

El documento de política debe adecuarse a los distintos tipos de sistemas que tiene la compañía. 

Como últimas palabras expongo aquellas que mencionó un director de Calidad de una importante consultora internacional:

" Escribe lo que vas hacer, y haz lo que hayas escrito "

Resume un trabajo pensado, elaborado, concienzudo y previendo las posibles incidencias que puedan ocurrir. Condiciones que no siempre se imponen en el mundo actual

 L. F. Real

La Política de Actualización del Software (IV)

En la política de actualización del software se deben tener en cuenta algunos elementos importantes. En la segunda parte vimos el inventario del software de la compañía y el ciclo de vida con ejemplos en la tercera. En esta cuarta parte vamos a comprobar cómo las características del negocio pueden imponer otras condiciones a la hora de instalar actualizaciones.

Las necesidades del negocio

 

No todos los negocios tienen los mismos requisitos y necesidades con respecto a las actualizaciones del software. Vamos a ver unos ejemplos.

Las compañías de servicios de viajeros ferroviarios o aéreos tienen las fechas de vacaciones estivales o navideñas como periodos prohibidos para realizar cualquier cambio o modificación en las aplicaciones. El volumen de operaciones se incrementa considerablemente. El trabajo diario se concentra en las operaciones del servicio a los viajeros. Se evita aumentar la carga de trabajo de los operarios así como añadir otros riesgos inherentes a los nuevos productos.

Estas condiciones impiden realizar las actualizaciones periódicas siguiendo el calendario o “roadmap” de los fabricantes software, tal como vimos en la segunda parte. Cabe esperar que pasadas las fechas restrictivas, se acumulen los parches y las versiones disponibles que hayan salido durante ese periodo de tiempo. Algunos serán más necesarios e importantes que otros, habrá que decidir cuáles se instalarán, cuándo y cómo.

Otro caso. Las empresas de telecomunicaciones tamibién tienen sus limitaciones. Quisiera destacar las que dependen de los equipos electrónicos. Sirva como ejemplo un proveedor de servicios de fibra. Los nodos de la red están constituidos por el misma familia de modelos de routers. Cada router tiene redundancia basada en la doble unidad de control, manteniendo una activa y la otra en reserva. Esto permite mantener el router funcionando mientras primero se instala la nueva versión firmware en la unidad de reserva. Cuando la reserva está preparada, conmuta para ser la activa y tomar el control. La descarga del nuevo firmware ahora se realiza en la otra unidad. Finalmente, ambas unidades están actualizadas sin que haya habido cortes en el tráfico de datos de los clientes.
No obstante, a pesar de la redundancia de los equipos, la empresa debe ser muy cauta a la hora de permitir las actualizaciones del firmware. La red está formada por cientos de routers que deberían ser actualizados cada cuatro, seis o doce meses, según recomiende el fabricante. En estas condiciones hay que tener en cuenta:

• La descarga del firmware a los routers se realiza de forma remota a través de la propia red. Esto afecta al rendimiento y la capacidad de la propia red. Pudiendo alterar el tráfico de clientes
• Durante el proceso de actualización, las unidades de control dejan de ser redundantes. Los routers quedan más vulnerables a otros eventos que puedan ocurrir y afecten al rendimiento de la unidad de control activa.

Por lo tanto, se requiere un estudio más riguroso sobre cómo y cuándo actualizar el firmware de los equipos de red y las consecuencias que pueda tener este hecho en el servicio a los clientes.
La manera en que se establece un calendario, una lista de equipos o grupos de ellos para la actualización del software deberán ser las particularidades que se deben incluir en las políticas de actualización.

 

Actualizaciones de seguridad

 

Hemos visto, cómo según el tipo de negocio, las actualizaciones se pueden posponer unos meses. No obstante no se pueden evitar o retrasar aquellas versiones o parches que solucionan problemas de seguridad. Los fabricantes suelen indicar cuáles son. Es posible que haya que instalar durante las fechas vacacionales, los días de máxima carga de trabajo o en muchos equipos al mismo tiempo. Estas situaciones deben estar previstas, analizando el riesgo y la gravedad de las consecuencias dependiendo de la decisión que se tome.

 

Impacto en los servicios de TI

 

 En los ejemplos anteriores sobre los negocios hemos dado un salto cualitativo. Hemos pasado desde un ámbito más técnico hacia el impacto en el ámbito de los servicios. Será la gestión de servicios la que decida en estos casos y entramos de lleno en los proceso de gestión de cambio, tal como entiende ITIL. Pero estas cuestiones exceden las notas de este artículo.

 

Mantenimiento externalizado

 

Muchas compañías tienen el mantenimiento externalizado con empresas que ofrecen estos servicios. En la SLA deben constar cláusulas respecto a las actualizaciones. Todo lo expuesto a través de los casos anteriores deberá tenerse en cuenta en los contratos de mantenimiento y estar descrito de forma clara en las políticas de actualización.

L. F. Real

"Supervirus" para el futuro

Repasando los informes sobre ciberseguridad del año pasado me ha llamado la atención el crecimiento y la expansión de los “supervirus”. Un rimbombante nombre que trata de sostener cierta analogía con las superbacterias que, gracias a mutaciones selectivas, consiguen ser resistentes a los antibióticos.

Estos “supersoftware” maliciosos no son nuevos. Cuando he leído más sobre ellos, he encontrado documentos escritos hace unos pocos años que los describen y analizan.

Para explicar en qué consisten vamos a partir de la siguiente pregunta.¿Cómo puedo eludir el análisis y la acción de los programas antivirus?. La respuesta se antoja inmediata. Sabiendo que los programas antivirus analizan sobre los soporte de datos como los discos duros, podría esquivar el antivirus si fuese capaz de colocar el malware en un lugar donde éste no busque ni analice. Para demostrar la certeza de tal afirmación tenemos los nuevos tipos virus informáticos capaces de hacerlo.

Fileless Malware. Este es un tipo de programa malicioso que se instala en la memoria RAM de los ordenadores. Su eliminación es sencilla, se apaga el equipo y los datos de la memoria se borran, entre ellos, este programa. El problema surge cuando los ordenadores y servidores infectados no se pueden apagar de una forma tan simple ni tampoco en cualquier momento. Esto ocurre con los centros de datos o servidores que funcionan 24x7 todos los días del año.

Apagar los sistemas requiere una preparación más allá de apretar un botón o teclear “shutdown”. El procedimiento debe ser tal que minimice el impacto en los servicios. Si queremos que éste se mantenga el proceso de apagar servidores debe contar con la presencia de otros servidores redundantes adicionales que entren en funcionamiento en lugar de los principales. Además, tiene que continuar con los procesos de arranque y restablecimiento hasta alcanzar la actividad normal.

En estas situaciones de emergencia, el foco se pone en la eliminación del malware descuidándose otras tareas y acciones importantes. Cada una tiene sus propios riesgos que hay que tener encuenta para ser gestionados adecuadamente. Si los ciberdelincuentes han sido hábiles en la creación, el malware se podrá propagar de unos servidores a otros, con lo cual el problema crece exponencialmente en complejidad

 

Bootkit. Este malware se instala entre el firmware almacenado en los circuitos integrados de arranque de los ordenadores y servidores. Los antivirus no analizan este tipo de programas. Pero la infección tampoco es sencilla. El acceso a estos circuitos y la instalación del firmware requiere ciertos conocimientos técnicos.

Es una buena herramienta para el espionaje industrial. Empresas dedicadas al mantenimiento de los sistemas microinformáticos de otras compañías pueden manipular este tipo de circuitos para obtener información relevante.

No es la primera vez que se manipula firmware de dispositivos. Sólo hay que hacer una sencilla búsqueda en internet sobre el caso de manipulación de routers Cisco por la NSA; o los productos importados de China con su carga maliciosa oculta.


Para conocer mejor estos “supervirus” dejo las siguientes referencias.




“El Fileless malware se erige como la mayor amenaza para tu ordenador en 2019” David Hernández, 9 -12-2018. Computer Hoy en Facebook

“VENI, VIDI, VICI: Malware sin fichero” Publicado el 02-02-2017, por Asier Martínez (INCIBE)

“Bootkits: Atacando el arranque” Publicado el 07-07-2015, por Antonio López (INCIBE)

“¿Rootkit o Bootkit? Aclarando la duda de forma definitiva” Ilya Lopes 19 Aug 2014, (Welivesecurity)

“LoJax: primer rootkit de UEFI en uso que se descubre, cortesía del grupo Sednit” ESET Research 27 Sep 2018

Whitepaper:
“LOJAX: First UEFI rootkit found in the wild, courtesy of the Sednit group”

L. F. Real

La Política de Actualización del Software (III)

En esta entrada, continuando con la anterior, voy a exponer unos ejemplos de ciclos de vida de productos comerciales. Son unas breves notas para destacar las diferencias de planificación entre distintos fabricantes.

 

Ejemplos del ciclo de vida

 

No todos los fabricantes tienen un ciclo de vida como el expuesto en la Parte II

Cada fabricante especifica los periodos de tiempo de sus productos y aporta, como hemos dicho anteriormente, su nomenclatura y lenguaje particular en las ediciones comerciales. Es necesario conocer y familiarizarnos con el vocabulario empleado en las aplicaciones y programas que empleamos en nuestro negocio. A veces, la terminología puede causar equivocaciones entre los interlocutores cuando se refieren a unos productos en los términos de otros fabricantes.

 

Sin planificación del ciclo de vida

 

Hay fabricantes que no tienen planificado ningún ciclo de vida. Las versiones salen sin previo aviso. En este caso, es una tarea obligada mantener una consulta periódica con el fabricante o sus socios distribuidores para conocer lo antes posible la existencia de una nueva versión. Suele ocurrir que estas consultas queden en suspenso. Sin la asignación concreta a un responsable para que la realice, puede que la versión no se actualice conforme a los requerimientos del fabricantes, siendo una situación grave cuando se trata de solucionar vulnerabilidades de seguridad.

 

Desarrollo de productos en líneas beta y comerciales

 

Otros fabricantes además de sacar al mercado versiones estables mantienen una línea paralela del producto en formato “beta”. Esta línea va evolucionando. En ésta se corrigen los errores y se incorporan las mejoras. Cuando la versión beta está suficientemente madura se convierte en una nueva versión estable comercial. Este método de desarrollo se emplea generalmente en productos Open Source.

Productos con versiones de urgente instalación.

Red Hat nos ofrece otro interesante ejemplo. Además de las versiones importantes y subversiones de ésta, denominadas Release Major y Minior respectivamente ofrece un tercer campo denominado Asynchronus.

Los números de las Release Major y Minor siempre están presentes. La identificación numérica de Asynchronous Release es aquella que soluciona un fallo o una vulnerabilidad de seguridad. Éstas son de urgente instalación. El detalle de la política de actualizaciones de Red Hat puede consultarse aquí  Update policies   y la página de soporte soporte

Modelos de ciclos de vida bien establecidos

La denominación “roadmap” hace referencia a un ciclo de vida previamente planificado. Cuando sale el producto al mercado su calendario de revisiones está establecido y la fecha de “expiración” anunciada. Veamos brevemente como lo resuelve Oracle, Cisco y un enlace para conocer el de Windows. Hay que tomar nota de los vocablos y nombres que utilizan los fabricantes para designar sus productos y las líneas de soporte y mantenimiento.

Oracle Database

La compañía Oracle ha cambiado recientemente la nomenclatura y el roadmap de liberación de versiones de Oracle Database. Las versiones tienen los siguientes campos:

Cada 3 meses (Quarter) habrá una actualización de versión con nuevas funcionalidades denominadas Release Updates: RU18.1, RU18.2, RU18.3 etc. No obstante, para cada versión trimestral se publicarán revisiones con mejoras en la seguridad y soluciones de los fallos. Estas se llaman revisiones o Release Update Revision, RUR y añaden un nuevo número seguido del anterior. RUR18.1.1, RUR18.1.2, RUR18.2.1, RUR18.3.1, RUR18.3.2 etc.

Cada RU finaliza en la RUR x.x.2, por ejemplo la 18.3.0 en la 18.3.2. A partir de aquí hay que saltar a la versión 19.3.0. Oracle asegura que mantendrá los mismos niveles de seguridad y correcciones en las versiones.

Con este calendario Oracle facilita que los clientes puedan programar las actualizaciones con las operaciones del negocio. Los clientes podrán ir actualizando de RU en RU a lo largo del año o por el contrario mantenerse en una versión y actualizar sus revisiones RUR.  Mas detalles en MOS, My Oracle Support.
 
Cisco
 
Tiene una política y un ciclo de actualizaciones bastante riguroso y a la vez complejo. Para un mismo producto lanza varios tipos de “Release” diferenciándose en la duración del período de mantenimiento o soporte técnico.

• Early Deployment (ED). Productos software que proporcionan nuevas funcionalidades y nuevo soporte a los equipos hardware. Son versiones de vida corta permiten a los clientes desplegar últimas funcionalidades y nuevos módulos o plataformas hardware. Incorporan versiones con la corrección de fallos.
• Maintenance Deployment (MD). Corresponde a versiones de software que proporcionan soporte de mantenimiento y corrección de errores. Proporcionan estabilidad y larga vida. El soporte técnico proporciona versiones periódicas de mantenimiento (Maintenance Release, MR).
• Deferral (DF) El propósito de Deferral Advisory es anunciar la eliminación de una versión de software e introducir una de reemplazo. Es el momento para que los clientes migren a la versión de reemplazo, tal como explicamos en la figura 1 de la parte II

Los hitos principales de las releases son:

• Primer envío al cliente (First Customer Shipment, FCS): el día en que el lanzamiento está disponible por primera vez para los clientes en Cisco.com
• Fin de las ventas (EoS): el día en que el producto no se puede solicitar ni se incluye en la fabricación de equipos de Cisco. Seis meses antes se anunció esta fecha.
• Fin del mantenimiento del software (End of Software Maintenance, EoSW): corresponde al día en que la ingeniería de Cisco deja de proporcionar soporte a un producto. Antes de este hito, hay soluciones alternativas como versiones compatibles o nuevos productos.
• Fin de soporte a vulnerabilidades y seguridad (End-of-vulnerability and security support, EoVS). Desde la fecha de finalización del mantenimiento software hasta éste día, Cisco se compromete a sacar una nueva versión que solucione problemas de seguridad si fuese necesario.
• Último día de soporte, (Last day of support, LoS). Después del hito EoVS será el Technical Assistant Center de Cisco (TAC) el que proporciona soporte a los clientes. Hasta el día LoS

El soporte se extiende durante dos periodos de tiempo.

• La Fase de Mantenimiento se extiende desde FCS hasta EoSM
• La Fase de Seguridad Opcional desde EoSM hasta EoVS.

El programa de mantenimiento de las releases se ofrece de dos modos según el tiempo de duración del soporte técnico. Así tenemos Releases con soporte estándar (Standard-Support) y Releases con soporte extendido (Extended-Support).

El soporte estándar dura en total 18 meses, correspondiendo 12 meses a la primera fase y 6 meses a la segunda. El soporte extendido dura 48 meses, siendo la primera fase de 36 meses y la segunda de 12 meses. El cliente debe adquirir el software de Cisco en las  releases cuyo soporte estándar o extendido se adecue a sus necesidades.

No obstante, Cisco ofrece una prolongación del periodo de soporte (48 meses adicionales en soporte estándar y 36 meses para el extendido) a través de contratos con el Centro de Asistencia Técnica, TAC.
Durante la fase de mantenimiento, Cisco saca versiones cada 3 ó 6 meses para corregir errores que hayan ido apareciendo.

Sistemas operativos Windows

Dado su amplio uso, aquí hay un enlace con el ciclo de vida de los productos Windows
Hoja de datos del ciclo de vida de Windows


Con esto damos por finalizado un breve repaso a los ciclos de vida que hemos tomado como ejemplo.

Es necesario conocer en qué situación se encuentra actualmente nuestro software, la versión, la fecha de instalación y las condiciones del mantenimiento. Por otro lado, hay que informarse de los hitos que tendrán lugar en los próximos meses de estos productos.

En la próxima entrega veremos como las características de los servicios TIC en algunos negocios imponen sus propias recomendaciones o nomas a la hora de efectuar actualizaciones de las versiones software. Factores que se deben tener en cuenta en la elaboración de la política y puede dar lugar a que existan variantes muy diferentes o haya que considerar políticas en plural.

 L. F. Real