CAPITULO 12

12. ADQUISICIÓN, DESARROLLO Y MANTENIMIENTO DE SISTEMAS DE INFORMACIÓN

12.1 REQUISITOS DE SEGURIDAD DE LOS SISTEMAS DE INFORMACIÓN

Objetivo: garantizar que la seguridad es parte integral de los sistemas de información.

Los sistemas de información incluyen sistemas operativos, infraestructura, aplicaciones del negocio, productos de vitrina, servicios y aplicaciones desarrolladas para usuarios. El diseño y la implementación del sistema de información que da soporte a los procesos del negocio pueden ser cruciales para la seguridad. Se deberían identificar y acordar los requisitos de seguridad antes del desarrollo y / o la implementación de los sistemas de información.

Todos los requisitos de seguridad se deberían identificar en la fase de requisitos de un proyecto y se deberían justificar, acordar y documentar como parte de todo el caso del negocio para un sistema de información.

12.1.1 Análisis y especificación de los requisitos de seguridad

Control

Las declaraciones sobre los requisitos del negocio para nuevos sistemas de información o mejoras a los sistemas existentes deberían especificar los requisitos para los controles de seguridad.

Guía de implementación

En las especificaciones para los requisitos de control se deberían considerar los controles automatizados que se han de incorporar en el sistema de información y la necesidad de controles manuales de apoyo. Se deberían aplicar consideraciones similares al evaluar los paquetes de software, desarrollados o adquiridos, para las aplicaciones del negocio.

Los requisitos de seguridad y los controles deberían reflejar el valor para el negocio de los activos de información involucrados (véase el numeral 7.2) y el daño potencial para el negocio que se puede presentar debido a falla o ausencia de seguridad.

Los requisitos del sistema para la seguridad de la información y los procesos para implementarla se deberían integrar en las fases iniciales de los proyectos del sistema de información. Los controles introducidos en la etapa de diseño son significativamente más baratos de implementar y mantener que aquellos incluidos durante o después de la implementación.

Si se adquieren productos, se debería seguir un proceso formal de adquisición y prueba. Los contratos con el proveedor deberían abordar los requisitos de seguridad identificados. Cuando la funcionalidad de la seguridad de un producto determinado no satisface el requisito específico, entonces es conveniente considerar los controles de los riesgos, introducidos y asociados, antes de adquirir el producto. Cuando se proporciona funcionalidad adicional y ello causa un riesgo de seguridad, tal funcionalidad se debería inhabilitar o se debería revisar la estructura del control propuesto para determinar si se puede obtener ventaja de la funcionalidad mejorada disponible.

Información adicional

Si se considera apropiado, por ejemplo por razones de costos, la dirección podría utilizar productos certificados y evaluados independientemente. Información adicional sobre los criterios para los productos de seguridad de la tecnología de la información se puede encontrar en la norma ISO/IEC 15408 o en otras normas sobre evaluación y certificación, según sea apropiado.

La norma ISO/IEC TR 13335-3 proporciona directrices sobre el uso de procesos de gestión de riesgos para identificar los requisitos de los controles de seguridad.

12.2 PROCESAMIENTO CORRECTO EN LAS APLICACIONES

Objetivo: evitar errores, pérdidas, modificaciones no autorizadas o uso inadecuado de la información en las aplicaciones.

Se deberían diseñar controles apropiados en las aplicaciones, incluyendo las aplicaciones desarrolladas por el usuario para garantizar el procesamiento correcto. Estos controles deberían incluir la validación de los datos de entrada, del procesamiento interno y de los datos de salida.

Se pueden necesitar controles adicionales para los sistemas que procesan o tienen impacto en la información sensible, de valor o crítica. Dichos controles se deberían determinar con base en los requisitos de seguridad y en la evaluación de riesgos.

12.2.1 Validación de los datos de entrada

Control

Se deberían validar los datos de entrada a las aplicaciones para asegurar que dichos datos son correctos y apropiados.

Guía de implementación

Es recomendable realizar verificaciones de las entradas de las transacciones del negocio, de los datos permanentes (por ejemplo, nombres y direcciones, límites de crédito, números de referencia del cliente) y de las tablas de parámetros ( por ejemplo, precios de venta, tasas de conversión de divisas, tasas de impuestos). Se recomienda tomar en consideración las siguientes directrices:

a). verificaciones de entradas duales u otras entradas, tales como verificación de fronteras o campos limitantes para especificar los rangos de los datos de entrada, con el fin de detectar los siguientes errores:

1). valores fuera de rango;

2). caracteres no válidos en los campos de datos;

