15. CUMPLIMIENTO

15.1 CUMPLIMIENTO DE LOS REQUISITOS LEGALES

Objetivo: evitar el incumplimiento de cualquier ley, de obligaciones estatutarias,
reglamentarias o contractuales y de cualquier requisito de seguridad.
El diseño, el uso, la operación y la gestión de los sistemas de información pueden estar
sujetos a requisitos de seguridad estatutarios, reglamentarios y contractuales.
Se debería buscar asesoría sobre los requisitos legales específicos de los asesores jurídicos de la organización o de abogados practicantes calificados. Los requisitos legales varían de un país a otro y pueden variar para la información creada en un país y que se transmite a otro (es decir, el flujo de datos trans-fronterizo).

15.1.1 Identificación de la legislación aplicable

Control

Todos los requisitos estatutarios, reglamentarios y contractuales pertinentes, así como el
enfoque de la organización para cumplir estos requisitos se deberían definir explícitamente,
documentar y mantener actualizados para cada sistema de información y para la organización
Guía de implementación
Los controles específicos y las responsabilidades individuales para cumplir estos requisitos se deberían definir y documentar de forma similar

15.1.2 Derechos de propiedad intelectual (DPI)

Control

Se deberían implementar procedimientos apropiados para asegurar el cumplimiento de los
requisitos legales, reglamentarios y contractuales sobre el uso del material con respecto al cual pueden existir derechos de propiedad intelectual y sobre el uso de productos de software patentados.
Guía de implementación
Se deberían tomar en consideración las siguientes directrices para proteger todo material que se pueda considerar propiedad intelectual:
a) publicar una política de cumplimiento de los derechos de propiedad intelectual que
defina el uso legal del software y de los productos de información;
b) adquirir software únicamente a través de fuentes conocidas y de confianza para
garantizar que no se violan los derechos de copia;
c) mantener la concientización sobre las políticas para proteger los derechos de propiedad
intelectual y notificar la intención de tomar acciones disciplinarias para el personal que
los viole;
d) mantener registros apropiados de los activos e identificar todos los activos con
requisitos para proteger los derechos de propiedad intelectual;
e) mantener prueba y evidencia sobre la propiedad de licencias, discos maestros,
manuales, etc.;
f) implementar controles para asegurar que no se excede el número máximo de usuarios
permitidos;
g) verificar que únicamente se instalan software autorizado y productos con licencia;
h) suministrar una política para mantener las condiciones de licencia apropiadas;
i) suministrar una política para la disposición o transferencia de software a otros;
j) usar las herramientas de auditoría adecuadas;
k) cumplir los términos y condiciones para el software y la información obtenidos de redes
públicas;
l) no duplicar, convertir en otro formato ni extraer de grabaciones comerciales (película,
audio) diferentes a los permitidos por la ley de derechos de copia;
m) no copiar total ni parcialmente libros, artículos, informes ni otros documentos diferentes
a los permitidos por la ley de derechos de copia.
Información adicional
Los derechos de propiedad intelectual incluyen derechos de copia de software o de
documentos, derechos de diseño, marcas registradas, patentes y licencias de códigos fuente.
Los productos de software patentados usualmente se suministran bajo un acuerdo de licencia
que especifica los términos y condiciones de la licencia, por ejemplo, limitar el uso de los
productos a máquinas específicas o limitar el copiado a la creación de copias de respaldo
únicamente. La situación de DPI del software desarrollado por la organización requiere ser
aclarada con el personal.
Los requisitos legales, reglamentarios y contractuales pueden imponer restricciones a la copia de material patentado. En particular pueden exigir que únicamente se utilice el material desarrollado por la organización o que tiene licencia y es suministrado a la organización por quien lo desarrolla. La violación de los derechos de copia puede conducir a acciones legales que pueden implicar procedimientos judiciales.

15.1.3 Protección de los registros de la organización

Control

Los registros importantes se deberían proteger contra pérdida, destrucción y falsificación, de acuerdo con los requisitos estatutarios, reglamentarios, contractuales y del negocio.
Guía de implementación
Los registros se deberían clasificar en tipos de registro, por ejemplo registros de contabilidad, registros de bases de datos, registros de transacciones, registros de auditoría y procedimientos operativos, cada uno con detalles de los periodos de retención y los tipos de medio de almacenamiento como papel, microfichas, medios magnéticos, ópticos, etc. Todo material relacionado con claves criptográficas y programas asociados con archivos encriptados o firmas digitales (véase el numeral 12.3), también se debería almacenar para permitir el descifrado de los registros durante el periodo de tiempo durante el cual se retienen los registros.
Es conveniente tomar en consideración la posibilidad de deterioro de los medios utilizados para almacenar los registros. Los procedimientos de almacenamiento y manipulación se deberían implementar según las recomendaciones del fabricante. Para almacenamiento a largo plazo, se recomienda considerar el uso de papel y microfichas.
procedimientos para garantizar la capacidad de acceso a los datos (facilidad tanto del medio como del formato) durante todo el periodo de retención para salvaguardar contra pérdida debido a cambio en la tecnología futura.
Los sistemas de almacenamiento de datos se deberían seleccionar de forma tal que los datos requeridos se puedan recuperar en el periodo de tiempo y el formato aceptable, dependiendo de los requisitos que se deben cumplir.
El sistema de almacenamiento y manipulación debería garantizar la identificación de los
registros y de su periodo de retención tal como se define en los reglamentos o la legislación
nacional o regional, si se aplica. Este sistema debería permitir la destrucción adecuada de los registros después de este periodo, si la organización no los necesita.
Para cumplir estos objetivos de salvaguarda de registros, la organización debería seguir los
siguientes aspectos:
a) se deberían publicar directrices sobre retención, almacenamiento, manipulación y
eliminación de registros e información;
b) es conveniente publicar una programación de retención que identifique los registros y el
periodo de tiempo de su retención;
c) se recomienda conservar un inventario de las fuentes de información clave;
d) se deberían implementar los controles apropiados para proteger los registros y la
información contra pérdida, destrucción y falsificación.
Información adicional
Puede ser necesario retener algunos registros de manera segura para cumplir requisitos
estatutarios, reglamentarios o contractuales, así como para dar soporte a las actividades
esenciales del negocio. Los ejemplos incluyen los registros que se pueden necesitar como para garantizar la defensa adecuada contra potenciales acciones civiles o criminales o para
confirmar el estado financiero de la organización con respecto a socios, terceras partes y
auditores. El periodo de tiempo y el contenido de los datos para la retención de información
pueden ser establecidos por la ley o la reglamentación nacional.
Información adicional sobre la gestión de los registros de la organización se puede encontrar en la norma ISO 15489-1.

