TRADUCCIÓN

NORMA INTERNACIONAL
ISO/IEC

17799:2000
BS 7799-1:2000

========================================

Informática – Código de Práctica para la

Administración de la Seguridad Informática

========================================

1
Prólogo

ISO (la Organización Internacional de Unificación) e IEC (la Comisión Electrotécnica

Internacional) conforman el sistema especializado para la unificación mundial. Los
organismos nacionales que son miembros de la ISO o IEC participan en la creación de
Normas Internacionales a través de comités técnicos establecidos por la correspondiente
organización para dar tratamiento a determinados campos de la actividad técnica. Los
comité técnicos de ISO e IEC colaboran en campos de interés mutuo. Otras organizaciones
internacionales, gubernamentales y no gubernamentales junto con la ISO e IEC también
participan en esta tarea.

Las Normas Internacionales se elaboran de acuerdo con las directivas de ISO/IEC, Parte 3.

En el campo de la informática, ISO e IEC han establecido un comité técnico conjunto,

ISO/IEC JTC 1. Los proyectos de Normas Internacionales adoptadas por el comité técnico
conjunto se hacen llegar a los organismos nacionales para su votación. La publicación en
carácter de Norma Internacional requiere la aprobación del 75%, como mínimo, de los
organismos nacionales con derecho a voto.

Existe la posibilidad de que algunos de los elementos de esta Norma Internacional puedan
quedar sujetos a los derechos de patente. ISO e IEC no estarán obligados a identificar total
o parcialmente los derechos de patente.

La Norma Internacional ISO/IEC 17799 fue preparada por el Instituto de Normas Británico
(BS 7799) y adoptada mediante un “procedimiento rápido” por el Comité Técnico Conjunto
ISO/IEC JTC 1, Informática, aprobada paralelamente por los organismos nacionales de ISO
e IEC.

2
Introducción

¿Qué es la seguridad informática?

La información es un activo que, al igual que otros activos comerciales importantes, tiene
un valor para una organización y por consiguiente debe protegerse de modo adecuado. La
seguridad informática protege la información respecto de una amplia gama de amenazas a
fin de asegurar a la comunidad comercial que los daños comerciales serán mínimos y la
rentabilidad en materia de inversiones y oportunidades comerciales serán las mejores.

La información puede adoptar diversas formas. Puede ser impresa o escrita, puede
almacenarse electrónicamente, transmitirse por correo o a través de medios electrónicos,
visualizarse en películas o divulgarse oralmente en una conversación. Sea cual fuere la
forma de la información o el medio por el que se transmita o almacene, siempre debería
protegerse adecuadamente.

Por lo tanto, la seguridad informática se caracteriza por la preservación de:

a) la confidencialidad: asegurando que sólo puedan acceder a la información los

usuarios autorizados;
b) integridad: salvaguardando la exactitud e integridad de la información y los
métodos de procesamiento;
c) disponibilidad: asegurando que los usuarios autorizados tengan acceso a la
información y activos asociados cuando lo requieran.

La seguridad informática se logra realizando una serie de controles adecuados, lo cuales

podrían consistir en políticas, prácticas, procedimientos, estructuras organizativas y
funciones relacionadas con el soporte magnético. Deben realizarse estos controles a fin de
asegurar que se cumplan los objetivos de seguridad específicos.

¿Por qué es necesaria la seguridad informática?

La información y los procesos de soporte, los sistemas y redes son activos comerciales
importantes. La confidencialidad, integridad y disponibilidad de la información puede
resultar esencial para mantener la competitividad, flujos de caja, rentabilidad, cumplimiento
jurídico e imagen comercial.

Las organizaciones y sus sistemas informáticos y redes deben enfrentar cada vez más
amenazas de seguridad provenientes de una amplia gama de fuentes, incluyendo la
comisión de fraude por computadora o el espionaje, sabotaje, vandalismo, incendio o
inundación que alcance a la misma. Las fuentes que producen daños y perjuicios tales
como los virus, piratas informáticos y los ataques a los servicios se han convertido en los
más comunes, más ambiciosos y cada vez más sofisticados.

3
La dependencia respecto de los sistemas y servicios informáticos significa que las
organizaciones son más vulnerables frente a las amenazas de seguridad. La interconexión
de las redes públicas y privadas y el múltiple acceso a los recursos informatizados
aumentan la dificultad de lograr el control del acceso. La tendencia a distribuir el
procesamiento informático ha debilitado la eficacia del control central especializado.

Muchos sistemas informáticos no han sido diseñados para que sean seguros. La seguridad
que puede lograrse a través de medios técnicos es limitada y debería respaldarse a través de
una gestión y procedimientos adecuados. La identificación de los controles que deberían
utilizarse requiere una cuidadosa y detallada planificación. La gestión de la seguridad
informática requiere, como mínimo, la participación de todos los empleados en la
organización. También puede requerirse la participación de proveedores, clientes o
accionistas. También será necesario contar con el asesoramiento especializado de
organizaciones externas.

Los controles de seguridad informática son considerablemente más baratos y más eficaces
si se incorporan cumpliendo con las especificaciones y diseño requeridos.

¿De qué forma se determinan los requerimientos de seguridad?

Resulta esencial que una organización identifique sus requerimientos de seguridad. Existen
tres fuentes principales.

La primera deriva de los riesgos de valoración respecto de la organización. A través de la

valoración del riesgo se identifican los activos sujetos a amenazas, se evalúa la
vulnerabilidad y la probabilidad de que la misma se produzca y se calcula su impacto
potencial.

La segunda constituye los requerimientos legales, normativos, reglamentarios y

contractuales que una organización, sus socios comerciales, contratistas y proveedores de
servicios tienen que cumplir.

La tercera es el grupo en particular de principios, objetivos y requisitos para procesar la

información que una organización preparó para brindar apoyo a sus operaciones.

Evaluación de los riesgos de seguridad

Los requerimientos de seguridad se identifican a través de una valoración metódica de los

riesgos de seguridad. Los gastos que generan los controles deben compensarse con el
probable daño comercial que pueda resultar de las fallas de seguridad. Las técnicas de
valoración de riesgo pueden aplicarse a toda la organización, ó únicamente a una parte de la
misma, así como también a los sistemas informáticos individuales, componentes del
sistema específicos o servicios cuando sea posible, razonable y útil.

4
La evaluación del riesgo constituye una consideración sistemática de:

a) el posible daño comercial que resulte de una falla de seguridad, teniendo en

cuenta las consecuencias potenciales de la pérdida de confidencialidad,
integridad o disponibilidad de la información y de otros activos;
b) la probabilidad razonable de que ocurra dicha falla a la luz de las amenazas y
vulnerabilidades existentes y los controles que se implementen en ese momento.

Los resultados de esta valoración ayudarán a guiar y determinar las medidas y prioridades
de gestión adecuadas para administrar los riesgos de seguridad informática y para aplicar
los controles seleccionados a fin de lograr una protección contra tales riesgos. El proceso
de evaluación de riesgos y la selección de controles probablemente deban llevarse a cabo
una serie de veces a fin de cubrir las diferentes partes de los sistemas de la información de
la organización o individuales.

La revisión periódica de los riesgos de seguridad y de los controles aplicados es importante

a fin de:

a) tener en cuenta los cambios de los requerimientos comerciales y las prioridades;

b) considerar las nuevas amenazas y vulnerabilidades;
c) confirmar que los controles sigan siendo efectivos y apropiados.

Las revisiones deberían llevarse a cabo en diferentes niveles de profundidad dependiendo

de los resultados de las valoraciones anteriores y los cambios de los niveles de riesgo que la
administración está preparada para aceptar. Las valoraciones de riesgo a menudo se llevan
a cabo a un nivel elevado, como una forma de priorizar los recursos en áreas de alto riesgo,
y luego en un nivel más detallado, para tratar los riesgos específicos.

Selección de controles

Una vez identificados los requerimientos de seguridad, deberían seleccionarse y aplicarse

los controles a fin de asegurar que los riesgos se reduzcan a un nivel aceptable. Los
controles pueden seleccionarse de este documento o de otros grupos de controles, o bien
pueden diseñarse nuevos controles para cumplir con las necesidades específicas, según
corresponda. Existen muchas formas diferentes de administrar el riesgo y este documento
proporciona ejemplos de criterios comunes. No obstante, es necesario reconocer que
algunos de los controles no son aplicables a cada uno de los sistemas o medio informático y
que probablemente no resulten practicables para todas las organizaciones. Por ejemplo, el
apartado 8.1.4. describe de qué manera las obligaciones pueden segregarse a fin de evitar
dolo y error. Probablemente las organizaciones más pequeñas no puedan segregar todas las
obligaciones y entonces será necesario contar con otras formas para lograr el mismo
objetivo de control. Los apartados 9.7 y 12.1 proporcionan otro ejemplo, describiendo de
qué manera puede controlarse el uso del sistema y obtenerse prueba de ello. Los controles
descriptos, por ejemplo la conexión al inicio de una sesión (logging) podría entrar en
conflicto con la legislación aplicable, tal como la protección de la privacidad de clientes o
en el ámbito del puesto de trabajo.

5
Los controles deberían seleccionarse en base al costo de aplicación en relación con los
riesgos que se están reduciendo y las pérdidas potenciales si se viola la seguridad. Los
factores no monetarios tales como los daños a la reputación también deberían tenerse en
cuenta.

Algunos de los controles en este documento pueden considerarse como principios de guía
para la gestión de seguridad informática y aplicable a la mayoría de las organizaciones.
Estos se explican en detalle bajo el título “Punto de partida de la seguridad informática”.

Punto de partida de la seguridad informática

Pueden considerarse una serie de controles en carácter de principios de guía que

proporcionan un buen punto de partida para lograr la seguridad informática. Estos se basan
en requerimientos legislativos esenciales o considerados la mejor práctica común para la
seguridad informática.

Los controles considerados como esenciales para una organización desde el punto de vista
de la legislación incluyen:

a) la protección de los datos y la privacidad de la información personal (véase

1.1.1.4.);
b) la salvaguardia de los registros de una organización (véase 12.1.3.);
c) los derechos de propiedad intelectual (véase 12.1.2.);

Los controles considerados como la mejor práctica común para la seguridad informática
incluyen:

a) el documento sobre política de seguridad informática (véase 3.1);

b) asignación de responsabilidades de seguridad informática (véase 4.1.3.);
c) la capacitación sobre seguridad informática (véase 6.2.1.);
d) el informe de incidentes de seguridad (véase 6.3.1.);
e) la gestión de la continuidad comercial (véase 11.1.).

Estos controles se aplican a la mayoría de las organizaciones y en la mayoría de los

entornos. Debería observarse que si bien todos los controles en este documento son
importantes, la conveniencia de cualquier control debería determinarse a la luz de los
riesgos específicos que una organización enfrenta. Por lo tanto, si bien el criterio expresado
es considerado un buen punto de partida, el mismo no reemplaza la selección de controles
basados en una evaluación de riesgo.

6
Factores de éxito críticos

La experiencia ha demostrado que los siguientes factores a menudo son críticos a la hora de
aplicar con éxito la seguridad informática dentro de una organización:

a) Política de seguridad, objetivos y actividades de la empresa que reflejen dichos

objetivos;
b) Criterio para aplicar la seguridad de acuerdo con la cultura de la organización;
c) Apoyo y compromiso visible por parte de la administración;
d) Buen entendimiento de los requerimientos de seguridad, evaluación de riesgo y
gestión de riesgo;
e) Comercialización efectiva de la seguridad a todos los administradores y empleados;
f) Distribución de guías sobre política de seguridad informática y normas a todos los
empleados y contratistas;
g) Capacitación adecuada;
h) Sistema global y equilibrado de cálculo que se utiliza para evaluar la evolución en la
gestión de seguridad informática y sugerencias constructivas para mejorar la misma.

Desarrollo de sus propias directrices

Este código de práctica puede considerarse como punto de partida para desarrollar la guía
específica de la organización. No todas las directrices y controles que aparecen en este
código de práctica pueden resultar aplicables. Además, pueden solicitarse los controles
adicionales que no se incluyeron en este documento. En este caso puede resultar útil
conservar las referencias que facilitarán la verificación del cumplimiento por parte de
auditores y socios en una organización.

7
 Informática – Código de práctica para la administración de la seguridad
informática

1. ALCANCE

Esta norma realiza recomendaciones respecto de la gestión de la seguridad informática a

aquellos que están a cargo de firmar, aplicar o mantener la seguridad en sus organizaciones.
La misma tiene el propósito de proporcionar una base común para crear normas de
seguridad para las organizaciones y una práctica de gestión de seguridad efectiva y
proporcionar confianza en las relaciones entre empresas. Deberían seleccionarse las
recomendaciones de esta norma y aplicarse de conformidad con las leyes y
reglamentaciones aplicables.

2. TÉRMINOS Y DEFINICIONES

A los fines de este documento, se aplican las siguientes definiciones.

2.1 Seguridad informática

La preservación de la confidencialidad, integridad y disponibilidad de la información.

- Confidencialidad
Asegurando que sólo puedan acceder a la información los usuarios autorizados.

- Integridad
Salvaguardando la exactitud e integridad de la información y métodos de procesamiento.

- Disponibilidad
Asegurando que los usuarios autorizados tengan acceso a la información y activos
asociados cuando lo requieran.

2.2 Evaluación del riesgo

La evaluación de la amenaza, impacto y vulnerabilidad de la información y medios de

procesamiento de información y la probabilidad de que ocurran.

2.3 Administración del riesgo

El proceso de identificación, control y minimización o eliminación de los riesgos de

seguridad que pueden afectar los sistemas informáticos a cambio de un costo aceptable.

8
3. POLÍTICA DE SEGURIDAD

3.1 Política de Seguridad Informática

Objetivo: Impartir directrices sobre administración y apoyar la seguridad informática.

La gestión debería establecer claras directrices sobre política y demostrar apoyo y

compromiso respecto de la seguridad informática a través de la creación y mantenimiento
de la política de seguridad informática en toda la organización.

3.1.1 Documento sobre política de seguridad informática

El documento sobre política debería ser aprobado por la administración. Además, debería
publicarse y comunicarse, cuando corresponda, a todos los empleados. Debería manifestar
el compromiso de la administración y establecer el criterio de la organización para
administrar la seguridad informática. Como mínimo, la guía debería incluir:

a) una definición de la seguridad informática, sus objetivos generales y alcance y la

importancia de la seguridad como mecanismo que permita compartir la
información (véase introducción);
b) una declaración de intención de la administración, respaldando los objetivos y
principios de la seguridad de información;
c) una breve explicación de las políticas, principios y normas de seguridad y el
cumplimiento de los requisitos de particular importancia para la organización, por
ejemplo:
a. cumplimiento de los requerimientos legislativos y contractuales;
b. necesidad de transmitir el concepto de seguridad;
c. prevención y detección de virus y demás software de índole delictiva;
d. gestión de la continuidad comercial;
e. consecuencias de la violación de la política de seguridad;
d) una definición de las responsabilidades general y específica respecto de la
administración informática, incluyendo la obligación de informar los
incidentes de seguridad;
e) referencia a la documentación que respalde la política, por ejemplo: las
políticas y procedimientos de seguridad más detallados sobre sistemas
informáticos o normas de seguridad específicos que los usuarios deberían
cumplir.

Esta política debería comunicarse a los usuarios a través de la organización de forma tal
que resulte accesible y fácil de interpretar.

9
3.1.2 Revisión y evaluación

La política debería estar a cargo de un responsable que además se ocupe de actualizarla y

revisarla de acuerdo con un proceso de revisión definido. Este proceso debería garantizar
la realización de una revisión en respuesta a todo cambio que afecte la valoración del riesgo
original, por ejemplo: hechos de seguridad significativos, nuevas formas de vulnerabilidad
o cambios en la infraestructura organizativa o técnica. Además, deberían programarse
revisiones periódicas de:

a) la efectividad de la política, demostrada por la naturaleza, cantidad y efecto de los

hechos de seguridad registrados;
b) costo e impacto de los controles sobre la eficiencia comercial;
c) efectos de cambios en la tecnología.

4. SEGURIDAD DE LA ORGANIZACIÓN

4.1 Infraestructura de la Seguridad Informática

Objetivo: Administrar la seguridad informática dentro de la organización.

Debería establecerse un marco de administración a fin de iniciar y controlar la aplicación

del sistema de seguridad informática dentro de la organización.
Deberían establecerse además medios de comunicación adecuados con los funcionarios
principales a cargo de la administración a fin de aprobar la política de seguridad
informática, asignar las funciones de seguridad y coordinar la aplicación de seguridad en la
organización. Si fuera necesario, debería contarse con el asesoramiento de especialistas en
materia de seguridad informática y el resultado del mismo debería comunicarse a la
organización. Asimismo, debería recurrirse al asesoramiento de especialistas en seguridad
externa para mantenerse en concordancia con las tendencias industriales, controlar las
normas y métodos de evaluación y proporcionar puntos de contacto adecuados cuando se
produzcan incidentes de seguridad. Además, debería fomentarse la determinación de un
criterio multidisciplinario, que incluya, por ejemplo, cooperación y colaboración de
administradores, usuarios, administradores, diseñadores de aplicaciones, auditores y
personal de seguridad, especialistas en áreas tales como el seguro y la gestión de riesgo.

4.1.1 Foros sobre administración de seguridad informática

La seguridad informática es una responsabilidad de la empresa compartida por todos los

miembros del equipo de administración. Por lo tanto, debería considerarse la posibilidad de
crear un foro de administración que garantice un respaldo claro y visible de la
administración a las iniciativas en materia de seguridad. Dichos foros deberían promover
la seguridad en el ámbito de la organización a través de un compromiso apropiado y
recursos adecuados. Los foros pueden ser parte de un órgano administrativo existente.
Típicamente, dichos foros se ocupan de:

10
 a) revisar y aprobar la política de seguridad y responsabilidades globales;
b) controlar los cambios significativos en la exposición de los activos informáticos a
las principales amenazas;
c) revisar y controlar los incidentes informáticos en materia de seguridad;
d) aprobar las principales iniciativas para reforzar la seguridad informática.

Un administrador debería estar a cargo de todas las actividades relacionadas con la

seguridad.

4.1.2 Coordinación de la Seguridad Informática

En una organización de gran envergadura los foros sobre funciones múltiples a cargo de
representantes de administración de los sectores relacionados de la organización pueden
resultar necesarios para coordinar la aplicación de controles de seguridad informática.
Típicamente, tales foros:
a) acuerdan las funciones y responsabilidades específicas respecto de la
información a lo largo de toda la organización;
b) acuerdan metodologías y procesos específicos respecto de la seguridad
informática, por ejemplo: la valoración del riesgo y el sistema de clasificación
de la seguridad;
c) acuerdan apoyar las iniciativas sobre seguridad informática a lo largo de toda la
organización, por ejemplo: el programa de difusión de temas atinentes a la
seguridad;
d) aseguran que la seguridad sea parte del proceso de planificación de la
información;
e) evalúan la suficiencia y coordinan la aplicación de los controles específicos de
seguridad informática para los nuevos sistemas o servicios;
f) revisan los incidentes de seguridad informática;
g) promocionan el apoyo comercial de la seguridad informática a lo largo de toda
la organización.

4.1.3 Asignación de responsabilidades respecto de la seguridad informática

Las responsabilidades respecto de la protección de cada uno de los activos y los procesos
de seguridad específicos deberían definirse claramente.

La política de seguridad informática (véase cláusula 3) debería proporcionar una guía

general respecto de la asignación de funciones y responsabilidades en cuanto a la seguridad
dentro de la organización. Esto debería completarse, si fuera necesario, con una guía más
detallada para lugares, sistemas o servicios específicos. Además debería definirse
claramente la responsabilidad local respecto del procesamiento de cada uno de los activos
físicos, aquellos relacionados con la información y la seguridad, tales como la planificación
de la continuidad comercial.

11
En muchas organizaciones debería designarse un administrador a cargo de la seguridad
informática que asuma la responsabilidad general respecto del desarrollo y aplicación del
sistema de seguridad y apoye la identificación de controles.

No obstante, la responsabilidad para recurrir a los controles y aplicar los mismos a menudo
estará a cargo de cada uno de los administradores. Una práctica común consiste en
designar a un responsable a cargo de cada activo de información, el que pasará a estar a
cargo de la seguridad día por día.

Los titulares de los activos informáticos pueden delegar sus responsabilidades en materia de
seguridad a cada uno de los administradores o proveedores de servicios. No obstante, el
titular continúa siendo responsable en última instancia de la seguridad de los activos y
debería estar en condiciones de determinar si cualesquiera de las responsabilidades
delegadas ha sido cumplida correctamente.

Resulta esencial que se determinan claramente las áreas a cargo de cada administrador; en
particular:

a) Deberían identificarse y definirse claramente los diversos activos y procesos de

seguridad asociados con cada sistema en particular;
b) El administrador a cargo de cada activo o proceso de seguridad debería estar de
acuerdo, debiendo documentar esta responsabilidad en detalle;
c) Los niveles de autorización deberían definirse y documentarse claramente.

4.1.4 Proceso de autorización para los mecanismos de procesamiento de información

Debería establecerse un proceso de autorización a cargo de la administración para procesar

toda nueva información.

Deberían considerarse los siguientes controles:

a) Los nuevos mecanismos deberían contar con la debida aprobación de usuarios

por parte de la administración, autorizando su propósito y uso. El administrador
a cargo de actualizar el medio de seguridad del sistema informático local debería
dar su aprobación a fin de asegurar que se cumplan todas las políticas y
requerimientos de seguridad pertinentes;

b) Cuando sea necesario, tanto el soporte físico (hardware) como el soporte

magnético (software) deberían verificarse a fin de asegurar que sean compatibles
con otros componentes del sistema.
Nota: En determinadas conexiones puede requerirse una aprobación de
caracteres.

c) El uso de mecanismos de procesamiento de información personal para procesar

información comercial y cualesquiera de los controles necesarios deberían estar
autorizados;

12
 d) El uso de mecanismos de procesamiento de información personal en el puesto de
trabajo puede provocar nuevas formas de vulnerabilidad y por consiguiente el
mismo debería evaluarse y autorizarse previamente.

Estos controles son especialmente importantes en un entorno de red.

4.1.5 Asesoramiento de un especialista en seguridad informática

Muchas organizaciones probablemente requieran el asesoramiento de un especialista en

seguridad. Sería importante que un asesor en seguridad informática experimentado de la
organización. No todas las organizaciones pueden aspirar a contratar un asesor
especializado. En tales casos, se recomienda que se identifique una determinada persona a
fin de coordinar el conocimiento y la experiencia internos de la organización para asegurar
una coherencia de criterios y proporcionar ayuda en la toma de decisiones en relación con
la seguridad. Estas organizaciones también deberían tener acceso a asesores externos
adecuados a fin de contar con el asesoramiento de un especialista fuera de su propia
experiencia.

Los asesores en materia de seguridad informática o contactos equivalentes deberían

proporcionar asesoramiento en todos los aspectos de la seguridad informática, recurriendo
tanto a su propia experiencia como al asesoramiento externo. La calidad de su evaluación
de las amenazas a la seguridad y asesoramiento sobre los controles determinará la
efectividad del sistema de seguridad informática de la organización. Para lograr la máxima
efectividad e impacto deberían estar autorizados a acceder directamente a la administración
de toda la organización.

El asesor de seguridad informática o contacto equivalente debería consultarse lo antes

posible desde el momento en que se detecte un incidente de seguridad o la interrupción del
servicio de asesoramiento o investigación prestado por un experto. Si bien la mayoría de
las investigaciones sobre seguridad interna normalmente se llevarán a cabo bajo control de
la administración, el asesor de seguridad informática puede convocarse para asesorar y
llevar a cabo la investigación.

4.1.6 Cooperación entre organizaciones

Las autoridades judiciales, órganos reguladores, proveedores de servicio informático y

operadores en telecomunicaciones deberían mantenerse en contacto a fin de asegurar que se
tomen las medidas necesarias y se cuente con el asesoramiento adecuado rápidamente en
caso de producirse un incidente de seguridad. De modo similar, deberían considerarse los
miembros de los grupos de seguridad y los foros industriales.

El intercambio de información sobre seguridad debería restringirse a fin de asegurar que la

información confidencial de la organización no sea divulgada a personas no autorizadas.

4.1.7 Revisión independiente de la seguridad informática

13
El documento sobre política de seguridad informática (véase 3.1) establece la política y las
responsabilidades respecto de la seguridad informática. Su aplicación debería revisarse en
forma independiente para asegurar que las prácticas de la organización reflejen la política
adecuadamente y que esta última sea posible y efectiva (véase 12.2).
Dicha revisión puede estar a cargo de un auditor interno, un administrador independiente o
una tercera organización especializada en esta tarea, debiendo en todos los casos contar con
la debida idoneidad y experiencia.

4.2 Seguridad del acceso de un tercero

Objetivo: Mantener la seguridad del mecanismo de procesamiento de información y

activos de información de la organización a los que acceden terceros.

Debería controlarse el acceso a los mecanismos de procesamiento de información de la

organización por parte de terceros.

Cuando sea necesario el acceso de un tercero, debería evaluarse el riesgo a fin de

determinar las consecuencias en cuanto a la seguridad y los requisitos de control. Los
controles deberían acordarse y definirse en un contrato celebrado con el tercero.

El acceso de un tercero también puede acarrear la participación de otras partes. Los

contratos que confieren el acceso a terceros deberían contemplar la posibilidad de designar
a otros participantes y condiciones necesarios para su acceso.

Esta norma podría utilizarse como base para preparar tales contratos y cuando se considere
la contratación externa del procesamiento de información.

4.2.1. Identificación de riesgo por el acceso de terceros

4.2.1.1 Tipos de Acceso

El tipo de acceso que se otorga a un tercero es de especial importancia. Por ejemplo, los
riesgos de acceso a través de una conexión a la red son diferentes de los riesgos provocados
por el acceso físico. Los tipos de acceso que deberían considerarse son:

a) acceso físico, por ejemplo a oficinas, salas de computación, gabinetes de archivo;

b) acceso virtual, por ejemplo a la base de datos y sistemas informáticos de una
organización.

4.2.1.2 Razones de acceso

Los terceros pueden obtener acceso por una serie de razones. Por ejemplo, existen algunos
terceros que prestan servicios a una organización y no están ubicados en la misma zona. En
este caso pueden lograr el siguiente acceso físico y virtual:

14
 a) personal a cargo de brindar asesoramiento técnico en materia de programas y
