Cierre de proyectos desde seguridad de la información y cumplimiento

ConexionesAnte cualquier proyecto de TI, ya sea que esté relacionado con el desarrollo de software, interfaces informáticas, modificaciones o implantaciones de activos informáticos, es necesario definir la información y registros necesarios como respaldo de certificación del cierre de proyecto, y adicionalmente para el aseguramiento del traspaso de la operación de seguridad aplicativa. Como complemento de estas dos condiciones y para realizar el cierre formal, se debe completar la actividad de verificación de cumplimiento que incluya las siguientes tareas principales:

  • Recolección de evidencias de pruebas en los diferentes ambientes y durante todo el ciclo de vida del proyecto.
  • Definición de la matriz de riesgos del aplicativo o activo informático, con su análisis correspondiente.
  • Metodología documental para las excepciones surgidas.
  • Definición de la estrategia de traspaso de operación de seguridad lógica.
  • Biblioteca de manuales operativos para la gestión de seguridad aplicativa.

La actividad de verificación de cumplimiento está directamente relacionada con la terminación del proyecto y por ello se debe identificar e incluir en el plan de línea base. Estas tareas abarcan organizar y archivar documentación del proyecto, como evidencias, excepciones, manuales operativos y técnicos, instructivos, y cualquier otra información a utilizar tanto en la fase productiva como en las acciones de monitoreo, control y auditoría por parte del personal de áreas de seguridad de la información y cumplimiento.

Al cerrar el proyecto, el gerente de proyecto debe revisar toda la información de los cierres de fases anteriores, para estar seguro de que se tiene toda la información necesaria. Se debe verificar, documentar y obtener evidencia de:

  1. Los controles, surgidos de un análisis de riesgos, a implantar en los sistemas, identificando y evaluando las interdependencias entre el nuevo sistema y los otros que se encuentran en el entorno de explotación (mapa de interfaces).
  2. La incorporación de rutinas y controles que contemplen tanto los requerimientos del negocio como los de seguridad de la aplicación o activo informático. Las rutinas y controles a considerar en todas las aplicaciones deben ser:
    • Agregado o limitación de funcionalidades.
    • Modificación de información.
    • Detección y corrección de errores.
    • Prevención de ejecución desordenada de rutinas.
    • Recuperación frente a errores.
  3. Que se hayan considerado los controles de autenticación y autorización dentro de las aplicaciones, que los mismos sean centralizados y obligatorios, conforme lo haya definido el dueño del sistema.
  4. Que aquellas funcionalidades que no estén permitidas a los usuarios sean deshabilitadas para evitar violaciones en la estrategia de seguridad en activos informáticos.
  5. Que exista una capa de acceso seguro entre la información interna de la aplicación y las interfaces externas, lo que implicaría que todas las comunicaciones ocurren a través de caminos confiables. Internet y las redes inalámbricas son ejemplos de redes no confiables.
  6. Que los procesos, cuentas y permisos estén diseñados para que se ejecuten con los mínimos privilegios necesarios.
  7. La implementación de salvaguardas a nivel de procedimiento mediante la segregación de tareas, bajo el concepto de control doble o por oposición de intereses, para evitar fallos en los procesos que pudieran tener un impacto económico o regulatorio.
  8. Segregar adecuadamente la nómina de roles y perfiles resultantes del módulo de seguridad de la aplicación.
  9. Los registros obtenidos de las pruebas de seguridad que incluyan fundamentalmente los siguientes aspectos:
    • Autenticación
    • Autorización
    • Certificados
    • Firewalls y otros métodos de control de acceso a redes
    • Visualización y configuración de opciones de seguridad
    • Cifrado y control de transmisión
    • Control de interfaces
  10. Los registros obtenidos de los casos de prueba deberán incluir tanto la información esperada como no esperada, para asegurar que los controles de validación sean efectivos.
  11. Todas las pruebas realizadas a modificaciones, mejoras considerables y los sistemas nuevos deben estar debidamente documentadas previamente a la instalación del software en ambiente productivo, y recibir la aprobación para su implantación por parte del dueño de la aplicación, sistema o información.