15.1.4 Protección de los datos y privacidad de la información personal

Control

Se debería garantizar la protección de los datos y la privacidad, de acuerdo con la legislación y los reglamentos pertinentes y, si se aplica, con las cláusulas del contrato.
Guía de implementación
Se debería desarrollar e implementar una política de protección y privacidad de los datos. Esta política se debería comunicar a todas las personas involucradas en el procesamiento de información personal.
El cumplimiento de esta política y de todos los reglamentos y leyes pertinentes a la protección de datos requiere estructura y control adecuados de gestión. Con frecuencia esto se logra mejor nombrando a una persona responsable, como por ejemplo un funcionario para protección
de datos, quien debería brindar guía a directores, usuarios y proveedores de servicios sobre sus responsabilidades individuales y los procedimientos específicos que se deberían seguir. La responsabilidad del manejo de la información personal y de la concientización sobre los principios de protección de datos debería estar acorde con los reglamentos y la legislación correspondientes. Se deberían implementar medidas técnicas y organizacionales apropiadas.
Información adicional
Varios países han introducido leyes que imponen controles a la recolección, el procesamiento y la transmisión de datos personales (generalmente se trata de información sobre personas vivas que pueden ser identificadas a partir de tal información). Dependiendo de la respectiva legislación nacional, estos controles pueden imponer funciones sobre aquellos que recolectan, procesan y distribuyen información personal y pueden restringir la capacidad de transferencia de datos a otros países.

15.1.5 Prevención del uso inadecuado de los servicios de procesamiento de información

Control

Se debería disuadir a los usuarios de utilizar los servicios de procesamiento de información
para propósitos no autorizados.
Guía de implementación
La dirección debería aprobar el uso de los servicios de procesamiento de información. Todo
uso de estos servicios para propósitos no relacionados con el negocio sin autorización de la
dirección (véase el numeral 6.1.4), o para cualquier propósito no autorizado se debería
considerar uso inadecuado de los servicios. Si se identifica alguna actividad no autorizada por medio de monitoreo u otros medios, esta actividad debería llamar la atención del director correspondiente para estudiar la acción legal y/o disciplinaria adecuada.
Antes de implementar los procedimientos de monitoreo se debería tener asesoría legal.
Todos los usuarios deberían conocer el alcance preciso de su acceso permitido y del monitoreo implementado para detectar el uso no autorizado. Esto se puede lograr dando a los usuarios autorización escrita, una copia de la cual debería estar firmada por el usuario y la organización debería conservarla. A los empleados de la organización, contratistas y usuarios de terceras partes se les debería advertir que no se permitirá acceso que no esté autorizado.
En el momento del registro de inicio, se debería presentar un mensaje de advertencia que
indique que el servicio de procesamiento de información al cual se está ingresando es
propiedad de la organización y que no se permite el acceso no autorizado. El usuario debe
reconocer y reaccionar apropiadamente al mensaje de la pantalla para continuar con el proceso de registro de inicio (véase el numeral 11.5.1).
Información adicional
Los servicios de procesamiento de información de una organización tienen el fin principal o
exclusivo de los propósitos del negocio.
La detección de intrusión, la inspección del contenido y otras herramientas de monitoreo
pueden ayudar y evitar el uso inadecuado de los servicios de procesamiento de información.
Muchos países tienen legislaciones que protegen contra el uso inadecuado del computador.
Puede ser un acto criminal usar el computador con propósitos no autorizados.
La legalidad de monitorear la utilización varía de un país a otro y puede exigir que la dirección advierta a los usuarios sobre tal monitoreo y / o obtenga su acuerdo. Cuando el sistema al cual se ingresa se utiliza para acceso público (por ejemplo en un servidor web público) y está sujeto a monitoreo de seguridad, se debería mostrar un mensaje que así lo indique.

15.1.6 Reglamentación de los controles criptográficos

Control

Se deberían utilizar controles criptográficos que cumplan todos los acuerdos, las leyes y los
reglamentos pertinentes.
Guía de implementación
Se recomienda tener presentes los siguientes elementos para el cumplimiento con acuerdos, leyes y reglamentos pertinentes:
a) restricción de importaciones y/o exportaciones de hardware y software de computadores
para la ejecución de funciones criptográficas;
b) restricción de importaciones y/o exportaciones de hardware y software de computadores
diseñados para adicionarles funciones criptográficas;
c) restricciones al uso de encriptación;
d) métodos obligatorios o discrecionales de acceso por parte de las autoridades del país a
la información encriptada mediante hardware o software para brindar confidencialidad al
contenido.
Se debería buscar asesoría legal para garantizar el cumplimiento con las leyes y los
reglamentos nacionales. Antes de desplazar la información encriptada o los controles
criptográficos a otros países, se debería tener asesoría legal.