quipos, que requiere acceder al sistema o a aplicaciones de bajo nivel;
b) socios comerciales o emprendimientos conjuntos, que pueden necesitar
intercambiar información, acceder a los sistemas informáticos o compartir bases
de datos.

La información podría exponerse a riesgo cuando acceda a la misma un tercero en el marco

de una administración inadecuada de la seguridad. Cuando una empresa necesita
conectarse a un tercero, debería llevarse a cabo una evaluación a fin de identificar los
requerimientos de controles específicos. Asimismo, debería tenerse en cuenta el tipo de
acceso requerido, el valor de la información, los controles empleados por el tercero y las
consecuencias de este acceso a la seguridad informática de la organización.

4.2.1.3 Contratistas que trabajan in-situ

Los terceros que trabajan in situ durante un período conforme a lo definido en sus contratos
también pueden dar lugar a deficiencias en materia de seguridad. Los ejemplos de terceros
in situ incluyen:

a) El personal a cargo de la actualización de equipos y soporte magnético y personal

técnico;
b) Servicios de limpieza, provisión de alimentos, guardias de seguridad y demás
servicios de soporte contratados externamente;
c) Estudiantes en cumplimiento de pasantías y demás designaciones de corto plazo.
d) Consultores.

Resulta esencial comprender qué controles se requieren para administrar el acceso de un

tercero a los mecanismos de procesamiento de información. En general, todos los
requerimientos de seguridad en función del acceso de terceros o los controles internos
deberían reflejarse en el contrato de terceros (véase también 43.2.2.). Por ejemplo, si existe
una necesidad especial de mantener la confidencialidad de la información, deberían
utilizarse acuerdos de no divulgación (véase 6.1.3).

El acceso a la información y a los mecanismos de procesamiento informático por parte de

terceros no debería permitirse hasta que se hayan aplicado los controles y se haya firmado
un contrato que defina los términos de la conexión o acceso.

4.2.2 Requerimientos de seguridad en contratos de terceros

Los acuerdos que incluyen el acceso de terceros a los mecanismos de procesamiento de

información de una organización deberían basarse en un contrato formal que contenga
todos los requerimientos de seguridad, o se refiera a los mismos, a fin de asegurar el
cumplimiento de las políticas y normas de seguridad de la organización. El contrato
debería asegurar que no haya malos entendidos entre la organización y el tercero. Las
organizaciones deberían aprobar la indemnización de sus proveedores. Deberían
considerarse los siguientes términos para incluirlos en el contrato:

15
a) la política general sobre la seguridad informática;
b) la protección de activos, incluyendo:
1) los procedimientos para proteger los activos de la organización, incluyendo
la información y el soporte magnético;
2) procedimientos para determinar si se ha producido algún tipo de
compromiso de activos, por ejemplo: pérdida o modificación de datos;
3) controles para asegurar la devolución o destrucción de información y activos
al extinguirse el contrato o en cualquier momento en que se acuerde durante
la vigencia del mismo;
4) integridad y disponibilidad;
5) restricciones para copiar y revelar información;

c) una descripción de cada servicio que se pondrá a disposición;

d) el nivel de servicios esperado y los niveles de servicio inaceptables;
e) la disposición sobre la transferencia de personal cuando resulte conveniente;
f) la respectiva responsabilidad de las partes del contrato;
g) las responsabilidades con respecto a cuestiones legales, por ejemplo: la legislación
sobre protección de información, en especial teniendo en cuenta los diferentes
sistemas legales nacionales si el contrato requiere la cooperación de organizaciones
en otros países (véase también 12.1);
h) los derechos de propiedad intelectual y cesiones de derechos de autor (véase 12.1.2)
y protección de cualquier trabajo de colaboración (véase también 6.1.3);
i) los acuerdos de control de acceso que abarquen:
1) los métodos de acceso permitidos y el control y uso de identificadores
únicos tales como los ID o claves de usuarios;
2) un proceso de autorización de acceso y derechos de usuarios;
3) requerimiento de mantener una lista de personas autorizadas a utilizar los
servicios que se ponen a disposición y cuáles son sus derechos y privilegios
con respecto a dicho uso;
j) la definición de criterios de cumplimiento verificable, control e informe de los
mismos;
k) el derecho a controlar y revocar la actividad del sumario;
l) el derecho a auditar las responsabilidades contractuales y a ordenar que dichas
auditorias sean llevadas a cabo por un tercero;
m) el establecimiento de un proceso escalonado para la solución de problemas; también
deberían considerarse los acuerdos contingentes cuando corresponda;
n) las responsabilidades con respecto a la instalación y mantenimiento de equipos y
soporte magnético;
o) una clara estructura de informes y formularios acordados para suministrar los
mismos;
p) un proceso claro y específico de administración de cambios;
q) los controles de protección física y mecanismos para asegurar que se cumplan estos
controles;
r) capacitación de usuarios y administradores en cuanto a los métodos, procedimientos
y seguridad;
s) los controles para asegurar la protección contra soportes magnéticos ilícitos;

16
t) acuerdos para informar, notificar e investigar los incidentes de seguridad y violación
de los sistemas de seguridad;
u) la participación de terceros con subcontratistas.

17
4.3 Contratación externa

Objetivo: Mantener la seguridad informática cuando la responsabilidad en cuanto al

procesamiento de información está a cargo de otra organización contratada.

Los acuerdos de contratación deberían contemplar los riesgos, controles y procedimientos

de seguridad para los sistemas informáticos, redes y/o entornos de escritorio en el contrato
entre las partes.

4.3.1 Requerimientos de seguridad en las contrataciones externas

Los requerimientos de seguridad de una organización que contrata en forma externa la

administración y control de todos o algunos de sus sistemas informáticos, redes y/o
computadoras deberían constar en un contrato celebrado entre las partes.

Por ejemplo, el contrato debería establecer:

a) de qué manera deben cumplirse los requerimientos legales, por ejemplo: legislación
de protección de la información;
b) qué medidas se adoptarán para asegurar que todas las partes vinculadas a la
contratación externa, incluyendo a los subcontratistas, conocen sus
responsabilidades con respecto a la seguridad;
c) de qué manera deben mantenerse y verificarse la integridad y confidencialidad de
los activos comerciales de la organización;
d) qué controles físicos y virtuales se utilizarán para restringir y limitar el acceso de los
usuarios autorizados a la información comercial confidencial de la organización;
e) de qué manera se mantendrá la disponibilidad de servicios en caso de desastre;
f) qué niveles de seguridad física deben estipularse para los equipos contratados en
forma externa;
g) el derecho a realizar auditorias.

Los términos expresados en la lista del apartado 4.2.2 deberían considerarse como parte de
este contrato. El contrato debería contemplar que se amplíen los requerimientos y
procedimientos de seguridad en un plan de administración de seguridad que debería ser
aprobado por ambas partes.

Si bien los contratos de contratación externa pueden plantear interrogantes de seguridad

complejos, los controles incluidos en este código de práctica podrían servir como punto de
partida para acordar la estructura y contenido del plan de administración de la seguridad.

18
5. Clasificación y control de Activos

5.1 Responsabilidad respecto de los activos

Objetivo: Mantener la protección adecuada de los activos de la organización.

Todos los activos informáticos principales deberían estar a cargo de un responsable

nombrado quien debería rendir cuenta de los mismos. La responsabilidad respecto de los
activos ayuda a asegurar que se mantenga la protección adecuada. Deberían identificarse
los responsables a los fines de todos los activos principales y debería asignarse a los
mismos la responsabilidad respecto del mantenimiento de los controles adecuados. La
responsabilidad respecto de la aplicación de controles puede delegarse. La responsabilidad
debería seguir correspondiendo a la persona a cargo de los activos.

5.1.1 Inventario de activos

Los inventarios de activos ayudarán a asegurar la efectiva protección de activos y también

pueden realizarse por otras razones comerciales tales como salud y seguridad, seguro o
finanzas (administración de activos). El proceso de compilación de un inventario de
activos es un aspecto importante de la administración del riesgo. Una organización debe
estar en condiciones de identificar sus activos y el valor relativo e importancia de estos
activos. En base a esta información, una organización puede entonces proporcionar niveles
de proporción de acuerdo con el valor e importancia de los activos. Cada activo debería
identificarse claramente y su titularidad y clasificación de seguridad (véase 5.2) acordada y
documentada, junto con su ubicación actual (importante cuando intenta cubrir pérdidas o
daños). Los ejemplos de activos asociados con los sistemas informáticos son:

a) activos de información: bases y archivos de datos, documentación del sistema,

manuales de usuario, material de capacitación, procedimiento operativo o de
apoyo, planes de continuidad, planes “b”, información archivada;
b) activos magnéticos: aplicaciones de soporte magnético, soporte magnético del
sistema, herramientas y aplicaciones de programas;
c) activos físicos: equipos de computadoras (procesadores, monitores,
computadoras portátiles, modems), equipos de comunicaciones (Routers,
PABXs, facsímil, contestadores automáticos), medio magnético (cintas y
discos), otros equipos técnicos (proveedores de energía, unidades de aire
acondicionado), muebles, instalaciones;
d) servicios: servicios informáticos y de comunicaciones, servicios generales, por
ejemplo: calefacción, iluminación, energía, aire acondicionado.

19
5.2 Clasificación de la información

Objetivo: Asegurar que los activos de información se reciban en un nivel de protección

adecuado.

La información debería clasificarse para indicar la necesidad, prioridades y grado de

protección. La información posee grados variables de sensibilidad y grado de importancia.
Algunos puntos pueden requerir un nivel de protección adicional o un manejo especial. El
sistema de clasificación de la información debería emplearse para definir un conjunto de
niveles de protección adecuados, y comunicar la necesidad de aplicar medidas especiales de
manejo.

5.2.1 Directrices de Clasificación

Las clasificaciones y los controles de protección de la información relacionados deberían

tener en cuenta las necesidades de la empresa en cuanto a compartir o restringir el acceso a
la información y los impactos comerciales asociados con tales necesidades, por ejemplo: el
acceso no autorizado o daño a la información. En general, la clasificación conferida a la
información es una forma abreviada de cómo debe manejarse y protegerse esta
información.

La información y los resultados de los sistemas que manejan datos clasificados deberían
dividirse en grupos en función de su valor y grado de sensibilidad respecto de la
organización. También puede resultar apropiado clasificar la información en función del
grado de importancia que la misma tiene para la organización, por ejemplo: en función de
su integridad y disponibilidad. A menudo una información deja de ser sensible o
importante después de un determinado período, por ejemplo, cuando la información ha sido
revelada al público. Estos aspectos deberían tenerse en cuenta ya que la sobre clasificación
puede dar lugar a un gasto comercial adicional innecesario. Las directrices de clasificación
deberían anticiparse y considerar el hecho de que la clasificación de cualquier punto de
información no necesariamente es fijo a lo largo del tiempo y puede cambiar de
conformidad con alguna política predeterminada (véase 9.1).

Debería considerarse además el número de categorías de clasificación y los beneficios que

obtendrán de su uso. Los esquemas excesivamente complejos pueden transformarse en
engorrosos y antieconómicos en lo que a uso se refieren o bien pueden resultar ser
impracticables. Debería tenerse cuidado en la interpretación de los rótulos de clasificación
de los documentos de otras organizaciones que pueden asignar diferentes definiciones a los
mismos rótulos o a aquellos que resulten similares.

La responsabilidad en cuanto a la definición de la clasificación de un punto de información,

por ejemplo: en un documento, registro de información, archivo de datos o disquete, o bien
para revisar periódicamente dicha clasificación, debería seguir correspondiendo a la
persona designada a cargo de la información o a aquella que generó la misma.

20
5.2.2 Rotulado y manejo informático

Resulta importante definir un conjunto de procedimientos apropiados con respecto al

rotulado y manejo informático de conformidad con el programa de clasificación adoptado
por la organización. Estos procedimientos deben cubrir los activos de información en
forma física y virtual. Para cada clasificación, deberían definirse procedimientos de manejo
a fin de cubrir los siguientes tipos de actividad de procesamiento de información:

a) copiado;
b) almacenado;
c) transmisión por correo, fax y correo electrónico;
d) transmisión verbal, incluyendo teléfono celular, mensajes grabados,
contestadores automáticos;
e) destrucción.

La información generada por los sistemas contienen datos que pueden clasificarse como
sensibles o importantes debería portar el rótulo de clasificación adecuado. El rótulo debería
reflejar la clasificación de acuerdo con las normas establecidas en el apartado 5.2.1. Los
rubros sujetos a consideración incluyen los informes impresos, los datos en pantalla,
medios registrados (cintas, discos, CDs, casetes), mensajes electrónicos y transferencias de
archivos.

Generalmente los rótulos físicos son la forma de rotulación más adecuada. No obstante,
algunos activos de información, tal como los documentos en forma electrónica, no pueden
rotularse físicamente y por lo tanto debe efectuarse por medio electrónico.

6. SEGURIDAD A CARGO DEL PERSONAL

6.1 Seguridad en la definición del trabajo y empleo de recursos

Objetivo: Reducir los riesgos de error humano, hurto, fraude o mala utilización de los
servicios.

La responsabilidad en materia de seguridad debería aplicarse en la etapa de contratación de

personal, incluirse en los contratos y controlarse durante el desempeño de cada empleado.

Las potenciales contrataciones de personal deberían examinarse adecuadamente (véase

6.1.2), especialmente para los trabajos críticos. Todos los empleados y terceros usuarios de
sistemas de procesamiento de información deberían firmar un contrato de confidencialidad
(de no divulgación).

21
6.1.1 Inclusión de la seguridad en la responsabilidad laboral

Las funciones y responsabilidades en relación con la seguridad, tal como lo establece la

política de seguridad informática de la organización (véase 3.1) debería documentarse, en
caso de corresponder. Estas deberían incluir las responsabilidades generales para aplicar o
mantener la política de seguridad así como también toda responsabilidad específica para la
protección de determinados activos o para la realización de ciertos procesos o actividades
de seguridad.

6.1.2 Examen del Personal y Política

La verificación del personal de la planta permanente debería realizarse en el momento de

procesarse las aplicaciones. Esta debería incluir los siguientes controles:

a) disponibilidad de referencias satisfactorias en cuanto a la reputación, por ejemplo:

una laboral y otra personal;
b) verificación del curriculum vitae del solicitante (exactitud y totalidad de datos);
c) confirmación de la idoneidad académica y profesional;
d) verificación de identidad independiente (pasaporte o documento similar).

Cuando un trabajo, ya sea a través de un nombramiento inicial o una promoción, involucre

una persona con acceso al procesamiento informático, y en especial, si dicho procesamiento
maneja información confidencial, por ejemplo; información financiera o información
altamente confidencial, la organización también debería llevar a cabo una verificación del
crédito. Para el personal de autoridad considerable, esta verificación debería repetirse en
forma periódica.

Un proceso de examen similar debería llevarse a cabo con respecto a los contratistas y
personal temporario. En el caso de que este tipo de personal sea contratado por intermedio
de una agencia, el contrato con la agencia debería especificar claramente las
responsabilidades de la agencia con relación al examen y los procedimientos de
notificación que tienen que seguir en caso de que no se haya completado el examen o si los
resultados dan motivo a duda o inquietud.

La administración debería evaluar la supervisión requerida con respecto al personal nuevo y

sin experiencia que cuente con autorización de acceso a sistemas confidenciales. La tarea
de todo el personal debería encontrarse sujeta a procedimientos de revisión y aprobación
periódicos llevados a cabo por los integrantes de mayor jerarquía del personal.

Los administradores deberían ser conscientes de que circunstancias personales de su

personal pueden afectar su trabajo. Los problemas personales o financieros, cambios en su
conducta o estilo de vida, ausencias reiteradas y pruebas de tensión o depresión podrían
conducir a fraudes, robos, errores y otros temas que involucren la seguridad. Esta
información debería ser manejada de conformidad con cualquier legislación adecuada
vigente en la jurisdicción respectiva.

22
6.1.3 Contratos de Confidencialidad

Los contratos de confidencialidad o no divulgación de información se utilizan para notificar

el carácter confidencial o secreto de la información. Los empleados deberían normalmente
firmar tales contratos como parte de los términos y condiciones que inician su vinculación
con la empresa.

El personal accidental y usuarios que sean terceros no ya cubiertos por un contrato vigente
(que contenga el contrato de confidencialidad) deberían firmar un contrato de
confidencialidad antes de que se les brinde acceso a las facilidades de procesamiento de
información.

Los convenios de confidencialidad deberían ser revisados cuando se produzcan cambios en

los términos de empleo o del contrato, especialmente cuando los empleados dejen la
organización o se produzca la extinción del contrato.

6.1.4 Términos y condiciones del empleo

Los términos y condiciones de empleo deberían declarar la responsabilidad del empleado

con respecto a la seguridad informática. En los casos apropiados, dichas responsabilidades
deberían seguir vigentes por un lapso determinado con posterioridad a la terminación del
empleo. Deberían incluirse las medidas a adoptar en caso de que el empleo no tenga en
cuenta los requisitos de seguridad.

Las responsabilidades y derechos legales del empleado, por ejemplo con respecto a las
leyes de derechos de autor o la legislación de protección a los datos, deberían ser aclarados
e incluidos dentro de los términos y condiciones de empleo. También debería incluirse la
responsabilidad por la clasificación y administración de los datos del empleador. En los
casos en que resulte pertinente, los términos y condiciones de empleo deberían manifestar
que tales responsabilidades se hacen extensivas fuera de las instalaciones de la organización
y del horario normal de tareas, vale decir en caso de que se realicen tareas en el hogar
(véase asimismo 7.2.5 y 9.8.1).

6.2 Capacitación del usuario

Objetivo: Asegurar que los usuarios sean conscientes de las amenazas e inquietudes que
penden sobre la seguridad informática y que estén en condiciones de apoyar la política de
seguridad de la organización en el transcurso de su tarea habitual.

Los usuarios deberían recibir capacitación con relación a procedimientos de seguridad y al

uso correcto de las facilidades de procesamiento informático a los efectos de minimizar los
posibles riesgos de seguridad.

23
6.2.1 Capacitación en Seguridad Informática

Todos los empleados de la organización y cuando correspondiere, terceros usuarios,

deberían recibir capacitación adecuada y actualizaciones a intervalos regulares respecto de
las políticas y procedimientos de la organización. Entre ellos, se incluyen los requisitos de
seguridad, responsabilidad legal y controles de la empresa, así como también capacitación
en cuanto al uso correcto del procesamiento informático, por ejemplo procedimiento de
conexión, uso de paquetes de programas, acceso previo a la información o servicios que se
brindan.

6.3 Respuestas antes incidentes de seguridad y malfuncionamiento

Objetivo: Reducir a un mínimo el daño provocado por incidentes de seguridad y errores en

el funcionamiento y efectuar un seguimiento con aprendizaje de tales incidentes.

Los incidentes que afectan la seguridad deberían ser comunicados a través de los canales
administrativos adecuados a la brevedad.

Todos los empleados y contratistas deberían tener conocimiento de los procedimientos de

comunicación de los distintos tipos de incidentes (falla de seguridad, amenaza, debilidad o
mal funcionamiento) que podrían tener impacto sobre la seguridad de los activos de la
organización. Se les debería exigir que comuniquen al punto de contacto designado al
efecto cualquier incidente que observen o sospechen que exista a la brevedad. La
organización debería establecer un proceso disciplinario formal para tratar aquellos casos
en los cuales empleados incurran en fallas de seguridad. A fin de poder encarar
debidamente dichos incidentes, podría resultar necesario recopilar pruebas a la brevedad
luego de ocurrido el incidente (véase 12.1.7)

6.3.1 Comunicación de incidentes de seguridad

Los incidentes de seguridad deberían ser comunicados a través de los canales

administrativos adecuados a la brevedad.

Debería crearse un procedimiento de comunicación formal junto con un procedimiento de

respuesta al incidente, estableciendo las medidas a tomar al recibirse un informe de
existencia de un incidente. Todos los empleados y contratistas deberían tener presente el
procedimiento de comunicación de incidentes de seguridad y se les debería exigir que
comuniquen dichos incidentes cuanto antes. Deberían crearse procesos de retroalimentación
de información conveniente a los efectos de garantizar que quienes comunican los
incidentes sean notificados de los resultados luego de que se haya resuelto el incidente y
cerrado el caso. Estos incidentes pueden utilizarse a modo de ejemplo para que el usuario a
través de la capacitación (véase 6.2) conozca lo que podría suceder, cómo responder ante
tales incidentes y cómo evitarlos en el futuro (véase también 12.1.7).

24
6.3.2 Comunicación de la existencia de deficiencias en la seguridad

Debería exigirse a los usuarios de servicios informáticos que registren y comuniquen

cualquier debilidad en la seguridad que observen o sospechen que exista o de amenazas al
los sistemas o servicios. Deberían comunicar estas cuestiones cuanto antes a su
administración o directamente al prestador del servicio. Debería informarse a los usuarios
que bajo ninguna circunstancia deberían intentar investigar una debilidad supuesta. Esta
medida se adopta para su propia protección dado que realizar pruebas respecto de
debilidades podría ser interpretado como un mal uso potencial del sistema.

6.3.3 Comunicación del malfuncionamiento de programas

Deberían crearse procedimientos de comunicación de errores en el funcionamiento de

programas. Se debería considerar la adopción de las medidas siguientes.

a) Los síntomas del problema y cualquier mensaje que aparezca en pantalla

deberían registrarse.
b) El computador debería aislarse y, de ser posible, interrumpir el uso del mismo.
El contacto pertinente debería recibir la alerta de inmediato. Si el equipo debe
ser examinado, debería desconectarse el mismo de cualquier red de la
organización antes de que se lo vuelva a conectar. Los diskettes no deberían ser
transferidos a otras computadoras.
c) El asunto debería ser comunicado inmediatamente al administrador de seguridad
informática.

Los usuarios no deberían intentar remover el programa bajo sospecha a menos que se les
autorice a proceder de esa manera. La recuperación debería estar a cargo de personal
experimentado y debidamente capacitado.

6.3.4 Aprendizaje a partir de los Incidentes

Deberían existir mecanismos que permitan que los tipos, volúmenes y costos de los
incidentes y errores de funcionamiento sean cuantificados y verificados. Esta información
debería emplearse para identificar los incidentes o errores de funcionamiento recurrentes o
de alto impacto. La existencia de tales situaciones puede indicar la necesidad de fortalecer o
agregar controles destinados a limitar la frecuencia, daño y costo de sucesos futuros o a
tomarlos en cuenta en el proceso de revisión de la política de seguridad (véase 3.1.2).

6.3.5 Proceso Disciplinario

Debería existir un proceso disciplinario formal destinado a ser aplicado a los empleados
que hayan violado las políticas y procedimientos de seguridad de la organización (véase
6.1.4 y, para la retención de pruebas, véase 12.1.7). Dicho proceso puede actuar como un
factor disuasivo para aquellos empleados que de otro modo podrían verse inclinados a no
tomar en cuenta los procedimientos de seguridad. Además, debería garantizar el tratamiento
correcto y justo de los empleados sospechados de cometer violaciones graves o recurrentes
en materia de seguridad.

25
7 SEGURIDAD FÍSICA Y AMBIENTAL

7.1. Áreas seguras

Objetivo: Impedir el acceso sin autorización, daños e interferencia a las instalaciones de la

empresa y su información.

Los sistemas de procesamiento informático de la empresa de carácter crítico o confidencial

deberían estar ubicados en zonas de seguridad, protegidos por un perímetro de seguridad
definido con barreras de seguridad y controles de ingreso adecuados. Deberían estar
protegidos físicamente frente al acceso sin autorización, daños e interferencia.

La protección proporcionada debería ser compatible con los riesgos identificados. Una
política de escritorios y pantallas limpios es la recomendada a fin de reducir el riesgo de
acceso sin autorización o daños a los documentos, medios de comunicación y sistemas de
procesamiento informático.

7.1.1 Perímetro de seguridad física

La protección física se puede lograr mediante la creación de varias barreras físicas en torno
de las instalaciones y sistemas de procesamiento de información de la empresa. Cada
barrera establece un perímetro de seguridad, cada una de ellas incrementa la protección
total. Las organizaciones deberían emplear perímetros de seguridad para proteger zonas
que contengan sistemas de procesamiento de información (véase 7.1.3). Un perímetro de
seguridad es algo que construye una barrera, por ejemplo, una pared, una puerta de ingreso
con control de tarjeta o una mesa de recepción. La ubicación y solidez de cada barrera
depende de los resultados que se obtengan en una evaluación del riesgo.

Los lineamientos y controles siguientes deberían tenerse en cuenta y aplicados en los casos
en que se considere pertinente hacerlo:

a) El perímetro de seguridad debería definirse claramente.

b) El perímetro de un sitio o edificio que contenga sistemas de procesamiento

informático deberían ser sólidos en sentido físico (vale decir que no deberían
existir brechas en el perímetro o zonas donde puedan producirse irrupciones con
facilidad). Las paredes externas del sitio deberían ser de construcción sólida y
todas las puertas externas deberían estar convenientemente protegidas contra
acceso sin autorización, por ejemplo mediante la acción de mecanismos de
control, barras, alarmas, cierres, etc.

c) Debería existir una zona de recepción con personal u otros medios de control
físico del acceso al sitio o edificio. El acceso a los sitios y edificios debería estar
habilitado para al personal autorizado exclusivamente.

26
 d) En caso necesario, las barreras físicas deberían extenderse desde el piso al techo
real a fin de impedir el ingreso sin autorización y la contaminación ambiental a
través de incendios e inundaciones.

e) Todas las puertas de escape ante incendio del perímetro de seguridad deberían
contener alarmas y cierres automáticos.

7.1.2 Controles de acceso físico

Las zonas de seguridad deberían encontrarse protegidas por controles de ingreso adecuados
que garanticen que solamente se permitirá el ingreso al personal autorizado. Se debería
considerar la aplicación de los controles que se enumeran a continuación:

a) Los visitantes de las zonas de seguridad deberían ser supervisados o admitidos y

su fecha y hora de ingreso y partida deberían registrarse. Solamente se
concederá acceso a los fines específicos autorizados y se deberían emitir
instrucciones sobre los requisitos de seguridad de la zona y procedimientos de
emergencia.

b) El acceso a información confidencial y a los sistemas de procesamiento

informático, debería encontrarse controlado y estar restringido a las personas
autorizadas al efecto solamente. Los controles de autenticación, es decir las
tarjetas magnéticas más clave de identificación deberían ser empleadas para
autorizar y validar todos los accesos. Se deberían contar con un rastreo
permanente de todos los accesos
c) Se debería exigir a todo el personal que utilice algún tipo de identificación
visible y se lo debería alentar para que encare a extraños que circulen sin
acompañamiento y a cualquiera que no use una identificación visible.