3). datos incompletos o ausentes;

4). exceso en los límites superiores e inferiores del volumen de datos;

5). datos de control inconsistentes o no autorizados;

b). revisión periódica del contenido de los campos clave o de los archivos de datos para confirmar su validez e integridad;

c). inspección de los documentos de entrada impresos para determinar cambios no autorizados (todos los cambios en los datos de entrada deben estar autorizados);

d). procedimientos de respuesta ante errores de validación;

e). procedimientos para probar la credibilidad de los datos de entrada;

f). definición de responsabilidades para todo el personal que participa en el proceso de entrada de datos;

g). creación de un registro de las actividades implicadas en el proceso de entrada de datos (véase el numeral 10.10.1).

Información adicional

Se recomienda la inspección y la validación automática de los datos de entrada, cuando se puedan aplicar, para reducir el riesgo de errores y evitar ataques normales, incluyendo desbordamiento de búfer o inyección de códigos.

12.2.2 Control de procesamiento interno

Control

Se deberían incorporar verificaciones de validación en las aplicaciones para detectar cualquier corrupción de la información por errores de procesamiento o actos deliberados.

Guía de implementación

El diseño y la implementación de las aplicaciones deberían garantizar que se minimizan los riesgos de falla en el procesamiento, los cuales originan pérdida de la integridad. Las áreas específicas que se han de considerar incluyen:

a). utilización de las funciones agregar, modificar y borrar para implementar los cambios en los datos;

b). procedimientos para evitar que los programas se ejecuten en orden erróneo o su ejecución después de falla previa del procesamiento (véase el numeral 10.1.1);

c). utilización de programas adecuados para la recuperación después de fallas con el fin de garantizar el procesamiento correcto de los datos;

d). protección contra ataques empleando desbordamiento / exceso en el búfer.

Se deberían elaborar listas de verificación adecuadas, documentar las actividades y mantener seguros los resultados. Los siguientes son algunos ejemplos de verificaciones que se pueden incorporar:

a). controles de sesión o de lotes, para conciliar los balances de archivos de datos después de actualizar las transacciones;

b). controles de balance, para verificar los balances de apertura frente a los balances de cierre previos, a saber:

1).controles para cada ejecución;

2). totales de actualizaciones de archivos;

3). controles programa a programa;

c). validación de los datos de entrada generados por el sistema (véase el numeral 12.2.1);

d). verificaciones de la integridad, la autenticidad o cualquier otra característica de seguridad de los datos o del software descargado o actualizado entre el computador central y el remoto;

e). totales de verificación (hash) de registros y archivos;

f). verificaciones para garantizar que los programas de aplicación se ejecutan en el momento correcto;

g). verificaciones para garantizar que los programas se ejecutan en el orden correcto y terminan en caso de falla, y que el procesamiento posterior se detiene hasta resolver el problema;

h). creación de un registro de las actividades implicadas en el procesamiento (véase el numeral 10.10.1).

Información adicional

Los datos que se han ingresado correctamente se pueden corromper por errores de software, errores de procesamiento o a través de actos deliberados. Las verificaciones de validación requeridas dependerán de la naturaleza de la aplicación y del impacto de la corrupción de los datos en el negocio.

12.2.3 Integridad del mensaje

Control

Se deberían identificar los requisitos para asegurar la autenticidad y proteger la integridad del mensaje en las aplicaciones, así como identificar e implementar los controles adecuados.

Guía de implementación

Se debería realizar una evaluación de los riesgos de seguridad para determinar si se requiere integridad del mensaje y para identificar el método más apropiado de implementación.

Información adicional

Se pueden usar las técnicas criptográficas (véase el numeral 12.3) como un medio apropiado para implementar la autenticación del mensaje.

12.2.4 Validación de los datos de salida

Control

Se deberían validar los datos de salida de una aplicación para asegurar que el procesamiento de la información almacenada es correcto y adecuado a las circunstancias.

Guía de implementación

La validación de los datos de salida puede incluir:

a). verificaciones de la verosimilitud para probar si los datos de salida son razonables;

b). cuentas de control de conciliación para asegurar el procesamiento de todos los datos;

c). suministro de información suficiente para que un lector o un sistema de procesamiento posterior determine la exactitud, totalidad, precisión y clasificación de la información;

d). procedimientos para responder las pruebas de validación de salidas;

e). definición de las responsabilidades de todo el personal que participa en el proceso de la salida de datos;

f). creación de un registro de las actividades del proceso de validación de la salida de datos.

Información adicional