15.2 CUMPLIMIENTO DE LAS POLÍTICAS Y LAS NORMAS DE SEGURIDAD Y CUMPLIMIENTO TÉCNICO

Objetivo: asegurar que los sistemas cumplen con las normas y políticas de seguridad de la
organización.
La seguridad de los sistemas de información se debería revisar a intervalos regulares.
Dichas revisiones se deberían llevar a cabo frente a las políticas de seguridad apropiadas y se deberían auditar las plataformas técnicas y los sistemas de información para determinar el cumplimiento de las normas aplicables sobre implementación de la seguridad y los controles de seguridad documentados.

15.2.1 Cumplimiento con las políticas y las normas de seguridad

Control

Los directores deberían garantizar que todos los procedimientos de seguridad dentro de sus áreas de responsabilidad se llevan a cabo correctamente para lograr el cumplimiento con las políticas y las normas de seguridad.
Guía de implementación
Los directores deberían revisar con regularidad en su área de responsabilidad el cumplimiento del procesamiento de información con las políticas de seguridad adecuadas, las normas y cualquier otro requisito de seguridad.
Si se halla algún incumplimiento como resultado de la revisión, los directores deberían:
a) determinar la causa del incumplimiento;
b) evaluar la necesidad de acciones para garantizar que no se presenten incumplimientos;
c) determinar e implementar la acción correctiva apropiada,
d) revisar la acción correctiva que se ejecutó.
Se deberían registrar los resultados de las revisiones y las acciones correctivas llevadas a cabo por los directores y conservar dichos registros. Los directores deberían informar de los
resultados a las personas que realizan revisiones independientes (véase el numeral 6.1.8),
cuando la revisión independiente tiene lugar en el área de su responsabilidad.
Información adicional
En el numeral 10.10 se discute el monitoreo operativo del sistema.

15.2.2 Verificación del cumplimiento técnico

Control

Los sistemas de información se deberían verificar periódicamente para determinar el
cumplimiento con las normas de implementación de la seguridad.
Guía de implementación
La verificación del cumplimiento técnico se debería realizar bien sea manualmente (con soporte de las herramientas de software apropiadas, si es necesario) por un ingeniero de sistemas con experiencia y / o con la ayuda de herramientas automáticas que generan un informe técnico para la interpretación posterior por parte del especialista técnico.
Si se utilizan evaluaciones de vulnerabilidad o pruebas de penetración, se recomienda tener cuidado puesto que dichas actividades pueden poner en peligro la seguridad del sistema. Tales pruebas se deberían planificar, documentar y ser repetibles.
La verificación del cumplimiento técnico únicamente la deberían realizar personas autorizadas y competentes o bajo supervisión de dichas personas.
Información adicional
La verificación del cumplimiento técnico involucra el examen de los sistemas operativos para asegurar que los controles de hardware y software se han implementado correctamente. Este tipo de verificación del cumplimiento requiere experiencia técnica especializada.
La verificación del cumplimiento también comprende, por ejemplo pruebas de penetración y
evaluaciones de la vulnerabilidad, las cuales pueden ser realizadas por expertos
independientes especialmente contratados para este propósito. Ello puede ser útil para
detectar vulnerabilidades en el sistema y verificar qué tan efectivos son los controles evitando el acceso no autorizado debido a estas vulnerabilidades.
Las pruebas de penetración y las evaluaciones de vulnerabilidad proveen una visión
instantánea de un sistema en un estado específico en un momento específico. Esta
instantánea se limita a aquellas porciones del sistema que se someten a prueba real durante el (los) intento (s) de penetración. Las pruebas de penetración y las evaluaciones de vulnerabilidad no substituyen a la evaluación de riesgos.

15.3 CONSIDERACIONES DE LA AUDITORÍA DE LOS SISTEMAS DE INFORMACIÓN

Objetivo: maximizar la eficacia de los procesos de auditoría de los sistemas de información y minimizar su interferencia.
Deberían existir controles para salvaguardar los sistemas operativos y las herramientas de
auditoría durante las auditorías de los sistemas de información.
También se requiere protección para salvaguardar la integridad y evitar el uso inadecuado de las herramientas de auditoría.

15.3.1 Controles de auditoría de los sistemas de información

Control

Los requisitos y las actividades de auditoría que implican verificaciones de los sistemas
operativos se deberían planificar y acordar cuidadosamente para minimizar el riesgo de
interrupciones de los procesos del negocio.
Guía de implementación
Se deberían tener presente las siguientes directrices:
a) los requisitos de auditoría se deberían acordar con la dirección correspondiente;
b) se debería acordar y controlar el alcance de las verificaciones;
c) las verificaciones se deberían limitar al acceso de sólo lectura del software y los datos;
d) el acceso diferente al de sólo lectura únicamente se debería permitir para copias
aisladas de archivos del sistema que se puedan borrar al terminar la auditoría, o se
debería dar protección adecuada, si existe la obligación de conservar dichos archivos
según los requisitos de documentación de la auditoría;
e) los recursos para llevar a cabo las verificaciones se deberían identificar explícitamente y
estar disponibles;
f) se deberían identificar y acordar los requisitos para el procesamiento especial o
adicional;
g) todo acceso se debería monitorear y registrar para crear un rastro para referencia; el
uso de rastros de referencia de tiempo se debería considerar para datos o sistemas
críticos;
h) se recomienda documentar todos los procedimientos, requisitos y responsabilidades;
i) la persona que realiza la auditoría debería ser independiente de las actividades
auditadas.

