Plan para implementaciones exitosas del sistema

Las organizaciones necesitan evaluar constantemente su arquitectura de sistemas e identificar proyectos que satisfagan las necesidades comerciales y añadan valor a la empresa. Los departamentos de tecnología de la información desempeñan un papel crucial a la hora de implementar sistemas, ya sea que los sistemas se desarrollen e implementen de manera interna o externa. Las decisiones importantes tomadas durante la implementación del sistema tienen un impacto en lo que ocurrirá en TI mucho después de que se completa un proyecto. Estos sucesos incluyen, pero no están limitados a los siguientes:

• La incapacidad de implementar ciertos tipos de tecnología en el futuro debido a la incompatibilidad con el sistema que se ha implementado
• Impactos financieros debido a que el equipo del proyecto no tuvo en cuenta los costos futuros del mantenimiento del sistema
• Implicaciones legales y de seguridad como resultado de que el equipo del proyecto ha fallado a la hora de evaluar e implementar las mejores prácticas de TI y los controles en el momento de la implementación
• Implicaciones en la continuidad del negocio porque los planes y procedimientos para la recuperación ante desastres no se consideraron adecuadamente en el tiempo de implementación

Todos los proyectos son únicos, pero existen principios básicos que los equipos de proyecto pueden aplicar para garantizar el éxito. Este documento describe los factores a considerar al implementar sistemas basados en las experiencias de proyectos del mundo real.

Gobernanza del proyecto

En un reciente proyecto de implementación de la red de área extendida definida por software (SD-WAN) en una empresa de fabricación farmacéutica en Sudáfrica, los miembros del equipo del proyecto descubrieron que sus expectativas y entregables eran diferentes de los de su socio de implementación de sistemas. El líder del proyecto constantemente tenía que hacer referencia al socio de implementación de sistemas de varios acuerdos y documentación que habían sido aprobados por ambas partes al comienzo del proyecto. Si parte de esta documentación básica del proyecto no hubiera sido aprobada, el esfuerzo y el costo para la empresa habrían sido significativamente más altos de lo esperado. Basado en este proyecto, el equipo del proyecto aprendió las siguientes lecciones clave:

• El objetivo del proyecto debe estar claramente definido, y el patrocinador (sponsor) del proyecto debe participar en la definición de los entregables claves antes de que comience el proyecto.
• Es posible que el equipo del proyecto no pueda documentar completamente las especificaciones técnicas del nuevo sistema al comienzo del proyecto. En estos casos, puede ser útil considerar ir al mercado con una solicitud de información (RFI) y consultar con expertos antes de emitir una solicitud de presupuesto o propuesta.
• Aunque el proyecto puede involucrar una nueva implementación del sistema o una mejora, el equipo del proyecto debe enfocarse en entender la configuración y los procesos del sistema actual (tal como está).
• Las empresas generalmente presupuestan los proyectos con un año de anticipación porque necesitan pasar por un proceso de aprobación del presupuesto. Si ha transcurrido un período de tiempo desde la aprobación del presupuesto y la fecha de inicio del proyecto, es beneficioso reevaluar la viabilidad del proyecto y el retorno esperado de la inversión (ROI), ya que proyectos recientes y cambios en el negocio pueden haber afectado los resultados del proyecto.
• Se debe redactar una descripción y declaración de intenciones del proyecto (project charter), y todas las partes responsables deben firmarlo al comienzo del proyecto. Este documento debe incluir detalles o referencias a otros documentos relevantes. Como mínimo, debe incluir lo siguiente:
  • Objetivos y resultados del proyecto
  • Elementos dentro del alcance, exclusiones y supuestos
  • Cronogramas de alto nivel y responsables. Los plazos detallados deben documentarse en el plan del proyecto.
• El plan del sistema (blueprint) es el documento más importante del proyecto. Debe ser revisado en detalle, ya que el documento del plan es la base para una implementación exitosa.
• Al inicio del proyecto, los siguientes registros deben guardarse en el repositorio de gestión del proyecto y mantenerse durante todo el proyecto:
  • Registro de decisiones. Las actas de las reuniones del comité directivo se pueden usar para determinar las decisiones clave del proyecto o para recoger el registro de decisiones. Es una cuestión de preferencia personal, pero a menudo es más sencillo usar un documento central o un registro en lugar de rastrear las decisiones clave en varias reuniones del comité directivo.
  • Registro de cambios
  • Registro de riesgos y problemas
  • Registro de Lecciones aprendidas. Este tipo de registro casi nunca se mantiene, lo que puede provocar que las empresas repitan errores costosos. Algunas empresas documentan las lecciones del proyecto como parte de la revisión posterior a la implementación. Sin embargo, se pueden aprender lecciones en cada etapa del proyecto desde el inicio hasta la finalización. Por lo tanto, es útil comenzar un registro de lecciones aprendidas al inicio del proyecto y agregarlo a lo largo del proyecto.
