© 2013 CYBSEC 1

Remediación ¿Parche o upgrade? La mejor pregunta para evitar recaídas en nuestros sistemas y procesos tecnológicos.

Hay diferentes entradas que pueden iniciar un proce so de remediación en nuestros sistemas, pero hay una sola forma de abordarlos: Co n la intensión que el remedio cure la enfermedad.

Cuando en nuestros escritorios empieza a resonar la palabra “Remediación” generalmente nuestra preocupación nos muestra los dos caminos que nos dirigen a ella:

1. Como se llegó al punto que nuestros recursos y procesos tecnológicos no estén acompañando las necesidades de cumplimiento del Negocio, o bien, no lleguen a cumplir con los objetivos de servicio a clientes internos.

2. Que hacer con esta situación y como definir una respuesta estratégica para resolverla dentro

de un plazo finito, el cual también debo establecer en función de las necesidades del Negocio. Primeramente tratemos de bajar a tierra la frase “necesidades del Negocio” para comprender que las mismas no están tan lejanas como suenan de nuestras propias necesidades ni del impacto negativo que puede causarnos el no tomar a tiempo acciones para encausar nuestros sistemas y procesos tecnológicos. Si de alguna forma han tenido la oportunidad de trazar un paralelismo entre Objetivos de Negocio, de Tecnología y de Seguridad de la Información, podrán haber visto la necesidad directa que tienen IT y SI en brindar un servicio al Negocio que le asegure los resultados esperados… Y el brindar esos servicios no son ni más ni menos que los resultados que IT y SI deben mostrar y que el Negocio espera; y si esto no sucede nuestro juego con la palabra “necesidad” terminaría en un estrepitoso “Game Over” .

Figura 1 – Como alinear objetivos Aclarado este concepto volvemos a la pregunta original, ¿Parche o Upgrade?. Si tomamos en frío la resolución de esta pregunta, obviamente vamos a responder que lo mejor es hacer todo para que la

© 2013 CYBSEC 2

remediación sea una oportunidad de mejora, pero si estamos ante una situación de crisis dada por el entorno o por los tiempos esta buena respuesta se va degradando rápidamente hasta llegar a remediar “de la mejor forma” . Otra pregunta entonces es ¿Cuál es la mejor VERSIÓN que quiero de mis sistemas o procesos remediados? Como lo que queremos es la mejor versión, es que buscaremos en este breve artículo las mejores respuestas para brindar una remediación efectiva y así permitir que los sistemas y procesos cambien de versión y no sean simplemente “parcheados”, teniendo en cuenta estas principales actividades:

• Definición de estrategias en función de observaciones, alcances y experiencia • Identificación de recursos técnicos y humanos • Definición de roles y funciones bien definidos • Conformación de equipos de trabajo • Capacitación a los diferentes equipos de acuerdo a su visión de objetivo y a su participación

en la remediación • Definición de las evidencias a obtener y su formato • Seleccionar la documentación que nos sirva para operar, seguir y controlar la remediación

Definir la estrategia de remediación requiere conocer cuál es alcance de las observaciones en cuanto a cantidad de plataformas y aplicaciones alcanzadas así como la magnitud de no-conformidades que puedan alcanzar a sus configuraciones técnicas, roles y perfiles, cuentas de usuario, permisos y privilegios, etc.; conociendo esta información podremos determinar más fácilmente que documentación de soporte necesitaremos y como armar y preparar nuestro equipo de trabajo. Nuestra estrategia debe delinearse siempre pensando que la remediación debe basarse para su ejecución en el orden lógico de Sistema Operativo ���� Base de Datos ���� Aplicaciones para asegurarnos que al llegar a la capa superior no han quedado inconsistencias en la capa de software de base que genere demoras en la remediación de aplicaciones, y a este orden debemos agregarle la complejidad de interacción entre las diferentes plataformas por lo que se agregan componentes tales como interfaces, cuentas de usuario especiales que ejecutan tareas específicas, procesos que al ejecutarse actualizan datos e información. Por ello al conformar los equipos debemos tener en cuenta no solo al personal de Tecnología y Seguridad de la Información, sino también a los dueños funcionales de las aplicaciones que con su conocimiento y experiencia sobre los procesos de Negocio deben liderar las tareas y compartir las decisiones a tomar. Esto nos lleva a determinar roles y funciones bien definidos al momento de conformar los equipos, para que cada uno desde su visión aporte su conocimiento minimizando impactos negativos sobre la disponibilidad de los sistemas e integridad de los datos. La generación de evidencias suele ser siempre, y en todos los casos, una de las tareas más tediosas y más difíciles de coordinar sobre todo en instalaciones multiplataforma, con gran cantidad de componentes y muchas aplicaciones involucradas. Por eso otra parte importante de las definiciones dentro de la estrategia es la generación y administración de las evidencias; respecto de esto debemos tener en cuenta dos principales aspectos que hacen a la optimización:

1. Definir qué tipo de evidencias se van a obtener por cada ítem observado y cuál va a ser su formato, para que nos certifiquen que la remediación ha sido efectiva y además sea aceptada por una probable Auditoría.

© 2013 CYBSEC 3

2. Determinar la completitud de datos que deban contener las evidencias, para optimizar la operación de obtención de las mismas y el volumen de archivos de datos a tratar y almacenar.