15.3.2 Protección de las herramientas de auditoría de los sistemas de información

Control

Se debería proteger el acceso a las herramientas de auditoría de los sistemas de información para evitar su uso inadecuado o ponerlas en peligro.
Guía de implementación
Las herramientas de auditoría de los sistemas de información, por ejemplo, software o archivos de datos, se deberían separar de los sistemas operativos y de desarrollo y no mantenerse en librerías de cinta, salvo que se les proporcione un nivel adecuado de protección adicional.

14. GESTIÓN DE LA CONTINUIDAD DEL NEGOCIO

14.1 ASPECTOS DE SEGURIDAD DE LA INFORMACIÓN EN LA GESTIÓN DE LA
CONTINUIDAD DEL NEGOCIO

Objetivo: contrarrestar las interrupciones en las actividades del negocio y proteger sus
procesos críticos contra los efectos de fallas importantes en los sistemas de información o
contra desastres, y asegurar su recuperación oportuna.
Se debería implementar un proceso de gestión de la continuidad del negocio para minimizar el impacto y la recuperación por la pérdida de activos de información en la organización (la cual puede ser el resultado de, por ejemplo, desastres naturales, accidentes, fallas del equipo y acciones deliberadas) hasta un nivel aceptable mediante la combinación de controles preventivos y de recuperación. En este proceso es conveniente identificar los procesos críticos para el negocio e integrar los requisitos de la gestión de la seguridad de la información de la continuidad del negocio con otros requisitos de continuidad relacionados con aspectos tales
como operaciones, personal, materiales, transporte e instalaciones.
Las consecuencias de desastres, fallas de seguridad, pérdida del servicio y disponibilidad del servicio se deberían someter a un análisis del impacto en el negocio. Se deberían desarrollar e implementar planes de continuidad del negocio para garantizar la restauración oportuna de las operaciones esenciales. La seguridad de la información debería ser una parte integral de todo el proceso de continuidad del negocio y de otros procesos de gestión en la organización.
La gestión de la continuidad del negocio debería incluir controles para identificar y reducir los riesgos, además del proceso general de evaluación de riesgos, limitar las consecuencias de los incidentes dañinos y garantizar la disponibilidad de la información requerida para los procesos del negocio.

14.1.1 Inclusión de la seguridad de la información en el proceso de gestión de la
continuidad del negocio

Control

Se debería desarrollar y mantener un proceso de gestión para la continuidad del negocio en
toda la organización el cual trate los requisitos de seguridad de la información necesarios para la continuidad del negocio de la organización.
Guía de implementación
El proceso debería reunir los siguientes elementos clave para la gestión de la continuidad del negocio:
a) comprensión de los riesgos que enfrenta la organización en términos de la probabilidad
y el impacto en el tiempo, incluyendo la identificación y la determinación de la prioridad
de los procesos críticos del negocio (véase el numeral 14.1.2);
b) identificación de todos los activos involucrados en los procesos críticos del negocio
(véase el numeral 7.1.1);
c) comprensión del impacto que puedan tener las interrupciones causadas por incidentes
de seguridad de la información (es importante encontrar soluciones para manejar los
incidentes que producen impactos menores, así como los incidentes graves que puedan
amenazar la viabilidad de la organización), y establecer los objetivos del negocio para
los servicios de procesamiento de información;
d) consideración de la adquisición de pólizas de seguros adecuadas que puedan formar
parte de todo el proceso de continuidad del negocio y de la gestión de riesgos
operativos;
e) identificación y consideración de la implementación de controles preventivos y
mitigantes adicionales;
f) identificación de recursos financieros, organizacionales, técnicos y ambientales
suficientes para tratar los requisitos identificados de la seguridad de la información;
g) garantizar la seguridad del personal y la protección de los servicios de procesamiento
de información y de la propiedad de la organización;
h) formulación y documentación de los planes de continuidad del negocio que abordan los
requisitos de seguridad de la información acorde con la estrategia acordada de
continuidad del negocio (véase el numeral 14.1.3);
i) prueba y actualización regular de los planes y procesos establecidos (véase el numeral
14.1.5);
j) garantizar que la gestión de la continuidad del negocio está incorporada en los procesos
y la estructura de la organización; la responsabilidad por el proceso de gestión de la
continuidad del negocio se debería asignar en un nivel apropiado en la organización
(véase el numeral 6.1.1).

14.1.2 Continuidad del negocio y evaluación de riesgos

Control