• Se deben programar reuniones periódicas del proyecto (por ejemplo, reuniones de actualización de estado semanales) y se deben definir los requisitos de la etapa. Las puertas de la etapa se usan para describir un punto en un proyecto o plan en el que se puede examinar el desarrollo y se pueden hacer cambios o decisiones importantes relacionadas con los costos, recursos, ganancias, etc.¹

EL PLAN DEL SISTEMA (BLUEPRINT) ES EL DOCUMENTO MÁS IMPORTANTE DEL PROYECTO

Hardware

Cuando una empresa decide implementar un sistema, generalmente define las especificaciones de hardware a un nivel muy amplio en la solicitud de propuesta (RFP) o en el documento de especificaciones de requisitos del usuario (URS), que es parte del proceso de licitación de compras. Si las especificaciones de hardware no están claramente definidas, el equipo de evaluación de ofertas puede encontrarse en una situación incómoda al comparar las propuestas de varios proveedores. Por ejemplo, el proveedor A puede proponer hardware superior, pero el proveedor B obtiene el mismo número de puntos de evaluación porque cumple con los requisitos establecidos en el documento RFP o URS. Por lo tanto, los equipos de proyecto deben evaluar sus requisitos de hardware desde un punto de vista crítico. Es una buena idea considerar lo siguiente, como mínimo:

• Las empresas deben definir estándares de hardware en términos de especificaciones mínimas y marcas preferidas.
• En algunos entornos, como la industria de fabricación farmacéutica, el uso de entornos y máquinas virtuales puede hacer que la administración de sistemas de TI sea más simple y eficiente. Si los sistemas son adecuados para entornos virtuales, es mucho más fácil para el equipo de TI añadir nuevas máquinas al proceso existente de copia de seguridad y replicación. Otras ventajas incluyen los beneficios de seguridad que vienen con los entornos virtuales.
• Si el proyecto implica el reemplazo de hardware que contiene datos (por ejemplo, discos duros), el hardware debe eliminarse de manera segura de acuerdo con las políticas y procedimientos de la empresa para la eliminación de datos confidenciales.

Sistema operativo

En un caso, un equipo de proyecto implementó un sistema sin tener en cuenta los requisitos del sistema operativo. Después de un tiempo, se evaluaron los controles generales de TI y los revisores observaron varios factores de riesgo de seguridad a nivel del sistema operativo. Posteriormente, el equipo del proyecto tuvo la tarea de remediar los problemas, y descubrió que, para hacerlo, el sistema de producción tenía que desconectarse. Como resultado, los esfuerzos de remediación supusieron el doble del tiempo de la configuración inicial. En base a las lecciones aprendidas de este proyecto, los equipos del proyecto deben considerar lo siguiente:

• Asegúrese de implementar la última versión estable del sistema operativo que sea compatible y con soporte. Parchee el sistema a los últimos niveles de parche antes de añadir aplicaciones y configurar servicios en el sistema.
• Deshabilite las cuentas predeterminadas y no use cuentas genéricas en el sistema. Cambie el nombre de las cuentas predeterminadas que sean necesarias. Es mucho más fácil configurar cuentas antes de instalar servicios y aplicaciones.
• Considere quién requerirá cuentas de administrador/privilegiadas y los niveles de acceso requeridos. Las cuentas locales deben tener los mismos requisitos de contraseña (es decir, longitud, complejidad, historial, bloqueo) que los establecidos en la política de seguridad corporativa.
• Evaluar los requisitos de seguimiento de auditoría. El registro de eventos predeterminado en Microsoft Windows tiene limitaciones conocidas (por ejemplo, facilidad de uso y período de retención). Considere usar herramientas de terceros para cubrir las necesidades.

Sistemas de control industrial

El Instituto Nacional de Estándares y Tecnología (NIST) de los EE.UU. define un sistema de control industrial (ICS) como:

Un sistema de información utilizado para controlar procesos industriales tales como fabricación, manejo de productos, producción y distribución. Los sistemas de control industrial incluyen control de supervisión y sistemas de adquisición de datos utilizados para controlar activos dispersos geográficamente, así como sistemas de control distribuido y sistemas de control más pequeños que utilizan controladores lógicos programables para controlar procesos localizados.²

LOS PROFESIONALES PUEDEN FIJARSE EN LA FUNCIONALIDAD DENTRO DE LA APLICACIÓN E IGNORAR.

