Proceso de Actualización

El proceso de actualización de los equipos va directamente relacionado a la necesidad de cubrir vulnerabilidades o errores en los sistemas de comunicación. Los dispositivos de seguridad no se actualizan porque solo existe una versión nueva, estas se actualizan por una necesidad concreta como lo puede ser una Vulnerabilidad y por Características nuevas, bugs declarados, o fallas en curso.
La necesidad más crítica es la que está sujeta a una vulnerabilidad, por tanto deberá aplicarse las medidas de protección necesaria para poder mitigar las brechas de seguridad.



1. Monitoreo de Vulnerabilidades.


La unidad que administra los equipos de Seguridad deberá estar monitoreando las nuevas vulnerabilidades declaradas por fábrica, y con eso se presenta una matriz de criticidad para realizar las actualizaciones  correspondientes en las plataformas ya sea de Entel o de Cliente.

La criticidad de cada vulnerabilidad puede ser clasificada como:

- Muy Crítica: Corresponde a vulnerabilidades que atenten contra cualquier dimensión de la seguridad de la información que puede ser, Perdida de la confidencialidad de la información, Perdida de la integridad de la información, y perdida de la Disponibilidad de la información. Cualquiera de estas vulnerabilidades atentaran contra la el negocio de cliente por tal razón,  deberán ser cubiertas en el menor tiempo posible ya que no tienen ningún proceso de mitigación por parte del fabricante. Esto obliga a realizar el proceso de parchado a la brevedad
- Critica: Son vulnerabilidades que al igual a lo anterior atentan contra cualquier dimensión de la seguridad de la información pero si poseen un proceso de mitigación establecida por el fabricante. Estas deben ser parchadas en el menor tiempo posible, pero tendrán menos prioridad que una vulnerabilidad de carácter muy crítico.
- Estándar: Cualquier vulnerabilidad que no se clasifique en las dos anteriores pasaran a ser estándar.
- No requerida: trata sobre vulnerabilidades en módulos apagados o desactivados..


2. Proceso de actualización por Vulnerabilidad



Cuando el software que administra el equipo se le declara una vulnerabilidad por fábrica esta se estudia y se revisa antes de aplicar el parche, esto para determinar la criticidad de la vulnerabilidad.

a. Plan de Mitigación

Si el equipo posee una vulnerabilidad al tener un proceso activo, este proceso se revisa si realmente debe estar utilizándose, en caso de ser necesario el proceso como activo,  se comunica el RFC y se planifica el proceso de actualización del equipamiento, en caso de que no se requiera este proceso, se apaga y se planifica la actualización con menor criticidad.
En caso de que exista un procedimiento de mitigación de la vulnerabilidad, esta se aplica disminuyendo así el riesgo de explotación de la vulnerabilidad declarada. En caso de que no exista un proceso de mitigación se deberá generar la incidencia correspondiente para poder realizar el proceso de actualización lo antes posible.

b. Nueva versión de Sistema Operativo

Cuando se realiza una actualización, esta se debe de estudiar para determinar cuáles serán las versiones más adecuadas para dar solución a la Vulnerabilidad. Cada Versión de sistema operativo cuenta con sus vulnerabilidades estas pueden estar declaradas, o no, estas últimas serán conocidas como vulnerabilidad de Día Cero. Por tal razón, se debe determinar cuál versión soluciona la vulnerabilidad declarada, y que esta no posea una vulnerabilidad declarada con mayor criticidad que la anterior.

3. Actualización por nuevas características.


Mientras va actualizándose la tecnología, nuevas características y herramientas van saliendo en cada dispositivo. Otra razón por la cual se puede realizar la actualización de un dispositivo son características de seguridad, compatibilidades y homologaciones de tecnología.
Un ejemplo claro de esto fue la necesidad de actualización de dispositivos Ironport que debían ser actualizados para que fueran compatibles con el nuevo canal de seguridad de HTTP que era TLS 1.2, que en versiones anteriores no era soportado.
Las nuevas características permiten dar un mejor servicio y mejorar la protección que pueden tener los usuarios ante nuevas amenazas y ataques.

c. Nueva versión de Sistema Operativo

La nueva versión a elegir debe de poseer la nueva característica deseada, y se debe de cuidad de que esta no posea errores de programación declarados como falla y además no debe de tener vulnerabilidades criticas declaradas. El no realizar este estudio previo a la actualización puede provocar una brecha de seguridad.

4. Actualización por bugs declarados.


El software que se utiliza en los equipos de comunicación puede presentar errores de ejecución en su puesta en producción, Cuando se declara un bug que pueda poner en riesgo la dimensión de la disponibilidad de la información, se debe de planificar la actualización masiva de los equipos que posean la versión de falla. Esta deberá ser planificada y ejecutada con mesura y en conjunto con participación de cliente.


d. Nueva versión de Sistema Operativo

La nueva versión a elegir debe de poseer la nueva característica deseada, y se debe de cuidad de que esta no posea errores de programación declarados como falla y además no debe de tener vulnerabilidades criticas declaradas. El no realizar este estudio previo a la actualización puede provocar una brecha de seguridad.



5. Actualización por falla.


Cuando se declara una falla producto de un bug, debe realizarse la actualización dentro de un ambiente de incidencia.