Se deberían identificar los eventos que pueden ocasionar interrupciones en los procesos del negocio junto con la probabilidad y el impacto de dichas interrupciones, así como sus
consecuencias para la seguridad de la información.
Guía de implementación
Los aspectos de seguridad de la información en la continuidad del negocio se deberían basar en la identificación de los eventos (o secuencia de eventos) que pueden causar interrupciones en los procesos del negocio de la organización, por ejemplo fallas de los equipos, errores humanos, robo, desastres naturales y actos terroristas. Se debería continuar con una evaluación de riesgos para determinar la probabilidad y el impacto de tales interrupciones, en términos de tiempo, escala de daño y periodo de recuperación.
participación de los dueños de los recursos y los procesos del negocio. Estas evaluaciones
deberían considerar todos los procesos del negocio sin limitarse a los servicios de
procesamiento de información, sino incluir los resultados específicos para la seguridad de la información. Es importante vincular en conjunto todos los aspectos del riesgo para obtener un panorama completo de los requisitos de continuidad del negocio de la organización. La evaluación debería identificar, cuantificar y priorizar los riesgos frente a los criterios y los objetivos pertinentes para la organización, incluyendo los recursos críticos, impactos de las interrupciones, duración permitida de corte y prioridades de recuperación.
Dependiendo de los resultados de la evaluación de riesgos, se debería desarrollar una
estrategia de continuidad del negocio para determinar el enfoque global para la continuidad del negocio. Una vez se ha creado esta estrategia, la dirección debería aprobarla y se debería crear y respaldar un plan para la implementación de esta estrategia.

14.1.3 Desarrollo e implementación de planes de continuidad que incluyan la seguridad de la información

Control

Se deberían desarrollar e implementar planes para mantener o recuperar las operaciones y
asegurar la disponibilidad de la información en el grado y la escala de tiempo requeridos,
después de la interrupción o la falla de los procesos críticos para el negocio.
Guía de implementación
En el proceso de planificación de la continuidad del negocio se deberían considerar los
siguientes aspectos:
a) identificar y acordar todas las responsabilidades y los procedimientos para la
continuidad del negocio;
b) identificar la pérdida aceptable de información y servicios;
c) implementar los procedimientos que permitan recuperar y restaurar las operaciones del
negocio y la disponibilidad de la información en las escalas de tiempo requeridas; es
necesario atender la evaluación de las dependencias internas y externas del negocio y
de los contratos establecidos;
d) procedimientos operativos que se han de seguir en espera de la terminación de la
recuperación y restauración;
e) documentación de procedimientos y procesos acordados;
f) formación apropiada del personal en los procedimientos y procesos acordados,
incluyendo el manejo de las crisis;
g) pruebas y actualización de los planes:
El proceso de planificación se debería centrar en los objetivos requeridos del negocio, por
ejemplo la restauración de servicios de comunicación específicos para los clientes en un lapso de tiempo aceptable. Los servicios y recursos que lo facilitan deberían identificarse, incluyendo el personal, los recursos no relacionados con el procesamiento de información, al igual que las disposiciones de respaldo para los servicios de procesamiento de información. Estas disposiciones de respaldo pueden incluir arreglos con terceras partes en forma de acuerdos recíprocos o servicios de suscripción comercial.
y, por lo tanto, pueden contener información sensible que es necesario proteger
adecuadamente. Las copias de los planes de la continuidad del negocio se deberían almacenar en un lugar lejano, a suficiente distancia para escapar a cualquier daño por algún desastre en la sede principal. La dirección debería garantizar que las copias de los planes de continuidad del negocio están actualizadas y protegidas con el mismo nivel de seguridad que se aplica en la sede principal. De igual modo, el otro material necesario para ejecutar los planes de continuidad se debería almacenar en un sitio lejano.
Si se utilizan lugares alternos temporales, el nivel de los controles de seguridad implementados en estos lugares debería ser equivalente al de la sede principal.
Información adicional
Es conveniente observar que los planes y las actividades de la gestión de crisis (véase el
numeral 14.1.3.f)) pueden ser diferentes de la gestión de la continuidad del negocio; es decir, se puede presentar una crisis que se pueda adaptar con procedimientos de gestión normales.

14.1.4 Estructura para la planificación de la continuidad del negocio

Control

Se debería mantener una sola estructura de los planes de continuidad del negocio, para
asegurar que todos los planes son consistentes, y considerar los requisitos de la seguridad de la información de forma consistente, así como identificar las prioridades para pruebas y
mantenimiento.
Guía de implementación
Cada plan de continuidad del negocio debería describir el enfoque para la continuidad, por
ejemplo el enfoque para garantizar la disponibilidad y seguridad de la información o del sistema de información. Igualmente, cada plan debería especificar el plan de escalada y las condiciones para su activación, así como las personas responsables de ejecutar cada componente del plan.
Cuando se identifican nuevos requisitos, todos los procedimientos de emergencia existentes, por ejemplo planes de evacuación o disposiciones de respaldo, se deberían modificar apropiadamente. Los procedimientos se deberían incluir en el programa de gestión de cambios de la organización para garantizar el tratamiento adecuado de los aspectos de la continuidad el negocio.
Cada plan debería tener un dueño específico. Los procedimientos de emergencia, los planes de recursos de emergencia manuales y de reanudación deberían ser responsabilidad de los dueños de los recursos o procesos apropiados del negocio involucrados. Las disposiciones de respaldo para los servicios técnicos alternos, como servicios de procesamiento de información y comunicaciones, usualmente deberían ser responsabilidad de los proveedores del servicio.
Una estructura para la planificación de la continuidad del negocio debería abordar los requisitos de seguridad de la información identificados y considera los siguientes aspectos:
a) las condiciones para la activación de los planes que describen el proceso a seguir (por
ejemplo, la forma de evaluar la situación y quién se va a involucrar) antes de activar
cada plan;
b) los procedimientos de emergencia que describen las acciones por realizar tras un
incidente que ponga en peligro las operaciones del negocio;
c) los procedimientos de respaldo que describen las acciones por realizar para desplazar
las actividades esenciales del negocio o los servicios de soporte a lugares temporales
alternos y para devolver la operatividad de los procesos del negocio en los plazos
requeridos;
d) los procedimientos operativos temporales por seguir mientras se terminan la
recuperación y la restauración;
e) los procedimientos de reanudación que describen las acciones por realizar para que las
operaciones del negocio vuelvan a la normalidad;
f) una programación de mantenimiento que especifique cómo y cuándo se realizarán
pruebas al plan y el proceso para el mantenimiento del plan;
g) actividades de concientización, educación y formación diseñadas para comprender los
procesos de continuidad del negocio y garantizar que los procesos siguen siendo
eficaces;
h) las responsabilidades de las personas, que describan quién es responsable de la
ejecución de cada componente del plan. Si se requiere, se deberían nombrar suplentes;
i) los activos y recursos críticos necesarios para ejecutar los procedimientos de
emergencia, respaldo y reanudación.