Por lo tanto, los controles de TI y seguridad inadecuados en el ICS tendrán como resultado operaciones inseguras y poco confiables. Como mínimo, las empresas deben considerar los siguientes controles relacionados con el ICS:

• Lo más importante es segregar o segmentar redes para evitar la propagación de actividades maliciosas.
• Restrinja el acceso físico y lógico al ICS en la medida de lo posible.
• Limite las interconexiones entre el ICS y otras redes a través de zonas desmilitarizadas (DMZ), firewalls, servidores proxy o dispositivos especializados de filtrado de red.
• Implemente medidas y controles para reducir el riesgo de vulnerabilidades (por ejemplo, a través de la administración de parches y la configuración técnica).
• Agregue ICS a los planes existentes de respuesta a incidentes y recuperación de desastres.

Software

Los beneficios, la funcionalidad adicional y el valor esperado de los nuevos paquetes de software y aplicaciones impulsan a los equipos de TI a embarcarse en proyectos de implementación de sistemas. Sin embargo, los profesionales pueden fijarse en la funcionalidad dentro de la aplicación e ignorar la integración, la seguridad, el modelo de configuración y otros elementos clave relacionados con la aplicación misma. Algunos de estos elementos que los equipos de proyecto deben considerar incluyen:

• Aclarar el acuerdo de licencia de software (es decir, perpetuo versus suscripción) y registrar las claves de licencia en un lugar centralizado.
• Añadir cualquier software nuevo a la lista interna de software autorizado.
• Realizar pruebas de penetración y vulnerabilidad en aplicaciones.
• Configuración de la mayoría de los sistemas de software con una interfaz de servidor y cliente que se comuniquen. No es aconsejable permitir que los usuarios inicien sesión directamente en los servidores para acceder a las interfaces de la aplicación.
• Alinear los parámetros de contraseña en las aplicaciones con los establecidos en la política de seguridad corporativa. Las cuentas predeterminadas deben deshabilitarse, y las cuentas genéricas en el sistema no deben usarse. Cualquier cuenta predeterminada que se requiera debe renombrarse.
• Evaluar los requisitos de auditoría de la trazabilidad y garantizar que la trazabilidad sea completa y precisa y que no se pueda editar ni eliminar de ninguna manera.

Copias de seguridad

Imagine que un equipo de proyecto implementa con éxito un nuevo sistema dentro del tiempo asignado, el presupuesto y los parámetros de calidad, para luego perder todos esos beneficios debido a la corrupción de datos, el cibercrimen, la negligencia o el comportamiento malicioso. Diseñar copias de seguridad del sistema durante el proyecto puede costar tiempo, pero resultará ser una inversión inteligente si alguna vez es necesario recuperarse de un desastre. Como mínimo, los equipos de proyecto deben considerar lo siguiente:

• Actualizar los cronogramas de respaldo existentes para incluir el nuevo sistema que se está implementando y configurar alertas para eventos de respaldo (es decir, respaldos exitosos y fallidos).
• Tener en cuenta el impacto del código malicioso que se replica y su efecto en la capacidad del equipo para restaurar datos (es decir, copias de seguridad fuera de línea para evitar que el ransomware dañe demasiado a la empresa) si la organización se replica entre centros de datos.
• No pasar por alto las implicaciones del acceso a datos confidenciales por parte de personal no autorizado a través de la restauración de copias de seguridad sin cifrar. La mayoría de las organizaciones consideran los controles de seguridad cuando implementan sistemas, pero algunas se detienen allí.
• Considerando el objetivo del punto de recuperación (RPO) y el objetivo del tiempo de recuperación (RTO) para el sistema específico que se está implementando. El RPO se determina en función de la pérdida de datos aceptable en caso de una interrupción de las operaciones. Indicar el punto en el tiempo más temprano que es aceptable para recuperar los datos. El RPO cuantifica efectivamente la cantidad aceptable de pérdida de datos en caso de interrupción.³ El RTO se define como “la cantidad de tiempo permitido para la recuperación de una función o recurso comercial después de un desastre”⁴

DISEÑAR COPIAS DE SEGURIDAD DEL SISTEMA DURANTE EL PROYECTO PUEDE COSTAR TIEMPO, PERO RESULTARÁ SER UNA INVERSIÓN INTELIGENTE SI ALGUNA VEZ ES NECESARIO RECUPERARSE DE UN DESASTRE.

Revisiones periódicas