Importante: La documentación de las pruebas y de las vulnerabilidades identificadas de los sistemas y aplicaciones deberá protegerse de manera adecuada.

.

Transición de la administración de seguridad aplicativa

El documento de cierre de proyecto debe incluir un capítulo en el que se desarrolle el proceso de traspaso de la administración de la seguridad de la aplicación. Este capítulo debe estar consensuado con el personal de seguridad de la información responsable de la futura administración.

En este punto se debe agrupar la información administrativa en un documento que podría denominarse “Manual de Operación de Seguridad”, que incluya la información relacionada con los siguientes procesos:

  • Gestión de configuración de la seguridad (módulo y opciones de aseguramiento de la aplicación o activo informático).
  • Gestión de identidades y accesos (roles y perfiles asociados a la aplicación, tipo de autorizaciones de acceso y detalle de ejecución de ABC de cuentas de usuario).
  • Gestión de pistas de auditoría y reportes (administración de bitácoras, desde la configuración de opciones de generación hasta su recolección).

.

Conclusión

Estas actividades de cierre propuestas, y que deben considerarse por parte de seguridad de la información y cumplimiento, aportarán a los proyectos:

  • Garantizar la certificación por parte de las áreas de Seguridad Informática en los aspectos referidos al aseguramiento de la confidencialidad, integridad y disponibilidad de la información.
  • Asegurar la condición de cumplimiento (compliance) del resultante de cada proyecto, con el marco regulatorio y la política de seguridad establecida por la organización.
  • Establecer condiciones de seguridad, control y auditoría en forma anticipada con otras áreas o terceros que deben administrar u operar el activo de información o aplicación en producción.

.

[email protected]

 

Fabián Descalzo, COBIT5 Foundation, Lead Auditor ISO/IEC 20000:2011, ISMS Auditor/Lead Auditor ISO/IEC 27001

Gerente de Servicios y Soluciones en el área de Gobierno, Riesgo y Cumplimiento (GRC) en Deloitte & Co., con 28 años de 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 y Gobierno de Seguridad de la Información. Miembro del Comité Directivo del “Cyber Security for Critical Assets LATAM Summit” para Qatalys Global sección Infraestructura Crítica (Gobiernos y empresas de América Latina en el sector de la energía, química, petróleo y gas), Miembro del Comité Científico ARGENCON del IEEE (Institute of Electrical and Electronics Engineers), Miembro del Comité Organizador CYBER 2015 de ADACSI/ISACA, certificado en Dirección de Seguridad de la Información (Universidad CAECE), instructor certificado ITIL Fundation v3-2011 (EXIN), auditor ISO 20000 (LSQA-Latu), IRCA ISMS Auditor / Lead Auditor ISO/IEC 27001 y Lead Auditor ISO/IEC 20000 TÜV Rheinland. Columnista especializado en áreas de Gobierno, Seguridad y Auditoría, Informática en Salud y Compliance en las revistas CISALUD, PERCEPCIONES (ISACA Montevideo Chapter), El Derecho Informático, CXO-Community, EXIN Newsletter y MAGAZCITUM; y disertante para CXO-COMMUNITY, Consejo Profesional de Ciencias Informáticas, ISACA Buenos Aires Chapter, ISACA Montevideo Chapter. Docente del módulo 27001 del curso de “IT Governance, Uso eficiente de Frameworks” y de la “Diplomatura en Gobierno y Gestión de Servicios de IT” del Instituto Tecnológico de Buenos Aires (ITBA); Docente en “Sistemas de Gestión IT” y “Seguridad de la Información” en TÜV Rheinland Argentina, Docente del módulo Auditoría y Control en Seguridad de la Información en la Universidad Nacional de Rio Negro. 

Tags:

  2 comments for “Cierre de proyectos desde seguridad de la información y cumplimiento

  1. Arjun
    01/07/2016 at 4:19 AM

    Information security is sometime shortened to InfoSec, this is the practice section of defending information from disclosure. It was the general term which can be used with some physical data

  2. Mark
    01/07/2016 at 6:50 AM

    Thank you for your posting. Actually information security is designed to protect the integrity and availability of computer system from intention. This has evolved into what is the common term that includes confidential

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.