14.1.5 Pruebas, mantenimiento y reevaluación de los planes de continuidad del negocio

Control

Los planes de continuidad del negocio se deberían someter a pruebas y revisiones periódicas para asegurar su actualización y su eficacia.
Guía de implementación
Las pruebas del plan de continuidad del negocio deberían asegurar que todos los miembros del equipo de recuperación y otro personal pertinente son conscientes de los planes y sus
responsabilidades para la continuidad del negocio y la seguridad de la información, y conocen su función cuando se ejecuta un plan.
La programación de las pruebas para los planes de continuidad del negocio debería indicar
cómo y cuándo se va a probar cada elemento del plan. Cada uno de los elementos se debería probar con frecuencia.
Es conveniente utilizar una variedad de técnicas para garantizar que los planes funcionarán en condiciones reales. Éstas incluirían:
a) la prueba sobre papel de varios escenarios (analizando las disposiciones de
recuperación con ayuda de ejemplos de interrupciones);
b) las simulaciones (particularmente para la formación del personal en sus funciones de
gestión de crisis / post-incidentes);
c) las pruebas de recuperación técnica (garantizando que los sistemas de información se
pueden restaurar eficazmente);
d) Las pruebas de recuperación en un lugar alterno (ejecutando procesos del negocio en
paralelo con las operaciones de recuperación fuera de la sede principal);
e) las pruebas de los recursos y servicios del proveedor (asegurando que los servicios y
productos proporcionados externamente cumplirán el compromiso contraído);
f) los ensayos completos (probando que la organización, el personal, el equipo, las
instalaciones y los procesos pueden hacer frente a las interrupciones).
Cualquier organización puede utilizar estas técnicas. Éstas se deberían aplicar de forma
pertinente para el plan específico de recuperación. Se deberían registrar los resultados de las pruebas y, cuando sea necesario, tomar las acciones para mejorar los planes.
Se debería asignar responsabilidad para las revisiones regulares de cada plan de continuidad del negocio. La identificación de los cambios en las disposiciones del negocio que aún no se reflejan en los planes de continuidad del negocio debería ir seguida de una actualización
adecuada del plan. Este proceso formal de control de cambios debería garantizar la distribución y el refuerzo de los planes actualizados mediante revisiones regulares del plan completo.
Los ejemplos de los cambios en donde se debería considerar la actualización de los planes de continuidad el negocio incluyen la adquisición de equipos nuevos, la mejora de los sistemas y cambios en:
a) el personal;
b) las direcciones o los números telefónicos;
c) la estrategia del negocio;
d) los lugares, dispositivos y recursos;
e) la legislación;
f) los contratistas, proveedores y clientes principales;
g) los procesos existentes, nuevos o retirados;
h) los riesgos (operativos y financieros).

13. GESTIÓN DE LOS INCIDENTES DE LA SEGURIDAD DE LA INFORMACIÓN

13.1 REPORTE SOBRE LOS EVENTOS Y LAS DEBILIDADES DE LA SEGURIDAD DE LA
INFORMACIÓN

Objetivo: asegurar que los eventos y las debilidades de la seguridad de la información
asociados con los sistemas de información se comunican de forma tal que permiten tomar las acciones correctivas oportunamente.
Es conveniente establecer el reporte formal del evento y los procedimientos de escalada.
Todos los empleados, contratistas y usuarios de tercera parte deberían tener conciencia sobre los procedimientos para el reporte de los diferentes tipos de evento y las debilidades que puedan tener impacto en la seguridad de los activos de la organización. Se les debería exigir que reporten todos los eventos de seguridad de la información y las debilidades tan pronto sea posible al punto de contacto designado.

13.1.1 Reporte sobre los eventos de seguridad de la información

Control