Considere el ejemplo de un padre muy tecnológicamente inteligente que compró un enrutador doméstico de Internet de los buenos y lo usó para implementar controles parentales en las tabletas de sus hijos. Unas semanas después, el padre notó que uno de sus hijos usaba una tableta fuera de las horas aceptables, como se definieron en el enrutador. Después de revisar los registros de actividad del enrutador, el padre correlacionó las horas en que la tableta estaba conectada al enrutador con las veces que vio al niño usando la tableta. El padre se sorprendió (pero quedó impresionado) al descubrir que un niño podía pasar fácilmente por alto los controles parentales conectándose directamente al extensor Wifi en lugar del enrutador. La revisión periódica de los registros garantiza que el sistema sea operado por personas autorizadas según lo previsto. Como mínimo, considere los siguientes controles de revisión para los sistemas que se están implementando:

• A nivel del sistema operativo, las siguientes revisiones deben llevarse a cabo periódicamente:
  • intentos de inicio de sesión exitosos y fallidos;
  • patrones de inicio de sesión (por ejemplo, intentos de inicio de sesión fuera del horario comercial);
  • tiempo transcurrido desde la última modificación de las contraseñas, especialmente para cuentas de administrador con un motivo comercial válido para no tener una antigüedad máxima de contraseña;
  • cambios de archivos y/o carpetas en el sistema operativo.
• A nivel de aplicación, los propietarios de la aplicación deberían definir, y deberían considerar procedimientos de auditoría y revisión periódica.

Prueba de sistema

Durante la fase de prueba, el plan de sistema (blueprint) debería compararse con el documento de como está construido y el sistema de producción en la realidad. Los usuarios comerciales necesitan ser incluidos en la fase de prueba, y las pruebas deben realizarse en un sistema que simule el entorno real. Otras consideraciones de prueba incluyen:

• Realización de pruebas de extremo a extremo, de interfaz, de compatibilidad, de estrés/volumen y de rendimiento.
• Probar la aplicación en diferentes sistemas operativos, teléfonos inteligentes, tabletas, computadoras de escritorio, clientes ligeros, etc.
• Probar la integración del Protocolo ligero de acceso a directorios (LDAP) y el impacto en la red.
• Realizar pruebas de integración completa para garantizar que no haya efectos adversos en módulos individuales.
• Realizar pruebas de caída y/o fallo del sistema para evaluar e identificar la gestión de errores y los procedimientos de recuperación del sistema.
• Enmascarar datos confidenciales y proteger o restringir el acceso a datos confidenciales durante la fase de prueba.

Post Implementación

Durante el proyecto, los derechos de acceso generalmente se relajan. Eliminar o destruir de forma segura las copias con información del negocio una vez que se completen las pruebas y revocar el acceso a terceros y al equipo del proyecto es esencial. El seguimiento de todos los problemas posteriores a la implementación y la actualización del registro de lecciones aprendidas en consecuencia también son acciones importantes posteriores a la implementación. Finalmente, el plan de recuperación ante desastres debe actualizarse al final del proyecto para incluir detalles del nuevo sistema.

Conclusión

Se pueden utilizar una serie de metodologías de gestión de proyectos, herramientas y listas de verificación al implementar sistemas de TI. Las recomendaciones en este documento no pretenden reemplazar ninguna de esas metodologías. Su objetivo es proporcionar a los equipos de proyecto elementos complementarios a tener en cuenta y están basadas en la experiencia con los principales proyectos de implementación del sistema. Las lecciones compartidas en este artículo se resumen en la figura 1 para recordar a los equipos de proyecto las consideraciones clave en cada fase del proyecto de implementación del sistema.

Notas finales

¹ Cambridge Dictionary, “stage gate,” https://dictionary.cambridge.org/dictionary/english/stage-gate
² National Institute of Standards and Technology, “Assessing Security and Privacy Controls in Federal Information Systems and Organizations,” Special Publication (SP) 800-53A, EE.UU., deciembre de 2014, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf
³ ISACA^®, Glosario, “Recovery point objective,” https://www.isaca.org/resources/glossary#glossr
⁴ ISACA, Glosario, “Recovery time objective,” https://www.isaca.org/resources/glossary#glossr

Hashim Seedat, CISA
Actualmente es el jefe de tecnología de la información en el National Bioproducts Institute NPC (NBI), con sede en Durban, Sudáfrica. Antes de unirse a NBI, fue miembro senior de la oficina de PricewaterhouseCoopers (PwC) Durban, liderando auditorías de TI y brindando seguridad a los clientes sobre las principales implementaciones de proyectos. Seedat prestó servicios en varias oficinas de PwC a nivel mundial, incluidas las oficinas de PwC en Boston (Massachusetts, EE. UU.) Y Atlanta (Georgia, EE. UU.), Y también realizó revisiones de calidad de auditoría interna en nombre de las firmas miembro de PwC.