Comúnmente, los sistemas y las aplicaciones se construyen asumiendo que al realizar la validación, la verificación y las pruebas adecuadas, la salida siempre será correcta. Sin embargo, esta suposición no siempre es válida; es decir, los sistemas que se han sometido a prueba aún pueden producir salidas incorrectas en algunas circunstancias.

12.3 CONTROLES CRIPTOGRÁFICOS

Objetivo: proteger la confidencialidad, autenticidad o integridad de la información, por medios criptográficos.

Se debería desarrollar una política sobre el uso de los controles criptográficos y establecer una gestión de claves para dar soporte al empleo de técnicas criptográficas.

12 Política sobre el uso de controles criptográficos.3.1

Control

Se debería desarrollar e implementar una política sobre el uso de controles criptográficos para la protección de la información.

Guía de implementación

Se recomienda tomar en consideración los siguientes aspectos al desarrollar una política criptográfica:

a). el enfoque de la dirección hacia el uso de controles criptográficos en toda la organización, incluyendo los principios generales bajo los cuales se debería proteger la información del negocio (véase el numeral 5.1.1);

b). con base en la evaluación de riesgos, se debería identificar el nivel requerido de protección teniendo en cuenta tipo, fortaleza y calidad del algoritmo de encriptación requerido;

c). uso de encriptación para la protección de la información sensible transportada por medios móviles o removibles, por dispositivos o a través de las líneas de comunicación;

d). enfoque para la gestión de claves, incluyendo los métodos para tratar la protección de las claves criptográficas y la recuperación de información encriptada en caso de pérdida, amenaza o daño de las claves;

e). funciones y responsabilidades, por ejemplo, quién es responsable de:

1). la implementación de la política;

2). la gestión de claves, incluyendo su generación (véase el numeral 12.3.2);

f). normas que se han de adoptar para la implementación eficaz en toda la organización (qué solución se usa para cuáles procesos del negocio);

g). impacto de la utilización de información encriptada sobre los controles que depende de la inspección del contenido (por ejemplo, detección de virus).

Cuando se implementa la política de encriptación de la organización, es conveniente tener en mente los reglamentos y las restricciones nacionales que se pueden aplicar al uso de técnicas criptográficas en diferentes partes del mundo y los aspectos del flujo trans-fronterizo de información encriptada (véase el numeral 15.1.6).

Los controles criptográficos se pueden utilizar para lograr diferentes objetivos de seguridad, por ejemplo:

a). confidencialidad: uso de encriptación de la información para proteger información sensible o crítica, bien sea almacenada o transmitida;

b). integridad / autenticidad: uso de firmas digitales o códigos de autenticación de mensajes para proteger la autenticidad e integridad de información sensible o crítica transmitida o almacenada;

c). no-repudio: uso de técnicas criptográficas para obtener prueba de la ocurrencia o no ocurrencia de un evento o acción.

Información adicional

La decisión sobre la idoneidad de la solución criptográfica debería formar parte del proceso más amplio de evaluación de riesgos y selección de controles. Esta evaluación se puede usar para determinar si un control criptográfico es adecuado, el tipo de control que se debería aplicar y para qué propósito y cuál proceso del negocio.

La política sobre el empleo de controles criptográficos es necesaria para maximizar los beneficios y minimizar los riesgos de usar las técnicas criptográficas, y para evitar el uso incorrecto o inapropiado. Cuando se utilizan firmas digitales, se recomienda considerar toda la legislación pertinente, en particular la legislación que describe las condiciones bajo las cuales la firma digital es legalmente obligatoria (véase el numeral 15.1).

Es conveniente buscar asesoría especializada para identificar el nivel apropiado de protección y definir las especificaciones adecuadas que suministrarán la protección requerida y el soporte a la implementación de un sistema seguro de gestión de claves (véase el numeral 12.3.2).

El comité ISO/IEC JTC1 SC27 ha desarrollado varias normas relacionadas con los controles criptográficos. Información adicional se puede encontrar en la norma IEEE P1363 y en las directrices OECD sobre criptografía.

12.3.2 Gestión de claves

Control

Se debería establecer la gestión de claves para apoyar el uso de técnicas criptográficas en la organización.

Guía de implementación

Todas las claves criptográficas deberían tener protección contra modificación, pérdida y destrucción. Además, las claves privadas y secretas necesitan protección contra divulgación no autorizada. El equipo usado para generar, almacenar y archivar las claves debería estar protegido por medios físicos.

Un sistema de gestión de claves se debería basar en un conjunto acordado de normas, procedimientos y método seguros para:

a). generar claves para diferentes sistemas criptográficos y diferentes aplicaciones;

b). generar y obtener certificados de claves públicas;