Los eventos de seguridad de la información se deberían informar a través de los canales de
gestión apropiados tan pronto como sea posible.
Guía de implementación
Se debería instaurar un procedimiento formal para el reporte de los eventos de seguridad de la información junto con un procedimiento de escalada y respuesta ante el incidente que
establezca la acción que se ha de tomar al recibir el reporte sobre un evento de seguridad de la información. Se debería establecer un punto de contacto para el reporte de los eventos de
seguridad de la información. Es conveniente garantizar que este punto de contacto se conoce en toda la organización, siempre está disponible y puede suministrar respuesta oportuna y adecuada.
Todos los empelados, contratistas y usuarios de tercera parte deberían tener conciencia de su responsabilidad para reportar todos los eventos de seguridad de la información lo más pronto posible. Deberían conocer el procedimiento para reportar los eventos de seguridad de la información y el punto de contacto. Los procedimientos de reporte deberían incluir los
siguientes aspectos:
a) procesos adecuados de retroalimentación para garantizar que aquellos que reportan los
eventos de seguridad de la información reciben notificación de los resultados después de
que se ha tratado y solucionado el problema;
b) formatos para el reporte de los eventos de seguridad de la información para soportar la
acción de reporte y ayudar a que la persona que hace el reporte recuerde todas las
acciones necesarias en caso de un evento de seguridad de la información;
c) el comportamiento correcto en caso de un evento de seguridad de la información, es
decir:
1) tomar nota inmediatamente sobre los detalles importantes (por ejemplo, tipo de
incumplimiento o violación, disfunción que se presenta, mensajes en la pantalla,
comportamiento extraño);
2) no ejecutar ninguna acción propia sino reportarla inmediatamente al punto de
contacto;
d) referencia a un proceso disciplinario formal establecido para tratar a los empleados,
contratistas o usuarios de tercera parte que cometieron la violación de la seguridad.
En entornos de alto riesgo, se puede suministrar una alarma de coacción4) a través de la cual
una persona bajo coacción pueda indicar tales problemas. Los procedimientos para responder
a las alarmas de coacción deberían reflejar la situación de alto riesgo que indican tales
alarmas.
Información adicional
Los siguientes son ejemplos de eventos e incidentes de seguridad.
a) pérdida del servicio, el equipo o las prestaciones;
b) mal funcionamiento o sobrecargas del sistema;
c) errores humanos;
4) Una alarma de coacción es un método para indicar secretamente que tiene lugar una acción "bajo
coacción".
d) incumplimientos de las políticas o las directrices;
e) violaciones de las disposiciones de seguridad física;
f) cambios no controlados en el sistema;
g) mal funcionamiento del software o del hardware,
i) violaciones del acceso:
Con el debido cuidado de los aspectos de confidencialidad, los incidentes de seguridad de la información se pueden usar en la formación sobre toma de conciencia de los usuarios (véase el numeral 8.2.2) como ejemplos de lo que podría pasar, cómo responder a tales incidentes y cómo evitarlos en el futuro. Para poder tratar adecuadamente los eventos e incidentes de seguridad de la información podría ser necesario recolectar evidencia tan pronto sea posible después del suceso (véase el numeral 13.2.3).
El mal funcionamiento u otro comportamiento anómalo del sistema puede ser un indicador de un ataque de seguridad o una violación real de la seguridad y por lo tanto siempre se debería reportar como evento de seguridad de la información.
Información adicional sobre el reporte de eventos de seguridad de la información y gestión de los incidentes de seguridad de la información se puede encontrar en la norma ISO/IEC TR 18044.

13.1.2 Reporte sobre las debilidades en la seguridad

Control

Se debería exigir a todos los empleados, contratistas y usuarios de terceras partes de los
sistemas y servicios de información que observen y reporten todas las debilidades observadas o sospechadas en los sistemas o servicios.
Guía de implementación
Todos los empleados, contratistas y usuarios de terceras partes deberían informar sobre estos asuntos a su director o directamente a su proveedor de servicio, tan pronto sea posible para evitar los incidentes de seguridad de la información. Los mecanismos de reporte deberían ser fáciles, accesibles y disponibles. Se les debería informar a ellos que, en ninguna circunstancia, deberían intentar probar una debilidad sospechada.
Información adicional
A todos los empleados, contratistas y usuarios de terceras partes se les debería aconsejar no intentar probar debilidades sospechadas en la seguridad. El ensayo de las debilidades se podría interpretar como un posible uso inadecuado del sistema y también podría causar daño al sistema o servicio de información que origine una responsabilidad legal por la realización individual del ensayo.

13.2 GESTIÓN DE LOS INCIDENTES Y LAS MEJORAS EN LA SEGURIDAD DE LA
INFORMACIÓN

Objetivo: asegurar que se aplica un enfoque consistente y eficaz para la gestión de los
incidentes de seguridad de la información.
Es conveniente establecer las responsabilidades y los procedimientos para manejar los eventos y debilidades de la seguridad de la información de manera eficaz una vez se han reportado. Se debería aplicar un proceso de mejora continua a la respuesta para monitorear, evaluar y gestionar en su totalidad los incidentes de seguridad de la información.
Cuando se requiere evidencia, ésta se debería recolectar para garantizar el cumplimiento de los requisitos legales.

13.2.1 Responsabilidades y procedimientos

Control

