TRADUCCIÓN

NORMA INTERNACIONALISO/IEC

17799:2000BS 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.

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

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

- DisponibilidadAsegurando 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.

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.

11

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;

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.

12

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

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).

13

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:

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;

14

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:

a) la política general sobre la seguridad informática;b) la protección de activos, incluyendo:

15

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;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.

16

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.

17

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.

18

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.

19

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).

20

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.

21

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.

22

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).

23

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.

24

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.

25

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.

26

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.

27

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;

28

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;

29

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.

30

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;

31

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”.

32

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;

33

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.

34

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.

35

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 problema2) 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);

36

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.

37

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;

38

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.

39

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 computadorab) 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.

40

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);

41

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.;

42

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.

43

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.

44

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.

45

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;

46

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:

47

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);

48

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?

49

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.

50

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);

51

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;

52

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:

53

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;

54

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.

55

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;

56

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;

57

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.

58

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;

59

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.

60

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;

61

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

62

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 9.4.7 y 9.4.8) y para que bloquee el acceso no autorizado conforme a la política de control

63

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.

64

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).

65

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.

66

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.

67

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

68

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.

69

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)

70

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.

71

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.

72

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

73

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.

74

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.

75

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;

76

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;

77

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.

78

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.

79

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.

80

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.

81

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

82

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;

83

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.

84

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:

85

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:

86

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.

87

11 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;

88

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.

89

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

90

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.

91

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

92

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.

93

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.

94

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;

95

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

96

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

97

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.

98

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.

99