c). distribuir claves a los usuarios previstos, incluyendo la forma de activar y recibir las claves;

d). almacenar las claves, incluyendo la forma en que los usuarios autorizados tendrán acceso a ellas;

e). cambiar o actualizar las claves incluyendo reglas sobre cuándo cambiarlas y cómo hacerlo;

f). tratar las claves perdidas;

g). revocar las claves, incluyendo la forma de retirarlas o desactivarlas, por ejemplo cuando las claves se han puesto en peligro o cuando un usuario se retira de la organización (en cuyo caso las claves también se deberían archivar);

h). recuperar claves pérdidas o corruptas como parte de la gestión de continuidad del negocio; por ejemplo, para la recuperación de información encriptado; archivar claves, por ejemplo para la información archivada o con copia de respaldo;

j). destrucción de claves;

k). registro y auditoría de las actividades relacionadas con la gestión de claves.

Para reducir la probabilidad de poner en peligro, activar o desactivar se deberían definir fechas para las claves de modo que sólo se puedan utilizar durante un periodo de tiempo limitado.

Este período dependería de las circunstancias en las cuales se usa el control criptográfico y del riesgo percibido.

Además de las claves privadas y secretas con gestión segura, también se debería pensar en la autenticidad de las claves públicas. Este proceso de autenticación se puede hacer con certificados de claves públicas que normalmente son emitidos por una autoridad de certificación, la cual debe ser una organización reconocida con controles y procedimientos idóneos establecidos para proporcionar el grado requerido de confianza.

El contenido de los acuerdos o contratos de servicios con proveedores externos de servicios criptográficos, por ejemplo con una autoridad de certificación, deberían comprender aspectos de responsabilidad, confiabilidad de los servicios y tiempos de respuesta para la prestación de los servicios (véase el numeral 6.2.3).

Información adicional

La gestión de las claves criptográficas es esencial para el uso eficaz de las técnicas criptográficas. La norma ISO/IEC 11770 brinda información adicional sobre la gestión de claves. Los dos tipos de técnicas criptográficas son:

a). técnicas de clave secreta, en donde dos o más partes comparten la misma clave y ésta se usa tanto para encriptar como desencriptar información; esta clave debe mantenerse secreta puesto que cualquiera que tenga acceso a ella puede descifrar toda la información encriptada con dicha clave, o introducir información no autorizada con esa clave;

b). técnicas de clave pública, en donde cada usuario tiene un par de claves, una clave pública (que se puede revelar a cualquiera) y una clave privada (que se debe mantener en secreto); las técnicas de clave pública se pueden usar para la encriptación y para producir firmas digitales (véase la norma ISO/IEC 9796 e ISO/IEC 14888).

Existe la amenaza de falsificar una firma digital reemplazando la clave pública del usuario. Este problema se puede tratar usando un certificado de clave pública.

Las técnicas criptográficas también se pueden usar para proteger las claves criptográficas. Es necesario que en los procedimientos se considere el manejo de solicitudes legales para acceder a las claves criptográficas, por ejemplo, puede ser necesario poner a disposición la información encriptada en un formato sin encriptación como evidencia en caso de un juicio.

12.4 SEGURIDAD DE LOS ARCHIVOS DEL SISTEMA

Objetivo: garantizar la seguridad de los archivos del sistema.

Los accesos a los archivos del sistema y al código fuente del programa deberían estar protegidos, y los proyectos de tecnología de la información y las actividades de soporte se deberían efectuar de forma segura. Se debería tener cuidado para evitar la exposición de datos sensibles en los entornos de prueba.

12.4.1 Control del software operativo

Control

Se deberían establecer procedimientos para controlar la instalación de software en los sistemas operativos.

Guía de implementación

Para minimizar los riesgos de corrupción de los sistemas operativos, se deberían tener en cuenta las siguientes directrices para controlar los cambios:

a). la actualización del software operativo, las aplicaciones y las librerías de los programas sólo deberían ser realizadas por administradores capacitados y con la debida autorización de la dirección (véase el numeral 12.4.3);

b). los sistemas operativos únicamente deberían contener códigos ejecutables aprobados y no códigos en desarrollo ni compiladores;

c). el software de las aplicaciones y del sistema operativo sólo se deberían implementar después del ensayo exhaustivo y exitoso; los ensayos deberían incluir pruebas sobre capacidad de uso, seguridad, efectos en otros sistemas y facilidad para el usuario, igualmente se deberían efectuar en sistemas separados (véase el numeral 10.1.4); se debería garantizar que todas las librerías fuente del programa correspondiente estén actualizadas;