Se deberían establecer las responsabilidades y los procedimientos de gestión para asegurar una respuesta rápida, eficaz y ordenada a los incidentes de seguridad de la información.
Guía de implementación
Además del reporte de los eventos y las debilidades de la seguridad de la información (véase el
numeral 13.1), el monitoreo de los sistemas, las alertas y las vulnerabilidades (10.10.2) se
debería emplear para detectar los incidentes de la seguridad de la información. Se recomienda
tener en cuenta las siguientes directrices para los procedimientos de gestión de los incidentes
de seguridad de la información:
a) es conveniente instaurar procedimientos para manejar los diferentes tipos de incidentes
de seguridad de la información, incluyendo:
1) fallas en el sistema de información y pérdida del servicio;
2) códigos maliciosos (véase el numeral 10.4.1);
3) negación del servicio;
4) errores producidos por datos del negocio incompletos o inexactos;
5) violaciones de la confidencialidad y la integridad;
6) uso inadecuado de los sistemas de información;
b) además de los planes normales de contingencia (véase el numeral 14.1.3), los
procedimientos también deberían comprender (véase el numeral 13.2.2):
1) el análisis y la identificación de la causa del incidente;
2) la contención;
3) la planificación e implementación de la acción correctiva para evitar la
recurrencia, si es necesario;
4) la comunicación con aquellos afectados o implicados con la recuperación
después del incidente;
5) el reporte de la acción a la autoridad apropiada;
c) se deberían recolectar y asegurar los rastros para auditoría y la evidencia similar (véase
el numeral 13.2.3), según sea apropiado para:
1) el análisis de los problemas internos;
2) el uso de evidencia forense con respecto a la posible violación del contrato o del
requisito reglamentario o en caso de juicios criminales o civiles, por ejemplo,
según la legislación sobre uso inadecuado del computador o sobre protección de
datos;
3) la negociación para la compensación proveniente de los proveedores de
software y servicios;
d) la acción para la recuperación de las violaciones de la seguridad y la corrección de las
fallas del sistema debería estar cuidadosa y formalmente controlada; los procedimientos
deberían garantizar que:
1) únicamente el personal claramente identificado y autorizado tiene acceso a los
sistemas y datos activos (véase el numeral 6.2 para el acceso externo);
2) todas las acciones de emergencia están documentadas en detalle;
3) la acción de emergencia se reporta a la dirección y se revisa de manera
ordenada;
4) la integridad de los sistemas y controles del negocio se confirma con retraso
mínimo.
Los objetivos de la gestión de los incidentes de seguridad de la información se deberían
acordar con la dirección y se debería garantizar que los responsables de esta gestión
comprenden las prioridades de la organización para el manejo de los incidentes de seguridad de la información.
Información adicional
Los incidentes de seguridad de la información podrían trascender las fronteras de la
organización y las nacionales. Para responder a tales incidentes existe la necesidad creciente de coordinar la respuesta y compartir la información sobre estos incidentes con las organizaciones externas, según sea apropiado.

13.2.2 Aprendizaje debido a los incidentes de seguridad de la información

Control

Deberían existir mecanismos que permitan cuantificar y monitorear todos los tipos, volúmenes y costos de los incidentes de seguridad de la información.
Guía de implementación
La información que se obtiene de la evaluación de los incidentes de seguridad de la
información se debería utilizar para identificar los incidentes recurrentes o de alto impacto.
Información adicional
La evaluación de los incidentes de seguridad de la información puede indicar la necesidad de mejorar o agregar controles para limitar la frecuencia, el daño y el costo de futuras
recurrencias, o de considerarlos en el proceso de revisión de la política de seguridad (véase el numeral 5.1.2).

13.2.3 Recolección de evidencias

Control

Cuando una acción de seguimiento contra una persona u organización después de un incidente de seguridad de la información implica acciones legales (civiles o penales), la evidencia se debe recolectar, retener y presentar para cumplir con las reglas para la evidencia establecidas en la jurisdicción pertinente.
Guía de implementación
Se deberían desarrollar y cumplir procedimientos internos cuando se recolecta y se presenta evidencia con propósitos de acción disciplinaria dentro de la organización.
En general, las reglas para la evidencia comprenden los siguientes aspectos:
a) admisibilidad de la evidencia: si la evidencia se puede utilizar o no en la corte;
b) peso de la evidencia: la calidad y cabalidad de la evidencia.
Para lograr la admisibilidad de la evidencia, la organización debería asegurar que sus sistemas
de información cumplen cualquier norma o código de práctica publicado para la producción de evidencia admisible.
El peso de la evidencia suministrada debería cumplir todos los requisitos aplicables. Para lograr el peso de la evidencia, se debería demostrar la calidad y cabalidad de los controles empleados para proteger correcta y consistentemente la evidencia (es decir, evidencia del control del proceso) en todo el periodo en el cual la evidencia por recuperar se almacenó y procesó, mediante un rastro sólido de la evidencia. En general, dicho rastro sólido se puede establecer en las siguientes condiciones:
a) para documentos en papel: el original se guarda con seguridad con un registro de la
persona que encontró el documento, el sitio en donde se encontró, la fecha en la cual
se encontró y el testigo de tal hallazgo; toda investigación debería garantizar que los
originales no han sido alterados;
b) para información en medios de computador: se deberían tomar duplicados o copias
(dependiendo de los requisitos que se apliquen) de todos los medios removibles, la
información en los discos duros o la memoria para garantizar la disponibilidad; es
conveniente conservar el registro de todas las acciones durante el proceso de copiado y
dicho proceso debería tener testigos; el medio y el registro originales (si no es posible,
al menos un duplicado o copia) se deberían conservar intactos y de forma segura.
Todo el trabajo forense se debería llevar a cabo únicamente en copias del material de
evidencia. Se debería proteger la integridad de todo el material de evidencia. El proceso de
copia del material de evidencia debería estar supervisado por personal de confianza y se
debería registrar la información sobre cuándo y cómo se realizó dicho proceso, quién ejecutó las actividades de copiado y qué herramientas o programas se utilizaron.
Información adicional
Cuando un evento de seguridad de la información se detecta inicialmente, es posible que no sea obvio si el evento llevará a una acción judicial. Por lo tanto, existe el peligro de destruir intencional o accidentalmente la evidencia necesaria antes de percatarse de la gravedad del incidente. Es aconsejable la participación inicial de un abogado o de la policía en cualquier acción legal contemplada y asesorarse sobre la evidencia requerida.
La evidencia puede trascender las fronteras de la organización y / o las jurisdiccionales. En
tales casos, se debería garantizar que la organización tiene derecho a recolectar la información requerida como evidencia. Se deberían tener en cuenta los requisitos de las diferentes jurisdicciones para maximizar las oportunidades de admisión en las jurisdicciones correspondientes.

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.3.1 Política sobre el uso de controles criptográficos

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 encriptada;
i) 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.