d) Los derechos de acceso a las zonas de seguridad deberían ser examinados y

actualizados en forma regular.

7.1.3 Seguridad de oficinas, salas y sistemas

Una zona de seguridad podrá ser una oficina o varias oficinas cerradas dentro de un
perímetro de seguridad física que pueden encontrarse cerrados o contener gabinetes y cajas
de seguridad que se pueden cerrar. La selección y diseño de una zona de seguridad debería
tomar en cuenta la posibilidad de daño por fuego, inundación, explosión, disturbio civil y
otra forma de desastre natural o provocado por el hombre. También se tendrán en cuenta las
normas y pautas de higiene y seguridad pertinentes. También se deberían tener en cuenta
las amenazas a la seguridad debidas a instalaciones vecinas, pro ejemplo, filtraciones de
agua provenientes de otras zonas.

27
Se debería considerar la posibilidad de aplicación de los controles que se detallan a
continuación:

a) Los sistemas fundamentales deberían concentrarse en sitio a los cuales no tenga

acceso el público.

b) Los edificios no deberían provocar obstrucciones y dar mínimos indicios de su

propósito sin signos obvio fuera o dentro del edificio que identifiquen la
presencia de actividades de procesamiento informático.

c) Las funciones y equipos de apoyo, pro ejemplo, fotocopiadores, máquinas de

fax, deberían encontrarse situados adecuadamente dentro de la zona de
seguridad a fin de evitar pedidos de acceso, que podrían comprometer la
información.

d) Las puertas y ventanas deberían encontrarse cerradas cuando no halla personal y

se debería considerar la posibilidad de proporcionar protección externas a las
ventanas, especialmente en planta baja.

e) Se deberían instalar sistemas de detección de intrusos convenientes ceñidos a

normas profesionales y verificados en forma regular a fin descubrir todas las
puertas externas y ventanas accesibles. Las zonas no ocupadas deberían contener
en todo momento alarmas. También se debería proporcionar cobertura a otras
zonas, por ejemplo, sala de computadoras o de comunicaciones.

f) Los sistemas de procesamiento informático de la organización deberían

encontrarse separados físicamente de los sistemas del mismo tipo manejados por
terceros.

g) Las guías y agendas telefónicas internas que identifiquen las posiciones de

sistemas de procesamiento informático confidenciales no deberían encontrarse a
disposición del público

h) Los materiales peligrosos o combustibles deberían almacenarse en forma segura

a un distancia prudencial de una zona de seguridad. Los suministros a granel
como ser la papelería no deberían almacenarse dentro de una zona de seguridad
cuando no resulte necesario.

i) El equipo de emergencia y medios de resguardo informático deberían estar

situados a una distancia prudencial que evite daño en caso de desastre en el sitio
principal.

28
7.1.4 El trabajo en áreas de seguridad

Se pueden exigir controles y lineamientos adicionales para fortalecer la seguridad de una

zona de seguridad, inclusive controles al personal o terceros que trabajen en dicha zona
como también a la actividad de terceros. Se debería considerar la posibilidad de utilizar los
controles que se detallan a continuación:

a) El personal debe tener conocimiento de la existencia de un área de seguridad o las

actividades que se lleven a cabo en la misma en la medida, sólo en la medida que
este conocimiento sea necesario para desarrollar su tarea;

b) El trabajo sin supervisión en una zona de seguridad debería ser evitado a fin de
impedir la realización de actividades dolosas y por razones de seguridad;

c) Las zonas de seguridad vacantes deberían encontrarse cerradas físicamente y se las

debería controlar periódicamente;

d) El personal de servicios de apoyo prestados por terceros debería contar con acceso
restringido a las zonas de seguridad o sistemas de procesamiento informático
confidencial. Este acceso debería contar con previa autorización y ser verificado.
Podrá resultar necesario contar con barreras y perímetros adicionales de control del
acceso físico entre zonas que cuenten con exigencias de seguridad diferentes dentro
del perímetro de seguridad;

e) No se debería permitir el ingreso sin autorización de equipos de fotografía, video,

audio u otros medios de grabación.

7.1.5 Aislamiento de las zonas de entrega y carga

Las zonas de entrega y carga deberían estar controladas y, de ser posible, aisladas de los
sistemas de procesamiento informático a fin de evitar accesos sin autorización. Los
requisitos de seguridad para dichas zonas deberían ser determinados a través de una
evaluación de riesgo. Deberían considerarse los controles siguientes:

a) El acceso a una zona de descarga desde fuera del edificio debería estar
restringido a personal identificado y autorizado;

b) La zona de descarga debería estar diseñada de tal forma que los suministros sean
descargados sin que el personal de entrega obtenga acceso a otras partes del
edificio;

c) La puerta o puertas externa/s de una zona de descarga debería/n encontrarse

asegurada/s cuando se abra la puerta interna;

d) El material que ingrese debería inspeccionarse a fin de detectar peligros posibles

[(véase 7.2.1d)] antes de retirarlos de la zona de descarga con destino al lugar de
uso;

29
 e) El material que ingrese debería registrarse, cuando fuere pertinente (véase 5.1),
al entrar al sitio.

7.2 Seguridad del equipo

Objetivo: Impedir pérdidas, daños o compromiso de activos e interrupciones en las

actividades de la empresa.

El equipo debería estar protegido físicamente de amenazas a la seguridad y peligros

provenientes del medido ambiente. La protección del equipo (inclusive del empleado fuera
del sitio) es necesaria para reducir el riesgo de acceso sin autorización a los datos y para
protegerlos contra pérdida o daño. Debería también considerarse la ubicación y disposición
de los equipos. Puede ser necesario contar con controles especiales de protección frente a
peligros o acceso sin autorización y para la salvaguardia de los sistemas de apoyo, como
por ejemplo el suministro de energía eléctrica y la infraestructura de cables.

7.2.1 Ubicación y Protección del Equipo

El equipo debería ubicarse o protegerse de forma tal de reducir los riesgos provenientes de
amenazas y peligros originados en el medio ambiente y del acceso efectuado sin
autorización. Se deberían tener presente los controles que se detallan a continuación:

a) El equipo debería estar ubicado en las zonas de trabajo correspondientes a fin de

minimizar el acceso innecesario;

b) Los sistemas de procesamiento y almacenamiento informático que manejan

datos confidenciales deberían ubicarse en lugares donde el riesgo de ser
advertidos durante su uso sea menor;

c) Los rubros que requieran protección especial deberían aislarse a fin de reducir el
nivel general de protección requerido;

d) Deberían adoptarse controles a fin de minimizar el riesgo de amenazas

potenciales que incluyan:

1) Robo;
2) Fuego;
3) Explosivos;
4) Humo;
5) Agua (o falla en su suministro);
6) Polvo;
7) Vibración;
8) Efectos químicos;

30
 9) Interferencia en el suministro de energía eléctrica;
10) Radiación electromagnética.

e) La organización debería considerar su política con respecto a la comida, bebida

y el acto de fumar en las proximidades de los sistemas de procesamiento
informático;

f) Las condiciones ambientales deberían controlarse para detectar situaciones que

puedan afectar el funcionamiento de los sistemas de procesamiento informático;

g) Debería considerarse el uso de medios de protección especial del tipo de las

membranas para teclados para el equipo situado en condiciones de uso
industrial;

h) Debería considerarse la posibilidad de que se produzca un desastre en

instalaciones vecinas, por ejemplo un incendio en un edificio vecino,
emanaciones de agua del techo o piso por debajo del nivel del suelo o una
explosión en la vía pública.

7.2.2 Suministro de energía

Debería protegerse al equipo frente a fallas en el suministro de energía u otras anomalías

eléctricas. Se debería proporcionar un suministro eléctrico adecuado que guarde relación
con las especificaciones técnicas de los equipos.

Se incluyen las siguientes opciones para lograr una continuidad en el suministro de energía:

a) Alimentación múltiple destinada a evitar que se produzca una falla en algun

punto de la red de suministro de energía;

b) Suministro de energía que no puede ser interrumpido (“UPS”);

c) Generador de apoyo.

Un suministro de energía UPS destinado a respaldar en forma ordenada el cierre o

funcionamiento continuo es recomendable para aquellos equipos que brinde apoyo a las
operaciones confidenciales de la empresa. Los planes de contingencia deberían abarcar las
medidas a tomar en caso de falla en el suministro de energía UPS. El equipo UPS debería
ser controlado en forma periódica a fin de garantizar que cuente con la capacidad adecuada
y ser verificado conforme a las recomendaciones del fabricante.

Se debería considerar la posibilidad de contar con un generador de apoyo en caso de que el

procesamiento deba continuar en casos de falla energética prolongado. En caso de que
sean instalados, los generadores deberían ser probados en forma periódica conforme a las
instrucciones que al efecto proporcione en fabricante. Se debería contar con un suministro
de combustible adecuado para garantizar que el generador permita el desarrollo de
actividades durante un período prolongado.

31
Además, los interruptores de energía de emergencia deberían estar situados cerca de las
salidas de emergencia en las salas de los equipos a los efectos de facilitar la rápida caída de
energía en caso de emergencia. Debería proporcionarse iluminación de emergencia en caso
de falla en el suministro de energía principal. Se debería contar con protección contra rayos
en todos los edificios y se debería contar asimismo con filtros para protección contra la
acción de los rayos en todas las líneas de comunicación externas.

7.2.3 Seguridad del cableado

El tendido de cables de energía y telecomunicaciones que lleven datos o servicios

informáticos auxiliares debería contar con protección frente a intercepción o daño. Se
debería considerar la instrumentación de los controles que se indican a continuación:

a) Las líneas de energía y telecomunicaciones conectadas a sistemas de

procesamiento informático deberían ser subterráneas, donde sea posible, o
encontrarse sometidas a protección alternativa adecuada;

b) El cableado de la red debería contar con protección frente a intercepción no

autorizada o daño, por ejemplo a través del uso de conductos o evitando rutas
que crucen zonas públicas;

c) Los cables de energía deberían encontrarse separados de los cables de

comunicaciones a fin de impedir interferencia;

d) Otros controles para sistemas de gran importancia o confidenciales incluyen:

1) La instalación de conductos blindados o salas o cámaras cerradas en

puntos terminales y de inspección;
2) El uso de rutas o medios de transmisión alternativas;
3) El empleo de cableado de fibra óptica;
4) La iniciación de barridos destinados a detectar elementos anexados sin
autorización a los cables.

7.2.4 Mantenimiento del equipo

El equipo debería mantenerse en forma correcta a fin de garantizar que esté completo y
disponible en todo momento. Se debería considerar aplicar los controles que se enumeran a
continuación:

a) Se debería mantener el equipo conforme a las recomendaciones del proveedor

en cuanto a intervalos de servicio y especificaciones técnicas;
b) Las reparaciones y el servicio del equipo deberían ser llevados a cabo por el
personal de mantenimiento debidamente autorizado;
c) Se deberían mantener registros de todas las fallas reales o supuestas y de todo el
mantenimiento preventivo y correctivo;

32
 d) Se deberían instrumentar controles adecuados cuando se retire el equipo de las
instalaciones a efectos de su mantenimiento (véase también 7.2.6 con respecto a
datos eliminados, borrados y sobre escritos). Se debería dar cumplimiento a
todos los requerimientos impuestos en las pólizas de seguro.

7.2.5 La seguridad del equipo fuera de las instalaciones de la empresa

Independientemente de la titularidad del equipo, su uso fuera de las instalaciones de la

organización a los efectos de tareas de procesamiento informático debería contar con
autorización de la administración. La seguridad que se brinde a dichos equipos debería ser
equivalente a la que cuenta en equipo in situ a los mismos fines, teniendo en consideración
los riesgos de trabajar fuera de las instalaciones de la organización. El equipo de
procesamiento informático incluye todo tipo de computadoras personales, ordenadores,
teléfonos móviles, papel u otros formularios que se utilicen para tarea en el hogar o que se
trasladen desde la ubicación normal de trabajo. Se deberían tomar en cuenta los
lineamientos siguientes:

a) Los equipos y medios de comunicación que se retiren de las instalaciones no

deberían quedar sin vigilancia en lugares públicos. Las computadoras portátiles
deberían ser trasladados como equipaje de mano y en la medida de lo posible
ocultadas durante el viaje;

b) Se debería dar cumplimiento en todo momento a las instrucciones que proporcionen

los fabricantes con respecto a la protección del equipo, por ejemplo contra el riesgo
de exposición a campos electromagnéticos potentes;

c) Deberían establecerse los controles del trabajo realizado en el hogar a través de una
evaluación de riesgo y aplicarse controles que se consideren convenientes, por
ejemplo, uso de gabinetes de archivo con cerradura, política de escritorios limpios y
controles al acceso en el caso de computadoras;

d) Debería contarse con una adecuada protección en materia de seguros para el equipo
que se retire de la empresa.

Los riesgos de seguridad, por ejemplo en cuanto a daño, robo y escucha ilegal pueden
variar considerablemente entre ubicaciones y se deberían tener presentes para determinar
los controles más adecuados. En 9.8.1 se puede encontrar mayor información con respecto
a otros aspectos de la protección de equipos móviles.

7.2.6 Disposición o nuevo uso seguro de los equipos

Se puede poner en riesgo la información por la disposición o nueva utilización descuidada

del equipo (véase también 8,.6.4). Los elementos de almacenamiento que contienen
información confidencial deberían ser destruidos físicamente o sobrescritos como forma de
seguridad en lugar de ser eliminados mediante el uso de la función “eliminar estándar”.

33
Todos los elementos del equipo que contengan medios de almacenamiento, por ejemplo
soportes físicos fijos, deberían ser controlados para garantizar que cualquier dato
confidencial y programa bajo licencia haya sido removido o sobrescrito antes de deshacerse
del mismo. Los elementos de almacenamiento dañados que contengan datos confidenciales
pueden demandar una evaluación de riesgo para determinar si dichos artículos deberían ser
destruidos, reparados o descartados.

7.3 Controles Generales

Objetivo: Impedir que se comprometa o robe la información y los sistemas de

procesamiento informático.

La información y los sistemas de procesamiento informático deberían estar protegidos

frente a la divulgación, modificación o robo de los mismos por personas carentes de la
debida autorización y se deberían contar con controles en funcionamiento destinados a
minimizar la pérdida o daño.

Los procedimientos de manejo y almacenamiento se tratan en 8.6.3

7.3.1 Política transparente sobre información impresa y en pantalla

La organización debería considerar adoptar una política de escritorio limpio para los
documentos y medios de almacenamiento removibles y una política de pantalla limpia para
los sistemas de procesamiento informático a fin de reducir los riesgos de acceso carente de
autorización, pérdida y daño de la información durante las horas de trabajo normales y
fuera de ellas. Dichas políticas deberían tomar en consideración las clasificaciones de
seguridad informática (véase 5.2) los riesgos correspondientes y los aspectos culturales de
la organización.

La información que se deja en los escritorios resultará posiblemente dañada o destruida en

desastres como puede ser una inundación o explosión.

Se deberían tener en cuenta los controles siguientes:

a) En los casos pertinentes, los documentos y medios de computación deberían ser

almacenados en gabinetes con cerradura y / o otras formas de mobiliario de
seguridad cuando no se los utilice y especialmente fuera del horario laboral;

b) La información empresaria crítica o confidencial debería ser puesta bajo llave

(en forma ideal en una caja de seguridad o gabinete a prueba de incendios)
cuando no se la requiera, especialmente cuando la oficina quede sin ocupantes;

34
 c) Las computadoras personales y terminales e impresoras de computadoras no
deberían quedar encendidas cuando no haya quien las atienda y cuando no se las
utilice, deberían contar con protección mediante el empleo de cierres con clave,
contraseñas y otros controles;

d) Los puntos de ingreso y salida de correo y las máquinas de teles y fax que no
cuenten con personal a cargo deberían contar con protección;

e) Fuera del horario normal de trabajo, las fotocopiadores deberían estar cerradas
con llave (o protegidas de alguna otra forma frente al uso no autorizado);

f) La información reservada o confidencial, debería ser retirada de las impresoras

en forma inmediata luego de impresa.

7.3.2 Remoción de bienes

Los equipos, información o programas no deberían ser retirados de las instalaciones sin
previa autorización. En los casos en que resulte necesario y pertinente, el equipo debería ser
apagado y vuelto a encender a su regreso. Se deberían emprender verificaciones in situ para
detectar la remoción no autorizada de bienes. Se debería concienciar a las personas para
que realizan las verificaciones en situ.

8. ADMINISTRACIÓN DE LAS OPERACIONES Y COMUNICACIONES

8.1 Procedimientos y Responsabilidades Operativos

Objetivo: Garantizar el funcionamiento correcto y seguro de los sistemas de procesamiento

informático.

Se deberían establecer cuáles son las responsabilidades y procedimientos de administración

y funcionamiento de todos los sistemas de procesamiento informático. Esta determinación
incluye el desarrollo de las instrucciones operativas respectivas y de los procedimientos de
respuesta ante incidentes.

En los casos adecuados, se debería instrumentar la separación de deberes (véase 8.1.4) a los
efectos de reducir el riesgo debido a mal uso negligente o deliberado del sistema.

8.1.1 Procedimientos Operativos Documentados

Los procedimientos operativos identificados por la política de seguridad deberían

documentarse y mantenerse documentados. Los procedimientos operativos deberían ser
tratados como documentos formales y los cambios deberían ser autorizados por la
administración.

35
Los procedimientos deberían especificar las instrucciones destinadas al logro de la
ejecución detalladas de cada tarea incluyendo:

a) Procesamiento y manejo de la información;

b) Requisitos de programación, inclusive interdependencias con otros sistemas, y
tiempos para el inicio del primer trabajo y terminación del último;
c) Instrucciones para enfrentar errores y otras situaciones excepcionales que
puedan surgir durante la ejecución de la tareas con inclusión de las restricciones
al uso de los útiles del sistema (véase 9.5.5);
d) Contactos de apoyo en caso de dificultades técnicas u operativas inesperadas;
e) Instrucciones especiales para manejo de productos como ser uso de papelería
especial o administración de productos confidenciales, inclusive procedimientos
para garantizar la disposición del producto en caso de tareas fallidas;
f) Procedimientos para la recuperación y reinicio del sistema en caso de falla del
sistema.

También se debería disponer de procedimientos documentados para las actividades de

mantenimiento del sistema conexas con los sistemas de comunicaciones y procesamiento
informático como son los procedimientos de encendido y cierre de la computadora,
resguardos, mantenimiento del equipo, sala de computación y administración y seguridad
en el manejo del correo electrónico.

8.1.2 Control de Cambio Operativo

Se deberían controlar los cambios que se produzcan en el procesamiento informático El

control inadecuado de los cambios en el procesamiento informático y sus sistemas es una
de las causas más comunes de falla de seguridad sistémica. Las responsabilidades y
procedimientos formales de administración deberían encontrarse vigentes a los efectos de
garantizar el control satisfactorio de todos los cambios que se produzcan en el equipo, los
programas o procedimientos. Los programas operativos deberían encontrarse sujetos a un
estricto control en cuanto a los cambios que se produzcan en los mismo. Cuando se
produzcan modificaciones en los programas, se debería retener un registro de auditoria
que contenga toda la información pertinente. Los cambios en el contexto operativo pueden
tener influencia sobre las aplicaciones. Cuando sea posible, se deberían integrar los
procedimientos de control de modificaciones en las aplicaciones y los de control operativos
(véase también 10.5.1). En especial, se deberían tener en cuenta los controles siguientes:

a) Identificación y registro de los cambios significativos;

b) Evaluación de la posible influencia de dichos cambios;

c) Procedimiento de aprobación formal de los cambios propuestos;

d) Comunicación de los detalles de las modificaciones a todos los interesados;

e) Procedimientos de identificación de responsabilidades por el aborto y

recuperación de cambios fallidos.

36
8.1.3 Procedimientos de administración de incidentes

Se deberían crear procedimientos y determinar responsabilidades respecto de la

administración de incidentes a fin de garantizar una respuesta ordenada, eficaz y rápida ante
incidentes que involucren la seguridad (véase asimismo 6.3.1). Se deberían tener presente
los controles que se enumeran a continuación:

a) Se deberían establecer procedimientos destinados a abarcar todos los tipos posibles

de incidentes de seguridad con inclusión de:

1) Fallas en el sistema informático y pérdida de servicio;

2) Denegatoria de servicio;
3) Errores resultantes de datos comerciales incompletos o inexactos;
4) Fallas en cuanto al mantenimiento de la confidencialidad.

b) Además de los planes de contingencia normales (destinados a recuperar los sistemas

o servicios tan rápidamente como fuere posible), los procedimientos deberían
también cubrir (véase asimismo 6.3.4):

1) El análisis e identificación de la causa del incidente;

2) La planificación e instrumentación si fuere necesario, de recursos
destinados a impedir su repetición;
3) Recopilación de rutas de auditoria y pruebas similares;
4) Comunicación con los afectados o involucrados en las tareas de
recuperación debidas al incidente;
5) Comunicación de lo actuado a la autoridad pertinente.

c) Las rutas de auditoria y pruebas similares deberían ser recopiladas ( véase 12.1.7) y
aseguradas, como corresponda a los efectos de:

1) Un análisis interno del problema

2) Su uso como prueba con relación a un incumplimiento potencial del
contrato, incumplimiento de requisitos reglamentarios y en caso de
proceso civil y penal, por ejemplo, por mal uso de la computadora o
asuntos relativo a la legislación de protección de datos;
3) La negociación de compensación con los proveedores de programas y
servicios.

d) Se debería controlar formal y cuidadosamente las acciones que se emprendan para

lograr una recuperación debido a fallas de seguridad y en el funcionamiento
correcto de los sistemas. Dichos procedimientos deberían garantizar que:

1) Se permita acceso a los sistemas y datos en vivo solamente a personal

autorizado y claramente identificado (véase asimismo 4.2.2 con respecto
al acceso de terceros);

37
 2) Se documentará en detalla todas las medidas de emergencia que se
tomen;
3) Las medidas de emergencia serán comunicadas a la administración y
revisadas en forma ordenada;
4) Se confirmará con la mínima demora la integridad de los sistemas y
controles de la empresa.

8.1.4 Separación de deberes

La separación de deberes es un método de reducción del riesgo de mal uso accidental o

deliberado de un sistema. Se debería considerar la oportunidad de separar la administración
o ejecución de ciertos deberes o zonas de responsabilidad a fin de reducir las oportunidades
de modificación no autorizada o uso indebido de la información o los servicios.

Las organizaciones pequeñas pueden encontrar que este método de control es difícil de
lograr pero, en principio, se lo debería aplicar en la medida de lo posible. En todos aquellos
casos en que sea difícil producir la separación, otros controles como la verificación de
actividades, seguimiento de auditoria y supervisión de la administración deberían
considerarse. Es importante que la auditoria de seguridad retenga su independencia.

Se debería tener el debido cuidado para que no haya persona que pueda perpetrar un fraude
en zonas de responsabilidad única sin ser detectada. La iniciación de un hecho debería
encontrarse separada de su autorización. Se debería considerar la aplicación de los
controles siguientes:

a) Es importante separar las actividades que permitan la celebración de acuerdos

ilegales destinados a cometer una defraudación, por ejemplo, la presentación de
una orden de compra y la verificación de la recepción de la mercadería;
b) Si existe peligro de acuerdo ilegal, entonces se necesitará idear controles para
que se involucren dos o más personas, disminuyendo así la posibilidad de que
exista una conspiración.

8.1.5 Separación de los sistemas operativos y de desarrollo

La separación del desarrollo, la prueba y el funcionamiento es importante a fin de lograr

una separación de los papeles involucrados. Las normas de transferencia de programas de
un estado de desarrollo a uno operativo deberían ser definidas y documentadas.

Las actividades de desarrollo y prueba pueden provocar problemas graves, por ejemplo,
modificaciones no queridas de los archivos o del sistema o falla del sistema. Se debería
considerar el nivel de separación necesario entre los contextos operativos, de prueba y
desarrollo, a fin de impedir que surjan problemas operativos. Se debería instrumentar
asimismo una separación similar entre las funciones de desarrollo y prueba. En este caso,
hay necesidad de mantener un marco conocido y estable en el cual desarrollar pruebas
significativas e impedir el acceso inadecuado por parte del encargado del desarrollo.

38
Si el personal de desarrollo y el de prueba tienen acceso al sistema operativo y a su
información, pueden llegar a introducir códigos no probados y sin autorización o alterar
datos operativos. En algunos sistemas, esta capacidad podría ser utilizada indebidamente
para cometer fraude o introducir códigos dolosos o indeseados. Un código doloso o
indeseado puede provocar graves problemas operativos. Los encargados del desarrollo y de
las pruebas también constituyen una amenaza a la confidencialidad de la información
operativa.

Las actividades de desarrollo y prueba pueden provocar cambios no intencionales en los

programas y la información si comparten el mismo contexto computacional. La separación
del desarrollo, la prueba y el aspecto operativo es por ende deseable a fin de reducir el
riesgo de cambio accidental o acceso no autorizado a programas operativos y datos
empresariales. Se deberían tener en cuenta los controles que se enumeran a continuación:

a) Los programas para desarrollo y operaciones deberían, en lo posible, funcionar

en diferentes procesadores de la computadora o en diferentes dominios o
directorios;
b) Las actividades de desarrollo y prueba deberían encontrarse en la medida de lo
posible, separadas;
c) No se debería poder acceder a los compiladores, editores y otros útiles del
sistema desde los sistemas operativos salvo que así se deba proceder;
d) Se deberían utilizar diferentes procedimientos de establecimiento de
comunicación para los sistemas operativos y de prueba a fin de reducir la
posibilidad de error. Se debería alentar a los usuarios a los efectos de que usen
contraseñas diferentes para estos sistemas y los menús deberían mostrar los
mensajes de identificación pertinentes.
e) El personal encargado de las tareas de desarrollo solamente tendrá acceso a las
contraseñas operativas cuando haya controles para la emisión de las contraseñas
en los sistemas operativos. Los controles deberían garantizar que tales
contraseñas sean modificadas después de ser usadas.

8.1.6 Administración externa

El uso de un contratista externo para administrar el procesamiento informático puede

introducir riesgos de seguridad como ser compromisos, daños o pérdida de datos en el lugar
de trabajo del contratista. Estos riesgos deberían ser señalados por anticipado acordando
con el contratista la instrumentación de controles adecuados e incorporándolos al contrato
(véase también 4.2.2 y 4.3 con respecto a los lineamientos de contratos de terceros que
involucran acceso a la organización y contratos de prestación de servicios por parte de
servicios).

