Download - Ing. Fernando Alcántar Hernández
INSTITUTO POLITÉCNICO NACIONAL
ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELÉCTRICA
SECCIÓN DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN
REVISIÓN DE NORMAS Y ESTÁNDARES DE SISTEMAS DE GESTIÓN DE
SEGURIDAD DE LA INFORMACIÓN
Trabajo que para obtener el grado de Especialista en Seguridad Informática y
Tecnologías de la Información
P R E S E N T A
Ing. Fernando Alcántar Hernández
Asesor:
Dr. José de Jesús Vázquez Gómez.
Ciudad de México, Junio de 2009
II
ACTA DE REVISIÓN DE TESINA
III
CARTA DE CESIÓN DE DERECHOS
IV
AGRADECIMIENTOS Y DEDICATORIA
Al Dr. José de Jesús Vázquez Gómez:
Quien gracias a su profesionalismo y espíritu institucional, dedicó su valioso
tiempo para realizar el presente trabajo.
A mi esposa:
Por brindarme su enorme apoyo durante todo este tiempo.
V
ÍNDICE GENERAL PRELIMINARES ACTA DE REVISIÓN DE TESINA ............................................................................................ II CARTA DE CESIÓN DE DERECHOS ..................................................................................... III AGRADECIMIENTOS Y DEDICATORIA ................................................................................ IV
ÍNDICE GENERAL .................................................................................................................. V ÍNDICE DE FIGURAS ............................................................................................................ VII ÍNDICE DE TABLAS ............................................................................................................. VII RESUMEN ............................................................................................................................ VIII ABSTRACT ............................................................................................................................ IX
INTRODUCCIÓN. .................................................................................................................... X OBJETIVO GENERAL. ......................................................................................................... XII OBJETIVOS PARTICULARES.............................................................................................. XII JUSTIFICACIÓN. ................................................................................................................. XIII CAPÍTULO I. 1 SISTEMA DE GESTIÓN DE SEGURIDAD INFORMÁTICA (SGSI). 1
1.1 MARCO DE REFERENCIA DEL SGSI. .......................................................................... 1 1.2 DESCRIPCIÓN. .............................................................................................................. 2
1.2.1 Alineación del SGSI a las misiones de la organización y de seguridad de la organización....................................................................................................... 3
1.2.2 Análisis de riesgos. ........................................................................................... 4 1.2.3 Controles de seguridad. .................................................................................... 6
1.2.4 Políticas de seguridad informática. ................................................................. 7 1.2.5 Monitoreo del sistema. ...................................................................................... 8 1.2.6 Recuperación y continuidad del negocio. ....................................................... 9
1.2.7 Cultura de seguridad en la organización. ...................................................... 10 CAPÍTULO II. 12 ISO/IEC 27001:2005. 12 2.1 DESCRIPCIÓN. ............................................................................................................ 12
2.2 El SGSI en ISO/IEC 27001:2005. ................................................................................. 18
CAPÍTULO III. 29 ENISA (EUROPEAN NETWORK AND INFORMATION SECURITY AGENCY). 29 3.1 DESCRIPCIÓN. ............................................................................................................ 29
CAPÍTULO IV. 36 NIST SP 800-53. 36 4.1 MARCO DE REFERENCIA. .......................................................................................... 36
4.1.1. FIPS-199. .......................................................................................................... 37
4.1.2. FIPS-200. .......................................................................................................... 39
4.2 NIST SP 800-53. ........................................................................................................... 40
CAPÍTULO V. 46 DEPARTAMENTO DE DEFENSA DE LOS ESTADOS UNIDOS DE AMÉRICA. 46 5.1 MARCO DE REFERENCIA. .......................................................................................... 46 5.2 DIRECTIVA DEL DoD 8500.01. .................................................................................... 48
VI
5.3 INSTRUCCIÓN DEL DoD 8500.2, IMPLEMENTACIÓN DEL IA. ................................. 52
CAPÍTULO VI. 58 COMPARATIVA DE LOS SISTEMAS DE GESTIÓN DE SEGURIDAD INFORMÁTICA. 58
6.1. DESCRIPCIÓN. ............................................................................................................ 58 6.2. PARÁMETROS DE COMPARACIÓN. .......................................................................... 58 6.3. ALCANCE. .................................................................................................................... 59 6.4. EVALUACIÓN DE RIESGOS. ....................................................................................... 60 6.5. POLÍTICA DE SEGURIDAD. ........................................................................................ 61
6.6. PROCESO DE GESTIÓN. ............................................................................................ 62 6.7. CONTROLES DE SEGURIDAD. .................................................................................. 63 CONCLUSIONES. .................................................................................................................. 66 RECOMENDACIONES. .......................................................................................................... 68 REFERENCIAS BIBLIOGRÁFICAS. ..................................................................................... 69 REFERENCIAS CIBEROGRÁFICAS..................................................................................... 71
VII
ÍNDICE DE FIGURAS Figura 1. Modelo PDCA aplicado a los procesos SGSI. .................................................... 15 Figura 2. Estructura de un SGSI. ......................................................................................... 33 Figura 3. Marco de Administración de Riesgo (Risk Amanagement Framework). .......... 44
ÍNDICE DE TABLAS Tabla 1. Controles de seguridad en ISO/IEC 27001. ........................................................... 25
Tabla 2. Identificadores, familias y clases de controles de seguridad. ............................ 41 Tabla 3. Temas de Control de IA. ......................................................................................... 57 Tabla 4. Comparativa del alcance de los SGSI. .................................................................. 60
Tabla 5. Comparativa de metodología de análisis de riesgos. ......................................... 61 Tabla 6. Comparativa de implementación de políticas de seguridad. .............................. 62
Tabla 7. Comparativa de procesos de gestión. .................................................................. 63
Tabla 8. Comparativa de controles de seguridad. .............................................................. 64
VIII
RESUMEN
En el presente trabajo se lleva a cabo una revisión de cuatro documentos relacionados con
sistemas de gestión de seguridad de la información emitidos por las siguientes
organizaciones: Organización de Estándares Internacionales en su documento ISO/IEC
27001:2005, el Instituto Nacional de Estándares y Tecnología de los Estados Unidos de
América en su publicación especial SP 800-53, la Agencia de Seguridad de la Información y
redes de la Unión Europea y el Departamento de Defensa de los Estados Unidos de América
en su Directiva 8500.01 y en la instrucción 8500.2. El objeto de la revisión es realizar una
comparativa de los controles de seguridad que implementan, en la que se señalen sus
diferencias y se determine cuales serían adecuados a organizaciones de tipo privadas,
gubernamentales y militares.
IX
ABSTRACT
The present study conducts a review of four documents relating to information security
management systems, issued by the following organizations: International Standards
Organization through ISO/IEC 27001:2005, the National Institute of Standards and
Technology of United States of America through Special Publication SP 800-53, European
Network Information Security Agency and the Department of Defense of the United States of
America through Directive 8500.01 and Instruction 8500.02. The purpose of the review is to
conduct a security controls comparative giving their differences and determine which would
be appropriate to private, governmental and military organizations.
X
INTRODUCCIÓN.
En este trabajo se realiza la revisión de algunos estándares y documentación
relativos a la administración de la seguridad informática, con el fin de elaborar
posteriormente una comparativa en la que se resalten los aspectos característicos y
más sobresalientes de cada uno de los documentos revisados y que esto a su vez
sirva como referencia para llevar a cabo la administración de un área de seguridad
informática en una organización.
En el primer capítulo se define el Sistema de Gestión de Seguridad de la
Información, sus características y la importancia de su implementación.
En el capítulo dos se describe el estándar internacional ISO 27001, el cual es de
origen británico y es utilizado en numerosas organizaciones de diferentes países
debido a la importancia que ha adquirido y a su apego a la Organización
Internacional para la Estandarización (International Organization for Standarization,
ISO).
La Agencia de Seguridad de la Información de la Unión Europea (European Network
Information Security Agency, ENISA), es una institución de gran influencia en los
aspectos de seguridad de la información en diferentes países de la Unión Europea,
por lo que se aborda en el capítulo tres de este documento para su revisión.
La Publicación Especial 800-53 del Instituto Nacional de Estándares y Tecnología
(National Institute of Standarts and Technology, NIST) del Departamento de
Comercio de Administración de los Estados Unidos de América, es un documento
XI
que sirve de guía en la aplicación de controles de seguridad informática en
organizaciones gubernamentales de los Estados Unidos de América y se menciona
en el capítulo cuatro.
En el quinto capítulo se habla sobre documentación existente en el Departamento de
Defensa de los Estados Unidos de América, la cual se eligió debido a que
históricamente, se ha observado que las organizaciones militares de los países
desarrollados han tenido gran influencia en el progreso tecnológico.
Posteriormente se elabora una comparativa de los documentos revisados en los
capítulos anteriores y se presenta en el capítulo seis.
Por último, se muestran las conclusiones del presente trabajo y se hacen algunas
recomendaciones.
XII
OBJETIVO GENERAL.
Revisar normas y estándares en materia de gestión de seguridad de la información,
con el fin de señalar sus principales características y que a su vez permita al
administrador de seguridad de Tecnologías de la Información (TI) en una
organización, seleccionar la documentación que mejor se adapte a las necesidades
de su empresa.
OBJETIVOS PARTICULARES.
Revisar normas y estándares nacionales y/o internacionales relativos a Gestión
de Seguridad de la Información.
Señalar las características más sobresalientes de cada uno de los documentos
revisados.
Elaborar una comparativa en la que se señalen las diferencias entre los
estándares seleccionados.
XIII
JUSTIFICACIÓN.
Diferentes organizaciones en la actualidad basan su administración en lo que se
denomina el Gobierno Corporativo, el cual especifica la distribución de los derechos y
responsabilidades entre los diferentes participantes de la organización y provee
también una estructura a través de la cual se establecen los objetivos, los medios
para alcanzarlos y la forma de hacer un seguimiento a su desempeño. Asimismo, se
observa que las organizaciones utilizan de manera cotidiana las Tecnologías de la
Información (TI) con el fin de coadyuvar en el desarrollo de las actividades diarias y
apoyar la obtención de los objetivos planteados. Debido a que las TI son parte
importante en las organizaciones, se denota la existencia de un área responsable de
la administración de su empleo y que algunos autores denominan Gobierno de TI.
Por otro lado, existen riesgos inmersos en el empleo inadecuado de las TI que
pueden afectar la confidencialidad, disponibilidad o integridad de la información. Para
ello, cualquier organización que haga uso de las TI requiere de un área dedicada a la
observación de los aspectos de seguridad informática, con el objeto de mantener un
nivel de riesgo aceptable para la propia organización.
En este sentido, hoy en día existen diferentes soluciones o controles que brindan
seguridad en los sistemas de información de una organización, pero se requiere que
sean administradas adecuadamente, es decir, que se inviertan los recursos
necesarios para la protección de los activos y que se orienten los esfuerzos hacia
aquellos sistemas que presenten mayor riesgo de sufrir pérdida, robo, daño ó
modificación.
XIV
La administración de los recursos y esfuerzos invertidos en la protección de los
activos de TI en una organización se conoce como Sistema de Gestión de Seguridad
de la Información (SGSI).1 Existen organizaciones que eligen la adquisición de
soluciones de seguridad informática muy costosas pensando que solucionarán sus
problemas y otras que invierten muy pocos recursos creyendo que no será necesario
debido a que “nunca antes se ha presentado un problema de seguridad”. Entonces,
el SGSI se encarga entre otras cosas, de identificar los riesgos existentes en la
organización y con el conocimiento y aprobación de los interesados de la propia
organización, administrarlos de manera adecuada y continua. Si no existe una
administración adecuada de los riesgos, es probable caer en el error de invertir
demasiados recursos en riesgos que no sean de alta prioridad para la organización y
desproteger aquellos que sí lo son, o por el contrario, de no invertir en aquellos que
presentan una mayor prioridad.
1 Conocido también como ISMS (Information Security Management System), por sus siglas en inglés.
1
CAPÍTULO I.
SISTEMA DE GESTIÓN DE SEGURIDAD
INFORMÁTICA (SGSI).
1.1 MARCO DE REFERENCIA DEL SGSI.
Algunos autores denominan al proceso de SGSI como gobierno de seguridad
en TI o como una parte fundamental de éste, el cual se encuentra contenido
dentro del Gobierno de TI y éste a su vez dentro del Gobierno Corporativo. Por
lo tanto, a continuación se muestran definiciones de cada uno de estos
conceptos.
Gobierno Corporativo. El gobierno corporativo puede ser entendido
como: “El proceso mediante el cual, el consejo de administración de una
entidad asegura el logro sostenido de sus objetivos, así como la
protección del patrimonio y de los intereses de todos sus stakeholders
(grupos de interés), a quienes debe ofrecer transparencia en las
prácticas de administración y control de calidad” [1]. El gobierno
corporativo tiene injerencia sobre el desarrollo de todas las áreas de
trabajo de la organización, y un buen sistema de gobierno corporativo
permite alcanzar las metas y objetivos. Es el proceso más general en la
administración de la organización.
Gobierno de TI. El gobierno de TI tiene como objetivo la alineación del
empleo de las TI a la misión de la organización con el fin de generar valor
2
para la misma y a su vez, preservar el valor generado mediante una
adecuada administración. Determina el marco para la toma de decisiones
y la responsabilidad para fomentar el comportamiento adecuado en el
uso de las TI y persigue la automatización de los procesos de la
organización.
Para llevar a cabo las actividades que cumplan con los objetivos de la
organización, se requiere de los diferentes servicios que proporcionan las
TI, las cuales deben estar alineadas y deben permitir a la organización
tomar ventaja total de su información para maximizar sus beneficios,
capitalizar oportunidades y ganar ventaja competitiva.
Gobierno de Seguridad en TI. El proceso de gobierno de seguridad de TI
determina las directrices a seguir, el alineamiento estratégico de las
actividades de seguridad informática con la organización para la
generación de valor, realiza la gestión de los riesgos existentes en los
activos informáticos y mide su desempeño para realizar el ciclo de
mejora continua.
El gobierno de seguridad de TI tiene como objetivo la protección de los
intereses de todos aquellos que dependen de la información y de los
sistemas y comunicaciones que lo habilitan contra daños que afecten su
disponibilidad, confidencialidad e integridad.
1.2 DESCRIPCIÓN.
La seguridad informática puede describirse como un conjunto de actividades
orientadas a la protección de la información y de los activos informáticos en una
organización, con el fin de garantizar su integridad, confidencialidad y
disponibilidad. Un SGSI es un sistema que identifica los riesgos de seguridad
de la información existentes en la organización, los presenta con niveles de
3
prioridad ante un comité encargado de definir la cantidad de recursos que se
deberán invertir y establece políticas y procedimientos basados en los objetivos
de la organización. Coordina las actividades de seguridad informática para dar
cumplimiento a los objetivos de gobierno.
En general, un SGSI cumple con los siguientes puntos fundamentales:
Se mantiene alineado a la misión de la organización y a la misión de
seguridad de la organización.
Propone un análisis de riesgos.
Plantea la elaboración de políticas de seguridad Informática.
Sugiere controles de seguridad.
Propone el monitoreo del sistema.
Establece esquemas de recuperación y continuidad del negocio.
Fomenta una cultura de seguridad en la organización.
Cada uno de los puntos señalados anteriormente, establece una parte
importante del SGSI y pueden variar en su implementación de acuerdo al
estándar o norma del que se refiera pero, sobre todo, dependen de las
necesidades reales de cada organización. A continuación se describirá cada
uno de los puntos.
1.2.1 Alineación del SGSI a las misiones de la organización y de
seguridad de la organización.
Como ya se ha mencionado anteriormente, el SGSI debe estar alineado
a los objetivos de la misión de la organización y a la misión de seguridad
de la organización, donde se busca establecer y mantener un estado de
armonía entre los recursos relacionados con las TI y las aspiraciones
estratégicas de la organización.
4
En este punto se deben identificar de forma específica los recursos y
procesos relacionados con la seguridad de TI y determinar el impacto
que tienen en los objetivos y metas de la organización.
Si la misión de seguridad no se encuentra alineada a la misión de la
organización, el SGSI podría proteger diferentes aspectos de seguridad,
pero tal vez no sean los más importantes para la organización, o sea,
aquellos que le generan valor y que permiten que se alcancen los
objetivos establecidos.
1.2.2 Análisis de riesgos.
El análisis de riesgos es uno de los primeros pasos a realizar en un
SGSI, debido a que en base a la evaluación de amenazas y
vulnerabilidades en los activos de una organización, permite determinar
cuáles serán los controles de seguridad específicos que deberán ser
implementados.
En este punto se establece una metodología, la cual contiene una fase
de identificación de riesgos, análisis y evaluación del impacto y una
selección de controles que los mitiguen.
Al final del análisis de riesgos, la organización se encuentra en
posibilidad de tomar una decisión en cuanto al tratamiento del riesgo, que
puede ser mitigado, transferido o aceptado.
Los análisis de riesgos suelen dividirse en dos tipos fundamentales:
cuantitativos y cualitativos.
Los análisis de riesgos cuantitativos se basan en la probabilidad de que
se produzca un hecho y la probable pérdida obtenida de que ese hecho
5
se produzca. Normalmente se determinan valores numéricos, los
resultados que se obtienen son objetivos y se expresan en porcentajes,
probabilidades de ocurrencia de amenazas, entre otros. Un análisis de
riesgos de este tipo puede ser complejo debido a los cálculos que deben
realizarse, además de requerir una considerable inversión de tiempo y
esfuerzos. Cuando la organización no cuenta con datos estadísticos, es
difícil realizar un análisis cuantitativo.
El análisis de riesgos cualitativo es la metodología más utilizada. En este
enfoque, no es necesario conocer la probabilidad y sólo se emplea la
pérdida potencial como factor de cálculo. Los resultados que se obtienen
en este tipo de análisis son subjetivos y los cálculos a realizar son
sencillos. El éxito de un análisis de este tipo depende en buena medida
del conocimiento de la organización que tenga el equipo encargado de
realizar este análisis.
El análisis de riesgos hace uso de los siguientes conceptos para su
desarrollo:
Amenaza. Hecho que puede producir un daño. Las amenazas
pueden ser naturales o hechas por el hombre.
Vulnerabilidad. Debilidad o falla. En seguridad informática
comúnmente se refiere a la debilidad o falla en un sistema.
Riesgo. Un riesgo es un evento que tiene la característica de ser
incierto y que en caso de ocurrir, tendrá un efecto negativo. En otras
palabras, es la probabilidad o posibilidad de que una amenaza
aproveche una vulnerabilidad.
Una metodología de análisis de riesgos, de manera general, comprende
6
los siguientes pasos:
Establece el alcance, conforme a los procesos críticos de TI de la
Organización.
Define los activos informáticos que se van a analizar, que deben ser
componentes del proceso de TI.
Identifica las amenazas que pueden comprometer la seguridad de
los activos.
Determina la probabilidad o posibilidad de ocurrencia de las
amenazas.
Determina el impacto de las amenazas.
Recomienda controles que disminuyan la probabilidad de los
riesgos, ajustándose a las necesidades de la organización,.
Documenta el proceso.
1.2.3 Controles de seguridad.
Los controles de seguridad pueden ir enfocados a proteger los activos o
los procesos de TI existentes en una organización, de acuerdo a la
clasificación que utilice y proponga el SGSI para ello. Los controles
pueden ser clasificados como administrativos, físicos o técnicos.
Los controles administrativos comprenden las políticas y procedimientos
de seguridad. Las políticas establecen qué es lo que se les permite o
prohíbe hacer a los usuarios, y los procedimientos son la descripción de
las tareas que se deben realizar para la protección de los activos.
Algunos ejemplos de controles administrativos son:
Asignación de responsabilidades.
Supervisión o auditorías.
Recuperación tras fallos.
7
Elaboración de planes de contingencia.
A los controles que delimitan el acceso físico a los activos informáticos se
les denomina controles físicos. También entran en esta categoría las
fuentes de alimentación ininterrumpida de suministro de energía. Estos
pueden ser:
Cerraduras.
Bloqueadores de teclados.
Vigilantes de seguridad.
Alarmas.
Sistemas de detección de fuego y humo.
Los controles técnicos son aquellos que se implementan a través de
hardware, software o una combinación de ambos, los cuales pueden
funcionar de forma automatizada. Ejemplos de estos controles son:
Antivirus.
Firma digital.
Tarjetas inteligentes.
Sistemas de detección de intrusos.
A los controles de seguridad también se les conoce como mecanismos o
salvaguardas de seguridad.
1.2.4 Políticas de seguridad informática.
Una política de seguridad es un conjunto de requisitos definidos por los
responsables de un sistema, que indica en términos generales qué está y
que no está permitido en el área de seguridad durante la operación
general del sistema [2].
8
El RFC 1244 define la política de seguridad como: “una declaración de
intenciones de alto nivel que cubre la seguridad de los sistemas
informáticos y que proporciona las bases para definir y delimitar
responsabilidades para las diversas actuaciones técnicas y organizativas
que se requerirán.” [3]
La política se refleja en una serie de normas, reglamentos y protocolos a
seguir, donde se definen las medidas a tomar para proteger la seguridad
del sistema. Las políticas de seguridad como parte integral de un SGSI,
tienen la intención de definir ¿Qué? ¿Por qué? ¿De qué? y ¿Cómo? se
debe proteger la información. Tratan a su vez de ser el medio de
interpretación de la seguridad para toda la organización [4].
Algunos de los principios que manejan las políticas de seguridad son:
Responsabilidad.
Autorización.
Mínimo privilegio.
Separación de cargo.
Auditoría.
Redundancia.
Reducción de riesgo.
Confidencialidad, integridad y disponibilidad.
1.2.5 Monitoreo del sistema.
El monitoreo del sistema contempla la supervisión del funcionamiento de
los controles implementados y permite llevar a cabo una
retroalimentación del sistema para mantener un ciclo de mejora en las
fases que lo conforman.
9
Con el monitoreo se pretende detectar errores de procesamiento,
brechas de seguridad, revisar el desempeño de las personas en las
actividades de seguridad, entre otras.
Una vez que se han obtenido los resultados, se detallan, archivan y
reportan a los responsables con el objeto de que establezcan medidas
preventivas de refuerzo.
Esta actividad se realiza en base a auditorías, comentarios de fallas por
parte de las áreas involucradas, incidentes ocurridos, revisión inhouse,
etc.
1.2.6 Recuperación y continuidad del negocio.
La recuperación y continuidad del negocio consiste en mantener en
operación a una organización después de que ha ocurrido una
contingencia, la cual se puede presentar por causas naturales como son
inundaciones, terremotos e incendios o por causas provocadas por el
hombre, ya sea de tipo intencionales o por errores.
La organización elabora un plan comúnmente denominado de
recuperación de desastres, en el cual se determinan los activos que
puede requerir en caso de presentarse una contingencia para mantener
la operación normal o por lo menos, para mantener un nivel de operación
que considere aceptable. Tales activos son considerados dentro de un
esquema en el cual se encuentran en un sitio alterno y lejano al original,
con el fin de evitar que éste también sea afectado por la contingencia.
Además, se establecen procedimientos en los cuales se indican las
acciones a realizar por parte del personal perteneciente a la
10
organización. El plan se da a conocer a la totalidad de individuos y para
poder garantizar su éxito, se deben realizar simulacros de reacción para
determinar el grado de conocimiento del plan y el entrenamiento por
parte del personal, así como los tiempos de respuesta a este tipo de
eventos.
Por otro lado, también existen esquemas que consideran la contratación
de una entidad externa que proporciona la infraestructura para llevar a
cabo la recuperación del negocio.
1.2.7 Cultura de seguridad en la organización.
En este rubro el responsable de la gestión de seguridad de la información
realiza actividades tendientes a fortalecer la cultura de seguridad en el
personal de la organización. Debido a que comúnmente el factor humano
representa el eslabón más débil dentro de la cadena de seguridad [5],
gran parte de los trabajos de seguridad se orientan a la creación de
conciencia en el personal y en su entrenamiento para la aplicación
correcta de medidas y buenas prácticas.
La creación de conciencia en el personal se puede materializar a través
de programas que contengan pláticas, conferencias, videos, revistas,
entre otros; en los cuales se indica la importancia de la aplicación de
medidas de seguridad y las consecuencias en la organización o inclusive,
en los individuos por no llevarlas a cabo.
En el entrenamiento se proporciona capacitación al personal para realizar
una adecuada implementación de controles de seguridad en los
diferentes aspectos en los que se tiene injerencia dentro de un sistema
de información. El entrenamiento se puede enmarcar dentro de un
programa periódico que mantenga una capacitación continua.
11
1.3 CONCLUSIONES.
Se observa que de acuerdo al empleo existente de TI en las organizaciones, se
presenta la necesidad de contar con un SGSI el cual mantenga una ubicación
en el organigrama, que a su vez es denominado por algunos autores como
gobierno de seguridad en TI. El gobierno de seguridad en TI debe estar
alineado a la misión y objetivos de la organización. Asimismo, el SGSI parte
normalmente de la elaboración de un análisis de riesgos, en el cual se
describen amenazas, vulnerabilidades en los activos, riesgos y su impacto en la
organización. En base a los resultados obtenidos del análisis de riesgos, se
pueden determinar los controles de seguridad que se deben implementar, los
cuales pueden ser de tipo administrativos, físicos y/ó técnicos. Una vez que se
implementan los controles de seguridad, se realiza un monitoreo en el que se
pretende detectar fallas en su implementación para llevar a cabo una
retroalimentación de todo el sistema, permitiendo a su vez, un proceso de
mejora continua que mantenga actualizado al SGSI.
12
CAPÍTULO II.
ISO/IEC 27001:2005.
2.1 DESCRIPCIÓN.
La “ISO/IEC 27001:2005, Information Technology -- Security techniques --
Information security management systems -- Requirements (Requerimientos --
Sistemas de gestión de seguridad de la información -- Técnicas de seguridad --
Tecnologías de la Información)” [6] es un estándar internacional publicado por la
Organización Internacional para la Estandarización (ISO) y la Comisión
Electrotécnica Internacional (IEC). El documento tiene sus orígenes en el
Estándar Británico BS7799 emitido por el Instituto de Normas Británico (British
Standard Institute, BSI) y fue adoptado, bajo la supervisión del grupo de trabajo
“Tecnologías de la Información” del Comité Técnico ISO/IEC JTC 11. El citado
estándar es parte de la familia de estándares ISO-2700x [7], el cual incluye los
siguientes estándares:
ISO/IEC 27000:2009 - Overview and vocabulary.
ISO/IEC 27001:2005 - Requirements.
ISO/IEC 27002:2005 - Code of practice for information security
1 Join Technical Comité No. 1
13
management.
ISO/IEC 27003 - Implementation guidance.
ISO/IEC 27004 - Measurement.
ISO/IEC 27005:2008 - Information security risk management.
ISO/IEC 27006:2007 - Requirements for bodies providing audit and
certification of information security management systems.
El estándar ISO/IEC 27001 es el documento que describe los requerimientos
del SGSI, mientras que los demás tratan de forma específica algunos temas
relacionados con el sistema. El ISO/IEC 27002 hace mención de los controles
específicos que se deben implementar en el SGSI y es la evolución del
estándar ISO/IEC 17799:2005. Los estándares 27003 y 27004 actualmente se
encuentran en fase de desarrollo.
El estándar ISO/IEC 27001:2005 se basa en los procesos establecidos en el
modelo de mejora continua PDCA (Plan, Do, Check, Act), por lo que a lo largo
de todo el desarrollo del sistema de gestión sugiere “establecer, implementar,
operar, monitorear, mantener y mejorar continuamente el SGSI”.
El modelo PDCA manifiesta lo siguiente en cada una de sus etapas:
Plan. (Establecer el SGSI). Establece la política, objetivos, proceso y
procedimientos del SGSI relevantes para manejar el riesgo y mejorar la
seguridad de la información para entregar resultados en concordancia
14
con las políticas y objetivos generales de la organización.
Do. (Implementar el SGSI). Implementa y opera la política, controles,
procesos y procedimientos del SGSI.
Check. (Monitorear y revisar el SGSI). Evalúa y, donde sea aplicable, mide el
desempeño del proceso en comparación con la política, objetivos y
experiencias prácticas del SGSI y reporta los resultados a la gerencia
para su revisión.
Act. (Mantener y mejorar el SGSI). Toma acciones correctivas y preventivas
basadas en los resultados de la auditoría interna del SGSI y la revisión
gerencial u otra información relevante, para lograr la mejora continua
del SGSI.
En la Figura 2.1 se muestra que el proceso del SGSI toma como entrada los
requerimientos y expectativas de la seguridad de información de las partes
interesadas, internamente desarrolla el modelo PDCA en un ciclo continuo, y en
la salida entrega resultados que satisfacen los requerimientos y expectativas
que se plantearon inicialmente. De manera interna, se observa la interacción de
las etapas que conforman al ciclo PDCA; la etapa de Plan establece el SGSI, la
cual permite la implementación y operación en la etapa de Do, una vez que se
cuenta con ello, se monitorea y revisa el sistema en la etapa de Check y con los
resultados obtenidos, se retroalimenta el sistema para mantenerlo y mejorarlo
en la etapa de Act.
15
Figura 1. Modelo PDCA aplicado a los procesos SGSI.
De manera general, el estándar ISO/IEC 27001:2005 se divide en 9 puntos
principales y 3 anexos como se menciona a continuación:
0 Introducción.
1 Alcance.
2 Referencias normativas.
3 Términos y definiciones.
4 Sistema de gestión de seguridad de la información.
5 Responsabilidades de la gerencia.
6 Auditorías internas.
7 Revisión gerencial del SGSI.
8 Mejoramiento del SGSI.
Partes interesadas
Requerimientos y expectativas de la seguridad de información.
Partes interesadas
Seguridad de información manejada.
Desarrollar, mantener y mejorar el
ciclo.
Establecer el SGSI
Plan
Implementar y operar el SGSI
Do
Mantener y mejorar el SGSI
Act
Monitorear y revisar el SGSI
Check
Modelo PDCA, ISO/IEC 27001:2005
16
Anexos.
En el primer punto, se habla de manera general sobre el objetivo del estándar,
el enfoque que tiene hacia el modelo PDCA y sobre la compatibilidad que tiene
con los estándares ISO 9001:2000 y 14001:2004.
En el punto 1 se trata el alcance del estándar, donde se manifiesta que puede
ser aplicado a cualquier tipo de organización, ya sea gubernamental, comercial,
o sin fines de lucro.
En el punto de referencias normativas, se hace mención del estándar “ISO/IEC
17799:2005, Tecnología de la información – Técnicas de seguridad – Código de
práctica para la gestión de la seguridad de la información”, del cual se hace
hincapié en la importancia que tiene para la aplicación del estándar ISO/IEC
27001.
En el punto 3 se mencionan 16 términos y definiciones que son utilizados a lo
largo del estándar.
El punto 4 del estándar, describe el SGSI a detalle y se divide en tres partes
principales:
Requerimientos generales.
17
Establecimiento y manejo del SGSI.
Requerimientos de documentación.
El punto de “Responsabilidades de la gerencia”, hace mención del “compromiso
de la gerencia” y “Gestión de recursos”.
El punto 6 propone la elaboración de un programa de auditoría para verificar
que se cumplan los objetivos de control, controles, procesos y procedimientos
del SGSI.
En la “revisión gerencial del SGSI”, se plantea la revisión programada del SGSI
por parte de la gerencia de la organización para asegurarse de su conveniencia
y efectividad.
En el punto 8 se habla sobre la mejora continua de la efectividad del sistema, la
cual deberá ser basada en los resultados de la auditoría y del análisis de los
eventos monitoreados, para llevar a cabo acciones correctivas y preventivas.
En los anexos se manifiestan tres temas:
Objetivos de control y controles.
Principios OECD2 y el modelo PDCA.
Correspondencia entre los estándares ISO 9001:2000 e ISO 14001:2004
2 OECD, Lineamientos OECD para la Seguridad de los Sistemas y Redes de Información – Hacia una cultura de seguridad. Paris: OECD, Julio 2002, www.oecd.org.
18
con el estándar ISO/IEC 27001:2005.
Debido a que la descripción principal del SGSI se encuentra contenida en los
puntos 4, 5, 6 y 8, a continuación serán revisados de manera detallada.
2.2 El SGSI en ISO/IEC 27001:2005.
Para el establecimiento del SGSI, el estándar ISO/IEC 27001:2005, propone lo
siguiente:
Definir el alcance y los límites del SGSI en términos de las características
del negocio.
Definir una política de seguridad.
Definir el enfoque de valuación del riesgo.
Identificar los riesgos.
Analizar y evaluar el riesgo.
Identificar y evaluar las opciones para el tratamiento de los riesgos.
Seleccionar objetivos de control y controles para el tratamiento de riesgos.
En la definición de la política, el estándar señala que debe incluir un marco
referencial para el establecimiento de sus objetivos, que tome en cuenta los
requerimientos de la organización en la parte de seguridad, que se establezca
el criterio con el que se evaluará el riesgo y que sea aprobada por la gerencia.
19
Para el “enfoque de valuación de riesgo de la organización”, se propone la
identificación de una metodología de cálculo de riesgo y el desarrollo de
criterios para aceptar el riesgo e identificar los niveles de riesgo aceptables.
Para ello, propone la revisión del estándar “ISO/IEC TR 13335-3, Tecnología de
Información – Lineamiento para la gestión de la seguridad TI – Técnicas para la
gestión de la seguridad TI”.
Los puntos “Identificar los riesgos”, “Analizar y evaluar el riesgo” e “Identificar y
evaluar las opciones para el tratamiento de los riesgos”, van relacionados con el
punto anterior y se refieren al manejo de riesgos en la organización.
En la parte de selección de objetivos de control y controles, el estándar hace
referencia al anexo A, el cual maneja una tabla con los objetivos de control y
controles que se encuentran alineados, inclusive en la numeración, a los
establecidos en el estándar ISO/IEC 17799:2005. La tabla establece once
categorías de seguridad principales acompañadas de 38 objetivos de control y
133 controles de seguridad, como se muestra a continuación:
CATEGORÍA DE
SEGURIDAD PRINCIPAL OBJETIVO DE CONTROL CONTROL
A.5 Política de seguridad. A.5.1 Política de seguridad
de la información.
A.5.1.1 Documento de la política de seguridad de la información.
A.5.1.2 Revisión de la política de seguridad de la información.
A.6 Organización de la seguridad de la información.
A.6.1 Organización interna.
A.6.1.1 Administración del compromiso de seguridad de la información.
A.6.1.2 Coordinación de la seguridad de la información.
20
CATEGORÍA DE SEGURIDAD PRINCIPAL
OBJETIVO DE CONTROL CONTROL
A.6 Organización de la seguridad de la información.
A.6.1 Organización interna.
A.6.1.3 Asignación de responsabilidades de seguridad de la información.
A.6.1.4 Proceso de autorización para facilidades de procesamiento de información.
A.6.1.5 Acuerdos de confidencialidad.
A.6.1.6 Contacto con autoridades.
A.6.1.7 Contacto con grupos de interés especial.
A.6.1.8 Revisión independiente de la seguridad de la información.
A.6.2 Partes externas.
A.6.2.1 Identificación de riesgos relativos a partes externas.
A.6.2.2 Orientación de la seguridad cuando se trata con clientes.
A.6.2.3 Orientación de la seguridad en acuerdos con terceros.
A.7 Gestión de activos.
A.7.1 Responsabilidad de los activos.
A.7.1.1 Inventario de activos.
A.7.1.2 Propiedad de activos.
A.7.1.3 Uso aceptable de activos.
A.7.2 Clasificación de la información.
A.7.2.1 Guías para la clasificación.
A.7.2.2 Manejo y etiquetado de información.
A.8 Seguridad en el personal.
A.8.1 Antes del contrato.
A.8.1.1 Roles y responsabilidades.
A.8.1.2 Antecedentes.
A.8.1.3 Términos y condiciones de contrato.
A.8.2 Durante el empleo.
A.8.2.1 Administración de responsabilidades.
A.8.2.2 Concientización, educación y entrenamiento en seguridad de la información.
A.8.2.3 Proceso disciplinario.
A.8.3 Terminación o cambio de empleo.
A.8.3.1 Responsabilidades por terminación en el empleo.
A.8.3.2 Devolución de activos.
A.8.3.3 Eliminación de derechos de acceso.
A.9 Seguridad física y del entorno.
A.9.1 Áreas seguras. A.9.1.1 Perímetro de seguridad
física.
21
CATEGORÍA DE SEGURIDAD PRINCIPAL
OBJETIVO DE CONTROL CONTROL
A.9 Seguridad física y del entorno.
A.9.1 Áreas seguras.
A.9.1.2 Controles físicos de entrada.
A.9.1.3 Seguridad en oficinas, áreas e instalaciones.
A.9.1.4 Protección contra amenazas externas y de entorno.
A.9.1.5 Trabajo en áreas seguras.
A.9.1.6 Acceso público, áreas de entrega y recepción.
A.9.2 Seguridad en el equipo.
A.9.2.1 Colocación y protección de equipo.
A.9.2.2 Utilidades de soporte.
A.9.2.3 Seguridad en el cableado.
A.9.2.4 Mantenimiento de equipo.
A.9.2.5 Seguridad en equipo en localidades externas.
A.9.2.6 Seguridad en el desecho o reutilización de equipo.
A.9.2.7 Eliminación de propiedad.
A.10 Gestión en las comunicaciones y operaciones.
A.10.1 Procedimientos operacionales y responsabilidades.
A.10.1.1 Procedimientos de operación documentados.
A.10.1.2 Gestión de cambios.
A.10.1.3 Segregación de obligaciones.
A.10.1.4 Separación de instalaciones de desarrollo, de prueba y operación.
A.10.2 Gestión de entrega de servicio a terceros.
A.10.2.1 Entrega de servicio.
A.10.2.2 Monitoreo y revisión de servicios a terceros.
A.10.2.3 Gestión de cambios de terceros.
A.10.3 Planeación y aprobación del sistema.
A.10.3.1 Administración de capacidades.
A.10.3.2 Aceptación de sistema.
A.10.4 Protección contra código malicioso y código móvil.
A.10.4.1 Controles contra código malicioso.
A.10.4.2 Controles contra código móvil.
A.10.5 Respaldos. A.10.5.1 Información de
respaldos.
A.10.6 Gestión de seguridad en red.
A.10.6.1 Controles de red.
A.10.6.2 Seguridad de servicios de red.
A.10.7 Manejo de medios.
A.10.7.1 Administración de medios removibles.
A.10.7.2 Eliminación de medios
A.10.7.3 Procedimientos de manejo de información.
22
CATEGORÍA DE SEGURIDAD PRINCIPAL
OBJETIVO DE CONTROL CONTROL
A.10 Gestión en las comunicaciones y operaciones.
A.10.7 Manejo de medios. A.10.7.4 Seguridad en la
documentación del sistema.
A.10.8 Intercambio de información.
A.10.8.1 Política y procedimientos de intercambio de información.
A.10.8.2 Acuerdos de intercambio.
A.10.8.3 Medios físicos en tránsito.
A.10.8.4 Mensajería electrónica.
A.10.8.5 Sistemas de información del negocio.
A.10.9 Servicios de comercio electrónico.
A.10.9.1 Comercio electrónico.
A.10.9.2 Transacciones en línea.
A.10.9.3 Información en publicidad disponible.
A.10.10 Monitoreo.
A.10.10.1 Auditoría de registros.
A.10.10.2 Monitoreo del uso del sistema.
A.10.10.3 Protección de la información de registros.
A.10.10.4 Registros de administradores y operadores.
A.10.10.5 Registro de errores.
A.10.10.6 Sincronización de relojes.
A.11 Control de acceso.
A.11.1 Requerimientos del negocio para el control de acceso.
A.11.1.1 Política de control de acceso.
A.11.2 Administración de acceso de usuario.
A.11.2.1 Registro de usuarios.
A.11.2.2 Administración de privilegios.
A.11.2.3 Administración de passwords de usuarios.
A.11.2.4 Revisión de derechos de acceso de usuarios.
A.11.3 Responsabilidades de usuarios.
A.11.3.1 Empleo de passwords.
A.11.3.2 Desatención de equipo de usuario.
A.11.3.3 Política de escritorios y pantallas limpios.
A.11.4 Control de acceso de red.
A.11.4.1 Política del empleo de servicios de red.
A.11.4.2 Autenticación de usuarios para conexiones externas.
A.11.4.3 Identificación de equipos en las redes.
23
CATEGORÍA DE SEGURIDAD PRINCIPAL
OBJETIVO DE CONTROL CONTROL
A.11 Control de acceso.
A.11.4 Control de acceso de red.
A.11.4.4 Diagnóstico remoto y configuración de protección de puertos.
A.11.4.5 Segregación en redes.
A.11.4.6 Control de las conexiones de red.
A.11.4.7 Control del ruteo de red.
A.11.5 Control de acceso en el sistema operativo.
A.11.5.1 Procedimientos de seguridad en inicio de sesión.
A.11.5.2 Identificación y autenticación de usuarios.
A.11.5.3 Sistema de administración de passwords.
A.11.5.4 Empleo de utilidades de sistema.
A.11.5.5 Finalización de sesiones.
A.11.5.6 Límite del tiempo de conexión.
A.11.6 Control de acceso en la información y aplicaciones.
A.11.6.1 Restricción de acceso a la información.
A.11.6.2 Aislamiento de sistemas sensibles.
A.11.7 Cómputo móvil y teletrabajo.
A.11.7.1 Cómputo móvil y teletrabajo.
A.11.7.2 Teletrabajo.
A.12 Adquisición, desarrollo y mantenimiento de sistemas de información.
A.12.1 Requerimientos de seguridad de sistemas de información.
A.12.1.1 Requerimientos, análisis y especificaciones de seguridad.
A.12.2 Procesamiento correcto en las aplicaciones.
A.12.2.1 Validación de datos de entrada.
A.12.2.2 Control de procesamiento interno.
A.12.2.3 Integridad de mensajes.
A.12.2.4 Validación de datos de salida.
A.12.3 Controles criptográficos.
A.12.3.1 Política de empleo de controles criptográficos.
A.12.3.2 Administración de llaves.
A.12.4 Seguridad en archivos de sistema.
A.12.4.1 Control de software operativo.
A.12.4.2 Protección de datos de prueba de sistema.
A.12.4.3 Control de acceso para código fuente de programas.
24
CATEGORÍA DE SEGURIDAD PRINCIPAL
OBJETIVO DE CONTROL CONTROL
A.12 Adquisición, desarrollo y mantenimiento de sistemas de información.
A.12.5 Seguridad en el desarrollo y soporte de procesos.
A.12.5.1 Procedimientos de control de cambios.
A.12.5.2 Revisión técnica de aplicaciones después de realizar cambios en el sistema operativo.
A.12.5.3 Restricciones en cambios de paquetes de software.
A.12.5.4 Fuga de información.
A.12.5.5 Contratación externa para desarrollo de software.
A.12.6 Administración de vulnerabilidades técnicas.
A.12.6.1 Control de vulnerabilidades técnicas.
A.13 Gestión de incidentes de seguridad de información.
A.13.1 Reporte de eventos de seguridad de información y vulnerabilidades.
A.13.1.1 Reporte de eventos de seguridad de información.
A.13.1.2 Reporte de vulnerabilidades de seguridad.
A.13.2 Gestión de incidentes de seguridad de información y mejoras.
A.13.2.1 Responsabilidades y procedimientos.
A.13.2.2 Aprendizaje en incidentes de seguridad de información.
A.13.2.3 Colección de evidencia.
A.14 Gestión de continuidad del negocio.
A.14.1 Aspectos de seguridad de la información de la gestión de continuidad del negocio.
A.14.1.1 Incluir seguridad en la información del proceso de gestión de continuidad del negocio.
A.14.1.2 Continuidad del negocio y gestión de riesgos.
A.14.1.3 Desarrollo e implementación de planes de continuidad incluyendo seguridad de la información.
A.14.1.4 Marco de planeación de continuidad del negocio.
A.14.1.5 Pruebas, mantenimiento y reevaluación de los planes de continuidad del negocio.
A.15 Cumplimiento. A.15.1 Cumplimiento con
requerimientos legales.
A.15.1.1 Identificación de legislación aplicable.
A.15.1.2 Derechos de propiedad intelectual.
A.15.1.3 Protección de grabaciones de organizacionales.
25
CATEGORÍA DE SEGURIDAD PRINCIPAL
OBJETIVO DE CONTROL CONTROL
A.15 Cumplimiento.
A.15.1 Cumplimiento con requerimientos legales.
A.15.1.4 Protección de la privacidad y datos personales.
A.15.1.5 Prevención de abuso de procesamiento de información.
A.15.1.6 Regulación de controles criptográficos.
A.15.2 Cumplimiento con políticas y estándares de seguridad y cumplimiento técnico.
A.15.2.1 Cumplimiento con políticas y estándares de seguridad.
A.15.2.2 Verificación de cumplimiento técnico.
A.15.3 Consideraciones en auditoría de sistemas de información.
A.15.3.1 Controles de auditoría en sistemas de información.
A.15.3.2 Protección de herramientas de auditoría de sistemas de información.
Tabla 1. Controles de seguridad en ISO/IEC 27001.
Para la implementación y operación del SGSI, se plantea lo siguiente:
Formulación de un plan de tratamiento del riesgo.
Implementación del plan de tratamiento del riesgo.
Implementación de los controles seleccionados para satisfacer los
objetivos de control.
Definir métricas para la efectividad de los controles o grupos de controles
seleccionados.
Implementar programas de capacitación.
Manejo de las operaciones del SGSI.
Manejo de los recursos.
Implementación de procedimientos para detección y respuesta de
incidentes de seguridad.
26
En el monitoreo y revisión del SGSI se plantea:
Ejecución de procedimientos de monitoreo y revisión.
Revisiones regulares de la efectividad del SGSI.
Medición de la efectividad de los controles.
Revisión de las evaluaciones de riesgo.
Realizar auditorías internas.
Revisión gerencial del SGSI.
Actualización de los planes de seguridad.
Registrar las acciones y eventos que pudieran tener impacto sobre el
desempeño del SGSI.
Para el mantenimiento y mejora del SGSI se propone realizar lo que se
menciona a continuación:
Implementar las mejoras identificadas.
Tomar las acciones correctivas y preventivas apropiadas.
Comunicar los resultados y acciones a todas las partes interesadas.
Asegurar que las mejoras logren los objetivos señalados.
El estándar aborda una parte de documentación en el punto del SGSI, en la
cual recomienda mencionar los enunciados de la política del SGSI, el alcance,
los procedimientos y controles, una descripción de la metodología del análisis
de riesgo, el reporte del análisis de riesgo, el plan del tratamiento del riesgo,
27
todos los procedimientos necesarios para asegurar la planeación, operación y
control de los procesos del SGSI y las métricas de la efectividad de los
controles de seguridad. También recomienda manejar un control de cambios en
la documentación que se genere y llevar un registro de la misma.
El estándar señala además, el aspecto de responsabilidad de la gerencia, en la
cual se propone la existencia de evidencia para plantear el compromiso que
tiene con el establecimiento, implementación, monitoreo, revisión,
mantenimiento, y mejoramiento del SGSI. Recomienda que la organización
proporcione los recursos necesarios para la implementación y desarrollo del
sistema, así como la capacitación para el personal participante.
En la parte de auditoría, el estándar indica que se lleven a cabo revisiones
periódicas para determinar que los objetivos de control, controles, procesos y
procedimientos del SGSI cumplan con los requerimientos del estándar y con la
normatividad interna. Asimismo, menciona que la norma ISO 19011:20023
podría ser una guía para llevar a cabo auditorías internas.
También se hace mención de que la gerencia realice revisiones periódicas del
SGSI, para asegurarse de su efectividad.
En lo correspondiente al mejoramiento del SGSI, el estándar propone llevar a
cabo acciones correctivas para eliminar inconformidades con los requerimientos
3 ISO 19011:2002, Guidelines for quality and/or environmental management systems auditing.
28
del sistema y evitar recurrencias. De igual manera, propone realizar acciones
preventivas para eliminar inconformidades potenciales de los requerimientos del
sistema y evitar su ocurrencia.
2.3 CONCLUSIONES.
Se observa que el estándar ISO/IEC 27001:2005, en el punto número 4 de su
contenido, propone la alineación del SGSI con los objetivos de la organización,
y propone además, contar con una política de seguridad en la cual se señalen
los requerimientos de seguridad. Maneja también, el desarrollo de un análisis
de riesgos aunque no proporciona una metodología específica, sólo hace
referencia a un documento que puede ser utilizado como guía para la selección
de una metodología adecuada.
Los controles de seguridad que propone, son los establecidos en el anexo A, los
cuales corresponden al estándar ISO/IEC 17799:2005.
Asimismo, a lo largo del documento se hace mención sobre el proceso de
monitoreo y mejora continua, el cual está basado en la metodología PDCA y se
habla sobre ello de manera más detallada en el último punto del estándar.
29
CAPÍTULO III.
ENISA (EUROPEAN NETWORK AND INFORMATION
SECURITY AGENCY).
3.1 DESCRIPCIÓN.
La Unión Europea cuenta con varias agencias especializadas y
descentralizadas en apoyo a los estados Miembros y a los ciudadanos, las
cuales responden a la necesidad de hacer frente a nuevas tareas de carácter
jurídico, técnico y científico. Las Agencias se agrupan en cinco categorías:
Agencias comunitarias.
Agencias de política exterior y de seguridad común.
Agencias de cooperación policial y judicial en materia penal.
Agencias ejecutivas.
Agencias y organismos de Euratom1.
Dentro de las agencias comunitarias se encuentra la Agencia Europea de
Seguridad en las Redes y de la Información (ENISA, European Network and
Information Security Agency), la cual funciona como un centro de
asesoramiento sobre cuestiones de seguridad en las redes y de la información,
tanto para los estados miembros, como para las instituciones de la Unión
Europea [8].
1 Euratom, Tratado de la Comunidad Europea de la Energía Atómica.
30
Las tareas de la ENISA son:
Asesorar y asistir a la Comisión y a los Estados miembros en materia de
seguridad de la información y en hacer frente a los problemas de
seguridad del material y de los programas informáticos (hardware y
software) en contacto con el sector empresarial.
Recoger y analizar datos sobre las incidencias que se producen en Europa
en materia de seguridad.
Fomentar la evaluación y los métodos de gestión de los riesgos para
mejorar la capacidad de hacer frente a cualquier amenaza a la seguridad
de la información.
Intercambiar buenas prácticas en materia de sensibilización y fomentar la
cooperación entre los diferentes actores en el ámbito de la seguridad de la
información, especialmente potenciando en el mundo empresarial
acuerdos de asociación entre el sector público y el privado.
Respaldar el establecimiento de normas para productos y servicios
relacionados con la sociedad de la información.
Para la materialización de sus labores, la ENISA lleva a cabo una serie de
publicaciones, tales como conferencias o eventos de seguridad, buenas
prácticas en materia de equipos de respuesta a incidentes, buenas prácticas
para la concientización del personal, temas sobre antivirus, ingeniería social,
análisis de riesgos, redes, entre otros.
Dentro de los documentos que se encuentran publicados en el sitio web de la
ENISA, no se cuenta con alguno que esté orientado exclusivamente al
establecimiento de un SGSI, sin embargo, existe un sitio dedicado
completamente a la gestión del riesgo (Risk Management) en el cual se hace
mención de los SGSI.
31
La ENISA considera la gestión del riesgo como la parte principal del SGSI, por
lo que en su sitio web publica amplia información del tema referido, en el cual
indica su importancia, describe su proceso, propone una estrategia para su
implementación y cita diferentes metodologías y herramientas existentes.
El tema en el cual la ENISA hace referencia al SGSI dentro de su publicación de
gestión de riesgos es “Administración de Riesgos y Sistemas de Gestión de
Seguridad de la Información (Risk Management and Information Security
Management Systems)” [9], el cual a su vez, se divide en tres puntos:
La necesidad de un SGSI (The Need for ISMS).
Factores críticos de éxito para los SGSI (Critical success factors for ISMS).
La estructura del SGSI (The ISMS Framework).
La necesidad de un SGSI. En este punto se hace hincapié sobre el hecho de
que la seguridad requiere de una administración y no debe considerarse
únicamente como un tema puramente técnico. La ENISA sustenta lo anterior en
datos estadísticos de expertos en seguridad, tales como el hecho de que un
administrador de seguridad invierte una tercera parte de su tiempo en aspectos
técnicos y las otras dos terceras partes en aspectos administrativos como el
desarrollo de políticas y procedimientos, elaboración de análisis de riegos y
planes de continuidad del negocio, difusión sobre concientización de seguridad,
por mencionar algunos. Asimismo, señala que el establecimiento,
mantenimiento y actualización de un SGSI provee un indicador de que una
organización está utilizando un enfoque sistemático para realizar la
identificación, evaluación y gestión de los riesgos de seguridad de la
información.
Factores críticos de éxito para los SGSI. Se menciona que un SGSI debe de
contar con lo siguiente para que sea efectivo:
32
Tener el compromiso inquebrantable del soporte por parte de la alta
gerencia de la organización.
Ser administrado de manera central, basado en una estrategia y una
política comunes para toda la organización.
Ser parte integral de la administración completa de la organización, la cual
esté relacionada al enfoque de gestión del riesgo, a los objetivos de
control y controles de seguridad y al grado de aseguramiento requerido.
Tener objetivos de seguridad y que las actividades estén alineadas a los
objetivos del negocio.
Llevar a cabo sólo las tareas necesarias y evitar exceso de controles y de
recursos.
Cumplir de manera integral con la filosofía de la organización.
Basar el SGSI en capacitación y concientización continuos del personal
que conforma a la organización.
Nunca considerar al proceso como terminado.
Se indica además, que el establecimiento del SGSI involucra establecer la
estructura de gestión, implementar los controles seleccionados, documentar el
sistema, aplicar el control apropiado para la documentación, y mantener
registros que demuestren su cumplimiento.
La estructura del SGSI. Se señala que el objetivo principal del SGSI es la
implementación de medidas apropiadas para eliminar o minimizar el impacto de
las diferentes amenazas y vulnerabilidades de la organización. Manifiesta
además, que no solamente el tamaño de la organización sino sus actividades
específicas de negocio, dictan sus requerimientos de seguridad en un nivel
operacional, regulatorio y legal.
Se señala que las pequeñas organizaciones con limitada infraestructura de
sistemas de información, de quienes no se demanda manejo de
almacenamiento y procesamiento de datos personales o confidenciales,
33
muestran menores riesgos o riesgos de baja probabilidad de impacto. Por lo
que estas organizaciones están orientadas a mantener un SGSI no
independiente y que forma parte de un proceso más amplio de administración
de riesgos.
Por otro lado, las grandes organizaciones como bancos e instituciones
financieras, de telecomunicaciones, hospitales e instituciones de salud y
públicas o gubernamentales, tienen bastantes razones para manejar su
información de manera muy seria. Por lo tanto, los requerimientos legales y
regulatorios están dirigidos al manejo de datos sensibles y personales, que
demandan de una mayor atención y prioridad en la administración de riesgos de
seguridad de la información. Por lo que la única alternativa, es contar con el
desarrollo e implementación de un proceso separado e independiente
denominado SGSI. En la figura 3.1 se muestran los 6 pasos para el desarrollo
de un SGSI que se manejan en el presente punto.
Figura 2. Estructura de un SGSI.
Framework, RM & ISMS, ENISA.
34
Los 6 pasos mostrados en la figura 2 son:
Definición de la política de seguridad.
Definición del alcance del SGSI.
Evaluación del riesgo.
Administración del riesgo.
Selección de los controles apropiados.
Declaración de aplicabilidad.
Se establece que los procesos de evaluación y administración del riesgo,
conforman el corazón del SGSI y que el primero de ellos se “transforma” en
manejo de reglas y políticas de seguridad y el otro, “transforma” objetivos del
SGSI en planes específicos para la implementación de controles y mecanismos
que minimicen vulnerabilidades y amenazas.
Los procesos y amenazas relativos a los pasos 5 y 6 (selección de controles
apropiados y declaración de aplicabilidad) no son parte de los riesgos de
información. Los controles están orientados a las acciones operativas que se
requieren para la implementación técnica, mantenimiento y control de las
medidas de seguridad.
Los controles de seguridad pueden ser derivados de conjuntos de controles y
mecanismos existentes que se encuentran incluidos comúnmente en
estándares y guías de seguridad, o pueden ser el resultado de una combinación
de controles propuestos para los requerimientos de una organización
específica.
El último paso, se refiere a la documentación de los riesgos identificados y
aplicados a la organización con la implementación técnica de los mecanismos
de seguridad que la citada organización ha decidido utilizar.
35
Se indica además, que los primeros pasos relativos a la “definición de la política
de seguridad” y a la “definición del alcance del SGSI” están orientados a la
administración y a temas estratégicos, mientras que los procesos de gestión de
riesgos son inherentes a la operación del “día a día”.
3.2 CONCLUSIONES.
A pesar de que la ENISA carece de una publicación en la que haga referencia
exclusivamente a los sistemas de gestión de seguridad de la información, en
uno de sus artículos se enfoca al tema de gestión de riesgos en el cual hace
mención de la importancia de contar con un SGSI, de algunos factores que son
determinantes para su buen funcionamiento y describe su estructura.
La ENISA considera la gestión del riesgo (evaluación y administración) como la
parte principal de un SGSI, por lo que dedica una publicación completa a la
evaluación, tratamiento, aceptación, monitoreo y revisión de riesgos; hace
mención y describe diferentes metodologías y herramientas existentes para la
gestión de riesgos y su implementación.
Si se hace referencia a la estructura de un SGSI, se observa que la información
que publica la ENISA, en su mayoría está enfocada a buenas prácticas para la
implementación de diferentes controles de seguridad y al análisis de riesgos,
del cual propone una gestión completa y lo toma como base para la creación de
políticas de seguridad y para realizar un monitoreo de los controles de
seguridad implementados.
36
CAPÍTULO IV.
NIST SP 800-53.
4.1 MARCO DE REFERENCIA.
El gobierno de los Estados Unidos de América, en reconocimiento a la
importancia que tiene la seguridad de la información para los intereses de
seguridad nacional y económicos de su país, emitió en el año 2002 la ley
“Federal Information Security Management Act of 2002” (FISMA)1 en la que se
decretan las medidas que deben aplicarse con el fin de asegurar la información
y los sistemas de información federal. En esta ley se designa al Instituto
Nacional de Estándares y Tecnología (NIST, National Institute of Standards and
Technology), para el desarrollo de estándares y guías de seguridad:
Estándares que sean utilizados por todas las agencias federales para que
lleven a cabo la categorización de su información y de sus sistemas de
información, basados en el objetivo de proveer niveles apropiados de
seguridad en la información de acuerdo a un rango de niveles de riesgo.
Guías que recomienden los tipos de información y sistemas de información
que deban ser incluidos en cada categoría.
Los requerimientos mínimos de seguridad de la información para cada
categoría de la información y sistemas de información.
1 Publicado en el título III de la “Public Law 107-347” del 17 de diciembre del 2002.
37
Los estándares y guías en los cuales se encuentran contenidos los lineamientos
para brindar seguridad a la información y a los sistemas de información federal
de los Estados Unidos de América y que pretenden dar cumplimiento con lo
establecido en la ley FISMA, son el FIPS-199, FIPS-200 y NIST SP 800-53. El
estándar FIPS-199 sirve para determinar la categorización de seguridad de la
información y de los sistemas de información en una organización federal, el
FIPS-200 muestra los requerimientos de seguridad mínimos con los que debe
cumplir y el NIST SP 800-53 propone un conjunto de controles de seguridad
base para aplicar de manera apropiada. Los dos primeros estándares sirven de
referencia al NIST SP 800-53, siendo esté último el que propone un esquema
de administración de controles de seguridad más amplio.
A continuación se hará una breve revisión de los estándares FIPS-199 y FIPS-
200 antes de abordar la publicación especial 800-53.
4.1.1. FIPS-199.
El estándar FIPS-199 es la publicación número 199 del NIST de los
Estándares de Procesamiento de Información Federal (Federal
Information Processing Standards), la cual se titula “Standards for
Security Categorization of Federal Information and Information Systems”
y tiene como objeto dar cumplimiento a lo establecido en FISMA de 2002
[10].
Las categorías de seguridad que establece el estándar están basadas en
el impacto potencial que tendría una organización si ocurriera un evento
que ponga en peligro la información y los sistemas de información
necesarios para cumplir con su misión. Para ello, establece tres objetivos
de seguridad:
38
Confidencialidad (Confidentiality). Preservar restricciones autorizadas
en el acceso y revelación de información, incluyendo los medios para la
protección de la privacidad de datos personales y la propiedad de
información. Define la pérdida de confidencialidad como la revelación no
autorizada de información.
Integridad (Integrity). Proteger contra la modificación o destrucción
indebida de información, e incluye el aseguramiento de no repudio y
autenticidad de información. Una pérdida de integridad es la modificación
o destrucción no autorizada de información.
Disponibilidad (Availability). Asegurar el acceso y el uso de
información en tiempo y de manera confiable. La pérdida de
disponibilidad es la interrupción del acceso o uso de la información o de
un sistema de información.
FIPS-199 indica tres niveles de impacto potencial, para los cuales debe
existir una brecha de seguridad (pérdida de confidencialidad, integridad o
disponibilidad).
Impacto potencial BAJO si, se espera que la pérdida de confidencialidad,
integridad o disponibilidad tenga un efecto adverso limitado en las
operaciones, activos o en los individuos de la organización.
Impacto potencial MODERADO si, se espera que la pérdida de
confidencialidad, integridad o disponibilidad tenga un efecto adverso
serio en las operaciones, activos o en los individuos de la organización.
Impacto potencial ALTO si, se espera que la pérdida de confidencialidad,
integridad o disponibilidad tenga un efecto adverso severo o
catastrófico en las operaciones, activos o en los individuos de la
39
organización.
El formato general que se utiliza para realizar la categorización de
seguridad en un tipo de información ó tipo de sistema de información es
el siguiente:
SCInformation type or Information system type = {(confidentiality, impact), (integrity,
impact), (availability, impact)}
Donde los valores aceptables para el impacto potencial son BAJO,
MODERADO, ALTO o NO APLICABLE para el caso de “tipo de
información” y BAJO, MODERADO o ALTO para el “tipo de sistema de
información”.
4.1.2. FIPS-200.
El estándar FIPS-200 “Requerimientos de seguridad mínimos para
información y sistemas de información federal”, al igual que FIPS-199,
tiene como objeto dar cumplimiento a lo establecido en FISMA de 2002
[11].
FIPS-200 cubre diecisiete áreas relativas a seguridad con la intención de
proteger la confidencialidad, integridad y disponibilidad de los sistemas
de información federal y la información que se procesa, almacena y
transmite por estos sistemas. Las diecisiete áreas son las siguientes:
- Control de Acceso (Access Control, AC).
- Concientización y Entrenamiento (Awareness and Training, AT).
- Auditoría y responsabilidad (Audit and Accountability, AU).
- Certificación, Acreditación y Evaluación de Seguridad, (Certification,
Accreditation and Security Evaluation, CA).
- Administración de Configuraciones (Configuration Management, CM).
40
- Planes de contingencia (Contingency Planning, CP).
- Identificación y Autenticación (Identification and Authentication, IA).
- Respuesta a Incidentes (Incident Response, IR).
- Mantenimiento (Maintenance, MA).
- Protección de Medios (Media Protection, MP).
- Protección Física y del Entorno (Physical and Environmental
Protection, PE).
- Planeación (Planning, PL).
- Seguridad en el Personal (Personnel Security, PS).
- Evaluación de Riesgos (Risk Assessment, RA).
- Adquisición de Sistemas y Servicios (System and Services
Acquisition, SA).
- Protección de Sistemas y Comunicaciones (System and
Communications Protection, SC).
- Integridad en los Sistemas e Información (System and Information
Integrity, SI).
Los controles de seguridad que se seleccionen en la organización para
alcanzar los requerimientos de seguridad mínimos manejados en este
estándar, deben basarse en lo que se encuentra contenido en la
Publicación Especial 800-53 del NIST.
4.2 NIST SP 800-53.
El NIST, como instituto que forma parte del Departamento de Comercio de los
Estados Unidos de América, tiene como misión promover la innovación y la
competitividad industrial a través del progreso de la ciencia, estándares y
tecnología, de tal manera que mejore la seguridad económica y proporcione
calidad de vida [12].
Como ya se mencionó anteriormente, la publicación especial 800-53 del NIST
41
propone un conjunto de controles de seguridad con el fin de que sean
implementados en una organización para brindar protección a la información y a
los sistemas de información de tipo federal [13]. Para la organización y
estructura de los controles de seguridad que establece el NIST SP 800-53, se
utiliza una clasificación de diecisiete familias de controles de seguridad
manejadas en el FIPS-200, a las cuales asigna un identificador de dos
caracteres, además de incluirlas dentro de tres clases generales de seguridad:
de administración, operacionales y técnicos (Tabla 4.1).
Asimismo, para identificar un control de seguridad dentro de una familia de
controles, se le agrega un identificador numérico.
IDENTIFICADOR FAMILIA CLASE
AC Control de Acceso Técnico
AT Concientización y Entrenamiento Operacional
AU Auditoría y Responsabilidad Técnico
CA Evaluación de Seguridad y Autorización Administración
CM Administración de Configuraciones Operacional
CP Planes de Contingencia Operacional
IA Identificación y Autenticación Técnico
IR Respuesta a Incidentes Operacional
MA Mantenimiento Operacional
MP Protección de Medios Operacional
PE Protección Física y de Entorno Operacional
PL Planeación Administración
PS Seguridad en el Personal Operacional
RA Evaluación de Riesgos Administración
SA Adquisición de Sistemas y Servicios Administración
SC Protección de Sistemas y Comunicaciones Técnico
SI Integridad del Sistema e Información Operacional
Tabla 2. Identificadores, familias y clases de controles de seguridad.
La estructura de los controles de seguridad que maneja el NIST SP 800-53 está
conformada por cuatro secciones clave:
42
Sección de Control. Provee un estado conciso de la capacidad de
seguridad específica necesaria para proteger un aspecto particular de una
organización o sistema de información.
Sección de Mejoras de Control. Proporciona estados de capacidad de
control para dar funcionalidad a un control básico y/o para incrementar la
fortaleza de un control.
Sección de Guía adicional. Provee información adicional y relativa al
control de seguridad específico.
Sección de Referencias. Incluye una lista de leyes federales aplicables,
Órdenes ejecutivas, políticas, directivas, estándares y guías que son
relevantes para un control de seguridad particular o para una mejora de
control.
El NIST SP 800-53, encuadra al proceso de selección y especificación de
controles de seguridad dentro de un programa de seguridad de la información
que se encuentra orientado a la administración del riesgo. Para ello, establece
un Marco de Administración del Riesgo (Risk Management Framework, RMF)
que cuenta con las siguientes actividades:
Categoriza (Categorize) el sistema de información y la información
procesada, almacenada y transmitida por el propio sistema, basado en un
análisis de impacto del FIPS-199.
Selecciona (Select) un conjunto de controles de seguridad de referencia
para el sistema de información basado en la categorización de seguridad
del FIPS-199 y en los requerimientos mínimos de seguridad definidos en
el FIPS-200. Indica la adecuación de los controles en base a una
evaluación de riesgos y propone como guía la publicación especial 800-30
43
“Guía de Administración de Riesgos para Sistemas de Tecnologías de
Información” (Risk Management Guide for Information Technology
Systems).
Implementa (Implement) los controles de seguridad y describe cómo son
empleados en componentes de hardware, software o firmware específicos
del sistema de información.
Evalúa (Assess) los controles de seguridad utilizando procedimientos de
evaluación apropiados para determinar que operen como se tiene previsto
y que produzcan los resultados deseados respecto a lo acordado en los
requerimientos de seguridad del sistema.
Autorizar (Authorize) la operación del sistema de información basada en
una determinación del riesgo para los activos y operaciones
organizacionales, individuos, otras organizaciones y la Nación como
resultado de la operación del sistema de información y la decisión de que
el riesgo es aceptable.
Monitorear (Monitor) los controles de seguridad en el sistema de
información en el que se incluya la evaluación de la efectividad del control,
la documentación de cambios en el sistema o en su entorno de operación,
conducir los análisis de impacto de seguridad de los cambios asociados y
reportar el estado de seguridad del sistema a las autoridades
organizacionales designadas.
La figura 4.1 ilustra las actividades específicas en el Marco de Administración
del Riesgo, los estándares y guías asociados con cada actividad.
El paso 1 se refiere a la categorización del sistema de seguridad que establece
el estándar FIPS-199 y el cual se mencionó anteriormente.
44
El paso 2 relativo a la selección de controles de seguridad, se encuentra
conformado a su vez por tres pasos:
- Seleccionar los controles de seguridad de referencia iniciales.
- Adaptar los controles de seguridad de referencia.
- Complementar los controles de referencia adaptados.
Figura 3. Marco de Administración de Riesgo (Risk Amanagement Framework).
Después de que los controles de seguridad son implementados (paso 3 del
RMF), evaluados en efectividad (paso 4 del RMF) y el sistema de información
es autorizado (paso 5 del RMF) para entrar en operación de acuerdo a la
estrategia de administración de riesgo de la organización, se inician las
acciones específicas de seguimiento como parte de un programa continuo de
NIST SP 800-53, Rev. 3.
45
monitoreo (RMF paso 6). El programa de monitoreo continuo incluye una
evaluación de la efectividad de los controles de seguridad para determinar si
existe la necesidad de modificar o actualizar el conjunto de controles actuales
basándose en cambios en el sistema o en su entorno de operación.
4.3 CONCLUSIONES.
Las publicaciones del NIST consideran un esquema de administración de
seguridad en los documentos FIPS-199, FIPS-200 y NIST SP 800-53, en los
cuales, el último de ellos es el que menciona una estructura referenciada
principalmente en los controles de seguridad que deben ser implementados en
una organización de tipo gubernamental. La publicación especial 800-53 tiene
como objetivo dar cumplimiento a ley establecida en el FISMA que tiene como
fin proteger la información y los sistemas de información de tipo federal,
asimismo, establece una organización y una estructura de controles de
referencia bien definida que debe servir a cualquier organización federal de los
Estados Unidos de América. Por lo tanto, esta publicación cumple con la parte
de alineación con la misión de la organización. Por la parte de políticas, se
cuenta con lo establecido en la ley del FISMA para llevar a cabo la protección
de la información y los sistemas de información de tipo federal, y a pesar de que
no sea una propuesta específica de elaboración de políticas, puede ser
considerada como una política general en la cual se fundamentan todos los
esfuerzos de seguridad en las agencias federales.
En la parte de análisis de riesgos se propone la utilización de la guía contenida
en la publicación especial 800-30, la cual se encuadra dentro del marco de
administración de riesgos que maneja el ciclo de mejora continua para llevar a
cabo el monitoreo de la efectividad de la aplicación de los controles de
seguridad y su retroalimentación con el fin de optimizar su empleo.
46
CAPÍTULO V.
DEPARTAMENTO DE DEFENSA DE LOS ESTADOS
UNIDOS DE AMÉRICA.
5.1 MARCO DE REFERENCIA.
El Departamento de Defensa de los Estados Unidos de América (DoD), es un
departamento ejecutivo federal que tiene como responsabilidad proveer las
fuerzas militares necesarias para disuadir en la guerra y proteger la seguridad
del país [14]. Las fuerzas militares citadas son el Ejército, la Marina, la Fuerza
Aérea y la Infantería de Marina (Army, Navy, Air Force and Marine Corps.). El
Secretario de Defensa ejerce autoridad, dirección y control sobre el DoD,
incluyendo la Oficina del Secretario de Defensa, el Presidente de la Junta de
Jefes de Estado Mayor, tres Departamentos Militares, nueve Comandos
Combatientes Unificados, el Inspector General del DoD, quince Agencias de
Defensa y siete Actividades de Campo del DoD.
La Oficina del Secretario de Defensa (Office of the Secretary of Defense, OSD)
es el elemento principal de personal del Secretario de Defensa en el ejercicio de
desarrollo de políticas, planeación, administración de recursos, fiscales y
programa de evaluación de responsabilidades [15]. La OSD incluye Asistentes
del Secretario de Defensa, de los cuales, el Asistente del Secretario de Defensa
para Redes e Integración de Información/Jefe de Información del DoD
(Assistant Secretary of Defense (Network and Information Integration)/DoD
Chief Information Officer, ASD (NII)/DoD CIO) es el encargado de asesorar,
47
entre otros asuntos, al Secretario y Subsecretario de Defensa en lo
concerniente a TI [16].
La Sección 2224 del Título 10 del Código de los Estados Unidos, Establece que
el Secretario de Defensa de los Estados Unidos debe llevar a cabo un
“Programa de Aseguramiento de Información de Defensa”, el cual proteja y
defienda la información y sistemas de información del DoD, así como las redes
de información que son críticas para el Departamento y para las fuerzas
armadas durante las operaciones del “día a día” y en tiempo de crisis [17].
El programa de Aseguramiento de la Información tiene como objetivos proveer
continuamente de disponibilidad, integridad, autenticación, confidencialidad, no
repudio y la rápida restitución de la información y de los sistemas de
información que son elementos esenciales en la infraestructura de Información
de la Defensa.
Para ello, el ASD (NII)/DoD CIO cuenta con publicaciones de documentos
relacionadas al Aseguramiento de Información, en los cuales da cumplimiento a
lo establecido en la sección 2224 del título 10 del Código de los Estados
Unidos, algunos de ellos son los siguientes:
Directiva del DoD 8500.01, “Aseguramiento de la Información (Information
Assurance, IA)” [18].
Instrucción del DoD 8500.2, “Implementación del Aseguramiento de la
Información (IA)” [19].
El primer documento, tiene como propósito establecer las políticas y asignar
responsabilidades para lograr el aseguramiento de información del DoD a
través de un enfoque de defensa en profundidad que integre las capacidades
de personal, operaciones y tecnología.
48
El segundo documento implementa las políticas establecidas en el primero,
asigna responsabilidades y prescribe procedimientos para proporcionar
protección integral a los sistemas de información y redes del DoD. A
continuación se describen cada uno de los citados documentos:
5.2 DIRECTIVA DEL DoD 8500.01.
La directiva contiene 26 políticas generales en las que se indica lo siguiente:
1. Los requerimientos de IA deben ser identificados e incluidos en el diseño,
adquisición, instalación, operación, actualización o reemplazo de todos los
sistemas de información del DoD.
2. Todos los sistemas de información deben mantener un nivel apropiado de
confidencialidad, integridad, autenticidad, no repudio y disponibilidad, que
refleje un balance entre la importancia y sensibilidad de la información y
los activos informáticos; amenazas y vulnerabilidades documentadas;
fiabilidad de usuarios y sistemas de interconexión; el impacto del deterioro
o destrucción de los sistemas de información y la efectividad del costo.
Para propósitos del IA, todos los sistemas de información del DoD deben
ser organizados y administrados en cuatro categorías: aplicaciones de
sistemas de información automatizados (Automated Information System
Application, AIS Application), enclaves1, procesos basados en
outsourcing de TI y plataforma de interconexión de TI.
3. El IA debe ser un elemento visible de todos los portafolios de inversión
incorporando sistemas de información propios del DoD o controlados, para
incluir procesos de negocio de outsourcing soportados por sistemas de
información del sector privado y tecnologías de outsourcing.
1 Enclave: colección de entornos de cómputo interconectados por una o más redes internas bajo el control de una sola autoridad y política de seguridad.
49
4. La interoperabilidad e integración de soluciones de IA dentro de o
soportando al DoD, deben ser alcanzadas a través de la incorporación a
una arquitectura que permita la evolución de guerra de red centralizada,
manteniendo consistencia con el Comando, Control, Comunicaciones,
Cómputo, Inteligencia, Vigilancia, Marco de Arquitectura de
Reconocimiento, y un enfoque de defensa en profundidad.
5. El DoD debe organizar, planear, evaluar, entrenar y conducir la defensa de
sus redes de cómputo como operaciones de defensa de red de cómputo
(Computer Network Defense, CND) las cuales son coordinadas a través
de múltiples disciplinas.
6. El IA debe ser monitoreado, reportado y evaluado como un elemento
distinguible de la misión a través de todos sus componentes y debe ser
validado por el CIO del DoD.
7. A todos los sistemas de información les debe ser asignada una categoría
de aseguramiento de la misión que esté directamente asociada con la
importancia de la información que contienen, la cual está relacionada al
alcance de las metas y objetivos, particularmente a la misión de combate.
8. El acceso a todos los sistemas de información debe ser basado en una
necesidad demostrada y garantizada de acuerdo con las leyes aplicables
del DoD.
9. Para el personal extranjero y representantes de naciones extranjeras,
coaliciones y organizaciones internacionales, pueden ser autorizados para
acceder a los sistemas de información del DoD que contienen información
clasificada o información sensible sólo bajo las condiciones establecidas
por el DoD.
10. Los usuarios externos al DoD, deben mostrar siempre su afiliación.
50
11. El acceso a sitios web del DoD, deben ser estrictamente controlado por el
propietario del sitio web utilizando medidas técnicas, operacionales o de
procedimientos.
12. Los sistemas de información del DoD deben regular el acceso remoto y el
acceso a Internet empleando controles técnicos, tales como servicios de
proxy y zonas desmilitarizadas (DMZ).
13. Todos los sistemas de información del DoD deben ser certificados y
acreditados de acuerdo con las instrucciones del DoD.
14. Todas las interconexiones de los sistemas de información del DoD deben
ser administradas para minimizar los riesgos.
15. Todos los sistemas de información del DoD deben cumplir con la guía de
puertos y protocolos del DoD y administración de procesos como se
encuentre establecido.
16. El conducto de todas las actividades de seguridad de comunicaciones del
DoD, incluyendo la adquisición de productos, debe ser de acuerdo a las
Directivas establecidas por el mismo departamento.
17. Todo el hardware, firmware y componentes de software o productos del IA
incorporados dentro de los sistemas de información del DoD deben
cumplir con los requerimientos de evaluación y validación de la Política de
Seguridad de Sistemas de Información y Telecomunicaciones de
Seguridad Nacional Número 11.
18. Todos los productos de TI del IA incorporados dentro de los sistemas de
información del DoD deben ser configurados de acuerdo a las guías de
configuración de seguridad aprobadas por el DoD.
19. Los productos de software de dominio público y otros productos de
51
software que no poseen garantía o poseen garantía limitada, solamente
deben ser usados en sistemas de información del DoD para cumplir los
requerimientos operacionales.
20. Los sistemas de información del DoD deben ser monitoreados en base a
la categoría de aseguramiento de la misión asignada y a la evaluación del
riesgo para impedir, detectar y reaccionar a intrusiones, interrupción de
servicios u otros incidentes que amenacen las operaciones del DoD o los
recursos de TI, incluyendo el mal uso interno.
21. Las vulnerabilidades de los sistemas de información del DoD que sean
detectadas, deben ser evaluadas de acuerdo al impacto del DoD y deben
tener un seguimiento y ser mitigadas conforme a las soluciones del
departamento.
22. Todo el personal autorizado para acceder a los sistemas de información
del DoD, debe ser capacitado adecuadamente conforme a las políticas del
DoD.
23. Los individuos deben ser notificados de sus derechos de privacidad y
responsabilidades de seguridad conforme a lo establecido en el DoD.
24. Las tecnologías móviles deben ser categorizadas y controladas para
reducir amenazas a los sistemas de información de acuerdo a lo
establecido en el DoD.
25. Una autoridad designada debe ser la encargada de la operación de cada
sistema de información del DoD, incluyendo sistemas de información
soportados por el sector privado y tecnologías de información contratadas
con organizaciones externas.
26. Todos los sistemas de voz y radio, incluyendo servicios de telefonía celular
y servicios comerciales, deben ser protegidos de acuerdo a la clasificación
y sensibilidad de la información transmitida en el sistema.
52
5.3 INSTRUCCIÓN DEL DoD 8500.2, IMPLEMENTACIÓN DEL IA.
El documento “Department of Defense, Instruction 8500.2”, se encuentra
conformado por la propia instrucción y cuatro apartados, de los cuales, los
apartados 3 y 4 describen la implementación del programa de IA. El apartado 3
provee una visión general del programa de IA del DoD.
El programa de IA se manifiesta a través de cinco competencias esenciales, las
cuales son el sello distintivo de cualquier programa de administración de
riesgos exitoso:
- La posibilidad de evaluar necesidades de seguridad y capacidades.
- La capacidad de desarrollar un propósito de diseño de seguridad o
configuración que se adhiera a una arquitectura común y maximice el uso
de servicios comunes.
- La capacidad de implementar los controles o salvaguardas requeridos.
- La capacidad de probar y verificar.
- La capacidad de administrar cambios en una referencia mínima
establecida y de una manera segura.
La integración del IA se lleva a cabo a través de múltiples sistemas de
información, los cuales aseguran el cumplimiento con los controles federales y
del IA del DoD. Para propósitos de administración del IA, los sistemas de
información del DoD se organizan dentro de cuatro categorías:
- Aplicaciones de Sistemas de Información Automatizados (Automated
Information System, AIS).
- Enclaves.
- Procesos basados en Outsourcing de TI.
- Plataforma de TI.
53
Aplicaciones de AIS. Una aplicación de un AIS es el producto o entregable de
un programa de adquisición de TI, el cual tiene fácilmente identificados los
requerimientos de seguridad que deben ser dirigidos como parte de la
adquisición. Estos requerimientos son establecidos de acuerdo a su categoría
de seguridad de la misión, a la clasificación o sensibilidad de la información y a
la necesidad de conocimiento (need-to-know)2.
Enclaves. Un enclave es definido por el DoD como una colección de entornos
de cómputo que está conectada por una o más redes internas y se encuentra
bajo el control de una sola autoridad y una política de seguridad. Ejemplos de
estos incluyen a las redes de área local y sus aplicaciones AIS operacionales,
backbones de redes y centros de procesamiento de datos. Los enclaves del
DoD entregan capacidades estándares de IA, tales como defensa perimetral,
respuesta y detección de incidentes y administración de llaves. También
entregan aplicaciones comunes como automatización de oficina y correo
electrónico.
Procesos basados en Outsourcing de TI. Incluyen procesos de negocio
soportados por sistemas de información del sector privado, tecnologías de la
información y servicios de información contratados con organizaciones
externas. Estos procesos pueden proporcionar funcionalidad asociada con una
aplicación, un enclave, una plataforma de TI o una combinación de estos.
Plataforma de Interconexión de TI. Plataforma de TI se refiere a recursos de
cómputo, software y hardware que son físicamente parte de, están dedicados a
o son esenciales en tiempo real al desempeño de la misión de sistemas de
propósito especial tales como armas, simuladores de entrenamiento, pruebas
de diagnóstico y mantenimiento de equipo, calibración de equipo, equipo
2 Término que se utiliza para indicar quiénes son las entidades autorizadas para conocer alguna información.
54
utilizado en la investigación y en el desarrollo de sistemas de armas,
tecnologías médicas, vehículos de transporte, construcciones y utilidades de
sistemas de distribución, tales como agua y energía eléctrica.
Asimismo, el programa de IA se encuentra conformado por las siguientes
partes:
Programa de Coordinación. Es efectuado por la Oficina del Sub-Asistente del
Secretario de Defensa para las Operaciones de Seguridad e Información a
través de una Oficina del Programa de Aseguramiento de la Información para
toda la Defensa (DIAP).
Controles de IA. El Programa de IA de Defensa establece un conjunto de
Controles de IA de referencia que son aplicados a todos los sistemas de
información del DoD. Los Controles de IA del DoD son proporcionados en el
apartado 4. Cada control es identificado de manera única y es catalogado
formalmente; puede ser referenciado, medido y reportado en todo el ciclo de
vida de un sistema de información del DoD.
Evaluación y revisión de la gestión del IA. Indica la obligación que tienen las
Agencias y Departamentos Federales para incluir planes de adquisición de
recursos para el IA.
Marco Técnico del IA. Bajo el liderazgo de la NSA3 y en asociación con el
NIST, los ingenieros en seguridad de sistemas, propietarios y usuarios de
sistemas, científicos, investigadores, vendedores de productos y servicios y
representantes de estándares y otros consorcios trabajan juntos para mantener
el Marco Técnico de Aseguramiento de Información (Information Assurance
Technical Framework, IATF). El IATF es una guía de referencia común para
aplicar adecuada y apropiadamente la tecnología del IA conforme a los
3 Agencia Nacional de Seguridad, National Security Agency, NSA.
55
principios de la arquitectura de defensa en profundidad descritos a
continuación:
- Defensa técnica en múltiples localidades.
- Defensas técnicas de capas. Maneja la implementación de múltiples
mecanismos de defensa entre el adversario y el objetivo.
- Robustez específica. Se implementa un nivel de fortaleza de
confidencialidad de acuerdo al valor que se está protegiendo y la
amenaza. Los niveles de robustez manejados son Alta, Media y Baja
robustez de mecanismos y servicios de seguridad.
Evaluación y especificación de productos. Las especificaciones para la
implementación de productos de TI para el IA se proporcionan en forma de
perfiles de protección.
Especificación de Configuración de Seguridad. Se proporcionan
especificaciones para la implementación de seguridad en la configuración de los
productos de TI del IA a través de guías desarrolladas por la NSA.
Administración de Conexiones. Se administra lo relativo a conflictos y
decisiones de conexión en la Red del Sistema de Información de la Defensa
(Defense Information System Network, DISN).
Defensa de Red en cómputo. Establece la responsabilidad que tiene el
Comandante del Comando Estratégico de los Estados Unidos para coordinar y
dirigir las operaciones de Defensa de Red en Cómputo (CND).
Infraestructura de administración de llave. Proporciona un proceso unificado
para la administración de productos criptográficos.
Servicios de Soporte del IA. Se proporciona soporte y mantenimiento al IA a
56
través de recursos basados en web.
En el apartado número 4 de la Instrucción 8500.2 se establecen los niveles
mínimos de seguridad de la información para los controles específicos del IA de
cada sistema.
La asignación de controles se realiza de acuerdo a la categoría de seguridad de
la misión y al nivel de confidencialidad. Las Categorías de Seguridad de la
Misión (Mission Assurance Category, MAC) son tres:
MAC I. Los sistemas requieren integridad alta y disponibilidad alta.
MAC II. Los sistemas requieren Integridad alta y disponibilidad media.
MAC III. Los sistemas requieren integridad y disponibilidad básicas.
Los niveles de confidencialidad son:
Información clasificada.
Información sensible.
Información pública.
Los niveles de referencia de aseguramiento de la información se establecen a
partir de las nueve combinaciones de los niveles de confidencialidad con las
MAC. Un Control de IA describe una condición de objetivo de IA para ser
alcanzada a través de la aplicación de salvaguardas específicos o de la
regulación de actividades específicas. La condición de objetivo puede ser
probada, su cumplimiento es medible y las actividades requeridas para alcanzar
el control de IA son asignables y por lo tanto cuentan con responsabilidad.
Un Control de IA está conformado por: tema, número, nombre y texto. Los
posibles temas se indican en la siguiente tabla:
57
Abreviación Nombre del tema.
DC Diseño y Configuración de Seguridad
IA Identificación y Autenticación
EC Enclave y Entorno de Cómputo
EB Defensa Perimetral de Enclave
PE Física y Entorno
PR Personal
CO Continuidad
VI Administración de Vulnerabilidades e Incidentes
Tabla 3. Temas de Control de IA.
5.4 CONCLUSIONES.
El DoD cuenta con un sistema de gestión de seguridad de la información bien
definido a través de diferentes documentos en los que se establecen las
políticas de seguridad, y el programa de aseguramiento de la información. No
Implementa explícitamente una metodología de análisis de riesgos, sin
embargo, aplica cinco competencias esenciales que según el programa de IA,
son parte de cualquier programa de administración de riesgos. Implementa
controles de seguridad mínimos categorizados de acuerdo a los diferentes
niveles de seguridad y clasificación de la información y sistemas de información
existentes en la organización. Adicionalmente, se apoya del NIST y la NSA para
algunos de los aspectos de implantación de su sistema de gestión.
Dentro del programa de aseguramiento de la información se cuenta con un
proceso de revisión y evaluación en el cual se realiza la parte de monitoreo de
seguridad de un SGSI.
58
CAPÍTULO VI.
COMPARATIVA DE LOS SISTEMAS DE GESTIÓN DE
SEGURIDAD INFORMÁTICA.
6.1. DESCRIPCIÓN.
En este capítulo se pretenden señalar los diferentes aspectos de seguridad que
conforman a cada uno de los documentos que fueron revisados en el presente
trabajo, con el fin de que sean plasmados en una comparativa que sirva de
referencia al administrador de seguridad de la información de una organización,
para llevar a cabo la selección de estos aspectos y su implementación en un
SGSI.
6.2. PARÁMETROS DE COMPARACIÓN.
Para llevar a cabo la elaboración de la comparativa se tomarán los siguientes
parámetros de comparación que, de alguna manera, son comunes a los
documentos revisados y forman parte de un SGSI:
- Alcance. Define el ámbito hacia donde se encuentra orientado el SGSI.
Puede ser para organizaciones de tipo comerciales, gubernamentales,
militares, sin fines de lucro, privadas, etc.
59
- Evaluación de riesgos. Se describe el tipo de metodología que se utiliza
para realizar el análisis de riesgos, puede ser propia del SGSI o adoptada
de otro tipo de estándar o institución.
- Política de seguridad. Se menciona si existe o se propone una política de
seguridad y de qué manera se lleva a cabo.
- Proceso de gestión. Describe el proceso a través del cual se lleva a cabo
la implementación del SGSI.
- Controles de seguridad. Se mencionan las familias o categorías de los
controles de seguridad que utiliza el SGSI.
6.3. ALCANCE.
El alcance que contemplan cada uno de los documentos revisados, es el
siguiente:
ISO/IEC 27001:2005. Se encuentra orientado a todo tipo de organizaciones,
privadas, gubernamentales, comerciales, etc. Es un estándar de aplicación
general.
ENISA. La información que publica ENISA en su portal, está dirigida a todo tipo
de instituciones de la Unión Europea, aunque no cuenta con un sistema de
gestión propio y la información publicada está basada en la ISO/IEC
27001:2005.
NIST SP 800-53. Está dirigido a todas las instituciones gubernamentales de los
Estados Unidos de América.
Directiva 8500.01 e Instrucción 8500.02 del DoD. Se encuentran orientados
hacia organizaciones militares, específicamente para las áreas que conforman
60
al Departamento de Defensa de los Estados Unidos de América.
A continuación se muestra la tabla 6.1 con la comparativa de los diferentes
alcances que tienen los documentos revisados.
DOCUMENTO DE SGSI ALCANCE
ISO/IEC 27001:2005 Todo tipo de organizaciones.
ENISA Todo tipo de organizaciones de los Estados Miembros de
la Unión Europea.
NIST SP 800-53 Organizaciones gubernamentales de los Estados Unidos
de América.
DoD Departamentos, oficinas, agencias y todas las
organizaciones que conforman el Departamento de
Defensa de los Estados Unidos de América.
Tabla 4. Comparativa del alcance de los SGSI.
6.4. EVALUACIÓN DE RIESGOS.
Las metodologías de análisis de riesgos que utilizan los diferentes documentos
revisados son las siguientes:
ISO/IEC 27001:2005. Hace mención sobre la evaluación de riesgos y propone
el empleo del ISO/IEC TR 13335-3 como referencia para la implementación de
una metodología. No cuenta con una metodología propia.
ENISA. Indica los conceptos generales sobre evaluación de riesgos y menciona
diferentes metodologías que son conocidas a nivel internacional.
NIST SP 800-53. Describe la forma en que se debe implementar la evaluación
de riesgos y hace referencia a la publicación especial 800-30 en la que se
encuentra la metodología detallada.
61
DoD. No cuenta con una metodología de análisis de riesgos, en cambio, se
basa en cinco competencias esenciales que forman parte de cualquier
programa de administración de riesgos.
DOCUMENTO DE SGSI METODOLOGÍA PROPIA
DE ANÁLISIS DE RIESGOS
OBSERVACIONES.
ISO/IEC 27001:2005 Sí Propone la revisión de la ISO/IEC
27005.
ENISA No Proporciona información general y
muestra algunas metodologías.
NIST SP 800-53 Sí Cuenta con una metodología
descrita en NIST SP 800-30.
DoD No Establece cinco competencias
esenciales para realizar la
administración de riesgos
Tabla 5. Comparativa de metodología de análisis de riesgos.
6.5. POLÍTICA DE SEGURIDAD.
En este rubro se considera la proposición de políticas o el cumplimiento de una
política establecida para llevar a cabo el SGSI. Las políticas son consideradas
en los SGSI estudiados como se indica a continuación:
ISO/IEC 27001:2005. Propone la elaboración de políticas como parte de los
controles de seguridad. Debido a que es un estándar de referencia, hace
mención de que debe existir una política de seguridad de la información, por lo
que no cuenta con una política en la cual se deba apegar específicamente.
ENISA. No cuenta con una política de seguridad en la cual se deba apegar y
debido a que no establece un SGSI, sólo hace referencia a la ISO/IEC
27001:2005.
62
NIST SP 800-53. El NIST es un documento que tiene como intención dar
cumplimiento a la ley FISMA, en la cual se establece la política de seguridad de
la Información para las organizaciones gubernamentales de los Estados Unidos
de América.
DoD. El DoD da cumplimiento a la Sección 2224 del Título 10 del Código de los
Estados Unidos de América a través de la Directiva 8500.01, en la cual
establece las políticas de seguridad de la información
DOCUMENTO DE SGSI POLÍTICA DE
SEGURIDAD
OBSERVACIONES.
ISO/IEC 27001:2005 Sí Propone la implementación de la política de
seguridad e indica la manera de realizarla.
ENISA No Sólo recomienda basarse en la ISO/IEC
27001:2005.
NIST SP 800-53 Sí Comprendida en la ley FISMA 2002 de E.U.A.
DoD Sí Contenida en la Directiva 8500.01
Tabla 6. Comparativa de implementación de políticas de seguridad.
6.6. PROCESO DE GESTIÓN.
En el proceso de gestión se definen los pasos generales a seguir para la
implementación, mantenimiento y mejora del SGSI. A continuación se
mencionan los procesos de gestión para cada uno de los documentos
revisados:
ISO/IEC 27001:2005. El proceso se encuentra basado en el modelo de mejora
continua PDCA, en el cual se establecen cuatro fases principales: establecer y
administrar; implementar y operar; monitorear y revisar; y mantener y mejorar.
La ENISA no cuenta con un proceso de gestión y sólo hace referencia al
ISO/IEC 27001:2005.
63
NIST SP 800-53. El proceso de gestión se establece en el Marco de
Administración del riesgo. Considera 6 pasos para realizar su implementación.
DoD. El DoD no cuenta con un proceso de gestión específico, no obstante
utiliza las cinco competencias esenciales para llevar a cabo la administración
del riesgo y enfoca la administración del programa de IA en los sistemas de
información del DoD, los cuales se dividen en cuatro categorías.
DOCUMENTO DE SGSI PROCESO DE
GESTIÓN
OBSERVACIONES.
ISO/IEC 27001:2005 Sí Utiliza la metodología PDCA.
ENISA No Sólo recomienda basarse en la ISO/IEC
27001:2005.
NIST SP 800-53 Sí Implementa el proceso a través del Marco de
Administración del Riesgo.
DoD No Se basa en las cinco competencias esenciales
de la administración del riesgo y se enfoca en
los sistemas de información del DoD.
Tabla 7. Comparativa de procesos de gestión.
6.7. CONTROLES DE SEGURIDAD.
Los controles de seguridad de la información son los salvaguardas que se
utilizan para llevar a cabo el cumplimiento de las políticas de seguridad que
establece la organización. Para cada uno de los documentos de SGSI
revisados los controles de seguridad son considerados de la siguiente manera:
ISO/IEC 27001:2005. Establece en su anexo A 11 categorías de seguridad, 38
objetivos de control y 133 controles de seguridad.
ENISA. Nuevamente hace referencia a la ISO/IEC 27001:2005.
64
NIST SP 800-53. Cuenta con 17 familias de controles de seguridad basados en
tres clases de controles: operacionales, técnicos y administrativos.
DoD. Establece en su apartado número 4, los controles de seguridad mínimos
que deben aplicarse en los sistemas de información del DoD, los cuales están
basados en cuatro tipos de sistemas de información. Además, los controles
deben considerar las categorías de seguridad de la misión y los niveles de
confidencialidad de la información.
DOCUMENTO DE SGSI CONTROLES DE
SEGURIDAD
OBSERVACIONES.
ISO/IEC 27001:2005 Sí 11 Categorías de seguridad, 38 objetivos de
control y 133 controles.
ENISA No Sólo recomienda basarse en la ISO/IEC
27001:2005.
NIST SP 800-53 Sí 17 familias de controles de seguridad divididos
en tres clases (Administrativos, técnicos y
operacionales).
DoD No Recomienda los controles mínimos de
seguridad a implementar en los sistemas de
información del DoD, basados en tres
categorías de la misión y en tres niveles de
confidencialidad de la información.
Tabla 8. Comparativa de controles de seguridad.
6.8 CONCLUSIONES.
Los documentos revisados en el presente trabajo, muestran diferentes maneras
de implementar un SGSI en una organización. Mientras el ISO/IEC 27001:2005
es un documento que se encuentra orientado a cualquier tipo de organización,
los documentos del NIST SP 800-53 y la Instrucción 8500.02 del DoD están
enfocadas a organizaciones específicas de tipo gubernamental la primera y de
tipo militar la segunda. Estos últimos documentos, cuentan con características
65
muy específicas que se encuentran orientadas al tipo de funciones que realizan
y a la información que manejan.
66
CONCLUSIONES.
En la revisión de los documentos mencionados en el presente trabajo, se observan
diferentes maneras de implementar un SGSI en una organización, las cuales
dependen, entre otras cosas, del tipo de alcance que establezca el documento, la
forma de evaluar los riesgos, los controles de seguridad y su manera de
implementarlos, así como el proceso de gestión del sistema en el cual se consideran
fases para planear, establecer, implementar, revisar y mejorar el SGSI.
Los resultados obtenidos en la revisión de los documentos de SGSI, pueden ser
utilizados como guía por un administrador de seguridad de la información, para llevar
a cabo la materialización de un SGSI; todo dependerá de las necesidades propias de
seguridad de la organización. Deberá considerar el tipo de información que maneja,
su clasificación y categorización, el objetivo y misión de la organización en la que
pretende implementar el SGSI, la necesidad de realizar una evaluación de riesgos o
si partirá de la implementación de controles mínimos de seguridad, así como las
fases que deberá establecer para llevar a cabo el proceso de gestión del sistema.
Estos factores serán determinantes para realizar la selección del SGSI, el cual puede
tomar como referencia un documento completo de SGSI, o establecer su propio
SGSI a partir de diversos componentes de más de un documentos.
Como se mencionaba en el esquema europeo, es recomendable que el proyecto de
gestión de la seguridad de la información se implemente bajo un esquema dedicado
e independiente, siempre y cuando el tipo de organización cuente con sistemas de
información cuya importancia sea evidente para la organización.
67
Asimismo, el enfoque del NIST al proponer controles de base (mínimos necesarios)
para un sistema de gestión, es relevante pensando en que un sistema de gestión se
inscribe en un ciclo de mejora continua, como lo refieren los estándares ISO, y por lo
tanto se espera que se mejore o adecue conforme los cambios (amenazas,
vulnerabilidades, nuevas tecnologías, etc.) del entorno lo demanden.
Es importante señalar que estos cambios del entorno deben ser monitoreados
continuamente mediante un esquema de análisis y gestión de riesgos.
68
RECOMENDACIONES.
Los documentos revisados en el presente trabajo fueron seleccionados por el autor
utilizando un criterio en el cual se consideraron diferentes ámbitos de organizaciones,
tratando de que fueran representativos para los objetivos establecidos. Asimismo, los
documentos fueron revisados de tal manera que presentaran información general y
que sirvieran como una guía para llevar a cabo la selección de los componentes que
permitan el establecimiento de un SGSI en una organización, pero sin profundizar
demasiado en cada uno de sus aspectos. Por lo tanto, se recomienda que para aquel
administrador que tome como referencia el presente trabajo, realice una revisión
detallada de los componentes que por su importancia para la organización, requieran
ser implementados como parte de un SGSI.
69
REFERENCIAS BIBLIOGRÁFICAS.
[1] Fernández-Medina Patón Eduardo, “Seguridad de las Tecnologías de la
Información”, Ediciones AENOR (Asociación Española de Normalización y
Certificación), España, 2003.
[2] Huerta, Antonio Villalón. “Seguridad en Unix y Redes (Versión 1.2)”.
[3] RFC 1244, “Site Security Handbook”. J. Reynolds - P Holbrook, Julio 1991.
[4] Universidad de Oriente (UNIVO), El Salvador. “Manual de normas y políticas de
seguridad informática”.
[5] “Gestión del riesgo: Principios de implementación de herramientas y métodos
para la evaluación y gestión del riesgo para inventarios”, Agencia de Redes y
Seguridad de la Información de la Unión Europea (ENISA), 2006.
[6] “ISO/IEC 27001:2005, Information Technology -- Security techniques --
Information security management systems – Requirements”, Organización
Internacional para la Estandarización/Comisión electrotécnica Internacional,
ISO/IEC año 2005.
[7] International Organization for Standardization, International Standards for
Business, Government and Society, By TC, JTC 1 Information Technology, SC
27.
[9] Risk Management: Implementation principles and Inventories for Risk
Management/Risk Assessment methods and tools, Technical Department of
ENISA Section Risk Management, June 2006.
[10] “Standards for Security Categorization of Federal Information and Information
Systems”, Federal Information Processing Standards Publication 199 (FIPS-
199), Computer Security Division, Information Technology Laboratory, National
Institute of Standards and Technology, February 2004.
[11] “Minimum Security Requirements for Federal Information and Information
Systems”, Federal Information Processing Standards Publication 200 (FIPS-
200), Computer Security Division, Information Technology Laboratory, National
Institute of Standards and Technology, March 2006.
[13] NIST Special Publication 800-53 Revision 3, Recommended Security Controls
70
for Federal Information Systems and Organizations, National Institute of
Standards and Technology, U.S. Department of Commerce, Computer Security
Division, Information Technology Laboratory, Join Task Force, Transformation
Initiative, June 2009.
[16] Department of Defense Directive, Number 5144.1, Deputy Secretary of Defense,
May 2, 2005. United States of America.
[17] “Defense Information Assurance Program”, Section 2224, Chapter 131, Part IV,
Subtitle A, Title 10, United States Code, January 8, 2008.
[18] “Information Assurance (IA)” Department of Defense Directive Number
8500.01E, October 24, 2002, Certified Current as of April 23, 2007, ASD
(NII)/DoD CIO.
[19] “Information Assurance (IA) Implementation”, Department of Defense Instruction
Number 8500.2, February 6, 2003.
71
REFERENCIAS CIBEROGRÁFICAS
[8] Portal de la Unión Europea, Agencias de la Unión Europea, Agencias
Comunitarias, ENISA. (Consultada en junio de 2009). Disponible en:
http://europa.eu/agencies/community_agencies/enisa/index_es.htm.
[12] www.nist.gov/public_affairs/general2.htm.
[14] The Department of Defense Organizational Structure, Organization and
functions guide, Director of Administration & Management, Office of the
Secretary of Defense, updated March 2008. (Consultado en junio de 2009).
Disponible en: http://www.defenselink.mil/odam/omp/pubs/GuideBook/DoD.htm.
[15] Office of the Secretary of Defense, June 2009. Disponible en:
http://www.defenselink.mil/osd/.