d). se debería usar un sistema de control de configuración para mantener el control el software implementado, así como de la documentación del sistema;

e). es conveniente instaurar una política de estrategia de restauración al estado anterior antes de implementar los cambios;

f). se debería conservar un registro para auditoría de todas las actualizaciones de las librerías de los programas operativos;

g). es conveniente conservar las versiones anteriores del software de aplicación como medida de contingencia;

h). las versiones antiguas del software se deberían archivar junto con toda la información requerida y los parámetros, procedimientos, detalles de configuración y software de soporte, en la medida en que los datos se retengan en archivo.

El software suministrado por el vendedor utilizado en los sistemas operativos se debería mantener en el nivel con soporte del proveedor. Con el tiempo, los vendedores de software dejarán de dar soporte a las versiones antiguas del software. La organización debería considerar los riesgos de depender de software sin soporte.

En toda decisión para mejorar a una nueva versión se debería contar con los requisitos del negocio para el cambio, y la seguridad de la nueva versión, es decir, la introducción de nueva funcionalidad en el sistema o la cantidad y gravedad de los problemas de seguridad que afectan a esta versión. Los parches de software se deberían aplicar cuando pueden ayudar a eliminar o reducir las debilidades de la seguridad (véase el numeral 12,6,1).

El acceso físico o lógico únicamente se debería dar a los proveedores para propósitos de soporte, cuando sea necesario, y con aprobación de la dirección. Las actividades del proveedor se deberían monitorear.

El software de computador puede depender de software y módulos suministrados externamente, lo cual se debería monitorear y controlar para evitar cambios no autorizados que puedan introducir debilidades de seguridad.

Información adicional

Los sistemas operativos únicamente se deberían mejorar cuando existe un requisito para hacerlo, por ejemplo, si la versión actual del sistema operativo ya no da soporte a los requisitos del negocio. Las mejoras no deberían tener lugar sólo porque esté disponible una nueva versión del sistema operativo. Las versiones nuevas del sistema operativo pueden ser menos seguras, menos estables, y menos entendidas que los sistemas actuales.

12.4.2 Protección de los datos de prueba del sistema

Control

Los datos de prueba deberían seleccionarse cuidadosamente, así como protegerse y controlarse.

Guía de implementación

Se debería evitar el uso de bases de datos operativos que contienen información personal o cualquier otra información sensible con propósitos de prueba. Si se utiliza información personal o de otra forma sensible para propósitos de prueba, todos los detalles y el contenido sensible se deberían retirar o modificar antes del uso para evitar el reconocimiento. Las siguientes directrices se deberían aplicar para proteger los datos operativos cuando se emplean con propósitos de prueba:

a). los procedimientos de control del acceso que se aplican a los sistemas de aplicación operativos también se deberían aplicar a los sistemas de aplicación de pruebas;

b). debería existir autorización separada cada vez que se copia la información operativa en un sistema de aplicación de prueba;

c). la información operativa se debería borrar del sistema de aplicación de prueba inmediatamente después de terminar la prueba;

d). el copiado y utilización de la información operativa se debería registrar para brindar un rastro para auditoría.

Información adicional

La prueba del sistema y de aceptación usualmente exige volúmenes sustanciales de datos de prueba que sean lo más cercanos posible a los datos operativos.

12.4.3 Control de acceso al código fuente de los programas

Control

Se debería restringir el acceso al código fuente de los programas.

Guía de implementación

El acceso al código fuente de programas y a los elementos asociados (como diseños, especificaciones, planes de verificación y planes de validación) se debería controlar estrictamente para evitar la introducción de funcionalidad no autorizada y evitar los cambios involuntarios. Para el código fuente de programas esto se puede lograr con el almacenamiento central controlado de dicho código, preferiblemente en las librerías fuente de programas. Las siguientes directrices se deberían considerar (véase el numeral 11) para controlar el acceso a tales librerías fuente de programas, con el objeto de reducir el potencial de corrupción de los programas de computador:

a). cuando sea posible, las librerías fuente de programas no se deberían mantener en los sistemas operativos;

b). el código fuente de programas y las librerías fuente de programas se deberían gestionar de acuerdo con los procedimientos establecidos;

c). el personal de soporte debería tener acceso restringido a las librerías fuente de programas;

d) la actualización de las librerías fuente de programas y de los elementos asociados, así como la emisión de fuentes de programa a los programadores, solamente se debería efectuar después de recibir la autorización apropiada;

e). los listados de programas se deberían mantener en un entorno seguro (véase el numeral 10.7.4);

f). se debería conservar un registro para auditoría de todos los accesos a las librerías fuente de programas;