Se deberían encarar temas especiales como ser:

a) La identificación de aplicaciones críticas o confidenciales que es mejor realizar

dentro de la empresa;

b) Obtención de aprobación de parte de los titulares de la aplicación comercial;

39
 c) Consecuencias para los planes de continuidad comercial;

d) Normas de seguridad a especificar y proceso de medición de su cumplimiento;

e) Asignación de responsabilidades y procedimientos específicos para controlar

eficazmente todos las actividades de seguridad pertinentes;

f) Responsabilidades y procedimientos de comunicación y manejo de los

incidentes de seguridad (véase 8.1.3).

8.2. Planificación y Aceptación de Sistemas

Objetivo: Minimizar el riesgo de fallas en los sistemas.

Se requiere contar con planificación y preparación por anticipado a fin de garantizar contar
con capacidad y recursos adecuados.
Se deberían efectuar proyecciones sobre los requerimientos futuros en cuanto a capacidad
a los efectos de reducir el riesgo de sobrecarga del sistema.
Se deberían determinar las exigencias operativas para los sistemas nuevos,
documentándolas y verificándolas previo a su aceptación y uso.

8.2.1. Planificación de la Capacidad

Las exigencias en cuanto a capacidad deberían ser controladas y se deberían realizar

proyecciones de necesidades futuras de capacidad a fin de garantizar de que se disponga de
energía suficiente para efectuar tareas de procesamiento y almacenamiento. Estas
proyecciones deberían tomar en cuenta las nuevas exigencias en materia de negocios y
sistemas y las tendencias actuales y proyectadas en cuanto a procesamiento informático en
la organización.

Los servidores exigen especial atención debido al costo mucho mayor y al tiempo que lleva
obtener capacidad nueva. Los administradores de servicios de servidores deberían controlar
la utilización de los principales recursos del sistema con inclusión de procesadores,
almacenamiento principal, almacenamiento de archivos, impresoras y otros elementos de
producto y sistemas de comunicaciones. Deberían señalar las tendencias en cuanto a uso, en
especial con relación a aplicaciones comerciales o herramientas informáticas para la
administración.

Los administradores deberían usar esta información para identificar y evitar potenciales
cuellos de botella que pudieran constituir una amenaza para la seguridad del sistema o los
servicios para usuarios y planificar los cursos de acción pertinentes para resolver la
situación.

40
8.2.2 Aceptación del sistema

Deberían establecerse criterios de aceptación para nuevos sistemas informáticos,

actualizaciones y versiones nuevas así como pruebas convenientes a aplicar al sistema antes
de su aceptación. Los administradores deberían garantizar que las exigencias y criterios de
aceptación de sistemas nuevas se encuentren definidas, acordadas, documentadas y
probadas con claridad. Se debería considerar la instrumentación de los controles que se
enumeran a continuación.

a) Requisitos en materia de funcionamiento y capacidad de la computadora

b) Procedimientos para la solución de errores y reiniciación de tareas y planes de
contingencia;
c) Preparación y prueba de procedimientos operativos de rutina según normas
definidas;
d) Acuerdo en cuanto a la vigencia de un conjunto de controles en materia de
seguridad;
e) Procedimientos manuales eficaces;
f) Acuerdo para la continuidad de los negocios tal como se establece en 11.1;
g) Prueba de que la instalación del nuevo sistema no afectará los sistemas
existentes, especialmente en horas pico de procesamiento tales como fin de mes;
h) Prueba de que se ha prestado atención al efecto que el nuevo sistema tiene sobre
la seguridad global de la organización;
i) Capacitación para hacer funcionar o utilizar los nuevos sistemas.

A los fines de procurar novedades de importancia, se debería consultar la función

operaciones y a los usuarios durante todas las etapas del proceso de desarrollo a los efectos
de garantizar la eficiencia operativa del diseño de sistema que se proyecte. Se deberían
llevar a cabo pruebas adecuadas para confirmar que se hayan satisfecho plenamente todos
los criterios de aceptación.

8.2 Protección contra programas ilícitos

Objetivo: Proteger la integridad de los programas y la información

Es necesario adoptar precauciones para impedir y detectar la introducción de programas

ilícitos. Los programas y el procesamiento informático son vulnerables a la introducción de
programas ilícitos como ser virus de computación, gusanos en red, “Caballos de Troya”
(véase asimismo 10.5.4) y bombas lógicas. Los usuarios deberían tener presente los
peligros que conllevan los programas ilícitos o carentes de autorización y los
administradores deberían, cuando sea pertinente, introducir controles especiales para
detectar su introducción o impedirla. En especial, resulta esencial que se tomen
precauciones para detectar la presencia de virus de computación en las computadoras
personales e impedir su acción.

41
8.3.1 Controles contra programas ilícitos

Se deberían implementar controles para detectar e inhibir la acción de programas ilícitos así
como procedimientos destinados a crear una adecuada conciencia al respecto en los
usuarios. La protección frente a la acción de programas ilícitos debería basarse en la
conciencia respecto de la importancia de la seguridad, acceso adecuado al sistema y
controles para la administración de modificaciones. Se debería considerar la utilización de
los controles que se enumeran a continuación:

a) Una política formal que exija el cumplimiento de las licencias de programas y

prohíba el uso de programas no autorizados (véase 12.1.2.2);

b) Una política formal de protección frente a riesgos conexos con la obtención de

archivos y programas de redes externas o por su intermedio o por cualquier otro
medio, señalando las medidas de protección que deban adoptarse (véase
asimismo 10.5, especialmente 10.5.4 y 10.5.5);

c) Instalación y actualización a intervalos periódicos de métodos para la detección

de virus y de programas de reparaciones para explorar computadoras y medios
como medida de control precautorio o en forma rutinaria;

d) Realización de exámenes periódicos de los programas y del contenido en datos

de los sistemas que constituyen el soporte de procesos fundamentales para la
empresa. La presencia de cualquier archivo no aprobado o de enmiendas no
autorizadas debería ser formalmente investigada;

e) Verificación en los medios electrónicos de cualquier archivo de procedencia

incierta o no autorizada o de archivos recibidos por intermedio de redes no
confiables a los efectos de detectar virus antes de usarlos;
f) Verificación de cualquier anexo de correo electrónico y de las descargas de los
mismos a los fines de detectar la presencia de programas ilícitos antes de su uso.
Esta verificación puede ser llevada a cabo en lugares diferentes, por ejemplo, en
los servidores de correo electrónico, computadoras de mesa o al ingresar en la
red de la organización;

g) Procedimientos y responsabilidades administrativas para enfrentar el tema de la

protección antivirus en los sistemas con capacitación para su uso, comunicación
y recuperación frente a ataques de virus (véase 6.3 y 8.1.3);

h) Planes adecuados de continuidad de la actividad comercial para hacer frente a

ataques de virus, inclusive a través de la recuperación de todos los datos
necesarios y la creación de resguardos en los programas y medidas destinadas a
la recuperación de datos (véase cláusula 11);

42
 i) Procedimientos para verificar toda la información relacionada con programas
ilícitos y garantizar que los boletines de advertencia sean exactos e informativos.
Los administradores deberían garantizar que fuentes confiables, por ejemplo,
diarios de buena reputación, sitios de Internet confiables o proveedores de
programas antivirus sean empleados para diferencia entre engaños y virus reales.
El personal debería tener presente el problema constituido por los engaños y qué
hacer al recibir uno.

Estos controles son especialmente importantes respecto de servidores de archivos en red

que constituyen el soporte de un gran número de estaciones de trabajo.

8.4 Tareas Internas

Objetivo: Mantener la integridad y disponibilidad del procesamiento informático y los

servicios de comunicación.

Se deberían crear procedimientos de rutina para lleva a cabo la estrategia acordada en

materia de resguardo de archivos (véase 112.1), toma de copias de resguardo de datos y
ensayo de su oportuna restauración, sucesos que involucren el establecimiento de
comunicación y fallas en el mismo y, cuando sea pertinente, el control del contexto que
rodea al equipo.

8.4.1 Resguardo de la Información

Periódicamente, se deberían realizar copias de resguardo de archivos que contenga

programas e información esencial para el desarrollo de los negocios. Se deberían realizar
resguardos de archivo adecuados a fin de garantizar que toda la información esencial de los
negocios y sus programas puedan ser recuperados luego de un desastre o falla en los
medios. Las medidas destinadas a realizar los resguardas de cada sistema deberían ser
probadas periódicamente para garantizar que cumplan con los requisitos contenidos en los
planes de continuidad de la empresa (véase cláusula 11). Se debería considerar aplicar los
controles que se enumeran a continuación:

a) Un nivel mínimo de información en copia de resguardo junto con registros

completos y exactos de las copias de resguardos y de los procedimientos de
restablecimiento documentados deberían ser almacenados en un sitio remoto a
distancia suficiente como para escapar de cualquier daño debido a desastre en el
sitio principal. Como mínimo, se deberían retener tres generaciones o ciclos de
información resguardada correspondiente a aplicaciones comerciales
importantes.;

43
 b) La información resguardada deberían tener un nivel adecuado de protección
ambiental y física (véase cláusula 7) congruente con las normas aplicadas en el
sitio principal. Los controles aplicados a los medios en el sitio principal deberían
extenderse para que cubran el sitio de resguardo.

c) Los medios de resguardo deberían ser probados periódicamente, cuando pueda

hacerse, para garantizar que resultan confiables en caso de uso de emergencia;

d) Los procedimientos de restablecimiento deberían ser verificado en forma

periódicamente y sometidos a prueba para garantizar que resulten efectivos y
que se puedan ejecutar en forma completa dentro del tiempo asignado al efecto
en los procedimientos operativos para recuperación de archivos.

Se debería determinar el período de retención en lo que respecta a información comercial

esencial y también cualquier requisito en materia de copias de archivo que deban ser
retenidas en forma permanente (véase 12.1.3).

8.4.2 Conexión de operadores

El personal operativo debería mantener un registro de sus actividades. Los registros

deberían incluir, según corresponda:

a) Iniciación del sistema y tiempos de finalización;

b) Errores de sistema y medidas correctivas adoptadas;
c) Confirmación del correcto manejo de archivos de datos y producto de la
computadora;
d) Nombre de la persona que efectúa el asiento en el registro.

Los libros de registro de operadores deberían esta sometidos a verificaciones periódicas e

independientes en el marco de los procedimientos operativos vigentes.

8.4.3 Conexiones defectuosas

Se deberían comunicar las fallas y tomar medidas para corregirlas. Las fallas comunicadas
por los usuarios con respecto a problemas en el proceso informático o en los sistemas de
comunicaciones deberían ser asentadas en registros. Deberían existir normas claras para el
manejo de las fallas que se comuniquen con inclusión de:

a) Examen de los registros de fallas para garantizar que las fallas hayan sido
resueltas en forma satisfactoria;
b) Examen de las medidas correctivas para garantizar que no se hayan
comprometido los controles y que las medidas tomadas cuenten con
autorización plena.

44
8.5 Administración de la Red

Objetivo: Garantizar la salvaguardia de la información en las redes y la protección de la

infraestructura de apoyo.

La administración de la seguridad de las redes que puede alcanzar los límites de la

organización exige atención.
También pueden resultar necesarios controles adicionales para proteger el traspaso de
datos confidenciales a las redes públicas.

8.5.1 Controles de la Red

Es necesario contar con una gama de controles a fin de lograr seguridad en las redes de
computadoras y mantenerlas. Los administradores de redes deberían aplicar controles para
garantizar la seguridad de los datos en las redes y proteger los servicios conectados frente a
accesos no autorizados. En especial, se deberían considerar los controles que se enumeran
a continuación:

a) Se debería separar la responsabilidad operativas de las redes del manejo

operativo de las computadoras cuando sea pertinente (véase 8.1.4);

b) Se deberían establecer cuáles son las responsabilidades y procedimientos

respecto de la administración de los equipos ubicados en lugares remotos
inclusive aquellos equipos situados en zonas frecuentadas por usuarios;

c) En caso necesario, se deberían establecer controles especiales para salvaguardar

la confidencialidad e integridad del traspaso de datos a las redes públicos y
proteger los sistemas conectados ( véase 9.4 y 10.3). También puede ser
necesario crear controles esp3eciales para mantener la disponibilidad de los
servicios de red y de las computadoras que se encuentren conectadas;

d) Las actividades de administración deberían estar estrechamente coordinadas

tanto a fin de optimizar el servicio a la empresa como garantizar que los
controles sean aplicados en forma congruente dentro de la infraestructura de
procesamiento informático.

8.6 Manejo y Seguridad de los Medios

Objetivo: Impedir daños a los activos e interrupciones en las actividades de la empresa. Los
medios de comunicación deberían estar contr0olados y protegidos en forma física.

Se deberían crear procedimientos ope4rativos adecuados para proteger documentos,

elementos de computadoras (cintas, discos, casetes) ingreso y egreso de datos y
documentación del sistema contra daño, robo y acceso no autorizado.

45
8.6.1 Administración de los medios informáticos removibles

Deberían existir procedimientos de administración de medios de computación removibles

como lo son las cintas, discos, casetes e informes impresos. Se debería considerar la
utilización de los controles que se enumeran a continuación:

a) En caso de que ya no sean necesarios, los contenidos previos de cualquier medio

que pueda volver a ser utilizados que deban ser eliminados de la organización
deberían ser borrados;

b) Se debería contar con autorización para la remoción de todos los medios de la

organización y se llevará un registro de todas las remociones que se efectúen a
fin de poder seguirlas mediante auditoria (véase 8.7.2);

c) Todos los medios deberían ser guardados en un ambiente seguro en caja de

seguridad de conformidad con las especificaciones de los fabricantes.

Todos procedimientos y autorizaciones deberían estar claramente documentados.

8.6.2 Disposición de los medios

La disposición de los medios cuando ya no se los necesite debería ser segura. La

información confidencial podría filtrarse a personas ajenas a ala empresa por la disposición
negligente de los medios. Se deberían crear procedimientos formales para la disposición
segura de medios. Se debería considerar la instrumentación de los controles que se
enumeran a continuación:

a) La disposición de los medios que contengan información confidencial se debería

efectuar en forma segura, por ejemplo a través de su incineración o
fragmentación o vaciándolos de datos a fin de que puedan ser usados
nuevamente:

b) La lista siguiente identifica los rubros que puedan requerir seguridad en su

disposición:

1) Documentos en soporte papel;

2) Registros de voz o de otro tipo;
3) Papel carbónico;
4) Informes de producto;
5) Cintas de impresión utilizables una sola vez;
6) Cintas magnéticas;
7) Discos o casetes removibles;
8) Medios de almacenamiento óptico (de todo tipo, inclusive todos los
medios de distribución de programas con que cuente el fabricante);
9) Listas de programas;
10) Datos de pruebas;
11) Documentación de sistemas.

46
 c) Puede resultar más sencillo tomar medidas conducentes a recolectar todos los
medios y disponer de los mismos en forma segura en lugar de intentar separar
aquellos medios que se consideren confidenciales;

d) Muchas organizaciones ofrecen servicios de recolección y disposición de

pápeles, equipo y medios. Se debe tener cuidado en seleccionar un contratista
conveniente y someterlo a controles adecuados;

e) La disposición de elementos confidenciales debería registrarse, cuando fuere

posible, a fin de poder efectuar un seguimiento por auditoria.

Al acumular medios para su disposición, se debería tener presente el efecto agregado que
puede hacer que una cantidad grande información no clasificada como confidencial
adquiera un cariz de mayor confidencialidad que una pequeña cantidad de información
clasificada.

8.6.3 Procedimientos de manejo de información

Los procedimientos de manejo y almacenamiento de información deberían ser creados a los

fines de proteger dicha información de divulgación no autorizada o uso indebido. Se
deberían redactar procedimientos de manejo de información compatible con su
clasificación (véase 5.2) en documentos, sistemas de computación, redes, computación
móvil, comunicaciones móviles, corre o electrónico, correo de voz, comunicaciones de voz
en general, multimedios, servicios postales, uso de fax y cualquier otro rubro confidencial,
por ejemplo: cheques en blanco, facturas. Se debería considerar la utilización de los
controles que se enumeran a continuación (véase asimismo 5.2 y 8.7.2):

a) Manejo y etiquetamiento de todos los medios [véase también 8.7.2]]

b) Restricciones al acceso a fin de identificar personal que carezca de autorización

de ingreso;

c) Mantenimiento de un registro formal de receptores de datos autorizados;

d) Garantía de que los datos ingresados sean completos, que su procesamiento se

complete adecuadamente y que se aplique validación a la salida de datos;

e) Protección de datos que esperan salida a un nivel compatible con su

confidencialidad;

f) Almacenamiento de medios en forma congruente con las especificaciones

suministradas por los fabricantes;

g) Mantenimiento de la distribución de los datos a un nivel mínimo;

47
 h) Clasificación de todas las copias de datos correspondientes a receptores
autorizados;

i) Examen de las listas de distribución y de receptores autorizados a intervalos

periódicos.

8.6.4 Seguridad de la documentación del sistema

La documentación del sistema puede contener una gama de información confidencial, por
ejemplo: descripciones de procesos de aplicación, procedimientos, estructuras de datos,
procesos de autorización (véase también 9.1). Se debería considerar la utilización de los
controles que se enumeran a continuación a los efectos de proteger la documentación de
sistemas de acceso no autorizado.

a) La documentación del sistema se debería almacenar en condiciones seguras;

b) La lista de acceso de la documentación del sistema debería ser reducida y contar

con la autorización del titular de la aplicación;

c) La documentación del sistema en poder de una red pública o provista por

intermedio de una red pública debería encontrarse debidamente protegida.

8.7 Intercambios de Información y Programas

Objetivo: Impedir la pérdida, modificación o uso indebido de información intercambiada

entre organizaciones.

Los intercambios de información y programas entre organizaciones deberían ser

controlados y dar cumplimiento a cualquier legislación pertinente (véase la cláusula 12).
Los intercambios deberían llevarse a cabo en base a acuerdos. Deberían crearse
procedimiento y normas de protección de información y medios en tránsito. Se deberían
considerar las consecuencias para los negocios y la seguridad conexas con el intercambio
electrónico de datos, comercio electrónico y correo electrónico y los requisitos para su
control.

8.7.1 Acuerdos de intercambio de información y programas

Los acuerdos, algunos de los cuales pueden ser formales, inclusive los acuerdos de
salvaguardia de programas cuando corresponda, deberían ser creados en el caso que haya
intercambio de información y programas (electrónico o manual) entre organizaciones. El
contenido de seguridad de dicho acuerdo debería reflejar la confidencialidad de la
información comercial involucrada. Los acuerdos sobre condiciones de seguridad deberían
considerar lo siguiente:

48
 a) Responsabilidades de la administración con respecto a la transmisión de control
y notificación, su despacho y recibo.

b) Procedimientos para notificar al remitente, transmisión, despacho y recibo;

c) Normas técnicas mínimas para la constitución y transmisión de paquetes;

d) Normas de identificación de “couriers”;

e) Responsabilidades, incluso legales, en caso de pérdida de datos;

f) Uso de un sistema de etiquetamiento consensuado para información crítica o

confidencial que garantice que el significado de las etiquetas sea comprendido
de inmediato y que la información se encuentre adecuadamente protegida;

g) Titularidad de la información y los programas y responsabilidades en cuanto a

protección de los datos, cumplimiento de las normas del derecho de autor de los
programas y temas similares (véase 12.1.2 y 12.1.4);

h) Normas técnicas para registrar y leer información y programas;

i) Cualquier control especial que pueda ser necesario a fin de proteger rubros
confidenciales como claves criptográficas (véase 10.3.5).

8.7.2 Seguridad de los Medios en Tránsito

La información puede ser vulnerable ante el acceso no autorizado, uso indebido o actos de
corrupción durante su transporte físico, por ejemplo, cuando se envían medios por
intermedio del servicio postal o correo privado. Los controles que se enuncian a
continuación deberían ser aplicados para salvaguardar los medios de computación que se
transporten entre distintos lugares.

a) Se deberían emplear transporte o correos privados confiables. Se debería acordar

con la administración una lista de correo privados autorizados y se instrumentará
un procedimiento de verificación de la identificación de los correos privados;

b) El empaquetamiento debería ser suficiente para proteger los contenidos del daño
físico que puedan sufrir durante el transporte en debida conformidad con las
especificaciones suministradas por los fabricantes;

c) Se deberían adoptar controles especiales, en caso necesario, a fin de proteger

información confidencial de divulgación o modificación efectuadas sin previa
autorización. Los ejemplos incluyen lo siguiente:

1) Uso de contenedores cerrados;

2) Entrega en mano;
3) Empaquetamiento de seguridad (que revele cualquier intento de obtener
acceso indebido);

49
 4) En casos excepcionales, división de la consignación en más de un
despacho y entrega que serán realizados por rutas diferentes;
5) Uso de firmas digitales y encriptación confidencial, véase 10.3

8.7.3 Seguridad del comercio electrónico

El comercio electrónico puede comprender el uso de intercambio electrónico de datos

(EDI), correo electrónico y operaciones en línea por redes públicas como Internet. El
comercio electrónico es vulnerable en la red a amenazas que pueden dar como resultado
actividades fraudulentas, litigios contractuales y divulgación o modificación de
información. Se deberían aplicar controles para proteger el comercio electrónico ante
dichas amenazas. Los temas de seguridad relacionados con el comercio electrónico
deberían incluir los controles que se enumeran a continuación:

a) Autenticación. ¿Cuál es el nivel de confianza existente en caso de que el cliente

y el operador se exijan verificación de identidad?;

b) Autorización. ¿Quién se halla autorizado a determinar precios, emitir o firmar

documentos comerciales fundamentales? ¿Cómo llegan a conocimiento del
socio comercial estas operaciones?;

c) Proceso de Licitación y Contratación. ¿Cuáles son los requisitos de

confidencialidad, integridad y prueba de despacho y recibo de documentos
fundamentales y de falta de rechazo de los contratos?

d) Información sobre Fijación de Precios. ¿Cuál es el nivel de confianza que se

pone en la integridad de la lista de precios publicada y en la confidencialidad de
los acuerdos de descuento confidenciales?

e) Operaciones de Pedidos. ¿En que consistente la confidencialidad e integridad de

la dirección de la orden de compra, pago y entrega y confirmación de recibo
que se otorga?

f) Inspección. ¿Cuál es el grado de inspección apropiado para verificar la

información de pago suministrada por el cliente?

g) Pago. ¿Cuál es la forma de pago más adecuada para impedir fraudes?

h) Ordenes. ¿Qué protección se necesita para mantener la confidencialidad e

integridad de la información de órdenes y evitar la pérdida o duplicación de
operaciones?

i) Responsabilidad Legal. ¿Quién asume el riesgo ante cualquier operación

fraudulenta?

50
Muchos de los puntos tratados precedentemente pueden ser encarados a través de la
utilización de técnicas criptográficas delineadas en 10.3, tomando en cuenta el
cumplimiento de los debidos requisitos legales (véase 12.1, especialmente 12.1.6 en lo que
respecta a la legislación sobre criptografía).

Los acuerdos sobre comercio electrónico entre socios comerciales deberían ser respaldados
por un acuerdo documentado que comprometa a ambas partes a cumplir los términos de
intercambio acordados, incluyendo detalles acerca de la autorización (véase b) precedente).
Pueden ser necesarios otros acuerdos relacionados con prestadores de redes de valor
agregado y servicios informáticos.

Los sistemas de comercialización pública deberían publicitar ante sus clientes sus términos
y condiciones de negociación.

Se debería prestar debida atención a la resistencia al ataque del huésped usado para el
comercio electrónico y las consecuencias en materia de seguridad de la interconexión de
cualquier red que sea necesaria para su instrumentación (véase 9.4.7).

8.7.4 Seguridad del Correo Electrónico

8.7.4.1 Riesgos para la Seguridad

El correo electrónico es usado para comunicaciones comerciales en reemplazo de formas

tradicionales de comunicación como el telex y las cartas. El correo electrónico difiere de las
formas tradicionales de comunicación comercial en, por ejemplo, su velocidad, estructura
del mensaje, grado de informalidad y vulnerabilidad ante acciones no autorizadas. Se
debería prestar atención a la necesidad de introducir controles que reduzcan los riesgos de
seguridad creados por el correo electrónico. Los riesgos de seguridad incluyen:

a) Vulnerabilidad de los mensajes frente a accesos no autorizados o modificación o

denegatoria del servicio;

b) Vulnerabilidad frente al error, por ejemplo en cuanto a dirección incorrecta o

equivocada y a la confiabilidad y disponibilidad del servicio en general;

c) Influencia del cambio en los medios de comunicación sobre los procesos

comerciales, por ejemplo, efecto del aumento de la velocidad de despacho o
efecto del envío de mensajes formales de persona a persona en lugar de entre
empresas;

d) Consideraciones legales como ser la necesidad potencial de demostrar origen,

despacho, entrega y aceptación;

e) Consecuencias de la divulgación pública de listas del personal;

f) Control del acceso de usuarios alejados a las cuentas de correo electrónico.

51
8.7.4.1.1 Política sobre Correos Electrónicos

Las organizaciones deberían instrumentar políticas claras con respecto al uso del correo
electrónico, inclusive respecto de:

a) Ataques al correo electrónico: por ejemplo, por virus, intercepción;

b) Protección de anexos al correo electrónico;
c) Lineamientos sobre cuando no usar el correo electrónico;
d) Responsabilidad del empleado en cuanto a no comprometer a la empresa, por
ejemplo, mediante envío de correos electrónicos difamatorios, acoso, compras
no autorizadas;

e) Uso de técnicas criptográficas para proteger la confidencialidad e integridad de

los mensajes electrónicos (véase 10.3);

f) Retención de mensajes que, almacenados, podrían ser utilizados en caso de

litigio;

g) Controles adicionales para la inspección del envío de mensajes que no puedan

ser autenticados.

8.7.5 Seguridad de los sistemas de oficinas electrónicas

Se deberían preparar políticas y lineamientos a instrumentar para controlar los riesgos

comerciales y de seguridad relacionados con sistemas de oficinas electrónicas. Estos
sistemas proporcionan la oportunidad de lograr una divulgación y utilización compartida
más rápida de la información comercial a través del uso de una combinación de
documentos, computadoras, computación móvil, comunicaciones móviles, correo
electrónico, correo de voz, comunicaciones de voz en general, multimedios, servicios
postales y fax.