Como parte importante para concretar estos dos puntos y que también forma parte de la estrategia a seguir, es apoyarnos en nuestro equipo técnico para que nos ayude a definir las mejores herramientas automáticas o manuales con las cuales poder concretar la obtención de evidencias y remediar sin poner en riesgo la operación ni los diferentes componentes del complejo esquema de aplicaciones que da servicio al Negocio. Ahora bien, podemos tener el mejor equipo técnico que si no lo capacitamos a visualizar que una remediación no se trata solamente de configurar parámetros, seguramente nos encontraremos en problemas de optimización de tiempos y recursos. Entender la documentación (normas, estándares, manuales de aplicación, etc.), conocer los motivos de los cambios e interiorizarse del funcionamiento procedural de las aplicaciones ayuda a que puedan explotar de mejor forma sus conocimientos técnicos y nos aporten mejores soluciones a la hora de la remediación. Respecto de la documentación, es importante repasar nuestra biblioteca de gestión operativa y recomendar a las áreas Funcionales la importancia de contar con manuales de aplicaciones que puedan servirnos de guía cada vez que necesitemos recorrer el proceso tecnológico de las mismas, lo que nos permite analizar mejor las posibilidades de remediación sin riesgo o bien si debemos determinar una excepción. Y sobre las excepciones también debemos capacitar adecuadamente a nuestros equipos, para que sepan que herramientas utilizar para justificarlas y documentarlas basándose en limitaciones operativas netamente funcionales o bien por limitaciones tecnológicas generalmente basadas en la obsolescencia. Extractar las diferentes definiciones establecidas desde las Normas de Tecnología y Seguridad de la Información, sumado a los estándares de configuración técnica de cada una de las plataformas y trasladado a una matriz de control puede darnos una visión rápida sobre cuáles son los principales puntos por plataforma que están o deben ser exceptuados por razones técnicas, en cuyo caso debemos de acompañar a esta condición con el respaldo documentado del fabricante, por ejemplo una nota o parte del manual técnico donde se describa la situación de excepción. Las limitaciones funcionales que pueden imposibilitar la remediación de alguna de las capas tecnológicas provienen de Procesos de Negocio, los que habitualmente requieren que por razones operativas deban existir determinadas condiciones No-Compliance relacionadas por ejemplo con cuentas de usuario, privilegios o interfaces. Para estas situaciones debe analizarse en profundidad con los Funcionales cual sería el impacto de una posible remediación, que recursos y esfuerzos requeriría y que impacto económico o en otros Procesos de Negocio tendría. Esto determinaría como respuesta tres posibles salidas:

1. Que la remediación pueda hacerse, y dentro de los plazos estipulados.

2. Que pueda hacerse, pero no dentro de los plazos convenidos, para lo cual debe presentarse un Plan de Trabajo donde se informe el análisis realizado, actividades, recursos y fechas comprometidas

© 2013 CYBSEC 4

3. Que no pueda remediarse, para lo cual es necesario acompañar esta decisión del informe de análisis realizado y refrendado con una solicitud de excepción firmada por el Dueño del Proceso, que generalmente es el Gerente del Área de Negocio involucrada.

Con respecto al análisis de excepciones, y principalmente para el punto 3, es importante que tengan en cuenta que cada pedido de excepción hace que los controles que debo implantar para asegurar Confidencialidad, Integridad y Disponibilidad al Negocio suban en forma exponencial, por lo tanto una de las variables económicas y de esfuerzo a tener en cuenta para justificar una excepción también es saber cuánto le cuesta al Negocio esa excepción ya que requerirá una inversión adicional en aumentar los controles. O sea que, como primer ejercicio, debo comparar entre el costo de remediar versus el costo de controlar. Cada una de las actividades que hemos identificado deben plasmarse en una línea de tiempo acotada a lo requerido por la Compañía, por ello debemos definir un cronograma en donde se concatenen cada uno de los puntos anteriores para cumplir con los tiempos sin degradar las necesidades de conocimiento y coordinación. Para finalizar y conocer cómo se llegó a la necesidad de remediación (siempre y cuando la misma no surja de una necesidad de alcanzar el cumplimiento de una nueva regulación por parte de la Compañía), lo mejor es detectar mediante un análisis de riesgo y control sobre los procesos de Proyectos, Puesta en Producción, Operación y Mantenimiento las posibles oportunidades de impacto negativo que puedan hacer que nuestros sistemas o procesos sufran cambios inesperados o fuera de cumplimiento con lo estipulado por las necesidades del Negocio. Conclusión: Recordemos que todos somos el Negocio, valoremos ca da participación que tengamos en los diferentes frentes de trabajo y aprendamos que la t area en equipo nutre de conocimiento y genera UPGRADES, no PARCHES. Fabián Descalzo Gerente de Governace, Risk & Compliance (GRC) Cybsec S.A. – Security Systems Fabián Descalzo es Gerente de Governance, Risk & Compliance (GRC) en Cybsec S.A., Director Certificado en Seguridad de la Información (Universidad CAECE), certificado ITIL v3-2011 y auditor ISO 20000. Posee amplia experiencia en la implementación y cumplimiento de Leyes y Normativas Nacionales e Internacionales en compañías de primer nivel de diferentes áreas de negocio en la optimización y cumplimiento de la seguridad en sistemas de información, Gobierno de TI/SI y Continuidad del Negocio. Actualmente es responsable de servicios y soluciones en las áreas de Gobierno, Riesgos y Cumplimiento asociados al aseguramiento del Negocio CYBSEC S.A. desde 1996 se dedica exclusivamente a prestar servicios profesionales especializados en Seguridad de la Información. Su área de servicios cubre América y Europa y más de 400 clientes acreditan la trayectoria empresaria. Para más información: www.cybsec.com