g). el mantenimiento y el copiado de las librerías fuente de programas deberían estar sujetos a un procedimiento estricto de control de cambios (véase el numeral 12.5.1).

Información adicional

El código fuente de programas es un código escrito por los programadores, el cual está compilado (y enlazado) para crear ejecutables. Algunos lenguajes de programación no distinguen formalmente entre el código fuente y los ejecutables ya que estos últimos se crean en el momento en que se activan.

Las normas NTC-ISO 10007 y NTC 4243 brindan información adicional sobre la gestión de la configuración y el proceso del ciclo de vida del software.

12.5 SEGURIDAD EN LOS PROCESOS DE DESARROLLO Y SOPORTE

Objetivo: mantener la seguridad del software y de la información del sistema de aplicaciones.

Los entornos de soporte y de desarrollo deberían estar estrictamente controlados.

Los directores responsables de los sistemas de aplicación también deberían ser responsables de la seguridad del entorno del proyecto o del soporte. Ellos deberían garantizar que todos los cambios propuestos en el sistema se revisan para comprobar que no ponen en peligro la seguridad del sistema ni del entorno operativo.

12.5.1 Procedimientos de control de cambios

Control

Se debería controlar la implementación de cambios utilizando procedimientos formales de control de cambios.

Guía de implementación

Los procedimientos formales de control de cambios se deberían documentar y hacer cumplir para minimizar la corrupción de los sistemas de información. La introducción de sistemas nuevos y de cambios importantes en los sistemas existentes debería seguir un proceso formal de documentación, especificación, prueba, control de calidad e implementación con gestión.

Este proceso debería incluir una evaluación de riesgos, análisis de los impactos de los cambios y especificación de los controles de seguridad necesarios. Este proceso también debería garantizar que la seguridad y los procesos de control existentes no se ponen en peligro, que se da acceso a los programadores de soporte sólo a aquellas partes del sistema necesarias para su trabajo y que existe acuerdo y aprobación formal para cualquier cambio.

Siempre que sea factible, los procedimientos de control de cambios operativos y de aplicación se deberían integrar (véase el numeral 10.1.2). Los procedimientos de control de cambios deberían incluir:

a). el mantenimiento de un registro de los niveles acordados de autorización;

b). la garantía de que los cambios son realizados por los usuarios autorizados;

c). la revisión de los controles y de los procedimientos de integridad para asegurar que no se pondrán en peligro debido a los cambios;

d). la identificación de todo el software, la información, las entidades de bases de datos y del hardware que requieran mejora;

e). la obtención de la aprobación formal de las propuestas detalladas antes de iniciar el trabajo;

f). la garantía de que los usuarios autorizados aceptan los cambios antes de la implementación;

g). la garantía de que la documentación del sistema está actualizada al finalizar cada cambio y que la documentación antigua se archiva o elimina;

h). el mantenimiento de una versión de control para todas las actualizaciones de software;

i). el mantenimiento de un rastro para auditoría de todos los cambios solicitados;

j). la garantía de que la documentación operativa (véase el numeral 10.1.1) y los procedimientos de usuario se cambian en función de la necesidad con el objeto de mantener su idoneidad;

k). la garantía de que la implementación de los cambios tiene lugar en el momento oportuno y no perturba los procesos del negocio involucrados.

Información adicional

El cambio del software puede tener impacto en el entorno operativo.

La buena práctica incluye la prueba del software nuevo en un entorno separado tanto del entorno de producción como del de desarrollo (véase el numeral 10.1.4). Esto proporciona medios para controlar el software nuevo y facilitar la protección adicional de la información operativa que se usa con propósitos de prueba. Se deberían incluir parches, paquetes de servicio y otras actualizaciones. Las actualizaciones automáticas no se deberían utilizar en sistemas críticos ya que algunas de ellas pueden causar fallas de las aplicaciones críticas (véase el numeral 12.6).

12.5.2 Revisión técnica de las aplicaciones después de los cambios en el sistema operativo

Control

Cuando se cambian los sistemas operativos, las aplicaciones críticas para el negocio se deberían revisar y someter a prueba para asegurar que no hay impacto adverso en las operaciones ni en la seguridad de la organización.

Guía de implementación

Este proceso debería comprender los siguientes aspectos:

a). revisión de los procedimientos de integridad y control de la aplicación para asegurarse de que no se han puesto en peligro debido a los cambios en el sistema operativo;

b). garantía de que el plan y el presupuesto de soporte anual cubrirán las revisiones y pruebas del sistema que resulten de cambios en el sistema operativo;