Se debería prestar atención a las consecuencias en materia de transacciones y de su

seguridad que presenta la interconexión de sistemas, a saber:

a) Vulnerabilidad de la información en los sistemas de oficinas, por ejemplo,

registro de llamadas telefónicas o conferencias telefónicas, confidencialidad de
las llamadas, almacenamiento de fax, apertura de correo electrónico,
distribución del correo electrónico;

b) Política de controles adecuados para administrar la información compartida, por

ejemplo, uso de boletines electrónicos en la empresa (véase 9.1);

c) Exclusión de ciertas categorías de información comercial confidencial en caso

de que el sistema no provea un nivel adecuado de protección (véase 5.2);

52
 d) Restricción del acceso a la información diaria de ciertas personas físicas, por
ejemplo: personal que trabaja en proyectos confidenciales;

e) La conveniencia o no de que el sistema respalde las aplicaciones comerciales,

como ser comunicación de órdenes o autorizaciones;

f) Categorías del personal, contratistas o socios comerciales a quienes se permite el

uso del sistema y ubicaciones desde las cuales pueden tener acceso (véase 4.2):

g) Restricciones del uso de ciertos elementos a determinadas categorías de

usuarios;

h) Identificación de la condición de usuarios, vale decir, empleados de la

organización o contratistas en directorios a beneficio de otros usuarios:

i) Retención y resguardo de la información del sistema (véase 12.1.3 y 8.4.1);

j) Requerimientos y acuerdos de emergencia (véase 11.1)

8.7.6 Sistemas a disposición del público

Se debe tener cuidado en proteger la integridad de la información que se publica por vía
electrónica a fin de impedir su modificación sin autorización lo cual podría dañar la
reputación de la organización editora. La información contenida en un sistema que se
encuentra a disposición del público, vale decir, la informador contenida en un servidor de la
Web accesible por intermedio de Internet puede tener que cumplir con leyes, normas y
disposiciones de la jurisdicción en la cual se encuentre ubicado el sistema o en que se
realice la operación comercial. Debería existir un proceso de autorización formal antes de
que se facilite la información al público.

Los programas, datos y otra información que demande un elevado nivel de integridad y que
se encuentren a disposición del público deberían ser protegidos a través de los mecanismos
que resulten adecuados, por ejemplo mediante firmas digitales (véase 10.3.3). Los sistemas
de publicación electrónicos, especialmente los que permiten retroalimentación e ingreso
directo de información, deberían ser controlados cuidadosamente a fin de que:

a) La información sea obtenida cumpliendo con toda la legislación de protección de

datos (véase 12.1.4);

b) El ingreso de información y su procesamiento por el sistema de publicación sea

procesado en su totalidad con exactitud y oportunidad;

c) La información confidencial sea protegida durante el proceso de recopilación y al

ser almacenada;

53
 d) El acceso al sistema de publicación no permita el cacceso no previsto a redes a las
cuales se encuentre conectado.

8.7.7. Otras Formas de Intercambio Informático

Deberían existir procedimientos y controles que protejan el intercambio informático

mediante el uso de voz, fax y video. La información podría verse comprometida debido a
falta de conciencia, políticas o procedimientos respecto del uso de dichos medios, por
ejemplo podría ser escuchada en un teléfono móvil en un lugar público, en máquinas de
contestación, podría producirse un acceso no autorizado a través de sistemas de correo
electrónico de voz por discado o accidentalmente mediante el envío de fax a la persona
equivocada usando el equipo de envío de fax.

Las operaciones de la empresa se podrían ver perturbadas y podría ponerse en peligro la

