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.
Al seleccionar los medios de almacenamiento electrónico, se
deberían incluir los 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 evidencia de que
la organización funciona cumpliendo las reglas estatutarias o reglamentarias, 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.
CAPITULO 14
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 cumplimentació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.
Las evaluaciones de riesgos para la continuidad del negocio
se deberían efectuar con la plena 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 implementacion 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 requerido, 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.
Los planes de continuidad del negocio deberían afrontar las
vulnerabilidades de la organización 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.
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).
jueves, 4 de junio de 2015
CAPITULO 13
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 empleados, 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;
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.
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.