c). garantía de la notificación oportuna sobre los cambios en el sistema operativo para permitir la realización de las pruebas y las revisiones apropiadas antes de la implementación;

d). garantía de que se hacen cambios en los planes de continuidad del negocio (véase el numeral 14).

Un grupo o un individuo específico debería ser responsable de monitorear las vulnerabilidades y las nuevas versiones de parches y arreglos (fixes) del distribuidor (véase el numeral 12.6).

12.5.3 Restricciones en los cambios a los paquetes de software

Control

Se debería desalentar la realización de modificaciones a los paquetes de software, limitarlas a los cambios necesarios, y todos los cambios se deberían controlar estrictamente.

Guía de implementación

En la medida de lo posible y viable, los paquetes de software suministrados por el vendedor se deberían usar sin modificaciones. Cuando sea necesario modificar un paquete de software, se deberían tener en cuenta los siguientes puntos:

a). el riesgo de que los procesos de integridad y de control incorporados se vean comprometidos;

b). si es necesario obtener el consentimiento del vendedor;

c). la posibilidad de obtener los cambios requeridos del vendedor como un programa estándar de actualizaciones;

d). el impacto, si la organización se hace responsable del mantenimiento futuro del software como resultado de los cambios.

Si los cambios son necesarios, el software original se debería conservar y los cambios se deberían aplicar a una copia claramente identificada. Se debería implementar un proceso de gestión de las actualizaciones del software para asegurarse de que los parches más actualizados aprobados y las actualizaciones de las aplicaciones están instalados en todo el software autorizado (véase el numeral 12.6). Todos los cambios se deberían probar y documentar en su totalidad de manera que se puedan volver a aplicar, si es necesario, para mejoras futuras del software. Si así se requiere, las modificaciones se deberían probar y validar por un organismo de evaluación independiente.

12.5.4 Fuga de información

Control

Se deberían evitar las oportunidades para que se produzca fuga de información.

Guía de implementación

Se deberían considerar los siguientes aspectos para limitar el riesgo de fuga de información, por ejemplo, mediante el uso y explotación de los canales encubiertos:

a). exploración de los medios y comunicaciones de salida para determinar la información oculta;

b). comportamiento de las comunicaciones y del sistema de modulación y enmascaramiento para reducir la probabilidad de que una tercera parte pueda deducir información a partir de tal comportamiento;

c). utilización de sistemas y software que se consideran con integridad alta, por ejemplo usar productos evaluados (véase la norma ISO/IEC 15408);

d). monitoreo regular de las actividades del personal y del sistema, cuando está permitido por la legislación o los reglamentos existentes;

e). monitoreo del uso de los recursos en los sistemas de computador.

Información adicional

Los canales encubiertos son vías que no están destinadas para conducir flujos de información, pero que, sin embargo, pueden existir en un sistema o una red. Por ejemplo, los bits de manipulación en los paquetes de protocolo de comunicaciones se podrían usar como un método oculto de señalización. Debido a su naturaleza, evitar la existencia de todos los posibles canales encubiertos sería difícil, si no imposible. No obstante, la explotación de tales canales se realiza con frecuencia a través de códigos troyanos (véase el numeral 10.4.1). Por lo tanto, tomar medidas para proteger contra códigos troyanos reduce el riesgo de explotación de los canales encubiertos. La prevención del acceso no autorizado a la red (véase el numeral 11.4), así como las políticas y los procedimientos para desalentar el uso inadecuado de los servicios de información por parte del personal (véase el numeral 15.1.5) facilitarán la protección contra canales encubiertos.

12.5.5 Desarrollo de software contratado externamente

Control

La organización debería supervisar y monitorear el desarrollo de software contratado externamente.

Guía de implementación

Cuando el desarrollo del software se contrata externamente, se recomienda tener en cuenta los siguientes puntos:

a). acuerdos sobre licencias, propiedad de los códigos y derechos de propiedad intelectual (véase el numeral 15.1.2);

b). certificación de la calidad y exactitud del trabajo realizado;

c). convenios de fideicomiso en caso de falla de la tercera parte;

d). derechos de acceso para auditar la calidad y exactitud del trabajo realizado;

e). requisitos contractuales para la calidad y la funcionalidad de la seguridad del código;

f). realización de pruebas antes de la instalación para detectar códigos troyanos o maliciosos.

12.6 GESTIÓN DE LA VULNERABILIDAD TÉCNICA

Objetivo: reducir los riesgos resultantes de la explotación de las vulnerabilidades técnicas publicadas.