información si hubiese una falla en las comunicaciones, sobre carga o interrupción (véase
7.2 y cláusula 11). Asimismo, la información podría verse en `peligro si usuarios no
autorizados tuviesen acceso a la misma (ver cláusula 9).

Se deberían establecer en forma explícita los procedimientos que se espera el personal siga
en cuanto a uso de voz, fax y otros medios de comunicaciones, los cuales deberían incluir:

a) Recordar al personal que deberían tomar las precauciones debidas, por ejemplo:
no revelar información confidencial a fin de evitar ser escuchados o
interceptados al efectuar una llamada telefónica por:

1) Gente en la inmediata vecindad, especialmente al usar teléfonos

celulares;

2) Escuchas grabadas y otras formas de escuchas ilegales realizadas a través

del acceso físico a teléfonos manuales o líneas telefónicas o el empleo
de receptores-exploradores al usar teléfonos móviles analógicos;

3) Gente ubicada del lado receptor de la línea:

b) Recordar al personal que no deberían efectuar conversaciones de índole

confidencial en lugares públicos u oficinas abiertas y lugares de reunión con
paredes delgadas;

c) No permitir la existencia de máquinas de contestación o de mensajes pues

pueden ser rebobinadas por personas carentes de autorización, almacenadas en
sistemas de acceso común o depositadas en forma incorrecta como resultado de
un discado equivocado;

d) Recordar al personal los problemas que presenta el uso de máquinas de fax,

principalmente:

54
 1) El acceso no autorizado a depósitos de mensajes incorporados para
recuperar dichos mensajes;

2) La programación deliberada o accidental de las máquinas para que

envíen mensajes a determinados números;

3) El envío de documentos y mensajes a números equivocados sea mediante

discado incorrecto o bien por el uso de un número incorrecto
previamente almacenado.

9. CONTROL DE ACCESO

9.1 Requisitos de control de acceso de la empresa

Objetivo: Control del acceso informático.

El acceso informático y los procedimientos de la empresa deberían ser controlados en base

a exigencias de seguridad y de índole empresaria.

Se deberían tomar en cuenta las políticas de autorización para la divulgación de

información.

9.1.1 Política de control de acceso

9.1.1.1 Requisitos de la empresa y determinados por la política de la empresa

Los requisitos de la empresa respecto del control de acceso deberían ser definidos y
documentados. Las normas de control de acceso y los derechos de cada usuario o grupo de
usuarios deberían encontrarse claramente manifestados en la declaración sobre política de
acceso. Se debería proporcionar a usuarios y prestadores de servicios una declaración
explícita de los requisitos que la empresa exige cumplir en materia de controles de acceso.

Dicha política debería tener en cuenta lo siguiente:

a) Los requisitos de seguridad referidos a cada solicitud individualmente

considerada;

b) Identificación de toda la información relacionada con cada solicitud;

c) Políticas de autorización para la divulgación de información, por ejemplo,

necesidad de conocer los niveles en cuanto a principios y seguridad y
clasificación de información;

55
 d) Congruencia entre el control de acceso y las políticas de clasificación de
información de los distintos sistemas y redes;

e) Legislación pertinente y cualquier obligación contractual respecto de protección

al acceso a datos o servicios (véase cláusula 12);

f) Perfiles estandarizados de acceso por parte de usuarios conforme a categorías

comunes;

g) Administración de los derechos de acceso en un contexto de conexión en red

que permita reconocer todos los tipos de conexiones disponibles.

9.1.1.2 Normas sobre control de acceso

Al especificar las normas de control de acceso, se debería tener cuidado en considerar lo

siguiente:

a) Diferenciación entre normas que siempre deben ser cumplidas y normas que son
opcionales o condicionales;

b) Establecimiento de normas en función de la premisa “Está prohibido a menos que

se encuentre permitido en forma expresa” en lugar de la norma más débil de que
“Todo está permitido salvo que esté prohibido en forma expresa”;

c) Cambios en los rótulos de información (véase 5.2) que se inician automáticamente

en los procesos informáticos y aquellos que se inician a criterio del usuario;

d) Cambios en los permisos que se conceden al usuario para iniciar el sistema

informático automáticamente y aquellos cuya iniciación depende de un
administrador;

e) Normas que exigen contar con la aprobación del administrador o de otra persona
antes de ser puestas en práctica y otras que no requieren tal aprobación.

56
9.2 Administración del acceso del usuario

Objetivo: Impedir el acceso sin autorización a los sistemas informáticos.

Deberían existir procedimientos formales que controlen la asignación de derechos de

acceso a los sistemas y servicios informáticos.

Los procedimientos deberían abarcar todas las etapas del ciclo vital del acceso por parte del
usuario desde el registro inicial de nuevos usuarios a la cesación definitiva del registro de
usuarios que ya no requieren contar con acceso a los sistemas y servicios informáticos. Se
debería prestar especial atención, en los casos que corresponda, a la necesidad de controlar
la asignación de derechos de acceso privilegiado que permiten a los usuarios pasar por alto
los controles del sistema.

9.2.1 Registro del usuario

Deberían existir procedimientos formales de registro del usuario y de anulación de dicho

registro que permitan acceso a todos los sistemas y servicios informáticos de acceso
múltiple por parte de los usuarios.

El acceso a servicios informáticos de acceso múltiple debería encontrarse controlado a

través de un proceso formal de registro del usuario que debería incluir:

a) Usar una identificación única para el usuario de modo que se lo pueda vincular y
responsabilizar por sus acciones. El uso de identificación grupal solamente
debería permitirse cuando sea conveniente a efectos de la tarea a realizar;

b) Verificación de que el usuario está autorizado por el titular del sistema para usar
el sistema o servicio informático. Puede ser también conveniente que la
administración también brinde su aprobación por separado al derecho de acceso;

c) Verificación de que el nivel de acceso concedido es adecuado a los fines de la

empresa (véase 9.1) y congruente con la política de seguridad de la
organización, por ejemplo que no compromete la separación de deberes (véase
8.1.4);

d) Proporcionar al usuario una declaración escrita respecto de sus derechos de

acceso;

e) Exigir a los usuarios que firmen manifestaciones que señalen que comprenden
las condiciones de acceso;
f) Garantizar que los prestadores de servicios no brinden acceso hasta tanto se
hayan completado los procedimientos de autorización;

57
 g) Mantenimiento de un registro formal de todas las personas registradas como
usuarios de servicios;

h) Remoción inmediata de los derechos de acceso a los usuarios que hayan

cambiado de trabajo o dejado la organización;

i) Verificación periódica y eliminación de identificación y cuentas de usuarios

redundantes;

j) Garantizar que las identificaciones de usuarios que sean redundantes no sean

emitidas a favor de otros usuarios.

Se debería prestar atención a la inclusión de cláusulas en los contratos del personal y de

servicios que determinen sanciones en caso de intento de acceso no autorizado por parte del
personal o de los agentes de los servicios (véase también 6.1.4 y 6.3.5).

9.2.2 Administración de Privilegios

La asignación y uso de privilegios (cualquier rasgo o elemento de un sistema informático

de usuarios múltiples que permite que el usuario pase por alto los controles del sistema o de
la aplicación) debería ser restringido y controlado. El uso inadecuado de los privilegios del
sistema es a menudo un factor que contribuye al fracaso de los sistemas debido a su
violación.

Los sistemas habilitados para usuarios múltiples que requieren contar con protección frente
a acceso no autorizado deberían ser controlados en cuanto a la asignación de privilegios
mediante un proceso de autorización formal. Se debería considerar la instrumentación de
los pasos que se enumeran a continuación:

a) Los privilegios relacionados con cada producto del sistema, por ejemplo,
sistema operativo, sistema de administración de base de datos y cada aplicación,
deberían identificar las categorías del personal a las cuales resulte necesario
asignar tales privilegios;

b) Los privilegios deberían ser asignados a personas físicas en función de las

necesidades de uso y analizando caso por caso, es decir que se debería establecer
un requisito mínimo para su papel funcional solamente en caso necesario;

c) Se debería instrumentar un proceso de autorización y llevar un registro de todos

los privilegios que se asignen. No se deberían conceder privilegios sin completar
previamente el proceso de autorización;

d) Se debería promover el desarrollo y uso de rutinas de sistemas a fin de evitar la

necesidad de conceder privilegios a los usuarios;

58
 e) La identidad del beneficiario de un privilegio debería ser diferente a la identidad
que utilice para sus operaciones normales en la empresa.

9.2.3 Administración de las contraseñas de los usuarios

Las contraseñas son un medio común de validar la identidad de un usuario para acceder a
un sistema o servicio informático. La asignación de contraseñas debería ser controlada
mediante un proceso de administración formal, cuyo enfoque debería ser el siguiente:

a) Se requerirá a los usuarios que firmen una declaración de confidencialidad de

sus contraseñas personales y del uso de las contraseñas grupales solamente par
los miembros del grupo (este requisito podría ser incluido dentro de los términos
y condiciones de empleo, véase 6.1.4);

b) Se garantizará a los usuarios que mantengan sus propias contraseñas que se les
suministrará inicialmente una contraseña temporaria segura que deberían
cambiar inmediatamente. Las contraseñas temporarias que se suministren
cuando los usuarios olviden su contraseña serán concedidas solamente cuando se
logre la debida identificación del usuario;

c) Se requerirá que la entrega de contraseñas a los usuarios sea segura. El uso de

terceros o de mensajes de correo electrónico sin protección (texto claro) debería
evitarse. Los usuarios deberían acusar recibo de las contraseñas.

Las contraseñas nunca deberían ser almacenadas en un sistema de computación carente de

protección (véase: Otras tecnologías de identificación y autenticación del usuario como la
biométrica que permite, por ejemplo la verificación de impresiones digitales, verificación
de firma y uso de cospeles para discos rígidos, por ejemplo si correspondiere podrían usarse
tarjetas con chips).

9.2.4 Revisión de los derechos de acceso de los usuarios

A fin de mantener un control eficaz del acceso a los servicios y datos informáticos, la
administración debería llevar a cabo un examen formal y periódico de los derechos de
acceso de los usuarios a fin de que:

a) se examinen en forma periódica los derechos de acceso de los usuarios (se

recomienda que sea a intervalos de seis meses) y con posterioridad a la
introducción de cualquier modificación (véase 9.2.1);

b) se examinen las autorizaciones de derecho de acceso especial y privilegiado

(véase 9.2.2) a intervalos más frecuentes , se recomienda que sea cada 3 meses;

c) Se verifiquen las asignaciones de privilegios a intervalos periódicos a fin de

garantizar que no se obtengan privilegios que carezcan de autorización.

59
9.3 Responsabilidades de los Usuarios

Objetivo: Impedir el acceso de un usuario que carezca de autorización.

La cooperación de los usuarios autorizados es esencial paras lograr eficacia en la seguridad.

Los usuarios deberían tener presente sus responsabilidades en materia de mantenimiento de
un control eficaz de los accesos, especialmente en lo que respecta al uso de contraseñas y a
la seguridad del equipo del usuario.

9.3.1 Uso de la Contraseña

Los usuarios deberían seguir la buena práctica en materia de seguridad en la selección y uso
de contraseñas.

Las contraseñas proporcionan un medio de validación de la identidad del usuario y por

ende, una forma de determinar los derechos de acceso a los servicios de procesamiento
informático. Se debería aconsejar a todos los usuarios lo siguiente:

a) Las contraseñas deben ser confidenciales;

b) Se debe evitar guardar un registro en papel de las contraseñas a menos que sea
guardado en lugar seguro;

c) Se debe cambiar la contraseña siempre que haya indicios de posible peligro para
el sistema o la contraseña;

d) Se deben seleccionar contraseñas de calidad de extensión mínima de seis

caracteres que sean:

1) Fáciles de recordar;

2) No se encuentren relacionadas con algo que cualquier otra persona pueda

adivinar fácilmente u obtener usando información relacionada con la
persona, por ejemplo, nombres, números telefónicos y fechas de nacimiento,
etc.;

3) Deben encontrarse libres de caracteres idénticos consecutivos o de

agrupamientos que sean totalmente numéricos o alfabéticos.

e) Se deberían cambiar las contraseñas periódicamente o en función del número de

acceso (las contraseñas de cuentas privilegiadas deberían ser cambiadas con
mayor frecuencia que las contraseñas normales) y evitar volver a utilizar o
reciclar contraseñas viejas;

60
 f) Se deberían cambiar las contraseñas temporarias al producirse el primer ingreso;

g) No se incluirán contraseñas en cualquier proceso de ingreso automático, por

ejemplo, guardadas en una macro o función clave;

h) No se compartirán las contraseñas de usuario individuales.

Si los usuarios necesitan tener acceso a servicios o plataformas múltiples y deben mantener
contraseñas múltiples, se les debería informar que pueden usar una única contraseña de
calidad [véase d) precedente] para todos los servicios que proporcionen un nivel adecuado
de protección para las contraseñas guardadas.

9.3.2 Equipos de usuarios sin protección

Los usuarios deberían garantizar que el quipo no utilizado tenga protección adecuada. Los
equipos instalados en áreas frecuentadas por usuarios, por ejemplo, estaciones de trabajo o
servidores de archivos pueden requerir contar con protección específica frente a acceso no
autorizado cuando se los deje solos por un período prolongado. Todos los usuarios y
contratistas deberían tener presente los requisitos y procedimientos de seguridad para la
protección de equipos sin atención como también sus responsabilidades en cuanto a la
instrumentación de dicha protección. Se debería aconsejar a los usuarios que:

a) Finalicen las sesiones activas cuando hayan terminado su tarea a menos que
pueden tener la garantía de contar con un mecanismo de cierre adecuado, por
ejemplo un protector de pantalla que proteja la contraseña;

b) Apaguen las computadoras principales multiusuario al finalizar la sesión (es

decir que no se debe simplemente apagar la PC o terminal);

c) Garantizar la seguridad de las computadoras personales o terminales frente al

uso no autorizado a través del uso de un cierre bajo llave o control equivalente,
por ejemplo acceso con contraseña cuando los equipos no se encuentren en uso.

9.4 Control de acceso a la red

Objetivo: Protección de los servicios en red.

Se debería controlar el acceso tanto a los servicios en red internos como externos. Este
control es necesario a fin de asegurar que los usuarios que cuenten con acceso a las redes y
a los servicios en red no pongan en peligro la seguridad de estos servicios en red,
garantizando:

a) La existencia de interfaces adecuadas entre la red de la organización y las redes de

propiedad de otras organizaciones o redes públicas;
b) La existencia de mecanismos de autenticación adecuados para usuarios y equipo;
c) Control del acceso del usuario a los servicios informáticos.

61
9.4.1 Política sobre el uso de servicios en red

Las conexiones inseguras a servicios en red pueden afectar a toda la organización. Los
usuarios solamente deberían ser provistos de acceso directo a los servicios que se
encuentren específicamente autorizados a usar. Este control es importante especialmente
para las conexiones en red a aplicaciones confidenciales o de importancia fundamental
para la empresa o a usuarios en ubicaciones de alto riesgo, por ejemplo áreas públicas o
externas que se encuentren fuera de la administración y control de la organización.

Se debería formular una política concerniente al uso de redes y servicios en red. Dicha
política debería abarcar:

a) Las redes y servicios en red a los cuales se permite el acceso;

b) Los procedimientos de autorización para determinar quiénes tendrán acceso a

determinadas redes y servicios suministrados en red;

c) Controles y procedimientos administrativos destinados a proteger el acceso a las

conexiones en red y servicios en red.

Esta política debería ser compatible con la política de acceso a la empresa (véase 9.1);

9.4.2 Ruta Obligatoria

Puede que haya necesidad de controlar la ruta entre la terminal del usuario y el servicio de
computación. Las redes tienen por fin brindar el máximo alcance al uso compartido de
recursos y proporcionar flexibilidad en las rutas. Estos rasgos pueden también proporcionar
oportunidades de acceso no autorizado a las aplicaciones de la empresa o de uso indebido
de los sistemas informáticos. La reducción de dichos riesgos se puede lograr mediante la
incorporación de controles que restrinjan la ruta entre una terminal de usuario y los
servicios de computación a los cuales dicho usuario tiene acceso autorizado, a través por
ejemplo de la creación de una ruta obligatoria.

El objetivo de la ruta obligatoria es impedir que cualquier usuario seleccione rutas fuera de
aquella que le que corresponda entre la terminal del usuario y los servicios a los cuales
dicho usuario tiene acceso.

Esto normalmente exige instrumentar un cierto número de controles en distintos puntos de

la ruta. El principio consiste en limitar las opciones de rutas en cada punto de la red a través
de elecciones predefinidas.

Como ejemplos se pueden mencionar los siguientes:

a) Asignación de líneas especiales o números telefónicos;

b) Puertos de conexión automática a sistemas de aplicación específica o puertas de

seguridad;

62
 c) Limitación de las opciones de menú y menú secundario respecto de cada
usuario;

d) Impedimento al “rastreo de rutas” (roaming) ilimitado en la red;

e) Utilización efectiva de sistemas de aplicación específica y / o puertas de

seguridad para los usuarios de redes externas;

f) Control activo de las comunicaciones permitidas entre su fuente y destino

mediante puertas de seguridad, por ejemplo cortafuegos;

g) Restricción del acceso a la red a través de la creación de dominios lógicos

separados, por ejemplo, redes privadas virtuales para grupos de usuarios dentro
de la organización (véase también 9.4.6).

La política de control de acceso a la empresa regirá los requisitos a aplicar para la creación
de una ruta obligatoria. (véase 9.1).

9.4.3 Autenticación del usuario para conexiones externas

Las conexiones externas proporcionan un terreno propicio para el acceso no autorizado a la

información de la empresa, por ejemplo el acceso mediante métodos de discado. Por lo
tanto, el acceso por parte de usuarios ubicados en sitios alejados debería encontrarse
sometido a autenticación. Existen diferentes métodos de autenticación, algunos de ellos
brindan un mayor nivel de protección que otros, por ejemplo, los métodos basados en el uso
de técnicas criptográficas pueden proporcionar una autenticación sólida. Es importante
determinar a través de una evaluación del riesgo, el nivel de protección con el cual se
necesita contar. Esta evaluación es necesaria para lograr una selección adecuada de un
método de autenticación.

La autenticación de usuarios alejados puede lograrse mediante el uso, por ejemplo, de una
técnica de base criptográfica, cospeles para soporte físico o con la existencia de un
protocolo de desafío y respuesta. Las líneas privadas especiales o un sistema de verificación
de direcciones de usuarios en red también pueden emplearse para proporcionar una garantía
en cuanto al origen de la conexión.

Los procedimientos y controles a través del discado del número telefónico del usuario
como método de autenticación de la llamada mediante, por ejemplo, uso de modems puede
proporcionar protección frente a conexiones indeseadas o carentes de autorización
efectuadas a los sistemas de procesamiento informático de la empresa. Este tipo de control
autentica a los usuarios intentando establecer una conexión con una red de la organización
desde un punto lejano. Al usar este control, la organización no debería emplear los servicios
en red que incluyen la transferencia de llamadas o, si lo hace, debería desconectar esos
sistemas para evitar las debilidades que conlleva la transferencia de llamadas. También,
resulta importante que el proceso de nueva llamada incluya la garantía de que se produzca
una desconexión real de parte de la organización. De otro modo, el usuario ubicado en sitio

63
remoto podría mantener la línea abierta pretendiendo que se ha producido la verificación de
la llamada. Los procedimientos de nueva llamada y sus controles deberían ser chequeados
en profundidad para evitar que se dé esta posibilidad.

9.4.4 Autenticación de Computadoras enganchadas a una Red de

Computadoras

Un sistema de conexión automática a una computadora situada en sitio remoto podría

brindar una forma de obtener acceso no autorizado a una aplicación de la empresa. Las
conexiones a sistemas de computadoras situadas en lugares lejanos deberían por lo tanto
contar con la debida autenticación. Esto es de especial importancia si la conexión usa una
red que está fuera del control de la administración de seguridad de la organización. En 9.4.3
precedente se proporcionan algunos ejemplos de autenticación y de cómo lograrla.

La autenticación de computadoras en red puede servir como un medio alternativo para

autenticar grupos de usuarios ubicados en sitios lejanos a través de una conexión a una
sistema de computadoras seguro y compartido (véase 9.4.3).

9.4.5 Protección de puertos de diagnóstico remoto

El acceso a puertos de diagnóstico debería estar controlado en forma segura. Muchas

computadoras y sistemas de comunicaciones instalados contienen un sistema de diagnóstico
remoto mediante discado que será usado por los ingenieros de mantenimiento. Si dichos
puertos de diagnóstico quedan sin protección, proporcionan un medio de acceso no
autorizado. Por lo tanto, deberían ser protegidos mediante un mecanismo de seguridad
adecuado, por ejemplo, un cierre bajo llave así como un procedimiento que garantice que
solamente resultarán accesibles a través de un acuerdo celebrado entre el administrador del
servicio de computación y el personal de apoyo en materia de programas y discos rígidos
que solicita acceso.

9.4.6 La segregación dentro de las redes

Las redes se extienden en forma creciente más allá de los limites de las organizaciones a
medida que se forman sociedades empresariales que exigen la interconexión o participación
en el procesamiento informático y en las redes. Dicha extensión podría incrementar el
resigo de acceso no autorizado a sistemas informáticos ya existentes que usan la red,
algunos de los cuales podría requerir protección frente a los usuarios de otras redes debido
a la confidencialidad o importancia crítica que tienen. En tales circunstancias, la
instrumentación de controles dentro de la red a fin de segregar grupos de servicios
informáticos, usuarios y sistemas informáticos debería ser considerada.

Un método de control de la seguridad de grandes redes consiste en su división en dominios

lógicos de redes separadas, por ejemplo, un dominio de red interno a la organización y otro
externo, protegidos por un perímetro de seguridad definido. Dicho perímetro puede
instrumentarse mediante la instalación de una puerta segura entre las dos redes a
interconectar a fin de controlar el acceso y flujo informático entre los dos dominios. Esta
puerta debería esta configurada de tal modo que filtre el tráfico entre estos dominios (véase

64
9.4.7 y 9.4.8) y para que bloquee el acceso no autorizado conforme a la política de control
de acceso que tenga la organización (véase 9.1). Un ejemplo de este tipo de puerta es lo que
comúnmente se conoce como cortafuego.

Los criterios de segregación de redes en dominios deberían basarse en la política de control

de acceso y en los requisitos de acceso (véase 9.1) y también tomar en cuenta el costo
relativo y el impacto que provoque en el desenvolvimiento de la empresa debido a la
incorporación de rutas de red convenientes o tecnología de puertas (véase 9.4.7 y 9.4.8).

9.4.7 Control de conexión a redes

Los requisitos de la política de control de acceso en el caso de redes compartidas,

especialmente aquellas que se extienden a través de los límites de la organización pueden
demandar la instrumentación de controles destinados a restringir la capacidad de conexión
de los usuarios. Dichos controles pueden instrumentarse a través de puertas a la redes que
filtren el tráfico mediante cuadros o normas predefinidos. Las restricciones que se apliquen
deberían basarse en los requisitos y política para acceso correspondiente a las aplicaciones
de la empresa (véase 9.1) y deberían mantenerse y actualizarse consecuentemente.

Los siguiente son ejemplos de las aplicaciones a las cuales se les podrá aplicar
restricciones:

a) Correo electrónico:
b) Transferencia de archivos de una vía;
c) Transferencias de archivos de doble vía;
d) Acceso interactivo;
e) Acceso a red vinculado a la hora del día o a la fecha.

9.4.8 Control de Rutas de la Red

Las redes compartidas, especialmente aquellas que cruzan los límites de la organización
pueden exigir la instrumentación de controles de ruta que garanticen que las conexiones de
la computadora y los flujos informático no violen la política de control de acceso de las
aplicaciones de la empresa (véase 9.1). Este control es a menudo especial para las redes que
se comparten con terceros que no son usuarios de la organización.

Los controles de rutas deberían basarse en mecanismos de verificación positivos de

direcciones de origen y destino. La traducción de dirección ded la red es también un
mecanismo muy útil para aislar las redes e impedir que las rutas se propaguen de la red de
una organización a la red de otro. Se pueden instrumentar a través de programas o discos
rígidos. Los encargados de la instrumentación deberían ser conscientes de la solidez de
cualquier mecanismo que desplieguen.

65
9.4.9 Seguridad de los servicios de la red

La red ofrece una amplia gama de servicios públicos y privados,, algunos de los cuales
permiten incorporar valor agregado. Los servicios de la red pueden tener características de
seguridad únicas o complejas. Las organizaciones que utilizan servicios de la red deberían
garantizar que cuentan con una descripción clara de los atributos de seguridad de todos los
servicios que usan.

9.5 Control de acceso al sistema operativo

Objetivo: Impedir el acceso no autorizado a las computadoras.

Los elementos de seguridad a nivel de sistema operativo deberían ser usados para restringir
el acceso a los recursos de las computadoras. Estos elementos deberían estar dotados a los
efectos de:

a) Identificar y verificar la identidad y en caso necesario la termina o ubicación de

cada usuario autorizado;
b) Registrar los accesos al sistema exitosos y fallidos;
c) Proporcionar medios adecuado para efectuar autenticación; en caso de que se utilice
un sistema de administración por contraseña, se debería garantizar la calidad de las
contraseñas [véase 9.3.1.d]];
d) En los casos pertinentes, se debería restringir los tiempos de conexión de los
usuarios.
Otros métodos de control de accesos, como el de desafío y respuesta, pueden ser utilizados
si se justifican en base al riesgo para la empresa.

9.5.1 Identificación automática de la terminal

Se debería sopesar la posibilidad de contar con identificación automática de la terminal a

fin de autenticar las conexiones con ubicaciones determinadas y equipos portátiles. La
identificación automática de terminales es una técnica que puede usarse en caso de que sea
importante que la sesión solamente pueda ser iniciada desde una ubicación o terminal de
computación determinada. Se puede usar un identificador incluido en, o adjunto a, la
terminal para señalar si la terminal dada tiene permiso para iniciar o recibir operaciones
determinadas. Puede ser necesario aplicar protección física a la terminal a fin de mantener
la seguridad del identificador de terminal. Se pueden asimismo usar algu8nas otras técnicas
para autenticar usuarios (véase 9.4.3).

66
9.5.2 Procedimientos de conexión a la terminal

El acceso a los servicios informáticos debería conseguirse por intermedio de un proceso de

ingreso seguro. El procedimiento para ingresar al sistema de una computadora debería estar
diseñado en forma tal que minimice la oportunidad de acceso no autorizado. El
procedimiento de ingreso debería por lo tanto revelar un mínimo de información respecto
del sistema a fin de evitar proporcionar al usuario no autorizado asistencia innecesaria. Un
buen procedimiento de ingreso debería:

a) no revelar los identificadores del sistema o de la aplicación hasta que se haya

completa exitosamente el proceso de ingreso;
b) revelar un aviso general en cuanto a que solamente los usuarios autorizados
podrán acceder a la computadora;
c) no proporcionar mensajes de ayuda durante el procedimiento de ingreso que
contribuyan a permitir el acceso a un usuario no autorizado;
d) validar la información de ingreso solamente al completarse la carga de todos los
datos. Si se produjera una situación de error, el sistema no debería indicar que
parte de los datos es correcta o no lo es;
e) limitar el número de intentos fallidos de ingreso permitidos (se recomienda que
sean tres) y considerar:

1) registrar los intentos fallidos;

2) forzar una demora temporal antes de permitir otros inentos de ingreso o
rechazar cualquier otro intento sin autorización específica;
3) desconectar las conexiones de vinculación con los datos.

f) limitar los tiempos mínimo y máximo permitido para el procedimiento de

ingreso; en caso de ser excedido, el sistema debería dar por terminado el
ingreso;
g) desplegar la información siguiente al lograrse un ingreso exitoso:

1) fecha y hora del ingreso exitoso anterior;

2) detalles de cualquier intento de ingreso fallido producido desde el último
ingreso exitoso.

9.5.3 Identificación y Autenticación del Usuario

Todos los usuarios (inclusive el personal de apoyo técnico como ser operadores,
administradores de redes, programadores de sistema y administradores de base de datos)
deberían contar con un identificador único (identificación de usuario) para su uso único y
personal de modo que se puedan efectuar un seguimiento de actividades hasta la persona
responsable de las mismas. La identificación de usuario no debería proporcionar indicio
alguno del nivel de privilegio del usuario (véase 9.2.2) por ejemplo, administrador,
supervisor.

67
En casos excepcionales, cuando se obtenga de ello un claro beneficio empr4esarial, se
puede usar una identificación de usuario compartida para un grupo de usuarios o en una
tarea específica. Se debería documentar la aprobación por parte de la administración en
tales casos. Se podrán exigir controles adicionales para mantener la responsabilidad legal.

Existen varios procedimientos de autenticación que pueden usarse para substanciar el

reclamo de identidad de un usuario. Las contraseñas (véase también 9.3.1 y siguiente) son
un medio muy común de brindar identificación y autenticación en base a un secreto que
so0lo el usuario conoce. Lo mismo se puede lograr a través de medios criptográficos y
protocolos de autenticación.

Objetos tales como cospeles con memoria o tarjetas inteligentes que posean los usuarios
también pueden usarse para lograr identificación y autenticación. Las tecnologías de
autenticación biométrica que usan las características únicas de una persona también pueden
emplearse para autenticar la identidad de una persona. Una combinación de tecnologías y
mecanismos vinculados con seguridad dará como resultado una autenticación más sólida.

9.5.4 Sistemas de administración de contraseñas

Las contraseñas son uno de los medios principales para validar la facultad de un usuario
para acceder a un servicio de computación. Los sistemas de administración de contraseñas
deberían proporcionar un contexto eficaz e interactivo que asegure la calidad de4 las
contraseñas (véase x9.3.1 por los lineamientos sobre uso de contraseñas);

Algunas aplicaciones exigen del usuario contraseñas asignadas por una autoridad
independiente. En la mayoría de los caso, las contraseñas son seleccionadas y mantenidas
por lo usuarios.

Un buen sistema de administración de contraseñas debería:

a) instrumentar el uso de contraseñas individuales para mantener la responsabilidad

legal del usuario;
b) en los casos pertinentes, permiten que los usuarios seleccionen y cambien sus
propias contraseñas e incluir un procedimiento de confirmación para cubrir
errores de carga;
c) instrumentar un a elección de contraseñas de calidad de la forma descrita en
9.3.1;
d) en los casos en que los usuarios mantengan sus propias contraseñas,
instrumentar cambios en la contraseña de la forma descripta en 9.3.1;

e) en los casos en que los usuarios seleccionan contraseñas, deberían modificar las
contraseñas temporales cuando efectúen el primer ingreso (véase 9.2.3);

f) mantener un registro de contraseñas de usuario anteriores, por ejemplo de los 12

meses anteriores a fin de impedir utilizarlas nuevamente.

68
 g) No permitir la visualización de las contraseñas en la pantalla cuando se produce
el ingreso;

h) Guardar las contraseñas en archivos separados de los archivos de datos del

sistema de aplicaciones;

i) Alterar las contraseñas por omisión del vendedor luego de la instalación del
programa.

9.5.5 Uso de las aplicaciones del sistema

La mayoría de las instalaciones de computación tienen uno o más programas de

instrumentos del sistema que pueden ser capaces de sobrepasar los controles de
aplicaciones y sistemas; es esencial que se uso se encuentre restringido y sumamente
controlado. Se debería considerar la instrumentación de los controles que se enumeran a
continuación:

a) uso de procedimientos de autenticación para los instrumentos del sistema;

b) segregación de los instrumentos del sistema del programa de aplicaciones;
c) limitación del uso de instrumentos del sistema al número mínimo práctica
necesario para que trabajen usuarios confiable y autorizados;
d) autorización para uso ad hoc de instrumentos del sistema;
e) limitación de la disponibilidad de instrumentos del sistema, por ejemplo durante
la vigencia de un cambio autorizado;
f) establecimiento de requisitos de ingreso para el uso de los instrumentos del
sistema;
g) definición y documentación de los niveles de autorización correspondientes a
instrumentos del sistema;
h) remoción de todos los instrumentos innecesarios basados en programas y de los
programas del sistema.

9.5.6 Alarma de coacción para salvaguardia de los usuarios

Se debería considerar la posibilidad de proveer una alarma de coacción para aquellos

usuarios que puedan ser blanco de coerción. La decisión en cuanto a suministrar ese tipo de
alarma se debería fundamentar en una evaluación de riesgos. Se deberían definir las
responsabilidades y procedimientos para responder a una alarma por coacción.

9.5.7 Salida de sistema de la terminal

Las terminales inactivas ubicadas en sitios de alto riesgo, por ejemplo zonas públicas o de
acceso externo situadas fuera de la zona de administración de seguridad de la organización
o que sirvan a sistemas de alto riesgo deberían ser cerradas después de u período definido
de inactividad a fin de impedir el acceso de personas no autorizadas. El programa de salida
de servicio debería limpiar la pantalla de la terminar y cerrar tanto la aplicación como las
sesiones de red después de un período definido de inactividad. La demora para salida de

69
servicio debería ser reflejo de los riesgos de seguridad que sobrellevan la zona y los
usuarios de la terminal.

Una forma limitada de programa de salida de servicio de terminal puede ser proporcionado
por algunas computadoras personales que limpian la pantalla e impiden el acceso no
autorizado pero no cierran la aplicación o sesiones de red.

9.5.8 Limitación al tiempo de conexión

Las restricciones a los tiempos de conexión deberían proporcionar seguridad adicional para
aplicaciones de alto riesgo. La limitación del período durante el cual se permiten
conexiones de terminal a los servicios de computación reduce las oportunidades para lograr
el acceso sin previa 9utorización. Dicho control debería ser tenido en cuenta en el caso de
aplicaciones de la computadora de carácter confidencial especialmente en el caso de
terminales instaladas en sitios de alto riesgo como ser zonas públicas y de acceso desde el
exterior fuera del control por parte de la administración de seguridad de la organización.
Entre los ejemplos de tales restricciones se incluye los siguiente:

a) el uso de lapso temporales predeterminados, por ejemplo en el caso de

transmisiones de archivo en grupo o sesiones inter. activas regulares de corta
duración:

b) restricción a los tiempos de conexión para que no excedan de las horas normales
de trabajo en la oficina en caso de que no haya necesidad de trabajar horas
extraordinarios o ampliar el horario de operaciones.

9.6 Control de acceso a las aplicaciones

Objetivo: Impedir el acceso no autorizado a la información contenida en los sistemas

informáticos. Se deberían utilizar los instrumentos de seguridad a fin de restringir el acceso
al interior de los sistemas de aplicaciones. El acceso lógico a los programas y la
información se debería restringir a los usuarios autorizados. Los sistemas de aplicación
deberían:

a) controlar el acceso del usuario a las funciones informáticas y de sistema de

aplicaciones conforme a la política definida por la empresa en materia del
control de acceso;
b) proteger cualquier a los programas de los sistemas operativos o instrumentos
frente a los intentos de acceso no autorizado capaces de superar los controles de
las aplicaciones o del sistema;
c) no comprometer la seguridad de otros sistemas con los cuales se comparten
recursos informáticos;
d) poder brindar acceso a la información solamente al titular, otras personas
autorizadas al efecto o grupos definidos de usuarios.

70
9.6.1. Restricciones al acceso informático

Los usuarios de sistemas de aplicación, inclusive personal de apoyo, deberían contar con
acceso informático y a las funciones del sistema de aplicaciones conforme a la política que
se defina respecto del control de acceso en base a las necesidades respecto de cada
aplicación de la empresa y congruentemente con la política de acc4eso informático de la
organización (véase 9.1). Se debería tener presente la utilización de los controles que se
enumeran abajo a fin de respaldar las necesidades en materia de restricción al acceso.

a) dotar de menús de control de acceso a las funciones del sistema de aplicaciones;

b) restringir el conocimiento que el usuario disponga de las funciones informáticos
o del sistema de aplicaciones a las cuales no tenga autorización de acceso
mediante la edición adecuada de la d90cumentación del usuario;
c) control los derechos de acceso de los usuarios, por ejemplo, lectura, escritura,
eliminación y ejecución;
d) garantizar que las salidas de los sistemas de aplicaciones que manejen
información confidencial contenga solamente la información que sea pertinente
para el uso del dato descargado y se envíen solamente a terminales y
ui8bcaciones autorizadas, con inclusión de una revisión periódica de dichas
salidas de datos a fin de garantizar que se elimine la información redundante.

9.6.2 Aislamiento de los sistemas confidenciales

Los sistemas confidenciales pueden exigir contar con un contexto de computación especial
(asilado). Algunos sistemas de aplicaciones son lo suficientemente sensibles ante pérdida
potenciales que requieren que se los maneje de forma especial. Dicha sensibilidad puede
indicar que el sistema de aplicaciones deba funcionar en una computadora especial,
compartiendo recursos solamente con sistemas de aplicaciones confiables o funcionar sin
limitaciones. Se deben tener presentes los conceptos siguientes:

a) La confidencialidad de un sistema de aplicaciones debería ser identificada

explícitamente y documentada por el titular de la aplicación (véase 4.1.3);
b) Cuando una aplicación confidencial haya de funcionar en un contexto
compartido, los sistemas de aplicaciones con los cuales se comparten recursos
deberían encontrarse identificados y llegar a un acuerdo al respecto con el titular
de la aplicación confidencial.

9.7 Sistema de verificación del acceso y uso

Objetivo: Detectar actividades carentes de autorización.

Los sistemas deberían ser verificados a los efectos de detectar desvíos respecto de la
política de control de acceso y registrar los sucesos verificables a fin de proporciona
pruebas en caso de incidentes de seguridad.
La verificación de los sistemas permite determinar la eficacia de los controles adoptados y
controlar su compatibilidad con el modelo de política de acceso (véase 9.1)

71
9.7.1 Registro de incidentes

Las búsquedas realizadas por la auditoria que registren excepciones y otros sucesos de
importancia en materia de seguridad deberían ser guardados por un período previamente
pactado a fin de que puedan ser utilizados en investigaciones y verificaciones de control de
acceso que se hagan el futuro. Los ingresos de auditoria deberían incluir asimismo:

a) identificación del usuario;

b) fecha y horas de ingreso y egreso;
c) identidad de la terminal o ubicación si fuere posible;
d) registros de intentos exitosos y fallidos por ingresar al sistema;
e) registros de internos de acceso a datos y otros recursos exitosos y fallidos.

Ciertos ingresos a efectos de auditoria pueden tener que ser archivados como parte de la
política de retención de registros o debido a exigencias de recolección de pruebas (véase
también la cláusula 12).

9.7.2 Verificación del uso del sistema

9.7.2.1 Procedimientos y zonas de riesgo

Se deberían crear los procedimientos destinados a verificar el uso que se hace de los
procesos informáticos. Dichos procedimientos son necesarios a los efectos de garantizar
que los usuarios solamente realicen actividades que sean autorizadas en forma explicita. El
nivel de verificación exigido para cada proceso debería ser determinado mediante una
evaluación del riesgo. Se deberían considerar áreas que incluyan:

a) acceso autorizado, inclusive sus detalles como ser:

1) identificación del usuario,

2) fecha y hora de sucesos fundamentales,
3) tipos de sucesos;
4) archivos a los cuales se ha tenido acceso;
5) programas e instrumentos utilizados;

b) Todas las operaciones privilegiadas como ser:

1) uso de cuenta de supervisor;

2) iniciación y detención del sistema;
3) elemento para adjuntar ingresos y salidas de datos / separación

c) Intentos de acceso no autorizado como ser:

1) intentos fallidos;
2) violaciones a la política de acceso y notificaciones de puertas y
cortafuegos de red;
3) alertas provenientes de sistemas propios de detección de intrusos.

72
 d) fallas o alertas del sistema como ser:

1) alertas o mensajes en la consola;

2) excepciones al ingreso al sistema;
3) alarmas de la administración de la red.

9.7.2.2. Factores de riesgo

El resultado de las actividades de verificación debería ser revisado en forma periódica. La

frecuencia de la revisión debería depender de los riesgos involucrados. Se deberían
considerar factores de riesgo que incluyen:

a) situación crítica de los procesos de aplicación;

b) valor, confidencialidad y estado crítico de la información involucrada;
c) experiencia anterior en materia de infiltración y uso indebido de sistemas;
d) grado de interconexión del sistema (especialmente con redes públicas).

9.7.2.3 Registro y revisión de incidentes

Una revisión de los registros efectuados involucra comprender las amenazas que enfrenta el
sistema y la forma en que dichas amenazas pueden surgir. En 9.7.1 se dan ejemplos de
sucesos que pueden exigir una ulterior investigación en caso de existencia de incidentes de
seguridad.

Los registros del sistema a menudo contienen un gran volumen de información, mucha de
la cual es extraña al tema de la verificación de la seguridad. A fin de ayudar a identificar los
sucesos significativos a los efectos de una verificación de seguridad, se debería considerar
la realización de una copia automática de mensajes adecuados en un segundo registro y / o
el uso de instrumentos del sistema que resulten convenientes o herramientas de auditorias
para realizar un interrogatorio a los archivos.

Al asignar la responsabilidad respecto de una revisión de registro, se debería considerar la

realización de una separación de roles entre la persona o personas que emprenden la
revisión y aquellas cuyas actividades se encuentran bajo verificación.

Se debería presta especial atención a la seguridad del registro debido a que si se lo maneja
indebidamente puede crear una falsa sensación de seguridad. Los controles deberían tener
por objetivo proteger contra cambios no autorizados y problemas operativos inclusive:

a) que el registro se encuentre desactivado;

b) alteraciones en los tipos de mensajes que se registran;
c) la edición o eliminación de archivos del registro:
d) el agotamiento de los medios de archivo en registro que provoquen el no registro
de sucesos o su sobre escritura.

73
9.7.3 Sincronización de relojes

La correcta fijación de los relojes de las computadoras es importante a fin de garantizar la

exactitud de los registros de auditoria que pueden resultar necesarios para realizar
investigaciones o como prueba en casos legales o disciplinarios. Los registros de auditoria
inexactos pueden obstruir tales investigaciones y dañar la credibilidad de dichas pruebas.

En los casos en que un computador o un elemento para comunicaciones cuenta con el

funcionamiento de u reloj en tiempo real, el mismo debería ser fijado según una pauta
previamente acordada, pro ejemplo Hora Universal Coordinada (UCT) u hora estándar
local. Dado que algunos relojes pueden brindar la hora en forma incorrecta con el tiempo,
debería existir un procedimiento que verifique y corrija cualquier variación significativa.

9.8 Computación móvil y teletrabajo

Objetivo: Garantizar la seguridad de la información al usar computación móvil y sistemas

de tele trabajo.

La protección requerida debería resulta compatible con los riesgos que causan estos formas
específicas de trabajo. Al usar computación móvil, se deberían considerar los riesgos de
trabajar en un contexto desprotegido aplicándose al efecto la protección pertinente. En el
caso del tele trabajo, la organización debería proteger el sitio donde se realiza el tele trabajo
y garantizar que se den las condiciones que permitan esta forma de trabajo.

9.8.1. Computación móvil

Al usar computación móvil, por ejemplo, libretas de mano, computadoras manuales y

portátiles y teléfonos móviles, se debería tener especial cuidado en garantizar que no se
ponga en peligro la información de la empresa. Se debería adoptar una política formal que
tome en cuenta los riesgos del trabajo con computación móvil, en especial en situaciones de
desprotección. Por ejemplo, dicha política debería incluir requisitos de protección física,
controles de acceso, técnicas criptográficas, resguardo de archivos y protección antivirus.
Esta política debería incluir asimismo normas y asesoramiento con respecto a la conexión
de computadoras móviles a redes y guía sobre el uso de dichas computadoras en lugares
públicos.

Se debería tener cuidado en el cuidado de computación móvil en lugares públicos, salas de

reuniones y otras zonas desprotegidas que se encuentren fuera de las instalaciones de la
organización. Debería haber protección para evitar el acceso no autorizado a la información
guardad y procesada por dichos elementos y su divulgación, por ejemplo mediante el uso
de técnicas criptográficas (véase 10.3).

Es importante que cuando se use computación móvil en lugares públicos se tenga cuidado
en evitar el riesgo de intrusión visual por parte de personas no autorizadas. Deberían existir
procedimientos que brinden protección contra la acción de programas ilícitos los cuales
deberían encontrarse actualizados (véase 8.3). Se debería contar con equipo que permite el

74
resguardo rápido y fácil de la información. Estos resguardos deberían proporcionar debida
protección frente, por ejemplo, al robo o pérdida de información.

Se debería brindar la protección debida al uso de computación móvil conectada a redes. El

acceso desde lugares lejanos a información de la empresa por intermedio de la red pública y
mediante el uso de computación móvil solamente se debería producir después de que se
haya producido una identificación y autenticación exitosa y si existieren mecanismos de
control de acceso adecuados (véase 9.4).

La computación móvil también deberían contar con protección física frente a robo,
especialmente cuando quede, por ejemplo, en aut0móviles y otras medios de transporte,
habitaciones de hotel, centros de conferencia y salas de reuniones. El equipo que contenga
información confidencial, importante y / o crítica para la empresa no debería quedar sin
custodia y, cuando sea posible, debería ser colocado bajo llave o con cerraduras especiales
que lo aseguren. Para mayor información respecto de la protección física del equipo móvil
ver 7.2.5.

Debería capacitarse al personal en el uso de computación móvil a los efectos de

incrementar su conciencia respecto de los riesgos adicionales que emergen de esta forma de
trabajo y acerca de los controles que deberían instrumentarse.

9.8.2. Teletrabajo

El tele trabajo usa la tecnología de las comunicaciones para permitir que el personal trabaje
fuera de la organización alejado de su sitio físico de trabajo. Debería existir protección
adecuada del sitio de tele trabajo frente a robo del equipo y la información divulgación
indebida de la información, acceso no autorizado desde lugares remotos a los sistemas
internos de la organización o uso indebido de los mismos. Es importante que el tele trabajo
sea autorizado y controlado por la administración y que se existan disposiciones que
reglamenten este tipo de trabajo.

Las organizaciones deberían la posibilidad de desarrollar políticas, procedimientos y pautas

de control de las actividades de tele trabajo. Las organizaciones solamente deberían
autorizar las actividades de tele trabajo en caso que estén conformes en cuanto a la
existencia de medidas y controles de seguridad y que los mismos cumplen con la política de
seguridad de la organización. Se debería tener presente lo siguiente:

a) la seguridad física existente en el sitio de tele trabajo, tomando en cuenta la

seguridad física del edificio y el contexto local;
b) la propuesta en materia de marco para el tele trabajo:
c) los requisitos en cuanto a seguridad en las comunicaciones, teniendo en cuenta
la necesidad de acceso remoto a los sistemas internos de la organización, la
confidencialidad de la información a la cual se tendrá acceso y el vínculo de
comunicaciones y confidencialidad del sistema interno:
d) la amenaza de acceso no autorizado a la información o recursos por personas
ajenas que usen el sistema, por ejemplo, la familia y los amigos.

75
Los controles y acuerdos que se consideren deberían incluir lo siguiente:

a) el suministro de equipo o muebles adecuados para las actividades de tele trabajo;

b) definición del trabajo permitido, horas de trabajo, clasificación de la
información que se pueda tener y sistemas y servicios internos a los cuales tenga
acceso el tele trabajador;
c) suministro de equipo adecuado para comunicarse, con inclusión de métodos que
garanticen el acceso remoto;
d) seguridad física;
e) normas y guía para el acceso de la familia o visitantes al equipo y la
información;
f) suministro de computadoras y programas así como asistencia técnica y
mantenimiento;
g) procedimientos de resguardo de archivos y continuidad de la tarea;
h) auditoria y verificación de la seguridad;
i) revocación de la autorización, derechos de acceso y devolución del equipo en
caso de cese de las actividades de tele trabajo.

10. DESARROLLO Y MANTENIMIENTO DE SISTEMAS

10.1 Requisitos de seguridad de los sistemas

Objetivo: Garantizar que la seguridad se encuentre incorporada en los sistemas

informáticos con inclusión de la infraestructura, aplicaciones comerciales y aplicaciones
para el usuario. El diseño e instrumentación del proceso comercial que respalda la
aplicación o servicio puede ser crucial en materia de seguridad. Los requisitos de seguridad
deberían encontrarse identificados y acordados con anterioridad al desarrollo de los
sistemas informáticos.

Todos los requisitos de seguridad, con inclusión de la necesidad de medidas de emergencia,

deberían encontrarse identificados en la fase de establecimiento de los requisitos de un
proyecto y justificados, convenidos y documentados como parte del perfil global del
sistema informático de la empresa.

10.1.1. Análisis y especificaciones de los requisitos de seguridad

Las declaraciones de requisitos de la empresa respecto de nuevos sistemas y mejoras en los

existentes deberían especificar los requisitos de control. Dichas especificaciones deberían
considerar la inclusión de controles automatizados en el sistema y la necesidad de contar
con controles manuales como apoyo. Similares consideraciones deberían aplicarse al
evaluar los paquetes de programas para aplicaciones de la empresa. Si se considera
adecuado, la administración podrá desear usar productos certificados y evaluados en forma
independiente.

76
Los requisitos y controles de seguridad deberían ser el reflejo del valor que la empresa
asigna a los activos informáticos involucradas sy del daño potencial que la empresa pueda
experimentar a resultas de falla o ausencia de medidas de seguridad. El marco de análisis de
los requisitos de seguridad e identificación de los controles para cumplirlos lo realiza la
evaluación del riesgo y su administración.

Los controles introducidos en la etapa de diseño son significativamente más baratos de

instrumentar y mantener que los que se incluye durante la fase de instrumentación o con
posterioridad a la misma.

10.2 Seguridad en los sistemas de aplicaciones

Objetivo: Impedir pérdidas, modificaciones o uso indebido de datos del usuario en los
sistemas de aplicaciones.

Se deberían diseñar controles adecuados y rutas de auditoria o registros de actividades que

se incluyan en los sistemas de aplicaciones inclusive aplicaciones del usuario puestas por
escrito. Se deberían incluir la validación de los datos ingresados, su procesamiento interno
y salida de los mismos.

Pueden ser necesarios controles adicionales para sistemas que procesan, o influyan, en
activos críticos, valiosos o confidenciales de la organización. Dichos controles deberían ser
determinados en función de los requisitos de seguridad existentes y de la evaluación que se
haga del riesgo.

10.2.1 Validación de datos ingresados.

Los ingresos de datos en los sistemas de aplicaciones deberían ser validados para garantizar
que sean correctos y adecuados. Se deberían utilizar verificaciones al ingreso de
operaciones de la empresa, datos permanentes (nombres y direcciones, límites al crédito,
números de referencia de clientes) y cuadros de parámetros (precios de venta, tipos de
conversión monetarias, tasas impositivas). Se deberían tener presente los controles
siguientes:

a) Verificaciones duales o de otro tipo a los ingresos de datos a fin de detectar los
errores siguientes;

1) valores fuera de lugar;

2) caracteres inválidos en los campos de datos;
3) datos incompletos o faltantes;
4) exceso en los límites de volúmenes de datos superior e inferior;
5) datos de control incongruentes o carentes de autorización.

b) revisión periódica del contenido de campos o archivos de datos fundamentales a

los efectos de confirmar su validez e integridad;

77
 c) inspección de documentos de ingreso en copia dura para detectar cualquier
cambio no autorizado en los datos ingresados (todos los cambios en los
documentos para el ingreso de datos deberían contar con autorización);
d) procedimientos para responder frente a errores de validación;
e) procedimientos para verificar la plausibilidad de los datos ingresados;
f) definición de las responsabilidades de todo el personal involucrado en el proceso
de ingreso de datos.

10.2.2 Control de Procesamiento Interno

10.2.2.1 Áreas de Riesgo

Los datos que han sido ingresados correctamente pueden alterarse por errores de
procesamiento o actos deliberados. Deberían incorporarse a los sistemas verificaciones de
validación para detectar dichas alteraciones. El diseño de las aplicaciones debería
garantizar que se instrumenten restricciones a los efectos de minimizar el riesgo de que se
produzcan fallas de procesamiento que conduzcan a una pérdida de integridad. Las áreas
específicas a considerar incluyen:
a) el uso y ubicación en los programas de funciones de incorporación y eliminación a
fin de instrumentar cambios en los datos;
b) procedimientos destinados a impedir que los programas funcionen en un sentido
equivocado o que sigan funcionando después de producida una falla en el
procesamiento previo (véase también 8.1.1.);
c) uso de programas correctos a fin de lograr la recuperación de fallas y garantizar el
procesamiento correcto de los datos.

10.2.2.2 Verificaciones y Controles

Los controles requeridos dependerán de la naturaleza de la aplicación y del impacto en la

empresa debido a cualquier corrupción en los datos. Se incluyen a continuación algunos
ejemplos de verificaciones que pueden incorporarse.

a) controles de sesiones o grupos de operaciones a fin de conciliar los saldos de los

archivos de datos con las actualizaciones en las operaciones;
b) controles de saldos para verificar los saldos de apertura con los saldos de cierre
previos vale decir:

1) controles de ejecución;
2) totales para la actualización de archivos;
3) controles de programas;

c) validación de datos generados por el sistema (véase 10.2.1);

d) verificaciones de la integridad de los datos o de la descarga de programas o su
carga entre computadoras centrales y aquellos ubicado en sitios remotos (véase
10.3.3);
e) totales criptográficos de registros y archivos;

78
 f) verificaciones destinadas a garantizar que los programas de aplicaciones sen
ejecutados en el tiempo correcto;
g) verificaciones para garantizar que los programas sean ejecutados en el orden
correcto y terminen en caso de falla y que todo ulterior procesamiento se
detenga hasta que se produzca la resolución del problema.

10.2.3 Autenticación de mensajes

La autenticación de mensajes es una técnica usada para detectar cambios no autorizados o

corrupción en el contenido de un mensaje transmitido electrónicamente. Se puede
instrumentar en el soporte físico o en los programas que constituyen el soporte de un
aparato de autenticación de mensajes físicos o en un algoritmo del programa.

Se debería considerar contar con autenticación de mensajes para las aplicaciones cuando
existe la necesidad en virtud de consideraciones de seguridad de proteger la integridad del
contenido del mensaje, por ejemplo en el caso de transferencias electrónicas de fondos,
especificaciones, contratos, propuestas etc. De gran importancia u otros intercambios
electrónicos de datos de similares características. Se debería llevar a cabo una evaluación
de los riesgos de seguridad a fin de determinar si se requiere la autenticación del mensaje y
para identificar el método más adecuado para llevarla a cabo.

La autenticación de mensajes no tiene por fin proteger los contenidos de un mensaje frente
a su divulgación no autorizada. Se pueden usar técnicas criptográficas (véase 10.3.2 y
10.3.3) como medio adecuado para instrumentar la autenticación de mensajes.

10.2.4 Validación de egreso de datos

Los datos egresados de un sistema de aplicaciones deberían ser validados a fin de garantizar
que el procesamiento de la información almacenada sea correcto y adecuado a las
circunstancias. Comúnmente, los sistemas se construyen sobre la premisa de que producida
la validación, verificación y pruebas adecuadas, los datos que egresen siempre serán
correctos. No siempre es así. La validación de los datos egresados puede incluir:

a) verificación de probabilidad para probar si los datos egresados resultan

razonables;
b) controles de conciliación para garantizar que todos los datos han sido
procesados;
c) suministro de información suficiente para que un lector o sistema de
procesamiento subsiguiente determinar la exactitud, totalidad, precisión y
clasificación de la información;
d) procedimientos de respuesta a las pruebas de validación de egreso de datos;
e) definición de las responsabilidades de todo el personal involucrado el proceso de
egreso de datos.

79
10.3 Controles criptográficos

Objetivo: Proteger la confidencialidad, autenticidad o integridad de la información.

Los sistemas y técnicas criptográficas deberían ser usados para proteger la información que
se considere en riesgo y respecto de la cual otros controles no proporcionen protección
adecuada.

10.3.1 Política para el uso de los controles criptográficos

La decisión respecto de si es adecuado contar con una solución criptográfica debería ser
vista como parte de un proceso más amplio de evaluación de riesgos y selección de
controles. La evaluación del riesgo debería ser llevada a cabo a fin de determinar el nivel de
protección que se deba brindar a la información. Esta evaluación puede entonces ser usada
para determinar si es adecuado contar con un control criptográfico, qué tipo de control se
deba aplicar y a qué fines y sobre qué procesos de la empresa.

La organización debería desarrollar una política para el uso de controles criptográficos

destinados a la protección de su información. Dicha política es necesaria a fin de maximizar
los beneficios y minimizar los riesgos de usar técnicas criptográficas y para evitar el uso
inadecuado o incorrecto. Al desarrollar dicha política, se debería tener en cuenta lo
siguiente:

a) el enfoque administrativa con respecto al uso de controles criptográficos en la

organización, inclusive respecto de los principios generales bajo los cuales se
debería proteger la información de la empresa;
b) el enfoque frente a la administración de las claves, inclusive sobre los métodos a
utilizar para enfrentar la recuperación de información encirptada en el caso de
claves, pérdidas, dañadas o en peligro;
c) roles y responsabilidades;
d) instrumentación de la política:
e) administración de claves;
f) determinación del nivel adecuado de protección criptográfica;
g) normas a adoptar para lograr la instrumentación eficaz en toda la organización
(solución a emplear respecto de los procesos de la empresa).

10.3.2 Encriptación

La encriptación es una técnica criptográfica que se puede usar para proteger la

confidencialidad de la información. Se la debería tener en cuenta respecto de la protección
de información confidencial o crítica.

En base a una evaluación del riesgo, se debería identificar el nivel necesario de protección
tomando en cuenta el tipo y calidad de algoritmo de encriptación usado y la longitud de las
claves criptográficas utilizadas.

80
Al instrumentar la política criptográfica de la organización, se deberían tener presente las
reglamentaciones y restricciones nacionales que puedan ser de aplicación al uso de técnicas
criptográficas en diferentes partes del mundo y a temas relacionados con el flujos
transnacionales de información encriptada. Además, se deberían tener presente los
controles de aplicación a la exportación e importación de tecnología criptográfica (véase
asimismo 12.1.6).

Se debería buscar el consejo de los especialistas para identificar el nivel adecuado de

protección, seleccionar los productos adecuados que brinden el nivel de protección
requerida y la instrumentación de un sistema seguro de administración de claves (véase
también 10.3.5). Además, puede ser necesario contar con asesoramiento legal respecto de
las leye3s y reglamentaciones de aplicación al uso que la organización pretenda hacer de la
encriptación.

10.3.3 Firmas digitales

Las firmas digitales proporcionan un medio de protección de la autenticidad e integridad de

los documentos electrónicos. Por ejemplo, se los puede utilizar en el comercio electrónico
donde hay necesidad de verificar quién ha firmado un documento electrónico y controlar si
los contenidos del documento firmado han sido modificados.

Las firmas digitales pueden ser aplicadas a cualquier forma de documento que se procese
electrónicamente, por ejemplo se pueden usar para firmar pagos electrónicos, transferencias
de fondos, contratos y convenios. Las firmas digitales pueden ser instrumentadas usando
una técnica criptográfica basada en un para de claves con relación única respecto de las
cuales una clave se usa para crear una firma (la clave privada) y la otra para verificar la
firma (la clave pública).

Se debería tener cuidado en proteger la confidencialidad de la clave privada. Esta clave

debería ser mantenida en secreto puesto que cualquiera que tenga acceso a la misma puede
firma documentos, pro ejemplo, pagos, contratos, por ende falsificando la firma del titular
de dicha clave. Además, la protección de la integridad de la clave pública también es
importante. Esta protección es brindada mediante el uso de un certificado de clave pública
(véase 10.3.5).

Se necesita tener en cuenta el tipo y calidad del algoritmo de la firma usada y la longitud
de las claves a utilizar. Las c,.aves criptográficas usadas para firmas digitales deberían ser
diferentes de las empleadas para encriptación (véase 10.3.2).

Al usar firmas digitales, se debería tener en cuenta cualquier disposición legal pertinente
que describa las condiciones bajo las cuales una firma digital es legalmente vinculante. Por
ejemplo, en el caso del comercio electrónico, es importante saber la situación legal de las
firmas digitales. Puede ser necesario tener contratos vinculantes u otros acuerdos que
respalden el uso de firmas digitales en caso de que el marco legal no resulte adecuado. Se
debería buscar asesoramiento legal con respecto a las leyes y reglamentaciones que puedan
ser de aplicación al uso que la organización intente hacer de las firmas digitales.

81
10.3.4 Servicio de pruebas irrefutables

Se deberían utilizar los servicios de pruebas irrefutables cuando sea necesario dirimir
controversias acerca de si un hecho o acción ha ocurrido o no, por ejemplo un litigio que
involucre el uso de una firma digital en un contrato o pago electrónico. Estos servicios
pueden ayudar a determinar la prueba para substanciar si sucedió un determinado hecho o
acción, por ejemplo, la negativa a enviar una instrucción firmada digitalmente usando el
correo electrónico. Estos servicios se fundamentan en el uso de las técnicas de encriptación
y firma digital (véase también 10.3.2 y 10.3.3).

10.3.5 Administración de claves

10.3.5.1. Protección de claves criptográficas

La administración de las claves criptográficas es esencial para lograr un uso eficaz de las
técnicas criptográficas. Cualquier peligro o pérdida que afecte a las claves criptográficas
puede comprometer la confidencialidad, autenticada y / o integridad de la información. El
sistema de administración debe respaldar el uso que la organización haga de los distintos
tipos de técnicas criptográficas a saber:

a) las tendencias de claves secretas en que dos o más partes comparten la misma
clave y se usa tanto para encriptar como para descifrar información. Esta clave
tiene que mantenerse en secreto pues cualquier que tenga acceso a la misma
podrá descifrar la información encriptada de esa manera o introducir
información no autorizada.
b) Técnicas de clave públicas en que cada usuario tiene un par de claves, una clave
pública (que puede ser revelada a cualquiera) y una clave privada (que tiene que
ser mantenida en secreto). Las técnicas de claves públicas pueden ser usadas
para encriptar (véase 10.3.2) y producir firmas digitales (véase 10.3.3)

Todas las claves deberían encontrarse protegidas frente a modificación y destrucción y las
claves secretas y privadas tienen que contar con protección frente a divulgación no
autorizada. Las técnicas criptográficas también pueden ser usadas a tal fin. Se debería
utilizar protección física para proteger el equipó usado para generar, guardar y archivar
claves.

10.3.5.2 Normas, procedimientos y métodos

Un sistema de administración de claves se debería basar en un conjunto de normas,

procedimientos y métodos seguros previamente convenidos a los efectos de:

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

b) genera y obtener certificados de claves públicas;
c) distribuir claves a usuarios, explicando inclusive la forma de activarlas al ser
recibidas.

82
 d) Almacenar las claves, e informar la forma en que los usuarios autorizadas
obtendrá acceso a las mismas;
e) Modificar o actualizar claves inclusive las normas de modificación de las claves
y su empelo;
f) Enfrentar el problema de la claves en peligro:
g) Revocar claves inclusive la forma de su retiro y desactivación, por ejemplo, en
caso de que las claves han sido comprometidos o cuando un usuario deje una
organización (en cuyo caso las claves deberían ser archivadas);
h) Recuperar claves perdidas o corrompidas como parte de la administración de la
empresa, por ejemplo, recuperación de información encriptada;
i) Activar las claves, por ejemplo, respecto de la información archivado o
resguardada;
j) Destruir las claves;
k) Registrar y auditar las actividades relacionadas con la administración de claves.

A fin de reducir la probabilidad de riesgo, las claves deberían contar con fechas de
activación y desactivación definidas de modo que solamente puedan ser usadas durante un
período limitado de tiempo. Este período de tiempo debería depender de las circunstancias
bajo las cuales se use el control criptográfico y la percepción del riesgo.

Se puede tener que considerar la instrumentación de procedimientos para el manejo de

pedidos legales de acceso a las claves criptográficas, por ejemplo, puede ser necesario
facilitar la información encriptada en forma descifrada como prueba en un caso judicial.

Además del tema de la seguridad de las claves privadas y secretas, también se debería tener
en cuenta la protección de las claves públicas. Existe la amenaza de que alguien falsifique
una firma digital mediante el reemplazo de la clave pública del usuario por la propia. Este
problema se encara con el uso de un certificado de clave pública. Estos certificados
deberían ser emitidos en forma tal que vincula en forma univoca la información relacionada
con el titular del par de clave privada y pública con la clave pública. Por lo tanto, es
importante que el proceso de administración que origine estos certificados sea confiable.
Este proceso normalmente es llevado a cabo por una autoridad de certificación que debe ser
una organización reconocida que posea controles y procedimientos que brinden el grado
requerido de confianza.

Los contenidos de los convenios de nivel de servicios o contratos con proveedores externos
de servicios criptográficos, por ejemplo, los celebrados con una autoridad de certificación,
deberían abarcar temas tales como la responsabilidad legal, confiabilidad de los servicios y
tiempos de respuesta para la prestación de los servicios (véase 4.2.2).

10.4 Seguridad de los archivos del sistema

Objetivo: Garantizar que los proyectos informáticos y actividades de apoyo sean llevados a
cabo en forma seguro. Se debería controlar el acceso a los archivos del sistema.
El mantenimiento de la integridad del sistema debería ser responsabilidad de la función
usuario o grupo de desarrollo al cual pertenezca el sistema o programa de aplicación

83
10.4.1 Control de programas operativos.

Se debería controlar la instrumentación de los programas a utilizar en los sistemas

operativos. A fin de minimizar el riesgo de corrupción de los sistemas operativos, se
deberían tener en cuenta los controles que se enumeran a continuación:

a) actualización de las bibliotecas de programas operativos se debería realizar

solamente a través de bibliotecario nombrado al efecto que cuente con la debida
autorización de la administración (véase 10.4.3);
b) en caso de ser posible, los sistemas operativos solamente deberían poseer código
ejecutable;
c) el código ejecutable no debería instrumentarse en un sistema operativo hasta
tanto se cuente con pruebas de que se o ha probado con éxito y se ha obtenido la
aceptación del usuario y que se han actualizado las correspondientes bibliotecas
de origen de los programas;
d) se debería llevar un registro de auditoria con todas las actualizaciones
correspondientes a las bibliotecas de programas operativos;
e) se deberían retener las versiones anteriores del programa como medida de
contingencia.

Los programas proporcionados por el vendedor usados en los sistemas ope5rativos deberían
ser mantenidos con apoyo de dicho proveedor. Cualquier decisión de actualizar el programa
debería tomar en cuenta la seguridad de la nueva versión, es decir la introducción de nuevas
funciones de seguridad o el número y gravedad de los problemas de seguridad que afecten
esta versión. Se deberían efectuar arreglos parciales de los programas cuando contribuyan a
eliminar o reducir las debilidades en materia de seguridad.

Los proveedores tendrán acceso físico o lógico a efectos de brindar apoyo solamente en
caso necesario y con aprobación de la administración. Las actividades del proveedor
deberían ser verificadas.

10.4.2 Protección de los datos de prueba del sistema

Los datos de prueba deberían ser protegidos y controlados. Las pruebas de aceptación y del
sistema normalmente exigen volúmenes considerables de datos de prueba que se acerquen
lo más posible a los datos operativos. El uso de bases de datos operativas que contengan
información personal debería ser evitado. Si se usa dicha información se la debería
despersonalizar previamente. Se deberían aplicar los controles siguientes a fin de proteger
los datos operativos cuando se usen a los fines de efectuar pruebas.

a) los procedimientos de control de acceso, que se apliquen a sistemas de aplicaciones

operativas deberían también aplicarse a los sistemas de aplicaciones para pruebas;
b) debería contarse con autorización separada cada vez que se copie información
operativa en un sistema de aplicación para pruebas;
c) la información operativa debería ser borrada de un sistema de aplicación para
prueba inmediatamente después de que se complete la prueba;

84
 d) la copia y uso de información operativa debería ser registrada a fin de permitir su
seguimiento mediante auditoria.

10.4.3 Control del acceso a la biblioteca de origen de los programas

A fin de reducir las posibilidades de que se produzca corrupción en los programas de

computación, se debería mantener un control estricto sobre el acceso a bibliotecas de origen
de programas de la manera siguiente (véase también 8.3)

a) cuando sea posible, las bibliotecas de origen de los programas no deberían estar en
los sistemas operativos;
b) Se debería nombrar un bibliotecario de programa para cada aplicación;
c) El personal de apoyo informático no debería tener acceso irrestricto a las bibliotecas
fuente de los programas.
d) Los programas bajo desarrollo o mantenimiento no deberían encontrarse en
bibliotecas de origen de programas operativos;
e) La actualización de bibliotecas de origen de programas y la emisión de orígenes de
programa a los programadores será realizada solamente por el bibliotecario
nombrado que cuente con autorización del administrador de apoyo informático de la
aplicación.
f) Las listas de programas deberían ser guardadas en lugar seguro (véase 8.6.4);
g) Se debería mantener un registro de auditoria de todos los accesos a las bibliotecas
de origen de los programas.
h) Las versiones antiguas de programas de origen deberían ser archivadas, indicándose
claramente las fechas y horas precisas en que funcionaban, junto con la totalidad de
los programas de apoyo, control de tareas, definiciones de datos y procedimientos;
i) El mantenimiento y copia de las bibliotecas de origen de los programas deberían
estar sujetos a procedimientos estrictos de control de cambios (véase 10.4.1).

10.5 La seguridad en los procesos de desarrollo y apoyo

Objetivo: Mantener la seguridad de los programas de los sistemas de aplicación y de la

información.

Proyectar y apoyar contextos bajo estricto control.

Los administradores responsables de los sistemas de aplicaciones deberían también
responsabilizarse por la seguridad del proyecto o del contexto de apoyo. Deberían
garantizar que todos los cambios que se vayan a introducir a los sistemas sean examinados
para verificar que pon ponen en peligro la seguridad sea del sistema o del contexto
operativo.

85
10.5.1 Procedimientos para controlar los cambios

A fin de minimizar la corrupción de los sistemas informáticos, debería haber control

estricto sobre la instrumentación de cambios. Los procedimientos formales de control de
cambios deberían ser aplicados. Se deberían garantizar que los procedimientos de control y
seguridad no sean puestos en peligro, que los programadores de apoyo tengan acceso
solamente a las partes del sistema a las cuales necesitan acceder debido a su trabajo y que
se obtenga acuerdo forma y aprobación para la introducción de cualquier cambio. El
cambio del programa de aplicaciones puede tener influencia en el contexto operativo.
Donde sea practicable, se deberían integrar las aplicaciones y los procedimientos de control
de cambios operativos (véase también 8.1.2). El proceso debería incluir lo siguiente:

a) mantenimiento de un registro previamente acordado de niveles de autorización;

b) garantía de que los cambios sean solicitados por usuarios autorizados;
c) revisión de los controles y procedimientos de integridad a fin de garantizar que no
se vean comprometidos por los cambios:
d) identificación de todos los programas de computación, información, bases de datos
y discos rígidos que tengan que ser modificados.
e) La obtención de aprobación formal de propuestas detalladas antes de la iniciación
de trabajos;
f) Garantía de que el usuario autorizado acepta los cambios antes de que se produzca
cualquier instrumentación;
g) Garantía de que la instrumentación se lleve a cabo con mínima interrupción de las
tareas de la empresa;
h) Garantía de que la documentación del sistema sea actualizada al finalizar cada
cambio y que la documentación antigua sea archivada o eliminada:
i) Mantenimiento de un control de versión para todas las actualizaciones de
programas;
j) Mantenimiento de una ruta de auditoria para todas las solicitudes de cambios;
k) Garantía de que la documentación operativa (véase 8.1.1) y los procedimientos para
el usuario sean cambiados en la forma necesaria para que el cambio resultado
adecuado;
l) Garantía de que la instrumentación de cambios se produzca en el momento correcto
y no perturbe los procesos de la empresa involucrados;

Muchas organizaciones mantienen un contexto en el cual los usuarios prueban los nuevos
programas segregado de los marcos de desarrollo y producción. Esta separación brinda el
medio de controlar los nuevos programas y permite protección adicional para la
información operativa que se emplea a efectos de realizar la prueba.

10.5.2 Revisión técnica de los cambios en el sistema operativo.

Periódicamente es necesario cambiar el sistema operativo, por ejemplo instalando un

programa o partes del mismo de nueva creación. Cuando se producen los cambios, los
sistemas de aplicaciones deberían ser revisados y robados para garantizar que no haya
impacto adverso sobre el funcionamiento o la seguridad. Este proceso debería abarcar:

86
 a) revisión de los procedimientos de integridad y control de aplicaciones a fin de
garantizar que sean puestos en peligro por los cambios que se produzcan en el
sistema operativo;
b) garantía de que el plan anual y presupuesto de apoyo cubrirá las revisiones y
pruebas del sistema resultantes de la introducción de cambios operativos;
c) garantía de que la notificación de cambios en el sistema operativa sea suministrado
con tiempo suficiente para permitir las revisiones oportunas previo a su
instrumentación;
d) garantía que se efectúen los cambios pertinentes en los planes de continuidad
empresaria (véase cláusula 11).

10.5.3 Restricciones a los cambios en los paquetes de programas

Las modificaciones en los paquetes de programas deberían ser desalentadas. En la medida

de lo posible, si se pudiese, los paquetes de programas proporcionados por el vendedor
deberían ser usados sin introducirles modificación alguna. Cuando se considere esencial
modificar un paquete de programas, se deberían tener en cuenta los puntos siguientes:

a) el riesgo de que se pongan en riesgo los controles y procesos de integridad

incorporados;
b) se debería averiguar si se tendrá que contar con el previo asentimiento del
vendedor;
c) la posibilidad de obtener los cambios requeridos del propio vendedor en carácter
de actualizaciones de programas estándar.
d) Influencia del cambio en los casos en que la organización se responsabiliza por
el mantenimiento futuro del programa;

Si se considera indispensable introducir cambios, el programa original debería ser retenido

y los cambios aplicados a una copia claramente identificada. Todos los cambios deberían
ser probado plenamente y documentados de modo que se pueda reaplicar en caso necesario
a futuras actualizaciones del programa.

10.5.4 Canales encubiertos y Código Troyano

Un canal encubierto puede exponer información a través de alguno medio indirecto y

oscuro. Puede activarse mediante el cambio de un parámetro accesible tanto a través de
elementos seguros como inseguros de un sistema de computación o mediante la
información incorporada a la corriente de datos. El Código Troyano tiene por fin afectar un
sistema en una forma no autorizada y no fácilmente notada así como en forma no requerida
por el receptor o usuario del programa. Los canales encubiertos y el código troyano rara vez
ocurren por accidente. En los casos en que los canales encubiertos o el Código Troyano son
un problema, se debería tener en cuenta lo siguiente:

a) los programas deben ser comprados solamente a proveedores conocidos de

buena reputación:

87
 b) los programas que se adquieran deben tener el código de origen a fin de poder
verificarlo;
c) se deben usar productos ya evaluados;
d) se debe inspeccionar el código de origen antes de usar el programa en las
operaciones de la empresa:
e) se debería controlar el acceso al código y su modificación, luego de instalarlo;
f) uso de personal plenamente confiable para trabajar en los sistemas de claves.

10.5.5 Contratación externa del desarrollo de los programas

Cuando se contrate externamente el desarrollo de los programas, se debería tener en cuenta

lo siguiente:

a) acuerdos de licencia, titularidad del código y derechos de propiedad intelectual

(véase 12.1.2);
b) certificación de la calidad y exactitud del trabajo ejecutado;
c) acuerdos de depósito de seguridad en caso de incumplimiento de tercero;
d) derecho de acceso respecto para realizar una auditoria de la calidad y exactitud
del trabajo realizado;
e) requisitos contractuales de calidad del código;
f) prueba previa a la instalación a fin de detectar un código troyano.

88
ADMINISTRACIÓN DE LA CONTINUIDAD DE LA EMPRESA

11.1 Aspectos de la administración de la continuidad de la empresa

Objetivo: Contrarrestar las interrupciones en las actividades de la empresa y proteger

procesos empresariales críticos frente a los efectos de grandes fallas o desastres.

Un proceso de administración de la continuidad de la empresa debería ser instrumentado a

los efectos de reducir la perturbación causada por desastres y fallas de seguridad (que
puedan ser el resultado, por ejemplo, de desastres naturales, accidentes, fallas en los
equipos y acciones deliberadas) a un nivel aceptable mediante una combinación de
controles preventivos y acciones de recuperación.

Las consecuencias de desastres, fallas de seguridad y pérdidas de servicio deberían ser

analizadas. Se deberían desarrollar e instrumentar planes de contigencia que garanticen que
los procesos de la empresa puedan ser reestablecidos dentro de un tiempo propicio. Dichos
planes deberían ser mantenidos y se tendrán que convertir en parte integrante de todos los
procesos administrativos.

La administración de la continuidad de la empresa debería incluir controles para identificar

y reducir riesgos, limitar las consecuencias de los daños provocados por incidentes y
asegurar la reanudación oportuna de las operaciones esenciales.

11.1.1 Proceso de administración de la continuidad de la empresa

Debería contarse con un proceso administrado para desarrollar y mantener la continuidad

de la empresa en toda la organización. Se deberían aunar elementos fundamentales de la de
la administración de la continuidad de la empresa como sigue:

a) comprensión de los riesgos que enfrenta la organización en función de la

probabilidad de que se materialicen y consideración de su impacto; se debería
además identificar y priorizar los procesos de mayor importancia para la
empresa;
b) comprensión del impacto probable de las interrupciones en la empresa (es
importante que se encuentren soluciones tanto para enfrentar incidentes de
menor envergaduras como así también para hacerlos con aquellos incidentes
graves que puedan poner en peligro la viabilidad de la organización) y
determinación de los objetivos de la empresa en materia de procesamiento
informático;
c) consideración de la adquisición de seguros apropiados que formen parte del
proceso de continuidad de la empresa;
d) formulación y documentación de una estrategia de continuidad de la empresa
congruente con los objetivos y prioridades acordados por la misma;

89
 e) formulación y documentación de planes de continuidad de la empresa alineados
con la estrategia establecida;
f) prueba y actualización periódica de los planes y procesos vigentes;
g) garantía de que la administración de la continuidad de la empresa se incluya en
la estructura y en los procesos de la organización. Se debería asignar
responsabilidad de coordinación del proceso de administración para la
continuidad de la empresa a un nivel adecuado dentro de la organización, por
ejemplo al foro de seguridad informática (véase 4.1.1).

11.1.2 Continuidad de la empresa y análisis de su impacto

La continuidad de la empresa debería comenzar por la identificación de hechos que puedan

provocar interrupciones en los procesos de la misma, por ejemplo fallas en los equipos,
inundaciones e incendios. Este estudio debería ser seguido por una evaluación del riesgo
para determinar la influencia de tales interrupciones tanto en términos de escala de daños
como de período para la recuperación. Ambas actividades deberían ser llevadas a cabo con
plena participación de los titulares de los procesos y recursos de la empresa. Esta
evaluación considera todos los procesos de la empresa y no se limita a l procesamiento
informático.

Según los resultados que arroje la evaluación de riesgo, se debería desarrollar un plan
estratégico para determina r en enfoque global frente a la continuidad de la empresa. Luego
de que se haya creado este plan, debería recibir el apoyo de la administración

11.1.3 Redacción e instrumentación de los planes de continuidad

Los planes deberían ser desarrollados a fin de mantener o restablecer las operaciones de la
empresa en las escalas temporales requeridas luego de una interrupción en procesos de
importancia grande para la empresa o de haberse producido fallas en los mismos. El
proceso de planificación de la continuidad de la empresa debería considera lo siguiente:

a) identificación y acuerdo respecto de todas las responsabilidades y

procedimientos de emergencia;

b) instrumentación de procedimientos de emergencia para permitir la recuperación

y restablecimiento dentro de escalas temporales requeridas. Necesita brindarse
especial atención a la evaluación de la dependencia externa de la empresa y los
contratos que se encuentren en vigencia.

c) documentación de los procedimientos y procesos acordados;

d) instrucción adecuada del personal con relación a los procesos y procedimientos

de emergencia acordados con inclusión del tema de la administración de crisis;

e) prueba y actualización de los planes.

90
El proceso de planificación debería centrarse en los objetivos de la empresa, por ejemplo,
restablecimiento de determinados servicios para clientes en un lapso de tiempo aceptable.
Se debería considera contar con los servicios y recursos que permitan que dicho
restablecimiento se produzca inclusive personal, recursos de procesamiento así como
también medidas de emergencia relacionadas con el procesamiento informático.

11.1.4 Marco de planificación de la continuidad de la empresa

Se debería mantener un marco único en los planes de continuidad de la empresa a los

efectos de garantizar que todos los planes sean congruentes e identificar las prioridades en
materia de prueba y mantenimiento. Cada plan de continuidad de la empresa debería
especificar claramente las condiciones para su activación, como también quienes son las
personas responsables de la ejecución de cada elemento del plan. Cuando se identifiquen
nuevas exigencias, se deberían modificar de la manera que resulte pertinente los
procedimientos de emergencia establecidos, por ejemplo planes de evacuación o cualquier
acuerdo de medidas de emergencia vigente.

El marco de planificación de continuidad de la empresa debería tener en cuenta lo

siguiente:

a) las condiciones para activar los planes que describen el proceso a seguir (cómo
evaluar la situación, personas a involucrar, etc.) antes de activar cada uno de los
planes;
b) procedimientos de emergencia que describen las acciones a tomar luego de un
incidente que ponga en peligro las operaciones de la empresa y / o la vida
humana. Dichos procedimientos deberían incluir medidas de administración de
relaciones públicos y un enlace eficaz con las autoridades públicas pertinentes,
por ejemplo, la policía, los bomberos y el gobierno local;
c) procedimientos de emergencia que describan las acciones a tomar para trasladar
las actividades esenciales de al empresa o servicios de apoyo a ubicaciones
temporarias alternativas y para poner nuevamente en funcionamiento los
procesos de la empresa dentro de las escalas temporales requeridas;
d) procedimientos de reanudación que describan las acciones a tomar para volver a
un ritmo de operaciones normales en la empresa.
e) Un programa de mantenimiento que especifique cómo y cuando se probará el
plan y el proceso de mantenimiento del plan;
f) Actividades de concientización y capacitación con el fin de crear comprensión
respecto de los procesos de continuidad de la empresa y garantizar que dichos
procesos sigan siendo eficaces;
g) Responsabilidades de las personas con descripción de las personas responsables
de la ejecución de cada elemento del plan. Según fuere necesario, se nombrarán
alternativas al efecto.

Cada plan debería tener un titular específico. Los procedimientos de emergencia, planes de
emergencia manuales y planes de reanudación deberían ser de responsabilidad de los
titulares de cada proceso o recurso de la empresa que se encuentre involucrado. Los
cuerdos de medidas de emergencia a los fines de contar con servicios técnicos alternativos

91
como ser comunicaciones y procesamiento informático deberían comúnmente ser de
responsabilidad de los prestadores del servicio.

11.1.5 Prueba, mantenimiento y nueva evaluación de los planes de continuidad de la

empresa

11.1.5.1 Prueba de los planes

Puede que se omita probar los planes de continuidad, a menudo debido a la existencia de
suposiciones incorrectas, olvidos o cambios en equipo o personal. Por lo tanto, dichos
planes deberían ser probados en forma periódica para garantizar que se encuentren
actualizados y sean eficaces. Dichas pruebas deberían también garantizar que todos los
miembros del equipo de recuperación y otro personal pertinente sean conscientes de la
existencia de los planes.

El programa de pruebas para la continuidad del plan o los planes deber{a indicar c{como y
cuando cada elemento del plan deba ser probado. Se recomienda probar cada elemento del
plan o los planes con frecuencia. Se deberían emplear diversas técnicas a fin de
proporcionar garantías de que el plan o los planes funcionarán en situaciones reales. Dichas
técnicas incluyen lo siguiente:

a) prueba en gabinete de diversos escenarios (con discusión de las medidas de

recuperación de la empresa a través de ejemplos de interrupciones);
b) simulaciones (especialmente para capacitar a la gente en los roles a asumir en el
manejo de una crisis y de los incidentes posteriores):
c) prueba de recuperación técnica (a fin de garantizar que los sistemas informáticos
pueden ser restablecidos con eficacia);
d) prueba de recuperación en un sitio alternativa (con funcionamiento de los
procesos de la empresa en paralelo con las operaciones de recuperación fuera del
sitio principal);
e) pruebas de líneas de proveedores y servicios (a fin de garantizar que los
servicios prestados externamente y sus productos satisfagan los compromisos
contraídos):
f) ensayos completos (prueba de que la organización, su personal, equipo, sistemas
y procesos pueden enfrentar una interrupción).

Estas técnicas pueden ser usadas por cualquier organización y deberían ser reflejo del
carácter de cada plan de recuperación.

11.1.5.2 Mantenimiento de los planes y nueva evaluación

Los planes de continuidad de la empresa deberían ser mantenidos a través de revisiones y

actualizaciones periódicas destinadas a garantizar su continuada eficacia (véase 11.1.5.1 a
11.1.15.3). Se deberían incluir procedimientos dentro del programa de administración del
cambio en la organización a los efectos de garantizar que los temas atinentes a la
continuidad de la empresa sean encarados de manera adecuada.

92
Se deberían asignar responsabilidades para las revisiones periódicas de cada plan de
continuidad de la empresa; se debería efectuar un seguimiento y actualización adecuada del
plan a través de la identificación de los cambios producidos en las disposiciones de la
empresa que aún no se reflejen en los planes de continuidad de la misma. El proceso formal
de control de los cambios debería garantizar que los planes de actualización sean
distribuidos y reforzadas mediante revisiones periódicas de la totalidad del plan.

a) personal;
b) direcciones o números telefónicos;
c) estrategia de la empresa;
d) ubicación, instalaciones y recursos;
e) legislación;
f) contratistas, proveedores y clientes principales:
g) procesos y procesos nuevos o retirados;
h) riesgo (operativo y financiero).

12 CUMPLIMIENTO

12.1 Cumplimiento con los requisitos legales

Objetivo: Evitar violación de cualquier ley criminal o civil, de disposiciones legales,

reglamentarias o contractuales, de obligaciones o cualquier requisito en materia de
seguridad.
El diseño, funcionamiento, uso y administración de un sistema informático puede estar
sujeto a requisitos reglamentarios, legal y contractuales en materia de seguridad.
Se debería buscar asesoramiento sobre requisitos legales específicos ante los asesores
legales de la organización o expertos legales debidamente calificados. Los requisitos de
índole legislativa varían de país en país y con respecto a la información creada en un país
que se transmite a otro(por ejemplo, los flujos de datos transnacionales).

12.1.1 Identificación de la legislación aplicable

Todos los requisitos legales, reglamentarios y contractuales deberían ser definidos

explícitamente y documentada en cada sistema informático. Los controles específicos y
responsabilidades individuales en cuanto al cumplimiento de dichos requisitos deberían
encontrarse claramente definidos y documentados.

12.1.2 Derechos de Propiedad Intelectual (IPR)

12.1.2.1 Derecho de autor

Se deberían instrumentar procedimientos adecuados para garantizar el cumplimiento de

restricciones legales sobre el uso de material con respecto al cual puedan existir derechos
de propiedad intelectual como ser derecho de autor, derecho de diseño, marcas de

93
comercio. La violación del derecho de autor puede conducir a acciones legal que involucren
eventualmente procedimientos penales.

Los requisitos legislativos, reglamentarios y contractuales pueden imponer restricciones a

la copia de material cubierto por derechos de propiedad. En especial, dichos requisitos
pueden exigir que solo el material que sea desarrollado por la organización y que cuente
con licencia o sea proporcionado por el diagramador a la organización, pueda ser utilizado.

12.1.2.2 Derecho de Autor sobre los Programas

Los programas cubiertos por derechos de autor son comúnmente provisto en virtud de un
convenio de licencia que limita el uso de los productos a máquinas determinadas y puede
limitar la copia a la creación de copias de resguardo del material solamente. Se deberían
considerar los controles siguientes:

a) publicidad de una política de cumplimiento con los derechos de autor sobre los
programas que defina el uso legal de programas y productos informáticos;
b) emisión de normas de procedimientos para la adquisición de programas;
c) conciencia de la necesidad de mantener los derechos de autor sobre los programas y
las políticas de adquisición y de notificación la intención de tomar medidas
disciplinarias contra el personal que viole dichos derechos;
d) mantenimiento de registros de activos adecuados;
e) mantenimiento de prueba de titularidad de licencias, discos maestros y manuales,
etc;
f) instrumentación de controles destinados a garantizar que el número máximo de
usuarios permitido no sea superado;
g) ejecución de verificaciones para que solo se instalen programas y productos bajo
licencia debidamente autorizados;
h) creación de una política de mantenimiento de condiciones adecuadas de licencia;
i) creación de una política de disposición o transferencia de programas a otros;
j) uso de herramientas de auditoria adecuadas;
k) cumplimiento de los términos y condiciones de los programas e informaciones
obtenidas de redes públicas (véase también 8.7.6).

12.1.3 Salvaguardia de los registros de la organización

Los registros importantes de una organización debería ser protegidos frente a pérdida,
destrucción y falsificación. Puede ser necesario que algunos registros sean retenidos en
lugar seguro a fin de satisfacer requisitos legales o reglamentarios como también como
apoyo de actividades esenciales para la empresa. Ejemplos de esto son los registros que
puedan resultar necesarios como prueba del funcionamiento de la organización en el marco
de normas legales o reglamentarias o para garantizar la adecuada defensa frente a posibles
acciones civiles o penales o para confirmar la situación financiera de una organización con
respecto a sus accionistas, socios y auditores. El período temporal y el contenido de datos a
retener como información puede ser determinado a través de una ley o reglamentación
nacional.

94
Los registros deberían ser ordenados en categorías según tipo, por ejemplo, registros
contables, bases de datos, registros de transacciones, auditorias y procedimientos
operativos, cada uno de ellos con detalles de los períodos de retención y tipo de medio de
almacenamiento, por ejemplo, papel, microficha, magnético, óptico. Cualquier clave
criptográfica conexa con archivos encriptados o firmas digitales (véase 10.3.2 y 10.3.3)
debería ser guardado en forma segura a disposición de las personas autorizadas cuando
corresponda.

Se debería prestar atención a la posibilidad de degradación de medios usados para el

almacenamiento de registros. Los procedimientos de almacenamiento y manejo deberían
ser instrumentados conforme a las recomendaciones del fabricantes.

En los casos en que se elijan medios de almacenamiento electrónicos, se debería n incluir

procedimientos que garanticen la capacidad de acceso a los datos (tanto a través de medios
de comunicación como de la legibilidad del formato) durante todo el período de retención
como salvaguardia contra pérdida debida a futuros cambios tecnológicos

Los sistemas de almacenamiento de datos deberían ser elegidos de manera tal que los datos
requeridos puedan ser recuperados en forma aceptable para un tribunal de justicia, por
ejemplo que se puedan recuperar todos los registros requeridos en un tiempo y formato
aceptables.

El sistema de almacenamiento y manejo debería garantizar la identificación clara de los

registros y de su período de retención legal o reglamentario. Debería permitir la destrucción
adecuada de los registros luego de dicho período en caso de que no resulten necesarios para
la organización.

A fin de cumplir con estas obligaciones, se deberían tomar las medidas siguientes en el
marco de la organización:

a) Se deberían emitir lineamientos sobre la retención, almacenamiento, manejo y

disposición de registros e información;
b) Se debería redactar un programa de retención con identificación de los tipos de
registros esenciales y el lapso de tiempo de retención;
c) Se debería mantener un inventario de fuentes de información sobre claves.
d) Se deberían instrumentar controles adecuados para la protección de registros e
información esenciales contra pérdida, destrucción y falsificación.

12.1.4 Protección de datos y privacidad de la información personal

Una serie de países ha introducido legislación que impone controles al procesamiento y

transmisión de información personal (en general se trata de información sobre personas que
pueden identificarse a partir de dicha información). Los controles pueden imponer
obligaciones respecto de la recopilación, procesamiento y divulgación de información
personal y puede restringir la capacidad de transferir la misma a otros países.

95
La observancia de la legislación sobre protección de información requiere estructuras de
administración y control. A menudo esto se logra designando a un empleado a cargo de la
protección de la información quién debería constituir una referencia para los
administradores, usuarios y proveedores de servicios respecto de sus responsabilidades
individuales y procedimientos específicos que deberían seguirse. La responsabilidad de
informar al funcionario a cargo de la protección de datos acerca de toda propuesta de
mantener la información personal en un archivo estructurado y de asegurar que conoce los
principios de protección de datos definidos en la legislación aplicable debería recaer en el
propietario de la información.

12.1.5 Prevención del mal uso de los medios de procesamiento informático

Los medios de procesamiento de información de una organización se proporcionan a los

fines comerciales. La administración debería autorizar el uso de los mismos. Todo uso que
se de a los mismos con fines distintos a los comerciales o bien que no estén autorizados por
la administración deberían considerarse como inapropiado. Si se identifica dicha actividad
por medio de controles o de otro modo, debería ponerse en conocimiento del administrador
correspondiente a fin de tomar la medida disciplinaria pertinente.

La legalidad del control del uso varía de un país a otro y puede exigir a los empleados que
informen tales controles o que acuerden los mismos. Debería contarse con asesoramiento
jurídico antes de aplicar los procedimientos de control.

Muchos países cuentan con una legislación para evitar el mal uso de la informática o bien
están en proceso de introducir la misma. Puede constituir un delito penal utilizar una
computadora con fines no autorizados. Por consiguiente, es esencial que todos los usuarios
tengan conciencia del alcance exacto de su alcance permitido. Por ejemplo esto puede
lograrse otorgando a los usuarios una autorización por escrito, cuya copia debería ser
firmada por el usuario y retenida por la organización en forma segura. Los empleados de
una organización, y terceros usuarios, deberían tener conocimiento de que no se permite
acceso alguno excepto el autorizado.

Al conectarse al sistema debería visualizarse un mensaje de advertencia en pantalla

indicando que el sistema al que se intenta acceder es privado y que el acceso no autorizado
no está permitido. El usuario debe tomar conocimiento y actuar en consecuencia a fin de
continuar con el proceso de conexión.

12.1.6 Reglamentación de los controles criptográficos

Algunos países han aplicado acuerdos, leyes, reglamentaciones u otros instrumentos para
controlar el acceso a los controles criptográficos o el uso de los mismos. Tales controles
pueden incluir:

A) la importación y/o exportación de soporte informático físico y magnético

para realizar funciones de criptografía;
B) importación y/o exportación de soporte informático físico y magnético
diseñado para realizar funciones de criptografía adherido al mismo;

96
 C) métodos de acceso obligatorios y discrecionales por parte de los países a la
información encriptada mediante el soporte físico y magnético a fin de
proporcionar la confidencialidad del contenido.

Debería contarse con asesoramiento jurídico a fin de asegurar el cumplimiento de la ley

nacional. Sería conveniente además contar con dicho asesoramiento antes de trasladar la
información encriptada o los controles de criptografía a otro país.

12.1.7 Recopilación de pruebas

12.1.7.1. Normas para las pruebas

Resulta necesario contar con pruebas adecuadas a fin de avalar una medida adoptada contra
una persona u organización. Siempre que esta medida sea de carácter disciplinario en el
ámbito interno, la prueba que se requiera se describirá en los procedimientos internos.

Cuando una acción esté alcanzada por el derecho civil o penal, la prueba que se presente
debería observar las normas de prueba estipuladas en la respectiva ley aplicable o en las
disposiciones del tribunal competente que entienda en la causa. En general, estas
disposiciones abarcan:

a) la admisibilidad de la prueba: si se puede usar o no la prueba ante un tribunal;

b) la carga de la prueba: la calidad e integridad de la prueba;
c) prueba adecuada de que los controles se han realizado en forma correcta y
coherente (por ejemplo, la prueba del control de un proceso) a lo largo del
período en el que la prueba que debe recuperarse fue almacenada y procesada
por el sistema:

12.1.7.2 Admisibilidad de la prueba

A fin de lograr la admisibilidad de la prueba, las organizaciones deberían asegurar que sus
sistemas informáticos cumplan con las normas o códigos de práctica publicados en relación
con la entrega de prueba admisible.

12.1.7.3 Calidad e integridad de la prueba

A fin de lograr la calidad e integridad de la prueba, se requiere un seguimiento de la misma.

En general, tal seguimiento puede determinarse bajo las siguientes condiciones:

a) Para documentos impresos: el original se conserva en forma segura y se registra

quién lo encontró, dónde lo encontró, cuándo lo encontró y quién presenció
dicho descubrimiento. La investigación debería asegurar que no se ha accedido
a los originales sin autorización.
b) Para la información en línea: deberían tomarse copias de todo medio removible,
información sobre discos rígidos o en memoria a fin de asegurar la
disponibilidad. La conexión de todas acciones durante el proceso de copiado

97
 debería mantenerse y el proceso debería realizarse en presencia de un testigo.
Debería mantenerse una copia del medio y de la conexión en forma segura.

Cuando se detecta un incidente por primera vez, no necesariamente puede resultar obvio
que finalice en una acción judicial. Por consiguiente, existe el peligro de que la prueba
necesaria se destruya por accidente antes de que se tome conciencia de la seriedad del
incidente. Resulta aconsejable recurrir a un abogado o a la policía tan pronto como sea
posible en cualquier acción jurídica contemplada y recibir asesoramiento sobre la prueba
requerida.

12.2 Revisiones de la política de seguridad y cumplimiento de las medidas técnicas

Objetivo: Asegurar el cumplimiento de los sistemas en el marco de las políticas y normas

de seguridad de la organización.

La seguridad de los sistemas de información deberían revisarse regularmente.

Dichas revisiones deberían realizarse de conformidad con las políticas de seguridad y las
plataformas técnicas apropiadas y los sistemas informáticos deberían auditarse de acuerdo
con las normas de seguridad aplicables.

12.2.1 Cumplimiento de la política de seguridad

Los administradores deberían asegurar que todos los procedimientos de seguridad dentro
de su área de responsabilidad se llevan a cabo en forma correcta. Además, todas las áreas
dentro de la organización deberían considerarse a la hora de realizar las revisiones regulares
a fin de cumplir con las políticas y normas de seguridad. Estas deberían incluir:
a) sistemas informáticos;
b) proveedores de sistemas;
c) propietarios de información y activos informáticos;
d) usuarios;
e) administración.

Los propietarios de sistemas informáticos (véase 5.1) deberían reforzar las revisiones
regulares del cumplimiento de sus sistemas con políticas de seguridad, normas y otros
requisitos de seguridad apropiados. El control operativo del uso del sistema se describe en
el apartado 9.7.

12.2.2. Verificación del cumplimiento de las medidas técnicas

Los sistemas informáticos deberían verificarse regularmente a fin de comprobar el

cumplimiento de las normas de seguridad aplicables. La verificación del cumplimiento
técnico incluye el análisis de los sistemas operativos a fin de asegurar que los controles de
soporte físico y magnético se han aplicado correctamente. Este tipo de verificación de
cumplimiento requiere la asistencia de personal técnico específico. Un ingeniero en

98
sistemas debería llevarse a cabo la misma en forma manual (recurriendo a herramientas de
soporte magnético, si fuera necesario) o bien a través de un paquete de soporte magnético
automático que genera un informe técnico para ser interpretado posteriormente por un
especialista técnico.

La verificación de cumplimiento también abarca, por ejemplo, la prueba de intrusión, que

debería realizarla un experto independiente contratado específicamente para tal fin. Esto
puede ser útil para detectar vulnerabilidades en el sistema y para verificar hasta qué punto
los controles son efectivos en cuanto a la prevención del acceso no autorizado debido a
tales vulnerabilidades. Debería actuarse con precaución en caso de que la prueba de
intrusión arroje como resultado el compromiso de la seguridad del sistema e
inadvertidamente explote otras vulnerabilidades.

Toda verificación de cumplimiento de medidas técnicas sólo debería llevarse a cabo por
parte de personas competentes autorizadas.

12.3 Consideraciones sobre auditoría del sistema

Objetivo: Maximizar la eficacia y minimizar la interferencia con los procesos de auditoría

de sistemas.

Deberían aplicarse controles a fin de salvaguardar los sistemas operativos y herramientas de

auditoría durante la auditoría del sistema.

Además se requiere protección a fin de salvaguardar la integridad e impedir el mal uso de

las herramientas de auditoría.

12.3.1 Controles de auditoría del sistema

Los requerimientos y actividades de auditoría que incluyen verificaciones de los sistemas

operativos deberían planearse y acordarse minuciosamente a fin de minimizar el riesgo de
disrupciones del proceso comercial. Deberían observarse los siguientes rubros:

a) Deberían acordarse requerimientos de auditoría acordes a una adecuada

administración.
b) Debería acordarse y controlarse el alcance de las verificaciones.
c) Las verificaciones deberían limitarse al acceso de “solo lectura” al soporte
magnético y la información.
d) Todo acceso diferente al de “sólo lectura” al soporte magnético e información
sólo debería permitirse para copias separadas de los archivos del sistema, las que
deberían borrarse cuando finalice la auditoría.
e) Los recursos informáticos para llevar a cabo las verificaciones deberían
identificarse y estar disponibles en forma explícita;
f) Deberían identificarse y acordarse requisitos para procesos especiales o
adicionales.

99
 g) Debería controlarse y conectarse todo acceso a fin de producir una ruta de
referencia;
h) Deberían documentarse todos los procedimientos, requisitos y
responsabilidades.

12.3.2 Protección de las herramientas de auditoría del sistema

El acceso a las herramientas de auditoría del sistema, por ejemplo el soporte magnético o
archivos de datos, deberían protegerse a fin de impedir cualquier posible mal uso del
sistema. Tales herramientas deberían separarse de los sistemas operativos y de desarrollo y
no deberían almacenarse en bibliotecas magnéticas o áreas de usuarios a menos que exista
un nivel apropiado de protección adicional.

100