La gestión de la vulnerabilidad técnica se debería implementar de forma eficaz, sistemática y repetible con toma de mediciones para confirmar su eficacia. Estas consideraciones deberían incluir a los sistemas operativos y otras aplicaciones en uso.

12.6.1 Control de las vulnerabilidades técnicas

Control

Se debería obtener información oportuna sobre las vulnerabilidades técnicas de los sistemas de información que están en uso, evaluar la exposición de la organización a dichas vulnerabilidades y tomar las acciones apropiadas para tratar los riesgos asociados.

Guía de implementación

Un inventario completo y actual de los activos (véase el numeral 7.1) es un prerrequisito para la gestión eficaz de la vulnerabilidad técnica. La información específica necesaria para dar soporte a la gestión de la vulnerabilidad técnica incluye los siguientes datos: vendedor del software, números de versión, estado actual de despliegue (por ejemplo qué software está instalado en cuál sistema) y las personas de la organización responsables del software.

Es conveniente tomar la acción oportuna y apropiada en respuesta a la identificación de vulnerabilidades técnicas potenciales. Se recomienda tener en cuenta las siguientes directrices para establecer un proceso de gestión eficaz de las vulnerabilidades técnicas:

a). la organización debería definir e instaurar las funciones y responsabilidades asociadas con la gestión de la vulnerabilidad técnica, incluyendo el monitoreo de la vulnerabilidad, la evaluación de riesgos de la vulnerabilidad, el uso de parches, el rastreo de activos y todas las responsabilidades de coordinación requeridas;

b). es conveniente identificar los recursos de información que se van a utilizar para identificar las vulnerabilidades técnicas pertinentes y para mantener la concientización sobre ellas para el software y otra tecnología (con base en la lista de inventario de activos, véase el numeral 7.1.1), estos recursos de información se deberían actualizar en función de los cambios en el inventario o cuando se encuentran recursos nuevos o útiles;

c). se debería definir una línea de tiempo para reaccionar ante la notificación de vulnerabilidades técnicas potenciales pertinentes;

d). una vez se ha identificado una vulnerabilidad potencial, la organización debería identificar los riesgos asociados y las acciones que se han de tomar; tales acciones podrían involucrar el uso de parches en los sistemas vulnerables y / o la aplicación de otros controles;

e). dependiendo de la urgencia con la que es necesario tratar la vulnerabilidad técnica, la acción a tomar se debería ejecutar de acuerdo con los controles relacionados con la gestión de cambios (véase el numeral 12.5.1) o siguiendo los procedimientos de respuesta ante incidentes de seguridad de la información;

f). si está disponible un parche, se deberían evaluar los riesgos asociados con su instalación (los riesgos impuestos por la vulnerabilidad se deberían comparar con los riesgos de instalar el parche);

g). es conveniente probar y evaluar los parches antes de su instalación para garantizar que son eficaces y no producen efectos secundarios intolerables; si no hay parche disponible, se recomienda considerar otros controles:

1). apagar los servicios o capacidades relacionadas con la vulnerabilidad;

2). adaptar o agregar controles de acceso, por ejemplo, barreras de fuego (firewalls), en las fronteras de la red (véase el numeral 11.4.5);

3). aumentar el monitoreo para detectar o prevenir los ataques reales;

4). crear conciencia sobre la vulnerabilidad;

h). se debería conservar un registro para auditoría para todos los procedimientos efectuados;

i). el proceso de gestión de la vulnerabilidad técnica se debería monitorear y evaluar a intervalos regulares para garantizar su eficacia y eficiencia;

j). se deberían tratar primero los sistemas con alto riesgo.

Información adicional

El funcionamiento correcto del proceso de gestión de la vulnerabilidad técnica es crítico para muchas organizaciones y por ello se debería monitorear con regularidad. Es esencial un inventario exacto para garantizar la identificación de vulnerabilidades técnicas potenciales y pertinentes.

La gestión de la vulnerabilidad técnica se puede ver como una sub-función de la gestión de cambios y como tal puede tomar ventaja de los procesos y procedimientos de gestión de cambios (véanse los numerales 10.1.2 y 12.5.1).

Los vendedores, con frecuencia, están bajo gran presión para sacar a la venta los parches tan pronto sea posible. Por lo tanto, es posible que un parche no trate el problema adecuadamente y tenga efectos colaterales negativos. En algunos casos, desinstalar un parche puede no ser tan fácil una vez que se ha aplicado.

Si no es posible someter los parches a las pruebas adecuadas, por ejemplo, debido a los costos o a la falta de recursos, se puede pensar en retrasar la aplicación del parche para valorar los riesgos asociados, basados en la experiencia reportada por otros usuarios.