GUÍA METODOLÓGICA 2012

GUÍA METODOLÓGICA 2012

PROGRAMA DE MEJORAMIENTO DE LA GESTIÓN Y

METAS DE EFICIENCIA INSTITUCIONAL SISTEMA DE SEGURIDAD DE LA INFORMACIÓN

Etapa I – Diagnóstico

Etapa II – Planificación Etapa III – Implementación

Etapa IV – Evaluación Junio 2012

Red de Expertos Secretaría y Adm. General del Min. del Interior – División Informática Dirección de Presupuestos del Min. de Hacienda – División Tecnologías de la Información

RED DE EXPERTOS PMG/MEI – SSI 2012 ______________________________________________________________________

2

Contenido Historial de revisiones ............................................................................................................ 3Objetivo y Alcance de esta Guía Metodológica ...................................................................... 4

Objetivo .............................................................................................................................. 4Alcance de la Guía Metodológica ....................................................................................... 4Cómo usar esta Guía Metodológica ................................................................................... 4

Sistema de Seguridad de la Información ............................................................................... 5Antecedentes ...................................................................................................................... 5Objetivo del SSI ................................................................................................................... 5Ventajas de contar con un SSI ............................................................................................ 5Roles y responsabilidades en el SSI Institucional ............................................................... 6Rol de la Red de Expertos ................................................................................................... 8Factores críticos de éxito .................................................................................................... 8

Descripción general de las etapas del Sistema ..................................................................... 10ETAPA I: Diagnóstico ............................................................................................................. 12

Acciones a realizar en la etapa I ....................................................................................... 12Documentos a entregar .................................................................................................... 12

ETAPA II: Planificación .......................................................................................................... 15Acciones a realizar en la etapa II ...................................................................................... 15Documentos a entregar .................................................................................................... 15

ETAPA III: Implementación ................................................................................................... 19Acciones a realizar en la etapa III ..................................................................................... 19Documentos a entregar .................................................................................................... 19

ETAPA IV: Evaluación ............................................................................................................ 21Acciones a realizar en la etapa IV ..................................................................................... 21Documentos a entregar .................................................................................................... 21

Plazos y Medios .................................................................................................................... 24ANEXO I: Instrumentos 2012 ............................................................................................... 25ANEXO II: Ejemplos de indicadores ..................................................................................... 36ANEXO III: Actividades para la implementación de controles ............................................. 42ANEXO IV: Plan de Auditorías ............................................................................................... 88ANEXO V: Activos de Información y la Normativa NCh-ISO 27001 ...................................... 90ANEXO VI Normativa vigente ............................................................................................... 97


3

Historial de revisiones Nº Revisión

Fecha Aprobación

Motivo de la revisión Páginas Modificadas

Autor

1 3-abril-2012 Reformulación de las etapas de Diagnóstico y Planificación, e inclusión de etapa 4 de Evaluación.

Todas Equipo Red de Expertos PMG-SSI DIPRES.

2 27-abril-2012 Modificaciones anexos. 81 a la 87 Equipo Red de Expertos PMG-SSI DIPRES.

3 29-mayo-2012

Modificación etapas 3 y 4. Anexo 4. 25 a 30 y 83 en adelante

Carola Córdova Red de Expertos PMG-SSI DIPRES.

4 05-junio-2012 Modificación etapas 1, 2. 19 a 25 Felipe Morales Red de Expertos PMG-SSI DIPRES.

5 05-junio-2012 Redefinición de la estructura del documento.

Todas a excepción de los anexos

Carmen Contreras Maria Teresa Villarroel Red de Expertos PMG-SSI DIPRES.

6 11-junio-2012 Incorporación de contenidos faltantes. 5 a 15 Felipe Morales Red de Expertos PMG-SSI DIPRES.

7 13-junio-2012 Corrección de ortografía, redacción y estilo. Incorporación de contenidos faltantes y diagramas en las etapas.

Todas Carola Córdova Red de Expertos PMG-SSI DIPRES.


4

Objetivo y Alcance de esta Guía Metodológica Objetivo El objetivo de esta Guía es presentar de manera detallada el desarrollo de cada uno de los requisitos técnicos asociados a las distintas etapas que componen el Sistema de Seguridad de la Información en el marco del Programa de Mejoramiento de la Gestión y las Metas de Eficiencia Institucional (PMG/MEI SSI)1

, facilitando a los servicios públicos verificar el cumplimiento de los objetivos comprometidos.

Alcance de la Guía Metodológica Esta Guía entrega los lineamientos para la presentación de los requisitos técnicos del Sistema de Seguridad de la Información (SSI). El desarrollo de algunos requisitos pudiera requerir del uso de herramientas que no son descritas en profundidad en esta Guía y, en general, el empleo de conocimientos, capacidades y habilidades que se suponen existentes en cada uno de los servicios comprometidos en el Sistema. Sin embargo, a lo largo de la Guía se enfatizan ciertos aspectos en los que se considera conveniente profundizar. Cómo usar esta Guía Metodológica El cuerpo central de la Guía se divide en tres partes: La primera de ellas describe el SSI, sus objetivos y elementos constitutivos. En una segunda parte, más extensa, se detallan las cuatro etapas del Sistema, su relación, las acciones necesarias y los medios para reportar su cumplimiento a la Red de Expertos del PMG/MEI. Y en la tercera se exponen los plazos y medios por los cuales se de debe remitir esta información. Además, se incluyen documentos anexos que cada Encargado del SSI puede utilizar como referencia. Esto es, información a ser estudiada en función del marco legal2

, que incorpora los decretos supremos y leyes que rigen el manejo de información en las instituciones.

Una vez estudiados tales antecedentes, en el anexo I de la Guía se entregan instrucciones sobre la forma en que se debe completar los formatos dispuestos por la Red de Expertos3

para verificar el cumplimiento de los requisitos técnicos en las diferentes etapas. Es recomendable ajustarse a tales instrucciones de modo que se pueda dar cuenta de manera completa y coherente de los requisitos.

1 Cuando este documento menciona el Sistema de Seguridad de la Información (SSI), se refiere al mismo en el marco del

PMG y las MEI, indistintamente. 2 Ver sección “Sistema de Seguridad de la Información”, apartado “Legislación y otros documentos de apoyo”, en sitio

Web www.DIPRES.gob.cl 3 Ver sección “Sistema de Seguridad de la Información”, apartado “Instrumentos 2012”, en sitio Web

www.DIPRES.gob.cl


5

Sistema de Seguridad de la Información Antecedentes A raíz de la publicación de la Ley Nº 19.799 Sobre Documentos Electrónicos, Firma Electrónica y servicios de certificación de dicha firma, en el año 2004 se publicaron una serie de decretos supremos a fin de reglamentar y operativizar distintos aspectos de la mencionada ley, en el marco del concepto de “Gobierno Electrónico” y del proceso de modernización del Estado. Uno de esos instrumentos, el Decreto Supremo N° 83 / 2005 - SEGPRES, planteó un código de prácticas para la gestión de la seguridad de la información en los órganos del Estado. Hacia el año 2007 el Ministerio del Interior, Coordinador del Subcomité de Gestión de Seguridad y Confidencialidad del Documento Electrónico, detectó que en las instituciones del sector público persistían algunas falencias respecto de estos temas, entre las cuales se menciona: Aplicaciones y sistemas informáticos con configuración inadecuada, sitios web de gobierno implementados deficitariamente y con vulnerabilidades conocidas, redes informáticas institucionales con debilidades en sus mecanismos de control de acceso y de regulación del tráfico de datos, problemas de continuidad operacional frente a incidentes de índole recurrente, como los cortes de energía eléctrica, e inexistencia de políticas de seguridad institucionales. A mediados del año 2009 el Comité de Ministros que rige el desarrollo del Programa de Mejoramiento de la Gestión (PMG), en el marco de la ley Nº 19.553, toma la decisión de incluir en el PMG, a partir de 2010, al Sistema de “Seguridad de la Información” – dentro del Área de Calidad de Atención a Usuarios – con el fin de enfrentar los problemas de seguridad detectados, y cuya asistencia técnica queda a cargo de la Red de Expertos conformada por analistas de la Secretaría y Administración General del Ministerio del Interior y de la Dirección de Presupuestos del Ministerio de Hacienda, con el fin de darle el debido impulso a la implementación de las normativas de gestión de seguridad. Igualmente, durante el año 2011, en el contexto de la Ley 20.212 se realiza lo propio para las Metas de Eficiencia Institucional, para su ejecución a partir de 2012. En este contexto se incluyó la Norma Chilena ISO 27001 como referente normativo, cuya propuesta incorpora todo tipo de activos de información, complementando al DS 83. Objetivo del SSI El objetivo del Sistema de Seguridad de la Información es “lograr niveles adecuados de integridad, confidencialidad y disponibilidad para toda la información institucional relevante, con el objeto de asegurar continuidad operacional de los procesos y servicios, a través de un sistema de gestión de seguridad de la información”4

.

Ventajas de contar con un SSI El SSI es una herramienta de apoyo a la gestión de una institución pública. Dado que la información es uno de los activos más importantes de toda organización moderna, requiere ser

4 Documento Técnico “Programa de Mejoramiento de la Gestión (PMG). Año 2012. Programa Marco Básico.


6

protegida convenientemente (junto a los procesos y sistemas que la manejan) frente a amenazas que puedan poner en peligro la continuidad de los niveles de servicio, rentabilidad social y conformidad legal, necesarios para alcanzar los objetivos institucionales. Actualmente, el conjunto de activos de información institucional (documentos en papel, bases de datos, sistemas y software de aplicación, equipos informáticos, redes de transmisión de datos, soportes de almacenamiento, y otros elementos de infraestructura) están sujetos a diferentes tipos de riesgos e inseguridades tanto desde dentro de la propia organización como desde fuera de ella. El SSI da la posibilidad de disminuir en forma significativa el impacto de los riesgos a los que están sometidos los activos de información. Para ello se hace necesario conocerlos y afrontarlos de manera ordenada, y a través de la participación proactiva de toda la institución, contemplar los procedimientos adecuados y planificar e implantar controles de seguridad basados en una evaluación de riesgos y en una medición de la eficacia de los mismos. Por otra parte, el SSI permite ir conformando un marco de gobierno para la seguridad de la información institucional, al establecer políticas, procedimientos y controles en relación a los objetivos estratégicos de la institución, con objeto de mantener siempre el riesgo por debajo del nivel aceptable por la propia organización. Para ello se contempla la designación del Encargado de Seguridad de la Información, la conformación de un Comité de Seguridad y la aprobación de una Política General de Seguridad Institucional, que exprese adecuadamente el compromiso del alto directivo público. A nivel estratégico, para los directivos de la institución, el SSI es una herramienta que les ofrece una visión global sobre el estado de sus activos de información, las medidas de seguridad que se están aplicando y los resultados que se están obteniendo de dicha aplicación. Todos estos datos permiten a la dirección una toma de decisiones sobre la estrategia a seguir. Mediante el SSI, la organización puede conocer los riesgos a los que está sometida su información y gestionarlos mediante una planificación definida, documentada y conocida por todos, que se revisa y mejora constantemente, atendiendo a los controles y objetivos de control que propone la normativa NCh-ISO 27001. Desde el punto de vista del desempeño institucional, facilita la entrega fluida de los bienes y servicios a los clientes/usuarios/beneficiarios, mediante la formulación de un Plan de Continuidad de Negocio, que permite enfrentar de forma correcta la continuidad operacional para los procesos institucionales relevantes, la contingencia tecnológica, especificando escenarios de catástrofe y fallas a enfrentar, y el manejo de crisis, estableciendo la estrategia de gestión en situaciones de contingencia. Roles y responsabilidades en el SSI Institucional Para el desarrollo del SSI, será necesario aunar el trabajo de los profesionales y técnicos de todas las áreas, con el fin de implementar adecuadamente los proyectos de interés institucional. Este equipo multidisciplinario permitirá establecer las responsabilidades, logrando la especialización en cada uno de los dominios de la NCh-ISO 27001, obteniendo resultados de calidad satisfactoria.


7

Dentro del desarrollo del Sistema se deberá tener presente al siguiente personal: 1. Directivos.

Dada la magnitud y relevancia de la tarea, se requiere de la participación activa de los más altos directivos de la institución, ya sea para entregar las orientaciones básicas, como para tomar las decisiones que influirán en el modo de operar del servicio público. Adicionalmente, es importante contar con un fuerte liderazgo y compromiso de los directivos que soporten la intervención de los procesos que se buscan mejorar. El rol que cumplen, no puede delegarse sin una significativa pérdida de credibilidad respecto a la seriedad del esfuerzo. En el caso específico del Jefe de Servicio, concretamente es quien aprueba las políticas de seguridad y valida el proceso de gestión de Seguridad de la Información, sanciona las estrategias y mecanismos de control para el tratamiento de riesgos que afecten a los activos de información institucionales, que se generen como resultado de los reportes o propuestas del Comité de Seguridad de la Información (CSI), así como los recursos necesarios para su ejecución.

2. Comité de Seguridad de la Información (CSI).

Tiene la responsabilidad de supervisar la implementación de procedimientos y estándares que se desprenden de las políticas de seguridad de la información, proponer estrategias y soluciones específicas para la implantación de los controles necesarios para implementar las políticas de seguridad establecidas y la debida solución de las situaciones de riesgo detectadas, arbitrar conflictos en materia de seguridad de la información y los riesgos asociados, y proponer soluciones sobre ello, coordinarse con los Comités de Calidad y de Riesgos de la institución, para mantener estrategias comunes de gestión y reportar a la Alta Dirección, respecto a oportunidades de mejora en el SGSI, así como de los incidentes relevantes y su gestión. Se recomienda que el CSI esté integrado por los siguientes funcionarios: a) Jefe Operaciones o Tecnologías de Información. b) Jefe de Recursos Humanos. c) Encargado de Calidad. d) Encargado de Riesgos. e) Asesor Jurídico (Abogado de la Institución). f) Jefes de Áreas Funcionales o encargados de procesos, si corresponde. g) Encargado de Seguridad de la Información (ESI).

3. Encargado de Seguridad de la Información (ESI).

Es un funcionario nombrado por el Jefe de Servicio como su asesor directo en materia de seguridad de la información. Debe organizar las actividades del CSI, coordinar la debida respuesta y priorización al tratamiento de incidentes y riesgos vinculados a los activos de información de los procesos institucionales y sus objetivos de negocio, monitorear el avance general de la implementación de las estrategias de control y tratamiento de riesgos, tener a su cargo el desarrollo inicial de las políticas de seguridad al interior de la institución, controlar su implementación y velar por su correcta aplicación, así como mantener coordinación con otras unidades del Servicio para apoyar los objetivos de seguridad y establecer puntos de enlace con


8

los Encargados de Seguridad de otros organismos públicos y especialistas externos, que le permitan estar al tanto de las tendencias, normas y métodos de seguridad pertinentes.

4. Profesionales y técnicos.

Un elemento importante en el equipo multidisciplinario que implementa y opera en el SSI es la activa participación de profesionales y técnicos seleccionados, que entienden y manejan el desarrollo de los procesos dentro de la institución. Para lo anterior, es necesario que cumplan con los perfiles acordes a los cargos, dado que ellos entregarán los antecedentes y atenderán los requerimientos en la práctica.

5. Otros funcionarios.

Además, será necesario incluir al personal que pueda ser relevante para el correcto desarrollo del programa de implantación del SSI, ya sea directa o indirectamente, entre otros: Personal a cargo de la gestión de calidad, dueños de procesos estratégicos de la institución o de procesos de provisión de productos y servicios, abogados/as del área jurídica, profesionales del área de tecnologías de la Información, personal del área de recursos humanos y de gestión de riesgo.

Rol de la Red de Expertos La Red de Expertos del SSI, tiene como misión fundamental brindar asistencia técnica a las instituciones que comprometen etapas del SSI. Para ello contempla las siguientes funciones: 1. Propones los Requisitos Técnicos del Sistema al Comité de Ministros del PMG/MEI. 2. Diseñar la Guía Metodológicas e instrumental para el desarrollo del Sistema. 3. Realizar labores de asistencia técnica directa en el desarrollo del SSI, al personal encargado por

parte de cada institución5

4. Elaborar un cronograma de trabajo global para establecer hitos en la asistencia técnica, que permitan conocer el avance de las instituciones participantes.

.

5. Evaluar el avance presentado por las instituciones durante la ejecución del SSI. 6. Asesorar a la Secretaría Técnica del PMG/MEI, en materias relacionadas con la preparación del

proceso de validación final del Sistema.

Factores críticos de éxito La experiencia ha demostrado que los siguientes factores con frecuencia son críticos para una exitosa implementación de la seguridad de la información dentro de una organización: 1. Una política de seguridad, objetivos y actividades que reflejen la misión institucional. 2. Un enfoque para implementar, mantener, monitorear y mejorar la seguridad de la información

que sea consistente con la cultura institucional. 3. El apoyo visible y compromiso de la alta dirección. 4. Comprensión de los requisitos de seguridad, de evaluación del riesgo y de su gestión. 5. Comunicación efectiva en la seguridad de la información con todos los directivos, jefes de

división, funcionarios y otras partes interesadas.

5 Esta asistencia técnica se brinda mediante la asignación de un analista por parte de DIPRES y otro por parte de la

Subsecretaría del Interior. DIPRES entrega asistencia técnica en los aspectos metodológicos y de gestión del SSI, y la S. Interior lo hace en los aspectos tecnológicos y de gestión de incidentes. Ver sección “Sistema de Seguridad de la Información”, apartado “Analistas PMG SSI”, en sitio Web www.dipres.gob.cl


9

6. Distribución de lineamientos sobre la política de seguridad de la información para todos los jefes de división, funcionarios y otras partes involucradas.

7. Provisión de recursos para las actividades de gestión de la seguridad de la información. 8. Provisión del conocimiento, capacitación y educación apropiados para lograr conciencia sobre

el tema. 9. Un proceso de gestión de incidentes de seguridad de la información. 10. Implementación de un sistema de medición para evaluar el desempeño en la gestión de la

seguridad de la información y adoptar las sugerencias de mejoramiento.

Estos factores se tornan operativos a través de los controles, procedimientos o estándares que se deben ir implementando progresivamente en el SSI.


10

Descripción general de las etapas del Sistema El SSI ha sido concebido con una estructura compuesta de cuatro etapas que son de carácter progresivo y acumulativo: Diagnóstico, Planificación, Implementación y Evaluación. Estas cuatro etapas reflejan el ciclo de mejora continua (PDCA: Plan – Do – Check - Act), como se observa en la figura 4, integrando en ellas los principales elementos constitutivos del SSI. Figura N°1: Ciclo de mejora continua en el SSI

Fuente: Elaboración propia. En la etapa de Diagnóstico institucional, se identifican y priorizan los activos relevantes de información que sustentan los procesos de provisión institucionales. Asimismo, esta etapa exige la realización de un análisis de los riesgos que afectan a tales activos, posibilitando identificar controles y objetivos de control, a partir de los elementos señalados en la NCh-ISO 27001.

Como producto de esta etapa se obtiene un inventario de activos estructurado que debe ser objeto de actualización permanente, a lo largo del ciclo de vida del Sistema.

En la etapa de Planificación, se toman los controles identificados en la etapa anterior, y en base a ellos se formulan iniciativas para su adecuada implementación, que deben ser volcadas en planes de trabajo de carácter anual. En esta etapa además se deben establecer los elementos del marco de gobierno para la seguridad de la información institucional, y adicionalmente formular los indicadores de gestión que se usarán posteriormente para realizar mediciones sobre la efectividad del SSI.

2


11

En la etapa de Implementación, se ejecutan las iniciativas detalladas en el programa de trabajo y se miden los indicadores formulados. En la etapa de Evaluación, se debe analizar todo el proceso desarrollado y difundir sus resultados, hacer las recomendaciones necesarias y velar por su implementación. Al mismo tiempo, se compromete un sistema de control y mejora continua, en el cual se establecen las revisiones de los resultados de los indicadores, la actualización del inventario y la gestión de los riesgos de SI.

Para el reporte de cada una de las etapas los servicios deben presentar los documentos correspondientes que permitan dar cuenta del cumplimiento de los requisitos técnicos. En la siguiente figura se especifican para cada una de ellas: Figura N°2: Documentos a presentar por etapas del SSI

Fuente: Elaboración propia. (*) Esta corresponde a la planilla electrónica de “Instrumentos 2012”, que se explica en detalle en el ANEXO I de esta Guía Metodológica.


12

ETAPA I: Diagnóstico Acciones a realizar en la etapa I 1. Diagnosticar la situación de SI institucional, poniendo énfasis en la adecuada identificación de

los activos de información vinculados a los procesos de provisión, para llegar a conformar un inventario de activos de información debidamente priorizado en términos de criticidad.

2. Para los activos con criticidad media y alta, especificar los riesgos más relevantes y los correspondientes controles que permiten su mitigación de aquellos que propone la NCh-ISO 27001 y el Decreto Supremo N°83.

3. Establecer el nivel en que la institución se encuentra con respecto a tales controles. 4. Determinar las brechas e iniciativas a ser abordadas en el Plan General de Seguridad de la

Información institucional. Documentos a entregar Figura N° 3: Documentación para reportar la etapa I


1. Alcance del SSI (oficio).

El diagnóstico se focaliza en la correcta identificación de los activos de información de la institución, que están vinculados en especial a sus procesos de provisión. Ellos corresponden a los necesarios para la obtención de los productos estratégicos (ver Ficha de Definiciones Estratégicas, formulario A1 de cada servicio, en el sitio www.dipres.gob.cl).


13

Para comenzar con las actividades requeridas en el diagnóstico, es preciso establecer el alcance del Sistema, esto es decidir si se comenzará con una selección de los procesos de provisión de bienes y servicios o con la totalidad de ellos. Para tomar tal decisión se debe adoptar como referencia aquellos declarados por la institución en sus definiciones estratégicas vigentes.

La selección del (los) proceso(s)/producto(s) debe realizarse considerando los siguientes criterios: • Porcentaje de la dotación asociado al proceso / producto. • Alcance geográfico del proceso / producto. • Frecuencia de aplicación del proceso / producto. • Porcentaje del presupuesto asociado a al proceso / producto. • Porcentaje de Ciudadanos/ Clientes/ Usuarios/ Beneficiarios que reciben el producto. Para efectos del desarrollo del SSI, se deberá fundamentar debidamente la selección realizada, indicando las métricas asociadas a cada uno de estos criterios.

La decisión que tome el servicio deberá comunicarla a la Red de Expertos – DIPRES mediante un oficio, acompañando el análisis antes señalado. Se recomienda que este documento sea trabajado previamente con la Red de Expertos – DIPRES a través del/la Analista correspondiente, a fin de que la fundamentación sea la más precisa y conduzca a la institución hacia un trabajo acotado a sus capacidades y con el impacto necesario.

2. Inventario de Activos de Información (planilla).

La realización de cada uno de los procesos estratégicos de provisión, involucra activos de información específicos que son generados / modificados / utilizados en cada una de las etapas relevantes de tales procesos.

Es importante identificar y caracterizar adecuadamente los activos de información vinculados a los procesos de provisión considerados en el alcance, porque de esta forma se permite mostrar las condiciones en las cuales éstos se encuentran, dadas las diferentes etapas de los procesos en los que participan. Indican bajo qué circunstancias está cada activo en la institución, ya sea en cuanto a su tipificación, condiciones físicas, responsabilidades asociadas, procedimientos para su tratamiento y sus requerimientos en confidencialidad, integridad y disponibilidad, conducentes a definir la criticidad del activo. Es relevante tener en cuenta que la descripción de tales condiciones, y la criticidad definida, orientan respecto de los riesgos que puede enfrentar un determinado activo. Es necesario que el encargado PMG/MEI-SSI, como también todos los funcionarios que tengan participación en el llenado del Inventario de Activos, cumplan con la totalidad de los pasos necesarios, a fin de asegurar las consistencia requerida para pasar al análisis de riesgos.

3. Análisis de Riesgo (planilla):

En el mismo documento donde se especifica el inventario de activos de información, en una hoja siguiente se detalla el análisis de los riesgos, dado que una vez identificados los activos


14

se requiere caracterizar los riesgos que los amenazan, cuantificando el nivel de severidad y el tratamiento necesario, sobre la base de los controles de seguridad para su mitigación, del conjunto que propone la NCh 27001. Al determinar el o los controles que se necesitan para cada riesgo, se debe señalar si los productos asociados a ellos existen en la institución. En ese caso se define como un control cumplido; al contrario, si un control no se ha implementado, éste representa una brecha a superar y se debe señalar como no-cumplido. Dicho análisis conduce a determinar el nivel de cumplimiento que tiene el servicio respecto del que debiese tener para mitigar sus riesgos de SI, reflejándose en la misma planilla, en la hoja correspondiente, de forma automática. Cabe señalar que en los controles que se declare cumplimiento se debe explicitar el documento que permite evidenciarlo, de modo que la Red de Expertos, u otro ente interno o externo a la Institución pueda solicitarlo de forma inequívoca. Se debe entender que los productos son las políticas, procedimientos, instrucciones u otros medios escritos que instauren un determinado control, creando la institucionalidad necesaria para su sustentabilidad en el tiempo. Este análisis puede implicar que el servicio no incluya todos los controles de SI que propone la norma. No obstante, la Red de Expertos ha determinado un conjunto de controles prioritarios, los cuales deben ser parte de la definición de aquéllos que es necesario a desarrollar.


15

ETAPA II: Planificación

Acciones a realizar en la etapa II La etapa de planificación entrega la organización de las actividades, uso de recursos y productos a generar en las etapas siguientes. Los productos y sus actividades asociadas incluidas en esta etapa adquieren la calidad de compromisos, a los cuales se les realizará un seguimiento que continúa en la etapa de Evaluación. Las acciones concretas son: 1. Formular o actualizar la Política General de Seguridad de la Información, formalizada por el

Jefe Superior del Servicio. 2. Nombrar al Encargado de Seguridad de la Información. 3. Conformar al Comité de Seguridad de la Información. 4. Definir el Plan General de Seguridad de la Información institucional, para el año en curso y

siguientes. 5. Elaborar el Programa de Trabajo Anual para iniciar la implementación del plan de seguridad

de la información definido. 6. Establecer los indicadores que permitirán evaluar la eficacia del SSI.

Documentos a entregar En virtud de que las etapas son acumulativas, cuando se haya comprometido la etapa de planificación también se debe reportar el diagnóstico actualizado. Por lo tanto, a los documentos propios de la etapa se agregan los de la anterior. Figura N° 4: Documentación para reportar la etapa II



16

1. Política de Seguridad (documento y/o resolución).

Se debe definir una Política General de Seguridad de la Información (PGSI), garantizando con ello que existe una declaración institucional que enfatiza el compromiso de la dirección con los objetivos de gestión de seguridad de la información. La política debe contar con los siguientes contenidos: • Una definición de seguridad de los activos de información, sus objetivos globales, alcance

e importancia. • Los medios de difusión de sus contenidos al interior de la organización. • Su re-evaluación periódica, a lo menos cada tres años. • La periodicidad con que se evaluará su cumplimiento. • Aprobación del Jefe de Servicio.

La Red de Expertos establece que la política debe ser realizada de acuerdo a los formatos que la institución estime convenientes, debiendo contemplar estos contenidos mínimos de manera explícita.

2. Nombramiento del Encargado de Seguridad (resolución). En el marco de Política General de SI, el Jefe de Servicio deberá designar, como asesor directo en estas materias, a un Encargado de Seguridad de la Información, considerando las siguientes funciones en la Resolución de nombramiento6

:

• Tener a su cargo el desarrollo inicial de las políticas de seguridad al interior de su organización y el control de su implementación, y velar por su correcta aplicación.

• Coordinar la respuesta a incidentes que afecten a los activos de información institucionales.

• Establecer puntos de enlace con encargados de seguridad de otros organismos públicos y especialistas externos que le permitan estar al tanto de las tendencias, normas y métodos de seguridad pertinentes.

3. Constitución del Comité de Seguridad (resolución o acta constitutiva firmada).

Paralelamente se deberá conformar un Comité de Seguridad de la Información, señalando sus funciones específicas7

.

Se sugiere que dicho Comité esté conformado por el Encargado de Seguridad, quien lo debería presidir, y por las personas que desempeñen los roles que a continuación se indican: • Jefe Operaciones o Tecnologías de Información. • Jefe de Recursos Humanos. • Encargado de Calidad.

6 Para mayores detalles ver el capítulo “Sistema de Seguridad de la Información”, apartado “Roles y responsabilidades

en el SSI Institucional” de esta Guía Metodológica. 7 Ídem.


17

• Encargado de Riesgos. • Asesor Jurídico (Abogado de la Institución). • Jefes de Áreas Funcionales o encargados de procesos, si corresponde.

La resolución o el acta constitutiva del CSI debe contener sus integrantes y las funciones. Entre los integrantes no puede estar el Encargado de Auditoría Interna del servicio, por cuanto no puede ser parte del Sistema que luego ha de ser objeto de las auditorías.

4. Plan General de Seguridad de la Información (planilla). Teniendo el marco institucional que implica la política general, el nombramiento del Encargado y la conformación del CSI, se debe dar forma al Plan General de Seguridad de la Información, para el año en curso y siguientes. Esta es la definición clara y operativa de los productos que se busca alcanzar. Este plan se puede realizar en el mismo documento en el cual se ha trabajado el inventario de activos y el análisis de riesgos, en la hoja correspondiente, dado que se deben considerar los resultados del diagnóstico, riesgos y brechas detectados en la Etapa I. El Plan debe ser consistente con la identificación de los productos necesarios definidos, especificar los responsables de su desarrollo y los plazos para su obtención. En el caso de los controles priorizados por la Red de Expertos, deben incorporarse en la planificación para realizarse durante la etapa 3 y/o el primer año de ejecución.

5. Programa de Trabajo Anual (planilla u opción de carta Gantt aparte).

Se debe elaborar un Programa de Trabajo Anual, para implementar las acciones del primer año del plan de seguridad de la información definido, que incluya hitos, actividades, plazos y responsables, y las acciones orientadas a difusión/capacitación/sensibilización a todos los funcionarios sobre el programa de trabajo y sus productos. Este se puede reportar en la misma hoja donde se presenta el plan general, pero se debe dar detalle de actividades para el primer año. También se puede remitir en una Carta Gantt en Project, resguardando que contenga todos los requisitos técnicos específicos.

6. Definición de indicadores (planilla):

Con el objeto de evaluar de manera objetiva la efectividad de la implementación del SSI para mitigar los riesgos definidos, se debe establecer indicadores de desempeño. Estos indicadores se deben planificar para ser medidos en la etapa de implementación y analizar los resultados en la etapa de evaluación. Es importante que la orientación que se le dé a estas métricas se asocie a los resultados del SSI, es decir, evitar indicadores que apunten sólo a los procesos o a la implementación del Sistema.


18

Otro elemento a considerar al momento de formular los indicadores, es que una vez que el SSI egrese del marco PMG/MEI, éstos serán una fuente de información importante respecto del desempeño del SSI, los cuales deberán ser revisados y mejorar en forma sucesiva. En el contexto de un servicio que egresa, estos indicadores han de ser susceptibles de ser incorporados en el Formulario F, sobre indicadores de desempeño institucional. En esta línea la Red de Expertos ha sugerido una serie de métricas que pueden comenzar a ser medidas por el servicio8

.

En el mismo documento donde se están desarrollando todas las planillas (inventario, riesgos, plan), se puede presentar los indicadores.

8 Ver Anexo II: Ejemplos de Indicadores de esta Guía Metodológica.


19

ETAPA III: Implementación

Acciones a realizar en la etapa III 1. Implementar el programa de trabajo anual definido en la etapa anterior. 2. Registrar y controlar los resultados de la implementación del programa de trabajo verificando

el avance en el nivel de cumplimiento de los controles que requiere el servicio. 3. Comenzar a medir los indicadores definidos. Documentos a entregar En virtud de que las etapas son acumulativas, cuando se haya comprometido la etapa de implementación, también se debe reportar el diagnóstico y la planificación con las actualizaciones correspondientes. Por lo tanto, a los documentos propios de la etapa se agregan los de las anteriores. Figura N° 5: Documentación para reportar la etapa III

Fuente: Elaboración propia. (*) Esta corresponde a la planilla electrónica de “Instrumentos 2012”, que se explica en detalle en el ANEXO I de esta Guía Metodológica. 1. Ejecución de actividades (planilla).

En la misma planilla de trabajo del SSI, en la hoja correspondiente, se debe registrar el término real de las actividades cuantificando las desviaciones. Se debe prever que las desviaciones admisibles son aquéllas que no implican el incumplimiento del compromiso en el año de implementación (enero a diciembre). Cualquier otro tipo de desviación deberá contar con una causa justificada, externa a la gestión del servicio, debiendo ser verificada y aceptada por la Red de Expertos.


20

El registro de la implementación de un determinado producto, asociado a un control desde el diagnóstico, se debe plasmar señalando la evidencia de ello. Dicha evidencia debe contener el control para el cual fue definida, de lo contrario no es válida como tal.

2. Avance en la implementación (planilla). El avance en la implementación se registra de forma automática y verídica siempre y cuando la institución realice lo señalado en el párrafo anterior. Esto es muy importante, porque la exposición del nombre de la evidencia permitirá dar cuenta de que el control está cumplido, por lo tanto incrementará el nivel de avance en la implementación de los dominios.

3. Medición de indicadores (planilla).

Se debe aplicar los indicadores diseñados en la etapa II y mostrar los resultados efectivos, en la misma hoja en que fueron formulados. De tales resultados dependerá la formulación de las metas para el siguiente período o si es necesario reformular indicadores. Es atendible que haya algunos indicadores con mayor data de medición que otros, puesto que en la etapa de implementación habrá algunos productos que posibilitarán la medición antes que otros.


21

ETAPA IV: Evaluación Acciones a realizar en la etapa IV La finalidad de esta etapa es llevar a cabo la verificación y validación del Sistema de Seguridad de la Información, tanto en su operación como en los aspectos que aún pudieran estar bajo implementación (plan general de SI). Ésto permitirá retroalimentar dicho Sistema facilitando la corrección de debilidades y su mejora continua efectiva. Las acciones concretas son: 1. Evaluar los resultados de la implementación del Plan General de Seguridad de la Información

y Programa de Trabajo Anual, y formular recomendaciones de mejora. 2. Difundir a los funcionarios los resultados de la evaluación del Plan y Programa de Trabajo

Anual. 3. Diseñar el Programa de Seguimiento a partir de las recomendaciones formuladas. 4. Mantener del grado de desarrollo del Sistema de acuerdo a cada una de las etapas. Documentos a entregar En virtud de que las etapas son acumulativas, cuando se haya comprometido la etapa de evaluación, también se debe reportar el diagnóstico, la planificación y la implementación con las actualizaciones correspondientes. Por lo tanto, a los documentos propios de la etapa se agregan los de las anteriores. Figura N° 6: Documentación para reportar la etapa IV



22

1. Evaluación de los Resultados Plan General (planilla y evidencias). Corresponde a una o varias acciones en las cuales la institución haya evaluado en detalle el proceso de implementación. El número y magnitud de tales acciones dependerá de la estructura del SSI, del tamaño de la institución y el nivel de madurez que haya alcanzado. Sí es preciso que se dé cuenta de manera explícita de que se consideró la revisión del porcentaje de cumplimiento logrado y que esto lo realice el CSI, los resultados de las actividades desarrolladas y la efectividad en la mitigación de riesgos –en este punto es fundamental haber analizado el resultado de los indicadores-, identificar los riesgos persistentes y otras debilidades, y su análisis de causa, y las recomendaciones de mejora, que consideren medidas correctivas y preventivas. La evaluación del SSI debe ser conocida y valorada por el CSI. Las conclusiones y recomendaciones que del Comité emanen deben quedar reflejadas en la correspondiente acta de sesión y ser incluidas en el Programa de Seguimiento de esta etapa, siendo consistentes. La realización de las actividades evaluativas se deben demostrar con evidencias, que deben ser registradas en la planilla y entregada como medios de verificación. Estas pueden ser actas de sesiones del CSI, informes de auditorías, registros revisiones por la dirección u otras. En ellas debe señalarse que tales acciones se realizaron, de manera inequívoca.

2. Difusión de los resultados de la implementación (planilla y evidencias). Corresponde a una o varias acciones destinadas a dar a conocer a los funcionarios los resultados obtenidos en la implementación. En algunos casos puede ser necesario mostrar algunos resultados a clientes, usuarios y beneficiarios. El número y magnitud de tales acciones dependerá de la estructura del SSI, del tamaño de la institución y el nivel de madurez logrado. La realización de tales actividades se debe demostrar con evidencia, que debe ser registrada en la planilla y entregada como medios de verificación. En ellas debe señalarse que tales acciones se realizaron, de manera inequívoca, y deben ser consistentes con los resultados obtenidos. Se hace presente que estas actividades no son las mismas que se planificaron para difundir y capacitar en torno a políticas y procedimientos u otros requerimientos de la fase de implementación, sino que están destinadas a que los funcionarios conozcan los logros alcanzados.

3. Programa de Seguimiento de Recomendaciones (planilla). El proceso de evaluación descrito en el punto I de este apartado debe dar origen a recomendaciones. Éstas se traducen en compromisos que las instituciones deben cumplir, a fin de corregir aspectos que hayan quedado con déficit en la implementación y su registro es en la planilla, en la hoja correspondiente, señalando el plazo y el responsable. Estos compromisos deben ser planificados y ejecutados en el más breve plazo posible. Hay algunas mejoras que requerirán más tiempo y pueden ser cerradas el año siguiente, pero aquéllas de fácil realización no se pueden extender, puesto que dilatan situaciones de carencia que impiden el avance y maduración del SSI, por ejemplo, corrección de aspectos puntuales en


23

los procedimientos, re-estructuración acotada de equipos de trabajo, actualizaciones pendientes, entre otras.

4. Sistema de Control y Mejora Continua (planilla).

Dado que esta es la última etapa del SSI en el marco del PMG/MEI, se debe establecer un conjunto de medidas articuladas que permitan sostener y mejorar el Sistema en el tiempo, más allá del proceso de implementación. Para cubrir tal finalidad es que las instituciones deben proponer un sistema de control y mejora continua, que al menos establezca una planificación que considere, a partir del período siguiente, las revisiones regulares del SSI, que pueden ser las que realiza el CSI, auditorías internas o externas, revisiones por la dirección, estudios u otras. También se debe incluir la revisión de indicadores y metas, el establecimiento de medidas de mejora a partir de sus resultados y la aprobación de tales medidas por parte del CSI o Dirección. Y un tercer aspecto, la actualización del inventario de activos y su incorporación a la gestión de riesgos institucional. Este último punto es fundamental, porque el inventario y la gestión de riesgos son elementos dinámicos en el SSI. La actualización del inventario permitirá ir ampliando el alcance del Sistema y poner al día la caracterización de los activos, que puede cambiar en el tiempo a medida que se toman acciones de protección que mitigan sus riesgos. Por otra parte, los servicios cuentan con una metodología institucional de gestión de riesgos, en la cual se debiera considerar el trabajo que se realiza en la misma línea para el SSI. Es importante converger en un mismo proceso de gestión de riesgos, evitando duplicidades e ineficiencias.


24

Plazos y Medios La documentación requerida en el proceso de validación del SSI debe ser reportada por los mecanismos, y de acuerdo a las instrucciones, que serán entregadas por la Secretaría Técnica del PMG/MEI. No obstante, la Red de Expertos, en el contexto de la asistencia técnica, ha establecido para el año 2012 tres hitos en los cuales las instituciones pueden remitir información para ser revisada, simulando un proceso de evaluación, cuyo objetivo es verificar el cumplimiento de los requisitos, conocer los avances y señalar de forma explícita los puntos donde pueda haber errores u oportunidades de mejoras, de manera que los servicios puedan hacerlas oportunamente y así, incrementar sus posibilidades de cumplimiento al cierre del período. Las fechas de tales hitos son las siguientes: • 31 de Mayo de 2012, 18 hrs. • 16 de Agosto de 2012, 18 hrs. • 31 de Octubre de 2012, 18 hrs. En cada hito los documentos deben ser enviados a la Red de Expertos aprobados por el Jefe de Servicio, en formato electrónico, a través del aplicativo dispuesto para ello en la sección de acceso restringido del sitio Web DIPRES: http://www.dipres.gob.cl Cada uno de estos hitos es de carácter voluntario, por lo tanto el hecho de que una institución no reporte información sólo implica que no tiene una visión por parte de la Red de Expertos de su situación, pero esta omisión no es vinculante respecto de la evaluación final. En acuerdo con la Red de Expertos y el o la Analista asignada, el servicio puede solicitar otras revisiones parciales, pero éstas no necesariamente implican una revisión en profundidad como la realizada en estos tres hitos. Esto se explica porque la Red de Expertos debe organizar adecuadamente los recursos de que dispone para poder realizar tales revisiones con la seriedad y calidad requeridas. Se recomienda un monitoreo mensual a los encargados PMG/MEI, con énfasis en el primer semestre para que en base a esa información se pueda apoyar la formulación presupuestaria con miras al siguiente periodo.

Este documento de origen electrónico, una vez impreso, pasa a ser copia no controlada y puede

quedar obsoleto. Para obtener la versión vigente, ir a http://www.dipres.gob.cl

http://www.dipres.gob.cl/�



25

ANEXO I: Instrumentos 2012 Recomendaciones Generales La planilla de instrumentos que ha sido confeccionada para su llenado contiene vínculos entre las hojas, así como también parámetros, por lo que se recomienda no alterarla para no afectar estas características. Fue creada de esta forma para dar cuenta del ciclo de mejora continua y la relación entre las etapas de diagnóstico-planificación-implementación-evaluación, traspasando los datos que vinculan las etapas entre las hojas del archivo instrumentos. Etapa 1: Diagnóstico 1. Hoja “Etapa 1 – Inventario”.

Este instrumento tiene por objetivo recoger el conjunto de los activos de información asociados a los procesos de provisión de bienes y servicios de la institución, cuyos productos estratégicos se encuentran en la Ficha A1. En él se deben considerar todos los activos de información de los procesos.

Los campos de esta hoja son los siguientes:

DESCRIPCIÓN DE PROCESOS Proceso: Corresponde al nombre del proceso de negocio (de provisión de productos/servicios estratégicos) al cual pertenecen los activos de información a incluir en el inventario. Subproceso: Son aquellos subprocesos en los que puede estar dividido el proceso transversal mencionado en la columna anterior, dependiendo de la complejidad del mismo. Etapa relevante: Detalle de las fases más importantes que se deben desarrollar en cada subproceso para dar origen a los productos.

IDENTIFICACIÓN DE ACTIVOS DE INFORMACIÓN Activo: Nombre del activo de información, en este campo debe incluirse todos los activos de información identificados para la etapa, independiente de su medio de soporte y sus características. Esta columna se encuentra destacada con azul pues es una de las que dan consistencia entre esta hoja y la siguiente. Identificador o código: En este campo de debe incluir el código dado por la institución al activo, en caso de corresponder a un activo de información no inventariado, este campo se debe completar con un número correlativo, que permita identificar en forma única al activo. Tipo: Clasificación del activo, estos pueden ser: • Persona: Funcionario o personal a honorarios que participa en un proceso de negocio. • Documento: Corresponde a un escrito que refleja el resultado de una acción determinada

y sustenta la toma de decisiones por parte de quien la administra y accede a ella. • Base de Datos: Es la información sistematizada y organizada.


26

• Formulario: Corresponde a documentos utilizados para recoger información. • Software: Programa computacional empaquetado producido por una empresa que lo

comercializa. • Sistema: Programa computacional desarrollado por la institución o por un externo a

medida, cuyo objetivo es apoyar un proceso de negocio. • Equipos: Objetos o dispositivos que realizan o apoyan la realización de una función. • Infraestructura: Construcción que permite alojar algunas o todas las funcionalidades de la

institución. • Expediente: Conjunto de documentos y formularios dispuestos en estricto orden de

ocurrencia, de ingreso o egreso. Este puede ser físico o electrónico, en cuyo caso la definición está dada por el DS 81: “Documento electrónico compuesto por una serie ordenada de actos y documentos representados en formato electrónico, dispuestos en estricto orden de ocurrencia, de ingreso o egreso en aquél, y que corresponde a un procedimiento administrativo o asunto determinado”.

Ubicación: Corresponde al lugar físico donde se encuentra el activo mientras es utilizado en el proceso, esta descripción debe ser lo suficientemente detallada como para determinar a partir de esta información las condiciones de seguridad física en las que se encuentra el activo. Responsable/dueño: Corresponde al rol o cargo de la persona propietaria del activo.9

Soporte: Corresponde al medio en el cual se encuentra registrado el activo, este puede ser en papel o digital. Manipulación: Identificación de la(s) persona(s) que utiliza(n) el activo de información, ya sea modificándolo, actualizándolo, trasladándolo o limpiándolo. Persona autorizada para copiar: Corresponde al rol o cargo de la(s) persona(s) autorizada para copiar el activo (aplicable al activo de información en papel y copias en medios magnéticos). Medio de almacenamiento: Descripción de la forma de guardar el activo cuando no está en uso dentro del proceso mismo. Tiempo de retención: Corresponde al tiempo en el cual el activo de información debe ser mantenido por la Institución en el medio de almacenamiento. Disposición: Corresponde al destino que se le da al activo de información una vez transcurrido el tiempo de retención. Recuperación (criterio): Forma en la cual es posible buscar el activo de información. En lo específico, es el criterio de búsqueda o los datos con los cuales se puede localizar el activo.

Algunos de los elementos de esta caracterización no aplican a todos los activos. Ej.: la característica Soporte no aplica al activo Persona.

9 Considerar la definición establecida en la NCH-ISO 27002


27

ANÁLISIS DE CRITICIDAD Confidencialidad: Corresponde a la clasificación Pública o Reservada de acuerdo a lo establecido en la Ley 20.285, expresado en la tabla de Valores para Cálculo de Criticidad. Integridad: Corresponde a la clasificación de acuerdo a la tabla. Disponibilidad: Corresponde a la clasificación de acuerdo a la tabla.

Tabla N° 1: Valores para Cálculo de Criticidad

Variables asociadas a la criticidad

Valores Categorías Significado

CONFIDENCIALIDAD10

1

Pública Son los actos y resoluciones de los órganos de la Administración del Estado, sus fundamentos, los documentos que les sirvan de sustento o complemento directo y esencial, y los procedimientos que se utilicen para su dictación. Asimismo, es pública la información elaborada con presupuesto público y toda otra información que obre en poder de los órganos de la Administración, cualquiera sea su formato, soporte, fecha de creación, origen, clasificación o procesamiento.

3 Reservada Condición excepcional amparada en la Ley 20.285 (artículo 21) y en otras leyes de quórum calificado.

INTEGRIDAD 1 Baja Información cuya modificación no autorizada puede corregirse aunque podría ocasionar riesgos leves para la institución o terceros.

2 Media Información cuya modificación no autorizada es de difícil corrección y podría ocasionar riesgos significativos para la institución, o terceros.

3 Alta Información cuya modificación no autorizada no podría corregirse, ocasionando consecuencias graves a la institución o a terceros.

DISPONIBILIDAD 1 Baja Información cuya inaccesibilidad permanente, durante una semana, podría ocasionar consecuencias significativas para la institución, o terceros.

2 Media Información cuya inaccesibilidad permanente durante, un día podría ocasionar consecuencias significativas a la Institución, al sector público nacional o a terceros.

3 Alta Información cuya inaccesibilidad permanente durante una hora, podría ocasionar consecuencias significativas a la Institución, al sector público nacional o a terceros.

Las consecuencias pueden ser cuantificables (monto monetario o entrega de servicio) y no

10 Se utiliza el concepto de acuerdo a la Ley 20.285.


28

cuantificables (imagen, valor estratégico de la información, obligaciones contractuales o públicas, disposiciones legales, etc.).

Criticidad: Esta columna se encuentra destacada con azul pues es una de las que dan consistencia entre esta hoja y la siguiente. Esta columna es calculada de acuerdo a los siguientes criterios: • Criticidad Baja: Ninguno de los valores asignados superan el 1. • Criticidad Media: Alguno de los valores asignados es 2. • Criticidad Alta: Alguno de los valores asignados es 3.

2. Hoja “Etapa 1- Riesgos”.

Este instrumento tiene por objetivo identificar los riesgos potenciales que amenazan los activos inventariados en la institución. Éstos pueden ser identificados por haberse materializado y haber afectado la seguridad de los activos, independiente de que exista registro de dicho incidente.

Esta hoja inicia con los activos identificados en la hoja “Etapa 1 – Inventario” que han sido clasificados con criticidad media y alta. Los activos identificados con criticidad baja aparecerán difuminados para indicar que para ellos no se requiere realizar el análisis.

Tal como se indicó en las “Recomendaciones Generales”, en este análisis es posible encontrar varios controles o varios productos asociados a un activo. En caso de darse esta situación, se debe insertar una fila posicionándose en aquélla indicada (<Inserte fila para agregar controles>).


Proceso – Activo – Criticidad: Corresponden a campos del Inventario de Activos, que permiten dar continuidad al análisis, por lo que se debe procurar no cambiar los nombres. IDENTIFICACIÓN Y ANÁLISIS DE RIESGOS DE SI Amenazas: “Causa potencial de un incidente no deseado, que puede dar lugar a daños a un sistema o a una organización.” (NCH-ISO 27002:2009), independiente de si se tiene registro de su materialización en el pasado. Registro histórico de su frecuencia: Periodicidad con que se ha producido el evento/incidente descrito, que se encuentre registrado. En caso de no haber registro indicar “No hay registro”. Descripción del Riesgo: Descripción del riesgo que amenaza el activo de información, entendiéndose éste como las condiciones de debilidad en los activos que pueden ser afectadas por la existencia de una amenaza concreta, y las consecuencias que esto tiene. Probabilidad de ocurrencia: Posibilidad de que el riesgo se materialice, este punto debe ser consistente con el registro histórico, en caso de que haya. Los valores posibles son: • Casi Certeza


29

• Probable • Moderado • Improbable • Muy Improbable Impacto: Corresponde a los efectos que tiene en la institución la materialización del riesgo. Los valores posibles son: • Catastróficas • Mayores • Moderadas • Menores • Insignificantes Severidad: Corresponde al nivel de gravedad del riesgo, este será calculado por la planilla y corresponde a la probabilidad de ocurrencia por el impacto (Tabla I). Los resultados posibles son: • Extremo • Alto • Moderado • Bajo Control/es para mitigar el riesgo (NCH 27001 y DS 83): Corresponde a las medidas que propone la NCh 27001 y DS 83 cuya implementación permitirá mitigar el riesgo identificado. Se debe agregar filas en caso de requerirse más de una. Tratamiento del riesgo: Nombre de los productos desarrollados o por desarrollar en el Servicio (evidencias), para los controles requeridos. Cumplimiento: Corresponde a la respuesta afirmativa o negativa respecto a la realización del producto citado en la columna precedente, y por tanto la verificación de que el control en cuestión está logrado. Nombre del Archivo Evidencia: Nombre del archivo que se presenta como medio de verificación de los controles que se declaren cumplidos, es decir, con un “SI” en la columna “Cumplimiento”.


30

Tabla N° 2: Tabla de Niveles de severidad del riesgo NIVEL PROBABILIDAD (P) NIVEL IMPACTO (I) SEVERIDAD DEL RIESGO S = (P x I)

Casi Certeza (5) Catastróficas (5) EXTREMO ( 25) Casi Certeza (5) Mayores (4) EXTREMO (20 ) Casi Certeza (5) Moderadas (3) EXTREMO (15 ) Casi Certeza (5) Menores (2) ALTO (10) Casi Certeza (5) Insignificantes (1) ALTO (5) Probable (4) Catastróficas (5) EXTREMO (20) Probable (4) Mayores (4) EXTREMO (16 ) Probable (4) Moderadas (3) ALTO (12) Probable (4) Menores (2) ALTO (8) Probable (4) Insignificantes (1) MODERADO (4) Moderado (3) Catastróficas (5) EXTREMO (15 ) Moderado (3) Mayores (4) EXTREMO (12 ) Moderado (3) Moderadas (3) ALTO (9) Moderado (3) Menores (2) MODERADO (6) Moderado (3) Insignificantes (1) BAJO (3) Improbable (2) Catastróficas (5) EXTREMO (10 ) Improbable (2) Mayores (4) ALTO (8) Improbable (2) Moderadas (3) MODERADO (6) Improbable (2) Menores (2) BAJO (4) Improbable (2) Insignificantes (1) BAJO (2) Muy improbable (1) Catastróficas (5) ALTO (5) Muy improbable (1) Mayores (4) ALTO (4) Muy improbable (1) Moderadas (3) MODERADO (3) Muy improbable (1) Menores (2) BAJO (2) Muy improbable (1) Insignificantes (1) BAJO (1)

Fuente: Guía Técnica Nº 53. CAIGG

Etapa 2: Planificación 1. Hoja “Etapa 2 – Plan General”.

Este instrumento tiene por objetivo registrar la planificación -en términos generales– que permitirá la obtención de los productos identificados en la etapa anterior en la hoja Riesgos - a desarrollar durante el 2012 y los años siguientes, si corresponde.


Producto esperado: Corresponde al producto definido en la hoja Riesgos. Es importante mantener la continuidad y consistencia entre la hoja Riesgos y Plan General. Se recomienda copiarlos y pegarlos. Responsable: Nombre y cargo del responsable de la implementación del producto. Actividades: Secuencia de actividades que la Institución debe realizar para la obtención del producto. Se recomienda identificarlas en forma consecutiva de acuerdo al orden de ejecución de las mismas.


31

Fecha de Inicio: Corresponde a la fecha de inicio de la actividad, se debe considerar formato dd-mm-yy Fecha de Término: Corresponde a la fecha de término de la actividad, se debe considerar formato dd-mm-yy. Responsable de la Actividad: Corresponde al nombre y cargo de la persona que ejecutará actividad. Difusión/Sensibilización: Corresponde a las instancias de difusión y/o sensibilización, planificadas para los productos esperados. Capacitación: Corresponde a las instancias de capacitación definidas para el año.

2. Hoja “Etapa 2 – Indicadores”11

Este instrumento tiene por objetivo definir los indicadores que serán medidos una vez implementados los controles.

.


Nombre del indicador: Descripción breve que da cuenta del aspecto a medir. Su estructura debe responder a los criterios de simpleza, claridad y comprensibilidad. Fórmula de cálculo: Es la expresión matemática que permite cuantificar el nivel o magnitud que alcanza el indicador en un cierto período (anual, semestral, etc.), considerando variables que se relacionan adecuadamente para este efecto. Fecha de inicio de la medición: Fecha en la cual se comienza a realizar las mediciones que requiere el indicador. Frecuencia de la medición: Corresponde a la periodicidad establecida para la medición de un indicador. Ejemplo: Bianual, anual, semestral, trimestral. Efectiva a Agosto de 2012: Se debe señalar, de acuerdo a la información disponible, los valores efectivos del numerador y denominador del indicador en Agosto del 2012. Este antecedente y las otras mediciones sirven de base para definir la meta que se comprometa para el año 2013.

11 Adaptado de: "INSTRUCCIONES PARA LA FORMULACIÓN PRESUPUESTARIA. FORMULARIO H. INDICADORES DE DESEMPEÑO AÑO 2011". Disponible en http://www.dipres.gob.cl/572/articles-36282_doc_pdf3.pdf (30 de Marzo de 2012) e “Indicadores de gestión en los servicios públicos. Serie Guía Metodológica. Santiago de Chile, junio de 1996”. Dirección de Presupuestos, citado en "SISTEMA INTEGRAL DE INFORMACIÓN Y ATENCIÓN CIUDADANA, SIAC. GUÍA METODOLÓGICA 2010". Disponible en: http://siac.msgg.gob.cl/uploads/f15be81f87_guia_final[1].pdf (30 de Marzo de 2012)


32

Efectiva a Octubre de 2012: Se debe señalar, de acuerdo a la información disponible, los valores efectivos del numerador y denominador del indicador en Octubre del 2012. Este antecedente y las otras mediciones sirven de base para definir la meta que se comprometa para el año 2013. Efectiva a Diciembre de 2012: Se debe señalar, de acuerdo a la información disponible, los valores efectivos del numerador y denominador del indicador en Diciembre del 2012. Este antecedente y las otras mediciones sirven de base para definir la meta que se comprometa para el año 2013. Meta: Compromiso a alcanzar respecto al valor del indicador al término del año siguiente. La meta no sólo representa un compromiso en términos del valor del indicador, sino también respecto de su numerador y denominador, los cuales deber ser adecuadamente estimados por la institución. Medios de verificación: Son los mecanismos de sistematización de la información, tales como informes consolidados, reportes, agregación de datos (subtotales por centro de responsabilidad, por región, por mes, por producto, etc., cuadros resúmenes u otros), que contienen el detalle requerido para la medición de los indicadores y a su vez, permiten verificar los valores informados en cada cifra del indicador, no sólo el valor final. Éstos son el resultado de la aplicación de instrumentos de recolección de datos disponibles (encuestas, fichas u otros registros controlados). Supuestos: Condiciones sobre las cuales está formulada la meta, entendiéndose por tal a aquellos factores externos a la gestión de la institución, respecto de los cuales el servicio no tiene control y que pueden afectar el cumplimiento de la meta. Notas: Se debe incorporar, cuando sea necesario, precisiones de alguna de las variables del indicador como por ejemplo conceptos técnicos o descripciones de aspectos metodológicos de la medición.

Etapa 3: Implementación 1. Hoja “Etapa 3 – Implementación”.

El objetivo de esta hoja es plasmar la ejecución de los hitos o actividades comprometidas en la etapa de planificación.


Productos esperados: Corresponde al producto definido en la hoja Riesgos y Plan General. Actividades comprometidas: Son aquellas que a las Institución se obligó a realizar para implementar los productos, en el Plan General. Término: Las dos columnas bajo este rótulo permiten comparar la fecha en la cual se había definido el término de la actividad con la fecha en que ésto realmente ocurrió.


33

• Estimado: Es la fecha en que se había definido serían terminadas las actividades, según el Plan General.

• Real: Es la fecha en que efectivamente finalizó la actividad, de modo que se genere el producto que da cumplimiento al control para el cual había sido definido. Se debe considerar formato dd-mm-yy.

Desviaciones (días): Es la diferencia entre la fecha estimada y la real. Cuando una actividad se haya terminado antes de lo programado, este valor será positivo. Si la actividad tuvo retrasos, será negativo. Observaciones: Esta columna permite señalar causas de desviaciones significativas u otras notas que la Institución considere relevantes. Cabe señalar que las desviaciones admisibles no pueden exceder el año de ejecución, salvo situaciones cuya causalidad sea externa a la Institución y verificable. Nombre del archivo evidencia: Se debe señalar con precisión el nombre del archivo que constituye el medio de verificación respecto del producto logrado. Es importante que el contenido del archivo sea exactamente lo que señala el nombre del producto, porque esta evidencia es la que permitiría considerar que tal(es) control(es) está(n) cumplido(s), incrementando el porcentaje de logro del servicio en la etapa de implementación.

Etapa 4: Evaluación 1. Hoja “Etapa 4 – Evaluación”

El objetivo de esta hoja es mostrar la evidencia de la realización de las actividades de evaluación y difusión.


Evaluación de los Resultados del Plan General / Medios de verificación (adjuntar): En las filas se mencionan los cuatro requisitos técnicos de los cuales debe dar cuenta la Institución, y en el encabezado de la columna se solicita el medio de verificación asociado a dicho requisito. • Revisión del % de cumplimiento logrado, por parte del CSI: En este caso se debería

adjuntar un acta de reunión del Comité, en la cual conste de manera explícita que se revisó el porcentaje de cumplimiento.

• Revisión de los resultados de las actividades desarrolladas y la efectividad en la mitigación de riesgos: En este requisito se puede aportar una revisión por parte del Comité (pudiendo estar de forma explícita en la misma acta que el punto anterior), un informe de auditoría u otras revisiones internas o externas asociadas al cumplimiento de las actividades y la mitigación de los riesgos, expresamente.

• Identificación de riesgos persistentes y otras debilidades, y su análisis de causa: Puede haber controles que no hayan sido efectivos para mitigar los riesgos y/o que existan otras debilidades acaecidas durante la fase de implementación. En este caso se deben identificar tales situaciones y analizar sus causas, adjuntando él o los medios de verificación que permitan reconocer dicha identificación y análisis, de forma explícita.


34

• Recomendaciones de mejora, que consideren medidas correctivas y preventivas: De acuerdo a los resultados obtenidos de los puntos anteriores, se debe planificar las medidas correctivas y preventivas necesarias, a fin de corregir los problemas y sus causas. Dichas recomendaciones deben ser aprobadas por el CSI porque son parte de la evaluación y deben constar en uno o varios medios de verificación que lo señalen de modo inequívoco.

Difusión de los resultados de la implementación / Medios de verificación (adjuntar): Se debe señalar el o los medios de verificación asociados a la difusión de los resultados en la organización. En este caso se pueden adjuntar publicaciones en la intranet institucional, el envío de correos electrónicos, campañas comunicacionales, entre otros. Se debe cuidar que expresen de forma clara que se están difundiendo los resultados de la implementación (porcentaje de logro, resultados de las actividades, debilidades y la forma de resolverlas).

2. Hoja “Etapa 4 – Programa Seguimiento”

El objetivo de esta hoja es mostrar de forma ordenada los compromisos asociados a las mejoras requeridas a la implementación, producto de la evaluación realizada. Los campos de esta hoja son los siguientes:

Recomendaciones y medidas de mejoramiento: Son las sugerencias y decisiones tomadas por el CSI sobre qué es necesario realizar para enmendar o mejorar la implementación. Compromisos: Son acciones concretas que permiten dar forma a las recomendaciones y medidas de mejoramiento. Plazo: Fecha en la cual se debe dar cumplimiento a cada compromiso. Se debe considerar formato dd-mm-yy. Responsable: Funcionario o funcionaria a cargo de que el compromiso se cumpla.

3. Hoja “Etapa 4 – Ctrl. y Mejora Cont.”

El objetivo de esta hoja es exponer de forma ordenada las instancias mínimas que tendrá que continuar desarrollando la Institución para mantener el grado de desarrollo alcanzado e incorporar, a partir de éste, medidas de control y mejora continua. Los campos de esta hoja son los siguientes:

REVISIONES REGULARES DEL SSI Revisión 1, 2, 3, etc. / Fecha: Se debe precisar cuándo se realizarán las revisiones del SSI. Puede tratarse de auditorías internas o externas, revisiones por parte del CSI, u otras actividades periódicas de esta naturaleza. Se debe considerar formato dd-mm-yy.

INDICADORES Y METAS Revisión de indicadores y metas / Fecha: Se debe precisar cuándo se realizarán las revisiones de los indicadores del SSI. Se debe considerar formato dd-mm-yy.


35

Establecimiento de medidas de mejora / Fecha: A partir de la revisión de los indicadores, cuándo se definirán las medidas de mejora que se requiera. Se debe considerar formato dd-mm-yy. Aprobación CSI o Dirección / Fecha: Se debe señalar para cuándo el CSI o la Dirección aprobará tales medidas de mejoramiento. Considerar formato dd-mm-yy.

INVENTARIO DE ACTIVOS Y RIESGOS Actualización del inventario de activos / Fecha: Se debe señalar cuándo se actualizará el inventario de activos de información. Dicha acción debe ser consistente con la política o procedimiento en el cual se haya definido la periodicidad de tal actualización, aunque puede haber otras actualizaciones que se requieran por cambios en los activos o sus atributos. Se debe considerar formato dd-mm-yy. Incorporación a gestión de riesgos institucional / Fecha: Se debe precisar a partir de cuándo el análisis de riesgo que se ha realizado y actualizado en el SSI, se hará parte de la gestión de riesgos institucional, incorporándolo en su planificación. Se debe considerar formato dd-mm-yy.


36

ANEXO II: Ejemplos de indicadores Tabla N° 3: Ejemplos de indicadores

Dominio al que se vincula

Indicador Métricas asociadas Etapa desde la cual es

factible medir Política de Seguridad

(5.1)

Cobertura de las políticas.

Porcentaje de los controles de ISO/IEC 27001 aplicables, para los cuales se han escrito, aprobado y comunicado las políticas.

4

Grado de despliegue y adopción de políticas en toda la organización.

Porcentaje de centros de responsabilidad que han adoptado las políticas respecto de toda la organización, medido por una auditoría, revisión por la dirección o alguna autoevaluación.

4

Organización de la SI (6.1 y

6.2)

Alcance de la gestión de riesgos de SI.

Porcentaje de centros de responsabilidad asociados a procesos de negocio que han implementado una estrategia para mantener los riesgos de seguridad de la información dentro de los umbrales explícitamente aceptados por la dirección del servicio.

4

Responsabilidad sobre la SI en la organización.

Porcentaje de funcionarios a los que se les han asignado y han aceptado formalmente, responsabilidades de seguridad de información.

3 ó 4

Responsabilidad sobre la SI en terceros.

Porcentaje de conexiones con terceras partes que han sido identificadas, evaluadas en cuanto a sus riesgos y consideradas seguras.

3 ó 4

Responsabilidad sobre la SI en terceros.

Porcentaje de terceros relevantes u otros que han sido formalmente certificados, conforme a ISO/IEC 27001 u otros estándares de seguridad que sean apropiados.

1

Efectividad de la planificación de la revisión por la dirección.

Número de revisiones por la dirección realizadas, respecto de las planificadas.

4 ó 4 bis

Efectividad de la planificación de las auditorías externas.

Número de auditorías internas / externas efectivamente realizadas, respecto de las planificadas.

4 bis

Gestión de activos (7.1 y

7.2)

Grado de despliegue del inventario de activos.

Porcentaje de los activos de información analizados en cada fase (inventariados / identificados / responsables nominados / riesgos evaluados / clasificados).

1

Eficacia de los planes de tratamiento de riesgo.

Porcentaje de los activos de información crítica para los que se implementó los planes de tratamiento de riesgos de seguridad de la información y se mantuvo estos riesgos dentro de límites aceptables.

4

Grado de criticidad Porcentaje de los activos de información en 1


37

de los activos de información institucionales.

cada categoría de clasificación (incluyendo una categoría especial: No clasificado aún).

Seguridad de RRHH (8.1, 8.2

y 8.3)

Grado de despliegue y adopción de políticas de RRHH.

Porcentaje del personal nuevo (funcionarios, contratistas, consultores, etc.) que han sido totalmente investigados y han aprobado, de acuerdo a las políticas de la institución antes de comenzar a trabajar.

3 ó 4

Eficacia de los procedimientos de eliminación.

Porcentaje de identificadores de usuario pertenecientes a personas que han dejado la organización, activos (o con desactivación pendiente) e inactivos (archivo y eliminación pendientes).

3 ó 4

Seguridad física y

ambiental (9.1 y 9.2)

Efectividad de las revisiones de seguridad física.

Número de revisiones periódicas de seguridad física de las instalaciones, incluidas las actualizaciones del estado de avance de las acciones correctivas y preventivas identificadas en revisiones anteriores.

4

Efectividad del procedimiento de mantención de equipos.

Mantenimientos a los equipos efectuados en relación a los planificados.

3 ó 4

Gestión de Operaciones y Comunicacion

es (10.1 al 10.10)

(10.1) % de implementación actualizaciones sistemas.

(Total Mensual Actualizaciones implementadas)/(Total Anual Actualizaciones

publicadas)* 100

3 ó 4

(10.1) % de implementación de soluciones a vulnerabilidades de sistemas.

(Total Mensual de soluciones a vulnerabilidades implementadas)/(Total Anual

Vulnerabilidades detectadas)* 100

3 ó 4

(10.1) % de Solicitudes Atendidas de Cambios.

(Total Mensual Solicitudes de Cambios)/(Total Anual Formularios de Gestión de Cambios)*

100

3 ó 4

(10.2) Cumplimiento y efectividad de los acuerdos de nivel de servicio (SLA)

Evaluación de los costos del tiempo de inactividad debido al incumplimiento de los

acuerdos de nivel de servicio.

3 ó 4

(10.2) Efectividad de proveedores de servicios y sus respectivas entregas de servicio.

Evaluación del rendimiento de proveedores incluyendo la calidad de servicio, entrega y

costos

3 ó 4

10.3 % de proyectos Implementados

(Proyectos en Planificación Implementados )/(Total Proyectos Planificados)*100

3 ó 4

10.3 % de Controles ISO NCh 27002 Of.2009 Implementadas

[Total de Controles ISO NCh 27002 Of.2009 Implementadas actuales /Total de Controles

ISO NCh 27002 Of.2009]*100

3 ó 4


38

10.5 % de respaldos exitosos de sistemas críticos e importantes

(Total de sistemas críticos e importantes respaldados exitosamente)/(Totalidad de

sistemas críticos e importantes)*100

3 ó 4

10.5 % de recuperaciones exitosas de sistemas críticos e importantes

(Total de recuperaciones exitosas de sistemas críticos e importantes)/(Totalidad de sistemas

críticos e importantes respaldados)*100

3 ó 4

10.6 Existencia y efectividad de estándares, directrices, procedimientos y herramientas de seguridad de redes

Evaluación del N° de incidentes de seguridad de red en el mes, categorizados por nivel de

gravedad

3 ó 4

10.7 Existencia y efectividad de procedimientos para la gestión de medios removibles

Evaluación de medidas de seguridad adoptadas para la gestión de medios removibles, en

cuanto al almacenamiento, permanencia y eliminación de información contenida en ellos

3 ó 4

10.8 Existencia y efectividad de políticas, procedimientos y controles para el intercambio seguro de información relevante

Evaluación de medidas de seguridad adoptadas en el intercambio de activos de información

relevante, crítica o sensible

3 ó 4

10.10 Existencia y efectividad de actividades de monitoreo, registro y supervisión

Tendencia en el número de eventos y/o incidentes de seguridad que han sido

correctamente registrados, analizados y han conducido a actividades de seguimiento

3 ó 4

Control de Accesos (11.1

al 11.5)

11.1 Existencia, revisión y adecuación de políticas de control de accesos

Evaluación de consistencia entre lo establecido en la política y la clasificación de criticidad de activos de información, y respecto a la legislación y normativa existente

3 ó 4

11.2 Existencia de un administrador de usuarios, con responsabilidades operativas para asignar y restringir privilegios sobre los sistemas

Establecer el grado de centralización o dispersión de las solicitudes de cambios de privilegios cursados

3 ó 4

11.3 Definición documentada y aplicada de

Porcentaje de usuarios/puestos de trabajo cuyas responsabilidades en seguridad de la información se encuentran formalmente

3 ó 4


39

responsabilidades relativas a seguridad de la información en los puestos de trabajo

aceptadas.

11.4 Existencia y efectividad de controles de seguridad perimetrales e internos, en cuanto a conexión, identificación, autenticación, routing, etc.

Evaluación de logs y estadísticas de las tecnologías de software y hardware implementadas para tales efectos, identificando la relación numérica entre vulnerabilidades aprovechadas e intentos de accesos o ataques bloqueados y repelidos

3 ó 4

11.5 Existencia y efectividad de controles de acceso a los sistemas operativos de las plataformas informáticas

Nivel de existencia de registro seguro, ID de usuario único, técnicas de autenticación, contraseñas robustas, control de utilitarios del S.O., cierre de sesiones inactivas, etc. Y evaluación de estadísticas de vulnerabilidad y su seguimiento, si existiesen.

3 ó 4

Adquisición/Desarrollo y

Mantención de Sistemas

(12.1 al 12.5)

12.2 Existencia y efectividad de validación de datos de entrada y salida a/de los sistemas de información

Porcentaje de sistemas para los cuales los controles de validación de datos se han definido e implementado, y se han demostrado eficaces mediante pruebas

3 ó 4

12.4 Adopción y aplicación de controles de seguridad para los archivos de aplicativos y código fuente

Porcentaje de sistemas evaluados conformes en relación a la normativa de seguridad existente en estas materias, respecto a aquellos que no han sido evaluados, o no han aprobado la normativa

3 ó 4

12.5 Existencia y adecuación de procedimientos formales para el control de cambios

Porcentaje de procesos de cambios que se han realizado conforme a la normativa existente al respecto, en relación al total de cambios solicitados y realizados

3 ó 4

Gestión de Incidentes de

SI (13.1 y 13.2)

Efectividad de los procedimientos de gestión de incidentes.

Análisis estadístico de la cantidad y tipo de llamadas a la mesa de soporte TI, relativas a seguridad de la información (por ejemplo, los cambios de contraseña; consultas acerca de los riesgos de seguridad de la información y los controles, como un porcentaje de todas las consultas).

3 ó 4

Grado de efectividad de la difusión acerca de los

De las estadísticas, crear y publicar un ranking de los centros de responsabilidad (ajustado por el número de funcionarios de cada uno),

4 ó 4 bis


40

procedimientos de gestión de incidentes.

mostrando aquellos que son claramente conscientes de la seguridad frente a aquellos que no lo son.

Eficiencia y efectividad de las políticas y procedimientos de gestión de incidentes.

Número y gravedad de los incidentes de SI; evaluaciones de los costos asociados al análisis, detención y reparación de los incidentes, así como las pérdidas sufridas, tangibles e intangibles.

3 ó 4

Efectividad de los controles sobre activos críticos.

Porcentaje de incidentes de seguridad que generaron costos por encima de los umbrales aceptables definidos por la dirección.

4 ó 4 bis

Gestión de Continuidad del Negocio

(14.1)

Efectividad en la implementación de los planes de continuidad del negocio.

Porcentaje de planes de continuidad del negocio en cada etapa del ciclo de vida (requerido / especificado / documentado / probado).

3 ó 4

Grado de despliegue de los planes de continuidad del negocio.

Porcentaje de centros de responsabilidad con planes de continuidad del negocio que han sido adecuadamente documentados y probados con pruebas dentro de los últimos 12 meses.

4 ó 4 bis

Cumplimiento (15.1, 15.2 y

15.3)

Efectividad de la política de cumplimiento.

Número de requerimientos legales agrupados y analizados por estado (cerrado, abierto, nuevo, atrasado) y nivel de significación o riesgo (extremo, alto, medio o bajo).

3 ó 4

Efectividad del procedimiento de control de cumplimiento por parte de los terceros.

Porcentaje de requerimientos externos claves considerados cumplidos a través de auditoria(s) u otros medios aceptables.

4

Efectividad de las auditorías o revisiones normativas.

Número de políticas internas y otros requerimientos o recomendaciones agrupados y analizados por estado (cerrado, abierto, nuevo, atrasado) y nivel de significación o riesgo (extremo, alto, medio o bajo).

4

Efectividad del SSI Porcentaje revisiones de cumplimiento de SI sin registros de incumplimientos substanciales de los controles.

4 y 4 bis

Efectividad de las auditorías

Número de recomendaciones de auditoría agrupadas y analizadas por estado (cerrado, abierto, nuevo, atrasado) y nivel de significación o riesgo (alto, medio o bajo).

4 y 4 bis

Efectividad del control de acciones correctivas.

Porcentaje de hallazgos de auditoría de SI que se han resuelto y cerrado, respecto del total que se abrió en el mismo período.

4 y 4 bis

Eficacia en el control de acciones correctivas.

Plazos reales en que se resolvieron o cerraron las recomendaciones, respecto de las fechas planificadas.

4 y 4 bis


41

Gestión de riesgos en

general, no se asocia a un

producto en específico.

Grado de despliegue del análisis de riesgos.

Porcentaje de riesgos identificados considerados con severidad extrema, alta, moderada o baja, además de los “no-evaluados”

1

Efectividad del SSI para controlar o mitigar los riesgos.

Tendencia en el número de riesgos relacionados con la seguridad de información para cada nivel de severidad.

4 ó 4 bis

Eficiencia del SSI. Gastos de la seguridad de información como porcentaje del presupuesto asignado.

1

Grado de despliegue o efectividad de los controles aplicados.

Porcentaje de riesgos de seguridad de la información a los que se les han aplicado los controles en forma completa y satisfactoria.

4

Fuente: Adaptado de ISO27k implementer's forum (www.ISO27001security.com). Está permitida la reproducción, distribución, uso y creación de trabajos derivados de este, siempre y cuando (a) no sean vendidos ni incorporados en ningún producto comercial, (b) sean correctamente atribuidos al ISO27k implementer’s fórum (www.ISO27001security.com), y (c) sean comprados bajo los mismos términos de éste.

ANEXO III: Actividades para la implementación de controles Tabla N°4: Actividades para la implementación de controles de S.I. – Etapa III DOMINIO ÁMBITO REFERENCIA

CONTROL ISO REQUISITO/CONTROL ACTIVIDADES A REALIZAR EN EL PMG/MEI SSI

Polít

ica

de S

egur

idad

Difusión de la Política General de la Información

A.5.1.1 La política de seguridad de la información debería ser comunicada a todos los usuarios de la organización de manera pertinente, accesible y comprensible

• Se debe realizar la difusión del documento Política General de Seguridad: o Publicación en sitios de acceso al personal o Inducción a nuevos funcionarios o Comunicaciones a través de charlas y reuniones o Oficios informativos o Inducción a partes externas relevantes

Revisión de la política de seguridad de la información

A.5.1.2 La política de seguridad de la información debería ser revisada a intervalos planeados o si ocurren cambios significativos para asegurar su continua idoneidad, eficiencia y efectividad.

• Someter a revisión la Política de Seguridad Institucional en Comité de Seguridad de la Información, considerando: o Retroalimentación de partes interesadas. o Resultados de las revisiones efectuadas por terceras partes. o Estado de acciones preventivas y correctivas o Cambios en los procesos institucionales, directiva, nueva legislación,

tecnología, etc. o Alertas ante amenazas y vulnerabilidades. o Información relacionada a incidentes de seguridad. o Recomendaciones provistas por autoridades relevantes.

Org

aniz

ació

n de

la S

egur

idad

de

la

Info

rmac

ión

Compromiso de la dirección con la seguridad de la información

A.6.1.1 La dirección debería apoyar activamente la seguridad dentro de la organización a través de una dirección clara, compromiso demostrado, asignación explícita de las responsabilidades de la seguridad de la información y su reconocimiento.

• El Jefe de Servicio deberá: o Asegurar que los objetivos de la seguridad de la información son identificados,

cumplen con los requerimientos de la organización, y están integrados a los procesos relevantes.

o Revisar la efectividad en la implantación de la política. o Proveer una dirección clara y el respaldo visible para llevar a cabo las iniciativas

de seguridad. o Proveer los recursos necesarios para la seguridad de la información o Aprobar planes de capacitación y sensibilización para los funcionarios. o Asegurar que la implementación de los controles de seguridad se realicen a

través de toda la organización. Asignación de las responsabilidades de la seguridad de la información

A.6.1.3 Todas las responsabilidades de la seguridad de la información deberían estar claramente definidas.

• La definición de responsabilidades debe considerar: o La identificación de los procesos y activos de información relevantes. o Formalizar a los responsables por cada proceso/activo de información

identificado. o Los distintos niveles de autorización para los activos de información


43

DOMINIO ÁMBITO REFERENCIA CONTROL ISO

REQUISITO/CONTROL ACTIVIDADES A REALIZAR EN EL PMG/MEI SSI

identificados. Autorización de proceso para facilidades procesadoras de información.

A.6.1.4 Se debería definir e implantar un proceso de autorización por parte de la dirección para las nuevas instalaciones de procesamiento de información.

• Se deben considerar los siguientes lineamientos: o Las nuevas instalaciones deberán poseer un mecanismo apropiado de

identificación de usuarios, la que debe ser otorgada por el responsable asignado, verificando el cumplimiento con las políticas de seguridad.

o Donde sea necesario, el hardware y el software deberá ser chequeado en su compatibilidad con la infraestructura actual.

o El uso de dispositivos de carácter personal como laptops o dispositivos de mano, que sean utilizados para procesar información de la institución, podrían introducir nuevas vulnerabilidades, por lo tanto deben considerarse controles adicionales.

Acuerdos de confidencialidad

A.6.1.5 Se deberían identificar y revisar regularmente que los requerimientos de confidencialidad o acuerdos de no-divulgación reflejan las necesidades de la organización para proteger la información.

• Para identificar los requerimientos de confidencialidad o acuerdos de no divulgación, se deberá considerar: o La clasificación de la información (pública – secreta). o La duración del acuerdo, incluyendo la duración indefinida o Las acciones necesarias una vez que el acuerdo haya terminado. o Las responsabilidades para evitar la divulgación no autorizada de la

información. o La propiedad de la información, la propiedad intelectual y cómo se relaciona

con la información secreta. o El uso permitido de la información secreta. o El derecho de auditar y supervisar actividades que involucren información

secreta. o La notificación oportuna frente a una divulgación no autorizada o violaciones

de la información secreta. o Los términos de devolución o destrucción de la información, una vez que cesa

un acuerdo. o Las acciones necesarias en el caso de no cumplir con el acuerdo.

Contacto con las autoridades

A.6.1.6 Se deberían mantener los contactos apropiados con las autoridades pertinentes.

• Se deben mantener contactos con las siguientes autoridades relevantes: o Responsables por el tipo de incidentes de seguridad, o de los procesos de

continuidad de negocio y recuperación ante desastres (proveedores de internet u operadores de telecomunicaciones, etc.).

o Entidades reguladoras. o Servicios de emergencia, salud, bomberos, carabineros.

Contacto con A.6.1.7 Se deberían mantener contactos • En especial el Comité de ámbito técnico y el Encargado de Seguridad deben estar


44



grupos de interés especial

apropiados con grupos de interés especial u otros foros de seguridad especializados y asociaciones de profesionales.

provisto de boletines y contacto permanente con las entidades de seguridad vigentes, considerando: o Mejorar el conocimiento acerca de las buenas prácticas y mantenerse al día en

materias de seguridad de la información. o Garantizar que la comprensión del ambiente de seguridad de la información es

actual y completa. o Recibir oportunamente las alertas, boletines y parches previniendo posibles

ataques o vulnerabilidades. o Tener acceso a asesoría especializada sobre seguridad de la información. o Compartir e intercambiar información sobre nuevas tecnologías, productos,

amenazas o vulnerabilidades. o Proveer puntos adecuados de enlace para el manejo de incidentes de

seguridad de la información. Revisión independiente de la seguridad de la información

A.6.1.8 Se debería revisar el enfoque de la organización en la gestión de la seguridad de la información y su implementación (es decir: objetivos de control, controles, políticas, procesos y procedimientos para la seguridad de la información) de manera independiente a intervalos planificados, o cuando ocurran cambios significativos en la implementación de la seguridad.

• Se debe coordinar con una entidad externa (auditor interno o consultor externo) para realizar una revisión de las actividades de implantación al menos 1 vez al año.

Identificación de los riesgos relacionados con los grupos externos

A.6.2.1 Se deberían identificar los riesgos asociados a la información del Servicio y sus medios de procesamiento a raíz de procesos de negocio que involucran a entidades externas y se deberían implementar controles apropiados antes de otorgarles acceso.

• Se deben identificar los riesgos relacionados con el acceso de terceros, teniendo en consideración: o Las instalaciones de procesamiento de información a los cuales requiere tener

acceso la entidad externa. o Qué tipo de acceso requiere el tercero (físico, lógico, conexión de red, on-site,

off-site, etc.). o El valor, sensibilidad y criticidad de la información involucrada. o Los controles necesarios para proteger la información que no deba ser

accesada por terceros. o Cómo se identifican y verifican los accesos. o Los medios y controles utilizados por los terceros para almacenar, transmitir,

procesar o intercambiar información.


45



o Impacto del acceso denegado al tercero, o que el tercero ingrese o reciba información inexacta o engañosa.

o Prácticas y procedimientos para manejar cualquier incidente de seguridad de la información, daños potenciales y términos y condiciones para la continuidad del acceso de la parte externa en el caso de un incidente de seguridad de la información.

o Requerimientos legales y regulatorios y otras obligaciones contractuales con el tercero que deban ser tenidos en cuenta.

o Los intereses de los clientes/usuarios/beneficiarios que puedan ser afectados por los acuerdos.

Tratamiento de la seguridad cuando se lidia con terceros

A.6.2.2 Se deberían tratar todos los requerimientos de seguridad identificados antes de proporcionar a clientes/usuarios/beneficiarios, acceso a la información o activos del Servicio.

• El tratamiento de la seguridad de los activos debe incluir: o Procedimientos para proteger los activos. o Procedimientos para determinar si se han comprometido los activos (pérdida,

modificaciones de datos, etc). o Protección de su integridad. o Restricciones para el copiado y la divulgación de información. o Descripción del producto o servicio a ser provisto. o Diferentes razones, requisitos y beneficios del acceso al

cliente/usuario/beneficiario. o Políticas de control de acceso. o Acuerdos para el informe, notificación e investigación de inexactitudes en la

información, incidentes de seguridad de la información y violaciones de seguridad.

o Una descripción de cada servicio que va a estar disponible. o El nivel a alcanzar por el servicio y los niveles inaceptables del servicio o El derecho al monitoreo o seguimiento y a revocar cualquier actividad

relacionada con los activos de información del Servicio. o Responsabilidades legales, contractuales y derechos de propiedad intelectual.

Tratamiento de la seguridad en acuerdos con terceros

A.6.2.3 Los acuerdos con terceros que involucran el acceso, procesamiento, comunicación o manejo de la información o medios de procesamiento de información del Servicio, o los contratos que impliquen agregar productos o servicios a los medios de

• Dentro de los acuerdos o contratos, se debe considerar: o La política de seguridad de la información. o Los controles para asegurar la protección de los activos. o La capacitación y concientización de los usuarios y administradores en

materias de seguridad. o Disposición para la transferencia del personal, cuando corresponda. o Responsabilidades respecto a la instalación y mantenimiento del hardware y

software.


46



procesamiento de información deberían abarcar todos los requerimientos de seguridad relevantes.

o Una estructura de informes clara y formatos de informe convenidos. o Un proceso claro y especificado para la gestión de cambios. o Políticas de control de accesos. o Acuerdos para el informe, notificación e investigación de inexactitudes en la

información, incidentes de seguridad de la información y violaciones de seguridad.

o Una descripción de cada servicio que va a ser provisto. o El nivel a alcanzar por el servicio y los niveles inaceptables del servicio. o La definición de criterios verificables de rendimiento, su seguimiento e

informe. o El derecho al monitoreo o seguimiento y a revocar cualquier actividad

relacionada con los activos de información del Servicio. o El derecho a auditar responsabilidades definidas en el acuerdo, a que dichas

auditorías sean efectuadas por terceros y a enumerar los derechos estatutarios de los auditores.

o Responsabilidades legales, contractuales y derechos de propiedad intelectual. o Acuerdos para el manejo de incidentes de seguridad. o Requerimientos de continuidad. o Condiciones para la negociación o términos de contratos.

Ges

tión

de

Act

ivos

Inventario de los activos

A.7.1.1 Se deben identificar los activos de información, elaborar un inventario de ellos y mantenerlo actualizado.

• Se deben identificar todos los activos de información incluyendo bases de datos y archivos de datos, manuales, material de entrenamiento, procedimientos de operación y soporte, planes de continuidad y contingencia, pistas de auditoría, información almacenada, aplicaciones, sistemas operativos, herramientas de desarrollo y utilitarios, computadores, equipos de telecomunicaciones, medios removibles, personas, especialistas y encargados.

• Se sugiere incorporar servicios de procesamiento y comunicaciones, servicios generales como luz, agua, HVAC, etc; además de intangibles, como la imagen de la institución y su reputación.

Propiedad de los activos

A.7.1.2 Toda la información y los activos asociados con los medios de procesamiento de información deben ser responsabilidad de una parte designada de la organización.

• El responsable tiene a su cargo lo siguiente: o Asegurar que los activos de información son debidamente clasificados,

considerando su criticidad y la Ley 20.285. o Definir y revisar periódicamente los accesos de acuerdo a la política

correspondiente. Uso aceptable de los activos

A.7.1.3 Se deben identificar, documentar e implementar reglas para el uso aceptable de la información y los

• Se debe crear un procedimiento para el manejo y uso de los activos críticos identificados, incluyendo: o Reglas para el correo electrónico e Internet


47



activos asociados con los medios del procesamiento de la información.

o Guías para el uso de dispositivos móviles, especialmente fuera de la organización.

o Normas para el copiado, almacenamiento y destrucción. Lineamientos de clasificación

A.7.2.1 Se debe clasificar la información en términos de su valor, requerimientos legales, sensibilidad y grado crítico para la institución

• Una vez identificados los activos de información relevantes por cada proceso institucional, debe ser clasificada su información de acuerdo a las regulaciones legales de la institución y las definiciones del dueño del proceso. También se debe considerar las disposiciones de la ley 20.285.

Etiquetado y manejo de la información

A.7.2.2 Se debe desarrollar e implementar un conjunto apropiado de procedimientos para el etiquetado y manejo de la información en concordancia con el esquema de clasificación adoptado por la institución

• Se debe etiquetar los activos de información identificados, de acuerdo a su clasificación, cubriendo tanto activos físicos como electrónicos.

Segu

rida

d de

rec

urso

s hu

man

os

Roles y responsabilidades

A.8.1.1 Se deberían definir y documentar los roles y responsabilidades de la seguridad de los funcionarios, personal a honorarios y terceros en concordancia con la política de seguridad de la información de la organización.

• Los roles y responsabilidades deben incluir los requerimientos para: o Implementar y actuar de acuerdo a las políticas de seguridad de la

información. o Proteger los activos de información. o Ejecutar actividades específicas de seguridad. o Asegurar que la responsabilidad sea asignada al individuo por acciones

tomadas. o Reportar cualquier incidente de seguridad.

Investigación de antecedentes

A.8.1.2 La verificación de antecedentes de todos los candidatos para el cargo, contratistas y terceros deberían llevarse a cabo en concordancia con las leyes, regulaciones y ética relevantes; y deberían ser proporcionales a los requerimientos de la función, la clasificación de la información a la cual se va a tener acceso y los riesgos percibidos.

• Para cada candidato a empleo dentro de la institución, se debe investigar: o La disponibilidad de referencias satisfactorias tanto como trabajador como

personales. o Un chequeo completo de su CV en cuanto a integridad y exactitud. o Confirmación de sus antecedentes académicos y profesionales. o Comprobación de la identidad. o Solicitud de certificado de antecedentes personales.

Términos y condiciones del

A.8.1.3 Como parte de su obligación contractual, los usuarios

• Para todos los funcionarios, personal a honorarios y terceros, deberá firmarse un acuerdo de confidencialidad.


48



empleo funcionarios, personal a honorarios y terceros deberían aceptar y firmar un contrato con los términos y condiciones de su función, el cual debería establecer sus responsabilidades y las de la institución para la seguridad de la información.

• Se deberán especificar sus derechos y deberes, considerando la propiedad intelectual y requerimientos legales.

• Se debe especificar sus responsabilidades para la clasificación y manejo de activos de información.

• Se debe especificar las responsabilidades por la administración de información recibida de otros Servicios u organizaciones externas.

• Se debe especificar las responsabilidades del Servicio para el manejo de la información personal de sus funcionarios y personal a honorarios.

• Se deben especificar las responsabilidades que se extienden fuera de las instalaciones del Servicio y fuera del horario de oficina, por ejemplo, cuando se trabaja desde la casa.

• Se debe especificar las acciones contra los funcionarios, personal a honorarios, y terceros, a ser llevadas a cabo si se desatienden los requisitos de seguridad.

Responsabilidades de la dirección

A.8.2.1 La dirección debería requerir a los usuarios funcionarios, personal a honorarios y terceras personas que apliquen la seguridad en concordancia con políticas y procedimientos bien establecidos por la institución.

• La dirección debe establecer, que los funcionarios, personal a honorarios y terceros: o Están apropiadamente instruidos en materias de seguridad de la información,

antes de otorgarles accesos a los activos de información. o Están orientados sobre las expectativas de su rol sobre seguridad de la

información dentro del Servicio. o Sean motivados a cumplir con las políticas de seguridad del Servicio. o Logren un nivel de conciencia sobre seguridad de la información acorde a sus

roles y responsabilidades dentro del Servicio o Aceptan las normativas de seguridad de la información y métodos apropiados

de trabajo. o Continúen teniendo aptitudes y calificaciones apropiadas.

Conocimiento, educación y capacitación en seguridad de la información

A.8.2.2 Todos los funcionarios de la institución, personal a honorarios y, cuando sea relevante, los terceros deberían recibir una adecuada capacitación en seguridad y actualizaciones regulares sobre las políticas y procedimientos institucionales conforme sea relevante para su función laboral.

• Se deben realizar actividades de capacitación permanentes a todo el personal en materias de seguridad de la información.

• Para el personal nuevo, debe incluirse esta materia en las charlas de inducción. • Deben incluirse materias específicas para funciones específicas dentro de la

institución.

Proceso A.8.2.3 Debería existir un proceso • Se debe establecer dentro del nombramiento o del contrato para honorarios, una


49



disciplinario disciplinario para los funcionarios que han cometido una violación a la seguridad.

declaración sobre la obligación de tomar razón sobre las políticas y procedimientos relativos a la seguridad de la información, y que su incumplimiento derivará en las sanciones correspondientes definidas en la Ley.

Responsabilidades de término

A.8.3.1 Se deberían definir y asignar claramente las responsabilidades de realizar la desvinculación o cambio en las funciones

• Se debe incluir dentro de las resoluciones de nombramiento o de contratos a honorarios las responsabilidades de acuerdo al tipo de información manejada por el funcionario, y las contenidas dentro de un contrato de confidencialidad, aún por un tiempo luego de la desvinculación.

Devolución de los activos

A.8.3.2 Todos los usuarios funcionarios, personal a honorarios y terceras personas deberían devolver todos los activos de la institución que tengan en su posesión al término de su empleo, contrato o acuerdo.

• Se debe crear un procedimiento de devolución y reutilización de activos una vez que se desvinculen los funcionarios o se produzca el cese del contrato a honorarios o con terceros. Este debe incluir el borrado efectivo de los datos y la estandarización del sistema al nuevo usuario.

Retiro de los derechos de acceso

A.8.3.3 Los derechos de acceso de todos los usuarios funcionarios, personal a honorarios y terceras personas a la información y los medios de procesamiento de información deberían ser removidos como consecuencia de su desvinculación, o deberían ser ajustados si sus funciones cambian

• Se debe crear un procedimiento de baja de usuarios en los sistemas de información, que considere la revocación de sus cuentas de acceso y privilegios, dependiendo de los siguientes factores de riesgo: o Cuando el término o cambio de puesto es iniciado por el funcionario, personal

a honorarios o terceros, o por razones administrativas. o Las responsabilidades actuales del funcionario, personal a honorarios o

tercero. o El valor de los activos que actualmente maneja.

Segu

rida

d Fí

sica

y A

mbi

enta

l

Perímetro de seguridad física

A.9.1.1 Se deberían utilizar perímetros de seguridad (barreras tales como paredes, rejas de entrada controladas por tarjetas o recepcionistas) para proteger las áreas que contienen información y medios de procesamiento de información.

• Los perímetros de seguridad deben ser claramente definidos, y la fortaleza de cada uno de ellos dependerán de los niveles de seguridad que requieran los activos de información de acuerdo a su nivel de exposición al riesgo.

• Los perímetros deben tener solidez física y deben estar protegidos por alarmas sonoras, rejas, candados, etc. Las puertas y ventanas deben ser debidamente protegidas del acceso no autorizado.

• Se debe considerar un recepcionista de entrada. • Donde sea aplicable, se deben mantener barreras físicas para evistar el acceso no

autorizado. • Todas las puertas contra incendio deben tener alarmas, ser monitoreadas y

probadas para establecer su nivel de resistencia. Deben estar regularizadas acorde a los estándares locales.

• Deben existir sistemas de detección de intrusos acorde a estándares internacionales y deben cubrir todos los lugares que permitan el acceso. Las áreas


50



no ocupadas deben estar siempre equipadas con sistemas de seguridad. • Las instalaciones que sean manejadas por la institución deben estar físicamente

separadas de aquellas que son manejadas por terceros. • Los lineamientos anteriores deben, además, quedar establecidos dentro de una

política o procedimiento. Controles de ingreso físico

A.9.1.2 Las áreas seguras deberían protegerse mediante controles de ingreso apropiados para asegurar que sólo se le permita el acceso al personal autorizado.

• Los siguientes lineamientos deben ser considerados: o La fecha y la hora de la entrada y salida deben ser registrados y todos los

visitantes deben ser supervisados a menos que su acceso se haya aprobado previamente, el acceso debe ser concedido sólo para propósitos y áreas específicas y deben tomar conocimiento de las instrucciones y procedimientos de seguridad de dicha área.

o El acceso a la áreas donde se procesa o almacena información sensible debe ser controlado y restringido sólo a las personas autorizadas. Se deben utilizar controles de autenticación como tarjetas de acceso con PIN, para autorizar y validar todos los accesos y se debe dejar un registro auditable.

o Todos los funcionarios, personal a honorarios y terceros así como todos los visitantes deben utilizar una credencial visible, y se debe notificar inmediatamente al personal de seguridad si se encuentran visitantes no acompañados y a cualquier persona que no lleve la identificación visible.

o Se debe conceder el acceso restringido del personal de soporte de terceras partes a las áreas seguras o sensibles sólo cuando sea requerido; este acceso debe ser autorizado y supervisado.

o Los derechos de acceso deben ser regularmente revisados, actualizados y revocados cuando sea necesario.

o Los lineamientos anteriores deben, además, quedar establecidos dentro de una política o procedimiento.

Asegurar las oficinas, habitaciones y medios

A.9.1.3 Se debería diseñar y aplicar la seguridad física para las oficinas, despachos e instalaciones.

• Deben considerarse los siguientes lineamientos: o Deben tomarse en cuenta las regulaciones y normativas referentes a higiene y

seguridad. o Debe existir un estándar para la elección de contraseñas robustas. o Las instalaciones críticas deben situarse evitando el acceso público. o Debe evitarse la señalética que evidencie demasiado un centro de

procesamiento. o Debe existir un directorio telefónico del personal clave, que esté fácilmente

disponible pero no al público en general. o Los lineamientos anteriores deben, además, quedar establecidos dentro de


51



una política o procedimiento.

Protección contra amenazas externas e internas

A.9.1.4 Se debería asignar y aplicar protección física contra daño por fuego, inundación, terremoto, explosión, revuelta civil y otras formas de desastres naturales o causados por el hombre.

• Deben considerarse los siguientes lineamientos: o Materiales peligrosos o inflamables deben ser almacenados a una distancia

prudente en un área segura. o Equipamiento de contingencia debe ser instalado a una distancia adecuada en

un área segura para evitar el daño frente a un desastre que afecte al sitio principal.

o Equipamiento de extinción de incendios debe ser provisto y de rápido acceso. o Los lineamientos anteriores deben, además, quedar establecidos dentro de

una política o procedimiento. Trabajo en áreas aseguradas

A.9.1.5 Se debería diseñar y aplicar la protección física y los lineamientos para trabajar en áreas aseguradas.

• Deben considerarse los siguientes lineamientos: o El personal sólo debe conocer la existencia de un área segura (o asegurada) si

por sus actividades lo requiere para desarrollar su trabajo. o El trabajo no supervisado en las áreas seguras, debe ser evitado tanto por

razones de seguridad como para prevenir actividades maliciosas. o Las áreas seguras desocupadas deben ser físicamente cerradas y chequeadas

periódicamente. o Cámaras fotográficas, de video, audio u otros dispositivos de reproducción, no

deben ser permitidos a menos que estén expresamente autorizados. o Los lineamientos anteriores deben, además, quedar establecidos dentro de

una política o procedimiento. Áreas de acceso público, entrega y carga

A.9.1.6 Se deberían controlar los puntos de acceso como las áreas de entrega y carga y otros puntos por donde personas no-autorizadas pudieran ingresar a las instalaciones y, si fuese posible, deberían aislarse de los medios de procesamiento de información para evitar el acceso no autorizado.

• Deben considerarse los siguientes lineamientos: o El acceso a la entrega y carga desde fuera del edificio debe ser restringido a

personal debidamente identificado y autorizado. o Las puertas externas deben ser aseguradas cuando se abran las puertas

internas. o El material que ingrese debe ser inspeccionado para evitar posibles amenazas

antes de que sea ingresado a su lugar de utilización. o Los envíos entrantes y salientes deben segregarse físicamente. o Los lineamientos anteriores deben, además, quedar establecidos dentro de

una política o procedimiento. Ubicación y protección del equipo

A.9.2.1 Se debería ubicar o proteger el equipo para reducir las amenazas y peligros ambientales y oportunidades de acceso no-

• Deben considerarse los siguientes lineamientos: o El equipamiento debe situarse de manera de minimizar el acceso innecesario a

las áreas de trabajo. o Las instalaciones de procesamiento de información y los equipos deben ser


52



autorizado ubicados de forma que su ángulo de visión quede restringido para reducir el riesgo de que la información sea vista por personas no autorizadas, y las instalaciones aseguradas para evitar el acceso no autorizado.

o Los activos de información que requieren protección especial se deben aislar. o Deben adoptarse controles que minimicen los riesgos de amenazas físicas,

ejemplo: robos, fuego, explosivos, humo, polvo, vibración, etc. o Procedimientos sobre no comer, beber o fumar cerca de los equipos de

procesamiento de información. o Se deben implementar las condiciones ambientales mínimas como

temperatura, humedad, y deben ser monitoreadas. o Se debe implementar protección ante fallas en el suministro eléctrico, y

proteger las líneas de alimentación. o Los lineamientos anteriores deben, además, quedar establecidos dentro de

una política o procedimiento. Servicios básicos de soporte

A.9.2.2 Se debería proteger el equipo de fallas de energía y otras interrupciones causadas por fallas en los servicios básicos de soporte.

• Todos los equipos y activos de información que formen parte de la infraestructura crítica de TICs (Servidores, Switches, Routers, Ventilación, etc.), deben ser alimentados con una red eléctrica independiente a la de alumbrado y protegida a través de equipos “UPS” que garanticen su funcionamiento ante cortes eléctricos.

• Los lineamientos anteriores deben, además, quedar establecidos dentro de una política o procedimiento.

Seguridad del cableado

A.9.2.3 El cableado de la energía y las telecomunicaciones que transporta datos o brinda soporte a los servicios de información debería protegerse contra la interceptación o daño.

• Se deben considerar los siguientes lineamientos: o Las líneas de energía y telecomunicaciones hacia las instalaciones de

procesamiento de información, dentro de lo posible deben ser subterráneas, o sujetas a una protección alternativa.

o El cableado de red debe ser protegido ante intercepción no autorizada o daño. o Los cables de poder deben estar separados de los de datos para evitar

interferencia. o Los cables deben rotularse adecuadamente para reducir al mínimo los errores

de manejo. o Se debe utilizar una lista documentada de las conexiones para reducir la

posibilidad de errores. o Se deben considerar controles adicionales para los sistemas críticos, como

instalación de conductos blindados en los terminales de inspección, uso de medios de transmisión alternativos que proporcionen una adecuada seguridad, utilizar cableado de fibra óptica, utilizar cubiertas contra campos electromagnéticos para proteger los cables.


53



o Se deben realizar barridos técnicos e inspecciones físicas contra dispositivos no autorizados conectados a los cables.

o Debe existir un mapa de los patch panels y un acceso controlado a la sala de cables.

o Los lineamientos anteriores deben, además, quedar establecidos dentro de una política o procedimiento.

Mantenimiento de equipo

A.9.2.4 Se debería mantener correctamente el equipo para asegurar su continua disponibilidad e integridad.

• Se deben considerar los siguientes lineamientos: o Los equipos deben mantenerse acorde a lo recomendado por el fabricante. o Sólo personal autorizado debe realizar las mantenciones. o Se deben registrar las mantenciones preventivas y correctivas y las fallas reales

o sospechosas. o Deben incorporarse controles específicos cuando el equipamiento sea

mantenido (ejemplo, respaldos de información, configuraciones, etc.). o Se deben considerar pólizas de seguros para el equipamiento y cumplir con sus

requisitos. o Los lineamientos anteriores deben, además, quedar establecidos dentro de

una política o procedimiento. Seguridad del equipo fuera de las instalaciones de la organización.

A.9.2.5 Se debería aplicar seguridad al equipo fuera de las dependencias del Servicio tomando en cuenta los diferentes riesgos de trabajar fuera de las instalaciones de la organización.

• Se deben considerar los siguientes lineamientos: o El equipamiento que es retirado de las áreas seguras no debe ser dejado

desatendido en áreas de acceso público. Si se debe viajar con el laptop, éste debe ser transportado como equipaje de mano.

o Se deben observar siempre las instrucciones del fabricante para proteger los equipos, por ejemplo, contra exposiciones a campos electromagnéticos intensos.

o Se deben considerar medidas de seguridad para el tele-trabajo o Las pólizas de seguros deben considerar el equipamiento fuera de las áreas

seguras. o Los lineamientos anteriores deben, además, quedar establecidos dentro de

una política o procedimiento. Seguridad en la eliminación o reutilización del equipo

A.9.2.6 Se deberían chequear los ítems del equipo que contiene medios de almacenaje para asegurar que se haya retirado o sobre-escrito cualquier data confidencial o licencia de software antes de su eliminación.

• Deben existir e implementarse procedimientos de borrado seguro de datos y de reutilización de equipos.


54



Retiro de bienes A.9.2.7 El equipamiento, la información o el software no debería retirarse sin autorización previa.

• Se deben considerar los siguientes lineamientos: o El equipamiento, la información o el software no deben retirarse de las

dependencias de la organización sin previa autorización. o Debe identificarse claramente al personal que tenga autorización para retirar

equipamiento fuera de las dependencias del Servicio. o Debe especificarse un tiempo máximo para el equipamiento retirado y

verificarse el cumplimiento de retorno. o Debe registrarse tanto la salida del equipamiento de las dependencias del

Servicio, como el retorno del mismo.

Ges

tión

de

las

com

unic

acio

nes

y op

erac

ione

s

Procedimientos de operación documentados

A.10.1.1 Los procedimientos de operación se deberían documentar, mantener y poner a disposición de todos los usuarios que los necesiten.

• Deben existir procedimientos para la operación de la infraestructura crítica de TICs incluyendo lo siguiente: o Manejo y procesamiento de la información. o Respaldos. o Requerimientos de tareas automatizadas, incluyendo las dependencias con

otros sistemas. Alerta sobre tareas ejecutadas correcta e incorrectamente. o Instrucciones para manejar errores o condiciones excepcionales. o Contactos de soporte ante la eventualidad de dificultades técnicas. o Procedimientos de manejo de medios y de retención de datos. o Reinicio de sistemas y procedimientos de recuperación ante fallas de los

sistemas. o Procedimientos de administración de logs de auditoría.

Gestión del cambio A.10.1.2 Se deberían controlar los cambios en los medios y sistemas de procesamiento de la información.

• Se deben considerar los siguientes ítems: o Identificación y registro de cambios significantes. o Planeamiento y chequeo de los cambios. o Evaluación de los potenciales impactos, incluyendo la seguridad de la

información. o Procedimiento formal de aprobación para los cambios propuestos. o Comunicación efectiva de los detalles del cambio a las personas relevantes. o Procedimientos de vuelta atrás, que incluyan responsabilidades de abortar y

recuperar ante cambios no satisfactorios. Segregación de los

deberes A.10.1.3 Los deberes y áreas de

responsabilidad deberían estar segregados para reducir las oportunidades de una modificación no-autorizada o mal uso no-intencional o mal uso de los activos

• Deben crearse perfiles de usuario que sean consecuentes con las descripciones del cargo que desempeñan, y que contengan los mínimos accesos a los sistemas de información para llevar a cabo sus funciones.

• El Encargado de seguridad debe validar estos perfiles y auditarlos al menos 2 veces al año


55



de la institución

Separación de los medios de desarrollo, prueba y operación

A.10.1.4 Los medios de desarrollo, prueba y operación deberían estar separados para reducir los riesgos de acceso no-autorizado o cambios en el sistema operacional.

• Los siguientes ítems deben ser considerados: o Políticas y procedimientos para la transferencia del software desde ambientes

de desarrollo a producción, y registro de actividad. o Las aplicaciones de desarrollo y producción deben correr en ambientes

física/lógicamente separados. o Los compiladores, editores y cualquier herramienta de desarrollo no debe

quedar disponible desde sistemas en producción. o Los sistemas de pruebas deben emular lo más cercano posible a los ambientes

productivos. o Los usuarios deberán utilizar distintos perfiles para sistemas productivos y de

prueba. o Los datos sensibles no deben ser copiados hacia ambientes de prueba.

Entrega del servicio A.10.2.1 Se debería asegurar que los controles de seguridad, definiciones del servicio y niveles de entrega incluidos en el acuerdo de entrega del servicio de terceros se implementen, operen y mantengan.

• Deben existir acuerdos de niveles de seguridad, definiciones de servicios y aspectos de la administración de los servicios.

• Deben existir acuerdos de servicio para la recuperación ante desastres o fallas.

Monitoreo y revisión de los servicios de terceros

A.10.2.2 Los servicios, reportes y registros provistos por terceros deberían ser monitoreados y revisados regularmente, y se deberían llevar a cabo auditorías regularmente.

• Debe existir una relación de administración de los servicios y procesos entre la institución y los terceros para: o Monitorear los niveles de servicio y chequear su adherencia a los acuerdos. o Revisar los reportes generados por los terceros y acordar reuniones. o Proveer información ante incidentes de seguridad de manera de dar

cumplimiento a la normativa de seguridad. o Revisar los registros de auditoría de los terceros, frente a problemas de

seguridad, operacionales, fallas, y discontinuidad de servicio. o Resolver y administrar los problemas identificados.

Manejo de cambios en los servicios de terceros

A.10.2.3 Se deberían manejar los cambios en la provisión de servicios, incluyendo el mantenimiento y mejoramiento de las políticas, procedimientos y controles de seguridad de la información

• El proceso de administración de cambios, necesita manejar: o Los cambios realizados por la institución para implementar mejoras a los

servicios ofrecidos; desarrollo de cualquier nueva aplicación o sistema; modificaciones o actualizaciones de los procedimientos o políticas de la institución; nuevos controles que resuelvan incidentes de seguridad o mejoren el nivel.


56



existentes teniendo en cuenta el grado crítico de los sistemas y procesos del negocio involucrados y la re-evaluación de los riesgos.

o Los cambios realizados por los terceros para mejorar las redes; el uso de nuevas tecnologías; adopción de nuevos productos o nuevas versiones; nuevas herramientas de desarrollo y ambientes; cambios a las locaciones físicas o facilidades de servicio; cambios en los fabricantes.

Gestión de la capacidad

A.10.3.1 Se debería monitorear, afinar el uso de los recursos y se deberían realizar proyecciones de los requerimientos de capacidad futura para asegurar el desempeño requerido del sistema.

• Deben existir informes periódicos del uso de las capacidades de los sistemas productivos críticos, de manera de obtener un estimado de su rendimiento y capacidad máxima sin degradar los servicios.

Aceptación del sistema

A.10.3.2 Se debería establecer el criterio de aceptación de los sistemas de información nuevos, actualizaciones o versiones nuevas y se deberían realizar pruebas adecuadas del sistema(s) durante el desarrollo y antes de su aceptación.

• Deben establecerse plataformas de pruebas para la aplicación de parches y actualizaciones de seguridad antes de ser puestas en producción, así también como el procedimiento asociado.

• Los siguientes ítems deben ser considerados previo a una aceptación formal: o Requerimientos de capacidad y desempeño. o Procedimiento de recuperación ante errores y planes de contingencia. o Preparación y rutinas de pruebas. o Acuerdo de los controles de seguridad a implementar. o Procedimientos de operación manual. o Acuerdos de continuidad del negocio. o Evidencia de que la instalación del nuevo sistema, no afectará a los actuales en

producción, en particular en tiempos de utilización excesiva. o Evidencia de que la instalación del nuevo sistema, no afectará al nivel de

seguridad actual en producción. o Entrenamiento en la operación de los nuevos sistemas. o Facilidad del uso, cómo afectan al desempeño de los usuarios y como prevén

errores humanos. Controles contra

códigos maliciosos A.10.4.1 Controles de detección, prevención

y recuperación para proteger contra códigos maliciosos y se deberían implementar procedimientos para el apropiado conocimiento del usuario.

• Los siguientes lineamientos deben ser considerados: o Establecer una política formal que prohíba el uso no autorizado de software. o Establecer una política formal que proteja ante los riesgos asociados al obtener

software y archivos a través de redes externas, o cualquier otro medio, indicando que medidas preventivas deben ser tomadas.

o Efectuar revisiones periódicas del software y los contenidos de los datos de los sistemas que soportan procesos de negocio críticos, y se debe investigar ante la presencia de cualquier archivo no autorizado.

o Se debe instalar software que detecte código malicioso que sea enviado a


57



través de cualquier medio y éste debe ser actualizado regularmente. o Definir procedimientos y responsabilidades para tratar con código malicioso,

entrenamiento en el uso, reporte y recuperación ante ataques. o Preparar apropiados planes de continuidad del negocio para recuperarse ante

eventuales ataques. o Implementar procedimientos para recopilar regularmente información como

listas de correo o sitios informativos. Controles contra

códigos móviles A.10.4.2 Donde se autorice el uso del código

móvil, la configuración debería asegurar que el código móvil autorizado opera de acuerdo con una política de seguridad claramente definida, y se debería evitar la ejecución del código móvil no-autorizado.

• Las siguientes acciones deben ser consideradas: o Ejecutar código móvil en un ambiente aislado. o Bloquear cualquier uso de código móvil. o Bloquear la recepción de código móvil. o Activar medidas técnicas. o Controlar los recursos a los cuales un código móvil puede acceder. o Utilizar controles criptográficos para autenticar un código móvil.

Respaldo de información

A.10.5.1 Se deberían hacer copias de respaldo de la información y software y se deberían probar regularmente en concordancia con la política de copias de respaldo acordada

• Los siguientes lineamientos deben ser considerados: o Debe ser definido el nivel necesario de respaldo. o Se deben proveer registros completos y registros de la información que se

respalda, así también como los procedimientos de recuperación. o La frecuencia de los respaldos debe estar acorde a los requerimientos de la

institución. o Los respaldos deben ser almacenados en una ubicación remota. o Los medios de respaldo deben ser almacenados en un lugar con protección

física y medioambiental. o Los medios de recuperación deben ser probados regularmente para asegurar

que puedan ser utilizados. o Los procedimientos de restauración deben ser probados regularmente. o Para los datos confidenciales, se debe proveer con respaldos protegidos con

mecanismos de inscripción. Controles de redes A.10.6.1 Las redes deberían ser

adecuadamente manejadas y controladas para poder proteger la información en las redes, y mantener la seguridad de los sistemas y aplicaciones utilizando la red, incluyendo la información en

• Los siguientes ítems deben ser considerados: o Las responsabilidades en la operación de las redes deben ser separadas de las

responsabilidades en el manejo de los servidores. o Deben establecerse responsabilidades y procedimientos de administración de

equipamiento remoto. o Deben establecerse controles especiales para resguardar la confidencialidad e

integridad de los datos que viajan sobre redes públicas o inalámbricas.


58



tránsito. o Deben establecerse los mecanismos apropiados de monitoreo y registro de las acciones relevantes para la seguridad.

Seguridad de los servicios de la red

A.10.6.2 En todo contrato de redes se deberían identificar e incluir las características de seguridad, niveles de servicio y requerimientos de gestión de todos los servicios de red, ya sea que estos servicios sean provistos interna o externamente.

• Las características de seguridad para los servicios de red, deberían: o Aplicar tecnología para asegurar los servicios de red, tal como autenticación,

encripción y control de conexiones. o Se deben establecer conexiones seguras a través de reglas de acceso de

acuerdo a los requerimientos de la institución.

Gestión de medios removibles

A.10.7.1 Deberían existir procedimientos para la gestión de los medios removibles.

• Los siguientes lineamientos deben ser considerados: o Si no es necesario, los contenidos de cualquier medio reutilizable, deben ser

removidos de la institución, haciéndolos irrecuperables. o Deben establecerse registros de auditoría. o Todos los medios deben almacenarse en un ambiente seguro, de acuerdo a las

especificaciones del fabricante. o La información almacenada en medios removibles que requiera estar

disponible después del tiempo de vida del medio, debe ser almacenado en cualquier otro medio de manera de garantizar que no exista pérdida de información

o Deben ser autorizados los medios removibles de acuerdo a los requerimientos de la institución.

Procedimientos para el manejo de información

A.10.7.2 Se deberían establecer los procedimientos para el manejo y almacenaje de información para proteger esta información de una divulgación no-autorizada o mal uso.

• Los siguientes ítems deben ser considerados: o Se debe manejar y rotular todos los medios indicando su nivel de clasificación o Se debe restringir el acceso al personal autorizado. o Se debe mantener un registro formal. o El almacenamiento de los medios debe estar acorde a las especificaciones del

fabricante. o Mantener la cadena de custodia al mínimo.

Seguridad de la documentación del sistema

A.10.7.3 Se debería proteger la documentación del sistema con accesos no-autorizados.

• Se deben considerar los siguientes ítems: o La documentación del sistema debe ser almacenada en un área segura. o Las listas de acceso a la documentación deben mantenerse al mínimo y solo

para el dueño del aplicativo. o Si la documentación es provista en una red pública, debe ser asegurada.

Políticas y procedimientos de

A.10.8.1 Se deberían establecer políticas, procedimientos y controles de

• Se deben considerar los siguientes ítems: o Los procedimientos diseñados para proteger el intercambio de información de


59



intercambio de información

intercambio formales para proteger el intercambio de información a través del uso de todos los tipos de medios de comunicación.

la intercepción, copiado, modificación, routing equivocado y destrucción. o Los procedimientos para la detección y protección de contra códigos

maliciosos que pueden ser transmitidos a través del uso de comunicaciones electrónicas.

o Los procedimientos para proteger la información electrónica confidencial o Comunicada que está en la forma de un adjunto. o Una política o lineamientos para el uso aceptable de los medios de

comunicación electrónicos. o Los procedimientos para el uso de comunicación inalámbrica, tomando en

cuenta los riesgos particulares involucrados. o Las responsabilidades del usuario empleado, contratista y cualquier otro para

que no comprometan a la organización; por ejemplo, a través de la difamación, hostigamiento, suplantación, re-envío de cadenas de cartas, compras no- autorizadas, etc.

o El uso de técnicas de codificación; por ejemplo, para proteger la confidencialidad, integridad y autenticidad de la información.

o Los lineamientos de retención y eliminación de toda la correspondencia del negocio, incluyendo mensajes, en concordancia con la legislación y regulaciones nacionales y locales relevantes;

o No dejar la información confidencial o crítica en medios impresos; por ejemplo, copiadoras, impresoras y máquinas de fax; ya que personal no-autorizado puede tener acceso a ellas;

o Los controles y restricciones asociados con el re-envío de los medios de comunicación; por ejemplo, re-envío automático de correo electrónico a direcciones externas.

o Instruir al personal que debería tomar las precauciones apropiadas; por ejemplo, no revelar información confidencial cuando realiza una llamada telefónica para evitar ser escuchado o interceptado.

o No dejar mensajes conteniendo información confidencial en máquinas contestadoras dado que estos pueden ser escuchados por personas no- autorizadas.

Acuerdos de intercambio

A.10.8.2 Se deberían establecer acuerdos para el intercambio de información y software entre la institución y entidades externas.

• Se deben considerar las siguientes condiciones de seguridad: o El manejo de las responsabilidades para el control y notificación de la

transmisión, despacho y recepción. o Los procedimientos para notificar al remitente de la transmisión, despacho y

recepción. o Los procedimientos para asegurar el rastreo y no-repudio.


60



o Los estándares técnicos mínimos para el empaque y la transmisión. o Los acuerdos de depósitos. o Los estándares de identificación del mensajero. o Las responsabilidades y obligaciones en el evento de incidentes de seguridad

de la información, como la pérdida de data. o El uso de un sistema de etiquetado acordado para la información confidencial

o crítica, asegurando que el significado de las etiquetas sea entendido inmediatamente y que la información sea adecuadamente protegida.

o La propiedad y responsabilidades de la protección de data, derechos de autor, licencias de software y consideraciones similares.

o Los estándares técnicos para grabar y leer la información y software. o Cualquier control especial que se pueda requerir para proteger los ítems

confidenciales, como claves criptográficas. Medios físicos en

tránsito A.10.8.3 Los medios que contienen

información deberían ser protegidos contra accesos no-autorizados, mal uso o corrupción durante el transporte más allá de los límites físicos de una institución

• Debe considerarse lo siguiente: o Se deberían utilizar transportes o mensajerías confiables. o Se deberían desarrollar procedimientos para chequear la identificación de los

mensajeros. o El empaque debería ser suficiente para proteger los contenidos de cualquier

daño que pudiera surgir durante el tránsito y en concordancia con las especificaciones de cualquier fabricante.

o Donde sea necesario, se deberían adoptar controles para proteger la información confidencial de la divulgación o modificación no-autorizada

Mensajes electrónicos

A.10.8.4 Se debería proteger adecuadamente la información involucrada en mensajes electrónicos.

• Debe considerarse lo siguiente: o Proteger los mensajes del acceso no-autorizado, modificación o negación del

servicio. o Asegurar la correcta dirección y transporte del mensaje. o La confiabilidad y disponibilidad general del servicio. o Las consideraciones legales. o Obtener la aprobación antes de utilizar los servicios públicos externos como un

mensaje instantáneo o intercambio de archivos. o Niveles mayores de autenticación controlando el acceso de las redes de acceso

público. Sistemas de

información negocio

A.10.8.5 Se deberían desarrollar e implementar políticas y procedimientos para proteger la información asociada con la

• Debe considerarse lo siguiente: o Vulnerabilidades conocidas en los sistemas administrativos y contables donde

la información es compartida entre diferentes partes de la institución. o Las vulnerabilidades de la información en los sistemas de comunicación


61



interconexión de los sistemas de información de negocio.

comercial; por ejemplo, grabando llamadas o conferencias telefónicas, la confidencialidad de las llamadas, almacenaje de faxes, apertura de correo, distribución del correo.

o Establecer una política y los controles apropiados para manejar el intercambio de información.

o Excluir las categorías de información confidencial y los documentos clasificados si el sistema no proporciona un nivel de protección apropiado.

o Restringir el acceso a la información diaria relacionada con personas seleccionadas; por ejemplo, el personal trabajando en proyectos confidenciales.

o La retención y respaldo de la información mantenida en el sistema. Comercio

electrónico A.10.9.1 La información involucrada en el

comercio electrónico que pasa a través de redes públicas debería protegerse de la actividad fraudulenta, disputas de contratos, divulgación no-autorizada y modificación.

• Se debe considerar lo siguiente (considerar su nivel de aplicabilidad): o El nivel de confianza que cada parte requiere de la identidad de la otra; por

ejemplo, a través de la autenticación. o Los procesos de autorización asociados con aquellos que pueden establecer

precios, emitir o firmar documentos de comercialización. o Asegurar que las contrapartes comerciales estén totalmente informados de sus

autorizaciones. o Determinar y cumplir con los requerimientos para la confidencialidad,

integridad, prueba de despacho y recepción de documentos claves, y el no-repudio de los contratos; por ejemplo, asociado con procesos de licitación y contratos.

o El nivel de confianza requerido para la integridad de las listas de precios publicitadas;

o La confidencialidad de cualquier data o información confidencial; o La confidencialidad e integridad de cualquier transacción, información de pago,

detalles de la dirección de entrega y la confirmación de la recepción; o El grado de verificación apropiado para chequear la información de pago

suministrada por un cliente; o Seleccionar la forma de liquidación más apropiada del pago para evitar el

fraude. o El nivel de protección requerido para mantener la confidencialidad e integridad

de la información de la orden. o Evitar la pérdida o duplicación de la información de la transacción. o La responsabilidad asociada con cualquier transacción fraudulenta.

Transacciones en- A.10.9.2 Se debería proteger la información • Se debe considerar lo siguiente:


62



línea involucrada en las transacciones en-línea para evitar una transmisión incompleta, routing equivocado, alteración no-autorizada del mensaje, divulgación no-autorizada, duplicación o repetición no-autorizada del mensaje.

o El uso de firmas electrónicas por cada una de las partes involucradas en la transacción.

o Todos los aspectos de la transacción. o El camino de las comunicaciones entre las partes involucradas debería ser

codificado. o Los protocolos utilizados para comunicarse entre todas las partes involucradas

sean seguros. o Asegurar que el almacenaje de los detalle de la transacción se localice fuera de

cualquier ambiente público accesible; por ejemplo, en una plataforma de almacenaje existente en el Intranet institucional, y no se mantenga y exponga en un medio de almacenaje directamente accesible desde el Internet.

o Utilizar una autoridad confiable (por ejemplo, para propósitos de emitir y mantener firmas digitales y/o certificados digitales) la seguridad es integrada e introducida durante todo el proceso de gestión de firma/certificado de principio a fin.

Información públicamente disponible

A.10.9.3 Se debería proteger la integridad de la información puesta a disposición en un sistema públicamente disponible para evitar una modificación no-autorizada.

• Se deberían controlar cuidadosamente los sistemas de publicación electrónica, especialmente aquellos que permiten retroalimentación y el ingreso directo de información de manera que: o La información se obtenga cumpliendo con la legislación de protección de

data. o El input de información para, y procesado por, el sistema de publicación será

procesado completa y exactamente de una manera oportuna. o Se protegerá la información confidencial durante la recolección,

procesamiento y almacenaje. o Que el acceso al sistema de publicación no permita el acceso involuntario a las

redes con las cuales se conecta el sistema. Registro de

auditoría A.10.10.1 Se deberían producir y mantener

registros de auditoría de las actividades, excepciones y eventos de seguridad de la información durante un período acordado para ayudar en investigaciones futuras y monitorear el control de acceso.

• Los registros de auditoría deberían incluir, cuando sea relevante: o Utilizar IDs. o Fechas, horas y detalles de eventos claves; por ejemplo, ingreso y salida. o Identidad o ubicación de la identidad, si es posible. o Los registros de intentos de acceso fallidos y rechazados al sistema. o Registros de intentos de acceso fallidos y rechazados a la data y otros recursos. o Cambios en la configuración del sistema. o Uso de privilegios. o Uso de las utilidades y aplicaciones del sistema. o Archivos a los cuales se tuvo acceso y los tipos de acceso.


63



o Direcciones y protocolos de la red. o Alarmas activadas por el sistema de control de acceso. o Activación y desactivación de los sistemas de protección; como sistemas anti-

virus y sistemas de detección de intrusiones. Uso del sistema de

monitoreo A.10.10.2 Se deberían establecer

procedimientos para el monitoreo del uso de los medios de procesamiento de la información y se deberían revisar regularmente los resultados de las actividades de monitoreo.

• Cada sistema de registro implementado, debe ser monitoreado y protegido ante accesos no autorizados. Las áreas que deberían considerar incluyen: o Acceso autorizado. o Operaciones privilegiadas. o Intentos de acceso no autorizado. o Alertas o fallas del sistema.

Protección del registro de información

A.10.10.3 Se deberían proteger los medios de registro y la información del registro para evitar la alteración y el acceso no autorizado.

• Se debe considerar dentro del medio de registro, lo siguiente: o Las alteraciones registradas a los tipos de mensajes. o Los archivos de registro que se editan o borran. o La capacidad de almacenamiento del medio de archivos de registro que se está

excediendo, resultando en una falla en el registro de eventos o la escritura encima de los eventos registrados en el pasado.

Registros del administrador y operador

A.10.10.4 Se deberían registrar las actividades del administrador del sistema y el operador del sistema.

• Todas las cuentas con privilegio de administrador o súper usuario dentro de los activos críticos identificados, deben ser continuamente registrados y monitoreados.

Registro de fallas A.10.10.5 Se deberían registrar y analizar las fallas, y se deberían tomar las acciones necesarias

• Cada acción indebida realizada por una cuenta de acceso, debe ser oportunamente notificada al Encargado de Seguridad para tomar las acciones requeridas.

Sincronización de relojes

A.10.10.6 Los relojes de todos los sistemas de procesamiento de información relevantes dentro de una organización o dominio de seguridad se deberían sincronizar con una fuente que proporcione la hora exacta acordada.

• Se deben sincronizar los relojes de todos los sistemas críticos identificados, contra un reloj central y este a su vez estar sincronizado con un reloj atómico en Internet.


64



Cont

rol d

e ac

ceso

Política de control del acceso

A.11.1.1 Se debería establecer, documentar y revisar la política de control de acceso en base a los requerimientos de negocio y de seguridad para el acceso.

• La política debería tomar en cuenta lo siguiente: o Los requerimientos de seguridad de las aplicaciones. o Identificación de toda la información relacionada con las aplicaciones y los

riesgos que enfrenta la información. o Las políticas para la divulgación y autorización de la información; por ejemplo,

la necesidad de conocer el principio y los niveles de seguridad, y la clasificación de la información.

o La consistencia entre el control del acceso y las políticas de clasificación de la información de los diferentes sistemas y redes.

o La legislación relevante y cualquier obligación contractual relacionada con la protección del acceso a la data o los servicios.

o Los perfiles de acceso de usuario estándar para puestos de trabajo comunes en la organización.

o La gestión de los derechos de acceso en un ambiente distribuido y en red que reconoce todos los tipos de conexiones disponibles.

o La segregación de roles del control del acceso; por ejemplo, solicitud de acceso, autorización de acceso, administración del acceso.

o Los requerimientos para la autorización formal de las solicitudes de acceso. o Los requerimientos para la revisión periódica de los controles de acceso. o La revocación de los derechos de acceso.

Registro del usuario A.11.2.1 Debería existir un procedimiento formal para el registro y des-registro del usuario para otorgar y revocar el acceso a todos los sistemas y servicios de información.

• El procedimiento de control del acceso para el registro y des-registro del usuario debería incluir: o Utilizar IDs de usuarios únicos para permitir a los usuarios vincularse y ser

responsables de sus acciones; sólo se debería permitir el uso de IDs grupales cuando son necesarios por razones comerciales u operacionales, y deberían ser aprobados y documentados.

o Chequear que el usuario tenga la autorización dada por el propietario del sistema para el uso del sistema o servicio de información; también puede ser apropiado una aprobación separada de la gerencia para los derechos de acceso.

o Chequear que el nivel de acceso otorgado sea apropiado para el propósito institucional y que sea consistente con la política de seguridad de la organización.

o Proporcionar a los usuarios un enunciado escrito de sus derechos de acceso. o Requerir a los usuarios que firmen los enunciados indicando que entienden las

condiciones de acceso.


65



o Asegurar que los proveedores del servicio no proporcionen acceso hasta que se hayan completado los procedimientos de autorización.

o Mantener un registro formal de todas las personas registradas para usar el servicio.

o Eliminar o bloquear inmediatamente los derechos de acceso de los usuarios que han cambiado de puesto o trabajo o han dejado la organización.

o Chequeo periódico para eliminar o bloquear los IDs de usuario y cuentas redundantes.

Gestión de privilegios

A.11.2.2 Se debería restringir y controlar la asignación y uso de privilegios.

• Se debe considerar: o Los privilegios de acceso asociados con cada producto del sistema; por

ejemplo, sistema de operación, sistema de gestión de base de datos y cada aplicación, y se deberían identificar los usuarios a quienes se les necesita asignar privilegios.

o Los privilegios se deberían asignar a los usuarios sobre la base de “sólo lo que necesitan saber”; es decir, los requerimientos mínimos para su rol funcional, sólo cuando se necesitan.

o Se debería mantener un proceso de autorización y un registro de todos los privilegios asignados. No se deberían otorgar privilegios hasta que se complete el proceso de autorización.

o Se debería promover el desarrollo y uso de rutinas del sistema para evitar la necesidad de otorgar privilegios a los usuarios.

o Se debería promover el desarrollo y uso de los programas que evitan la necesidad de correr con privilegios.

o Los privilegios se deberían asignar a un ID de usuario diferente de aquellos utilizados para el uso normal de la institución.

Gestión de las contraseñas de los usuarios

A.11.2.3 La asignación de contraseñas se debería controlar a través de un proceso de gestión formal.

• Se debe considerar lo siguiente: o Se debería requerir que los usuarios firmen un enunciado para mantener

confidenciales las claves secretas y mantener las claves secretas grupales sólo dentro de los miembros el grupo; este enunciado firmado se puede incluir en los términos y condiciones de empleo.

o Cuando se requiere que los usuarios mantengan sus propias claves secretas, inicialmente se les debería proporcionar una clave secreta temporal segura, la cual están obligados a cambiar inmediatamente.

o Establecer procedimientos para verificar la identidad de un usuario antes de proporcionar una clave secreta nueva, sustituta o temporal.

o Las claves secretas temporales deberían ser proporcionadas a los usuarios de


66



una manera segura, se debería evitar el uso de mensajes de correo electrónico de terceros o no protegidos (sin texto).

o Las claves secretas temporales deberían ser únicas para la persona y no deberían ser fáciles de adivinar.

o Los usuarios deberían reconocer la recepción de las claves secretas. o Las claves secretas nunca deberían ser almacenadas en los sistemas de

información de una forma desprotegida. o Las claves secretas predeterminadas por el vendedor deberían ser cambiadas

después de la instalación de sistemas o software. Revisión de los

derechos de acceso del usuario

A.11.2.4 El encargado de seguridad debería revisar los derechos de acceso de los usuarios a intervalos regulares utilizando un proceso formal.

• Se deben considerar los siguientes lineamientos: • Los derechos de acceso de los usuarios deberían ser revisados a intervalos

regulares; por ejemplo, un período de 6 meses, y después de cualquier cambio, como un ascenso, democión o terminación del empleo.

• Los derechos de acceso del usuario se deberían revisar y re-asignar cuando se traslada de un empleo a otro dentro de la misma organización.

• Las autorizaciones para derechos de acceso privilegiados especiales se deberían revisar a intervalos más frecuentes; por ejemplo, un período de 3 meses.

• Se debería chequear la asignación de privilegios a intervalos regulares para asegurar que no se hayan obtenido privilegios no autorizados.

• Se deberían registrar los cambios en las cuentas privilegiadas para una revisión periódica.

Uso de Contraseñas A.11.3.1 Se debería requerir a los usuarios que sigan buenas prácticas de seguridad en la selección y uso de contraseñas

• Cada sistema de autenticación de usuarios debe ser forzado a cumplir con el uso de contraseñas robustas considerando: o Mantener confidenciales las claves secretas. o Evitar mantener un registro (por ejemplo, papel, archivo en software o

dispositivo manual) de las claves secretas, a no ser que este se pueda mantener almacenado de manera segura y el método de almacenaje haya sido aprobado.

o Cambio de claves secretas cuando haya el menor indicio de un posible peligro en el sistema o la clave secreta.

o Seleccionar claves secretas de calidad con el largo mínimo suficiente o cambio de las claves secretas a intervalos regulares o en base al número de

accesos (las claves secretas para las cuentas privilegiadas se deberían cambiar con mayor frecuencia que las claves secretas normales), y evitar el re-uso de reciclaje de claves secretas antiguas.

o Cambiar la clave secreta temporal en el primer registro de ingreso.


67



o No incluir las claves secretas en ningún proceso de registro automatizado; por ejemplo, almacenado en un macro o función clave.

o No compartir las claves secretas individuales. o No usar la misma clave personal para propósitos laborales y no-laborales.

Equipo del usuario desatendido

A.11.3.2 Los usuarios deberían asegurar que el equipo desatendido tenga la protección apropiada.

• Se debe comunicar a los usuarios que deberían: • Cerrar las sesiones activas cuando se termina, a no ser que puedan asegurarse con

un mecanismo de cierre apropiado; por ejemplo, protector de pantalla asegurado mediante clave secreta.

• Salir de las computadoras mainframe, servidores y PCs de oficina cuando se termina la sesión (es decir, no sólo apagar la pantalla de la PC o Terminal).

• Asegurar las PCs o terminales contra un uso no autorizado mediante un seguro con clave o un control equivalente; por ejemplo, acceso con clave secreta, cuando no está en uso

Política de escritorio y pantalla limpios

A.11.3.3 Se debería adoptar una política de escritorio limpio para papeles y medios de almacenaje removibles y una política de pantalla limpia para los medios de procesamiento de la información.

• Se debe considerar lo siguiente: o La información comercial confidencial o crítica; por ejemplo, en papel o medios

de o Almacenamiento electrónicos; debería ser guardada bajo llave (idealmente en

una caja fuerte o archivador u otra forma de mueble seguro) cuando no está siendo utilizada, especialmente cuando la oficina está vacía.

o Cuando se dejan desatendidas, las computadoras y terminales deberían dejarse apagadas o protegidas con mecanismos para asegurar la pantalla y el teclado, controlados mediante una clave secreta, dispositivo o un mecanismo de autenticación de usuario similar y se deberían proteger con llave, claves secretas u otros controles cuando no están en uso.

o Se deberían proteger los puntos de ingreso y salida de correo y las máquinas de fax desatendidas;

o Se debería evitar el uso no autorizado de fotocopiadoras y otra tecnología de reproducción (por ejemplo, escáneres, cámaras digitales).

o Los documentos que contienen información confidencial o clasificada deberían sacarse inmediatamente de la impresora.

Política sobre el uso de los servicios de la red

A.11.4.1 Los usuarios sólo deberían tener acceso a los servicios para los cuales hayan sido específicamente autorizados.

• Esta política debería abarcar: o Las redes y servicios de la red a las cuales se tiene acceso. o Los procedimientos de autorización para determinar quién está autorizado a

tener acceso a cuáles redes y servicios en red. o Controles y procedimientos gerenciales para proteger el acceso a las

conexiones de la red y los servicios en red.


68



o Los medios utilizados para tener acceso a las redes y los servicios de la red (por ejemplo, las condiciones para permitir acceso a un proveedor del servicio de Internet o sistema remoto).

Autenticación del usuario para las conexiones externas

A.11.4.2 Se deberían utilizar métodos de autenticación apropiados para controlar el acceso de usuarios remotos.

• Deben implementarse medidas de encripción de datos para las comunicaciones remotas de usuarios, en conjunto con una autenticación robusta (ej: VPN, Token, etc.)

Identificación del equipo en las redes

A.11.4.3 La identificación automática del equipo se debería considerar como un medio para autenticar las conexiones de ubicaciones y equipos específicos.

• La identificación automática del equipo se debería considerar como un medio para autenticar las conexiones de ubicaciones y equipos específicos.

Protección del puerto de diagnóstico y configuración remoto

A.11.4.4 Se debería controlar el acceso físico y lógico a los puertos de diagnóstico y configuración.

• Los puertos, servicios y medios similares instalados en una computadora o red, que no son requeridos específicamente por funcionalidad comercial, deberían ser desactivados o removidos.

Segregación en redes

A.11.4.5 Los grupos de servicios de información, usuarios y sistemas de información deberían ser segregados en redes.

• Se deben crear “dominios de seguridad” en las redes de telecomunicaciones, que separen los tráficos de servicios productivos, usuarios, segmentos de desarrollo y desmilitarizados. Estos segmentos pueden ser lógicos o físicos dependiendo de la tecnología implementada

Control de conexión a la red

A.11.4.6 Para las redes compartidas, especialmente aquellas que se extienden a través de las fronteras de la institución, se debería restringir la capacidad de los usuarios para conectarse a la red, en línea con la política de control de acceso y los requerimientos de las aplicaciones de negocio

• Se puede restringir la capacidad de conexión de los usuarios a través de gateways de la red que filtran el tráfico por medio de tablas o reglas predefinidas. Los ejemplos de aplicaciones a las cuales se pueden aplicar las restricciones son: o Mensajes; por ejemplo, correo electrónico, o Transferencia de archivos, o Acceso interactivo, o Acceso a una aplicación.

Control de routing de la red

A.11.4.7 Se deberían implementar controles de routing en las redes para asegurar que las conexiones de la computadora y los flujos de información no violen la política de control de acceso de las

• Se deberían implementar controles de routing en las redes para asegurar que las conexiones de la computadora y los flujos de información no violen la política de control de acceso de las aplicaciones institucionales.


69



aplicaciones de negocio Procedimientos

para un registro seguro

A.11.5.1 El acceso a los sistemas operativos debería ser controlado mediante un procedimiento de registro seguro.

• Se debe considerar que el registro: o No debería mostrar identificadores del sistema o aplicación hasta que se haya

completado satisfactoriamente el proceso de registro. o Debería mostrar la advertencia general que a la computadora sólo pueden

tener acceso los usuarios autorizados. o No debería proporcionar mensajes de ayuda durante el procedimiento de

registro que ayuden al usuario no-autorizado. o Sólo debería validar la información del registro después de completar todo el

input de data. Si surge una condición de error, el sistema debería indicar qué parte de la data es correcta o incorrecta.

o Debería limitar el número de intentos de registro infructuosos permitidos; por ejemplo, tres intentos.

o Debería limitar el tiempo máximo y mínimo permitido para el procedimiento de registro. Si se excede este tiempo, el sistema debería terminar el registro.

o Debería mostrar información al termino de un registro satisfactorio o No debería mostrar la clave secreta que se está ingresando o considerar

esconder los caracteres de la clave secreta mediante símbolos. o No debería transmitir claves secretas en un texto abierto a través de la red.

Identificación y autenticación del usuario

A.11.5.2 Todos los usuarios tienen un identificador único (ID de usuario) para su uso personal, y se debería escoger una técnica de autenticación adecuada para sustanciar la identidad de un usuario.

• Sólo se debería permitir el uso de IDs genéricos para una persona cuando las funciones accesibles o acciones llevadas a cabo por el ID no necesitan ser rastreadas (por ejemplo, sólo acceso de lectura), o cuando existen otros controles establecidos (por ejemplo, la clave secreta para un ID genérico sólo es emitido para una persona a la vez y se registra dicha instancia).

Sistema de gestión de contraseñas

A.11.5.3 Los sistemas para el manejo de claves secretas deberían ser interactivos y deberían asegurar contraseñas adecuadas.

• Se debe tener en consideración: o Aplicar el uso de IDs de usuarios individuales y claves secretas para mantener

la responsabilidad. o Permitir a los usuarios seleccionar y cambiar sus propias claves secretas e

incluir un procedimiento de confirmación para permitir errores de input. o Aplicar la elección de claves secretas adecuadas. o Aplicar los cambios de claves secretas. o Obligar a los usuarios a cambiar las claves secretas temporales en su primer

ingreso o registro. o Mantener un registro de claves de usuario previas y evitar el re-uso.


70



o No mostrar las claves secretas en la pantalla en el momento de ingresarlas. o Almacenar los archivos de claves secretas separadamente de la data del

sistema de aplicación. o Almacenar y transmitir las claves secretas en un formato protegido (por

ejemplo, codificado o indexado). Uso de las

utilidades del sistema

A.11.5.4 Se debería restringir y controlar estrechamente el uso de los programas de utilidad que podrían ser capaces de superar los controles del sistema y la aplicación.

• Se debe tener en consideración: o El uso de los procedimientos de identificación, autenticación y autorización

para las utilidades del sistema. o La segregación de las utilidades del sistema del software de la aplicación. o Limitar el uso de las utilidades del sistema a un número práctico mínimo de

usuarios autorizados y confiables. o Autorización para el uso ad hoc de las utilidades del sistema. o Limitación de la disponibilidad de las utilidades del sistema; por ejemplo, por la

duración de un cambio autorizado. o Registro de todo uso de las utilidades del sistema. o Definir y documentar los niveles de autorización de las utilidades del sistema. o Eliminación o inutilizar todas las utilidades innecesarias basadas en software,

así como los software del sistema que sean innecesarios. o No poner las utilidades a disposición de los usuarios que tienen acceso a las

aplicaciones en los sistemas donde se requiere la segregación de los deberes. Cierre de una sesión

por inactividad A.11.5.5 Las sesiones inactivas deberían ser

cerradas después de un período de inactividad definido.

• Un dispositivo de cierre debería borrar la pantalla de la sesión y también, posiblemente más adelante, cerrar la aplicación y las sesiones en red después de un período de inactividad definido. El tiempo de espera antes del cierre debería reflejar los riesgos de seguridad del área, la clasificación de la información que está siendo manejada y la aplicación siendo utilizada, y los riesgos relacionados con los usuarios del equipo.

Limitación del tiempo de conexión

A.11.5.6 Se deberían utilizar restricciones sobre los tiempos de conexión para proporcionar seguridad adicional para las aplicaciones de alto riesgo.

• Se deberían considerar controles sobre el tiempo de conexión para las aplicaciones de cómputo sensibles, especialmente desde ubicaciones de alto riesgo; por ejemplo, áreas públicas o externas que están fuera de la gestión de seguridad de la organización. Los

ejemplos de tales restricciones incluyen: o Utilizar espacios de tiempo predeterminados; por ejemplo, para transmisiones

de archivos en lotes, o sesiones interactivas regulares de corta duración. o Restringir los tiempos de conexión a los horarios laborales normales, si no

existe ningún requerimiento para sobre-tiempo o una operación de horario extendido.


71



o Considerar la re-autenticación cada cierto intervalo de tiempo. Restricción del

acceso a la información

A.11.6.1 El acceso de los usuarios y el personal de soporte a la información y las funciones del sistema de la aplicación debería limitarse en concordancia con la política de control de acceso definida.

• Se debe considerar: o Proporcionar menús para controlar el acceso a las funciones del sistema de

aplicación. o Controlar los derechos de acceso de los usuarios; por ejemplo, lectura,

escritura, eliminar y ejecutar; o Controlar los derechos de acceso de otras aplicaciones. o Asegurar que los outputs de los sistemas de aplicación que manejan

información confidencial sólo contengan la información relevante para el uso del output y sólo sea enviada a las terminales y ubicaciones autorizadas; esto debería incluir revisiones periódicas de dichos outputs para asegurar que se descarte la información redundante.

Aislar el sistema confidencial

A.11.6.2 Los sistemas confidenciales deberían tener un ambiente de cómputo dedicado (aislado).

• Se debe considerar: o Que el propietario de la aplicación debería identificar y documentar

explícitamente la sensibilidad o confidencialidad del sistema de aplicación. o Cuando una aplicación confidencial va a correr en un ambiente compartido, el

propietario de la aplicación confidencial debería identificar y aceptar los sistemas de aplicación con los cuales va a compartir recursos y los riesgos correspondientes.

Computación y comunicaciones móviles

A.11.7.1 Se debería establecer una política y adoptar las medidas de seguridad apropiadas para proteger contra los riesgos de utilizar medios de computación y comunicación móvil.

• Cuando se utiliza medios de computación y comunicación móvil; por ejemplo, notebooks, dispositivos de mano, laptops, tarjetas inteligentes y teléfonos móviles; se debería tener especial cuidado en asegurar que no se comprometa la información institucional. La política de computación móvil debería tomar en cuenta los riesgos de trabajar con equipo de computación móvil en ambientes desprotegidos.

Tele-trabajo A.11.7.2 Se debería desarrollar e implementar una política, planes operacionales y procedimientos para las actividades de tele-trabajo.

• Se debe considerar: o La seguridad física existente en el lugar de tele-trabajo, tomando en cuenta la

seguridad física del edificio y el ambiente del local. o El ambiente de tele-trabajo físico propuesto. o Los requerimientos de seguridad de las comunicaciones, tomando en cuenta la

necesidad de acceso remoto a los sistemas internos de la organización, la confidencialidad de la información a la cual se tendrá acceso y el vínculo de comunicación y confidencialidad del sistema interno.

o La amenaza de acceso no autorizado a la información o recursos por parte de otras personas que utilizan el medio; por ejemplo, familia y amigos.

o El uso de redes en casa y los requerimientos o restricciones en la configuración


72



de los servicios de la red inalámbrica. o Las políticas y procedimientos para evitar las disputas relacionadas con los

derechos de propiedad intelectual desarrollados en equipo de propiedad privada.

o El acceso a equipo de propiedad privada (para chequear la seguridad de la máquina o durante una investigación), el cual puede ser evitado por la legislación.

o h) contratos de licencias de software que hacen que las organizaciones sean responsables por las licencias del software del cliente en las estaciones de trabajo de propiedad de los funcionarios, personal a honorarios y terceros;

o Los requerimientos de protección anti-virus y firewall.

Adq

uisi

ción

, des

arro

llo y

m

ante

nim

ient

o de

los

sist

emas

de

info

rmac

ión

Análisis y especificación de los requerimientos de seguridad

A.12.1.1 Los enunciados de los requerimientos de negocio para los sistemas de información nuevos, o las mejoras a los sistemas de información existentes, deberían especificar los requerimientos de los controles de seguridad.

• Los requerimientos de seguridad para a seguridad de la información y los procesos para implementar la seguridad deberían ser integrados en las primeras etapas de los proyectos de sistemas de información. Los controles introducidos en la etapa de diseño son significativamente más baratos de implementar y mantener que aquellos incluidos durante o después de la implementación.

Validación de la data de entrada

A.12.2.1 Se debería validar la input data para las aplicaciones para asegurar que esta data sea correcta y apropiada.

• Se deben considerar los siguientes lineamientos: o Valores fuera de rango. o Caracteres inválidos en los campos de data. o Data incompleta o faltante. o Exceder los límites superiores e inferiores del volumen de data. o Data de control no autorizada o inconsistente. o revisión periódica del contenido de los campos claves o archivos de data para

confirmar su validez e integridad. o Inspeccionar los documentos de input de la copia impresa en caso de cambios

no autorizados (todos los cambios a los documentos de input deberían ser autorizados).

o Procedimientos para responder a los errores de validación. o Procedimientos para probar la plausibilidad de la input data.


73



o Definir las responsabilidades de todo el personal involucrado en el proceso de input de data.

o Crear un registro de las actividades involucradas en el proceso de input de data.

Control del procesamiento interno

A.12.2.2 Los chequeos de validación se deberían incorporar en las aplicaciones para detectar cualquier corrupción de la información a través de errores de procesamiento o actos deliberados.

• Se deben considerar los siguientes lineamientos: o El uso de funciones agregadas, modificadas y eliminadas para implementar

cambios en la data. o Los procedimientos para evitar que los programas corran en el orden

equivocado o corran después de una falla en el procesamiento previo. o El uso de programas apropiados para recuperarse de fallas para asegurar el

correcto procesamiento de la data. o Protección contra ataques utilizando excesos/desbordamientos de la memora

intermedia. Integridad del

mensaje A.12.2.3 Se debería identificar los

requerimientos para asegurar la autenticidad y proteger la integridad del mensaje en las aplicaciones, y se deberían identificar e implementar los controles apropiados.

• Se debería realizar una evaluación de los riesgos de seguridad para determinar si se requiera la integridad del mensaje y para identificar el método de implementación más apropiado

Validación de la data de salida

A.12.2.4 Se debería validar la output data de una aplicación para asegurar que el procesamiento de la información almacenada sea el correcto y el apropiado para las circunstancias.

• La validación del output puede incluir: o Chequeos de plausibilidad para comprobar si el output data es razonable. o Conteo de control de conciliación para asegurar el procesamiento de toda la

data. o Proporcionar la información suficiente para un lector o el sistema de

procesamiento subsiguiente para determinar la exactitud, integridad, precisión y clasificación de la información.

o Procedimientos para responder a las pruebas de validación de output. o Definir las responsabilidades de todo el personal involucrado en el proceso de

output de data. o Crear un registro de las actividades en el proceso de validación del output de

data. Política sobre el uso

de controles criptográficos

A.12.3.1 Se debería desarrollar e implementar una política sobre el uso de controles criptográficos para proteger la información.

• Se debe considerar lo siguiente: o El enfoque institucional sobre el uso de los controles criptográficos a través de

la organización, incluyendo los principios generales bajo los cuales se debería proteger la información.


74



o En base a la evaluación del riesgo, se debería identificar el nivel de protección requerido tomando en cuenta el tipo, fuerza y calidad del algoritmo criptográfico requerido.

o El uso de codificación para la protección de la información confidencial transportada por los medios y dispositivos móviles o removibles o a través de las líneas de comunicación.

o El enfoque de la gestión de claves, incluyendo los métodos para lidiar con la protección de las claves criptográficas y la recuperación de la información codificada en el caso de claves pérdidas, comprometidas o dañadas.

o Roles y responsabilidades. o Los estándares a adoptarse para la implementación efectiva en toda la

organización. o El impacto de utilizar información codificada sobre los controles que se basan

en la inspección del contenido (por ejemplo, detección de virus). Gestión de claves A.12.3.2 Se debería establecer la gestión de

claves para dar soporte al uso de técnicas criptográficas en la organización.

• El sistema de gestión de claves se debería basar en un conjunto de estándares, procedimientos y métodos seguros acordados para: o Generar claves para los diferentes sistemas criptográficos y las diversas

aplicaciones. o Generar y obtener certificados de claves públicas. o Distribuir claves a los usuarios planeados, incluyendo cómo se deberían activar

las claves una vez recibidas. o Almacenar claves, incluyendo cómo los usuarios autorizados obtienen acceso a

las claves. o Cambiar o actualizar las claves incluyendo las reglas sobre cuándo se deberían

cambiar las claves y cómo se realiza esto. o Lidiar con las claves comprometidas. o Revocar las claves incluyendo cómo se deberían retirar o desactivar las claves.

Por ejemplo, cuando las claves se han visto comprometidas o cuando el usuario deja la institución.

o Recuperar las claves cuando han sido perdidas o corrompidas como parte de la continuidad y gestión del negocio; por ejemplo, para recuperar la información codificada.

o Archivar las claves; por ejemplo, para la información archivada o respaldada. o Destruir las claves. o Registrar y auditar las actividades relacionadas con la gestión de claves. o


75



Control del software operacional

A.12.4.1 Se deberían establecer procedimientos para el control de la instalación del software en los sistemas operacionales.

• Se debe considerar lo siguiente, para el control de cambios: o La actualización del software operacional, aplicaciones y bibliotecas de

programas sólo debería ser realizada por administradores capacitados con la apropiada autorización.

o Los sistemas operacionales sólo deberían mantener códigos ejecutables aprobados, y no códigos de desarrollo o compiladores.

o El software de las aplicaciones y el sistema de operación sólo se debería implementar después de una prueba extensa y satisfactoria; las pruebas deberían incluir pruebas de utilidad, seguridad, efectos sobre los sistemas y facilidad para el usuario; y se deberían llevar a cabo en sistemas separados.

o Se debería asegurar que se hayan actualizado todas las bibliotecas-fuente correspondientes del programa.

o Se debería utilizar un sistema de control de configuración para mantener el control de todo el software implementado, así como la documentación del sistema.

o Se debería establecer una estrategia de “regreso a la situación original” (rollback) antes de implementar los cambios.

o Se debería mantener un registro de auditoría de todas las actualizaciones a las bibliotecas del programa operacional.

o Se deberían mantener las versiones previas del software de aplicación como una medida de contingencia.

o Se deberían archivar las versiones antiguas del software, junto con toda la información requerida y los parámetros, procedimientos, detalles de configuración y software de soporte durante todo el tiempo que se mantengan la data en archivo.

Protección de la data del sistema

A.12.4.2 La data de prueba se debería seleccionar cuidadosamente, y se debería proteger y controlar.

• Cuando se utiliza la data operacional para propósitos de prueba se deberían aplicar los siguientes lineamientos para protegerla: o Procedimientos de control de acceso, los cuales se aplican a los sistemas de

aplicación operacional, y también se deberían aplicar a los sistemas de aplicación de prueba.

o Debería existir una autorización separada para cada vez que se copia información operacional en un sistema de aplicación de prueba.

o La información operacional debería ser borrada de los sistemas de aplicación de prueba inmediatamente después de haber completado la prueba.

o Se debería registrar el copiado y uso de la información operacional para proporcionar un rastro de auditoría.


76



Control de acceso al código fuente del programa

A.12.4.3 Se debería restringir el acceso al código fuente del programa.

• Se debe considerar que: o Cuando sea posible, no se deberían mantener las bibliotecas de fuentes del

programa en los sistemas operacionales. o El código fuente del programa y las bibliotecas de fuentes del programa

deberían ser manejadas de acuerdo con los procedimientos establecidos; o El personal de soporte no debería tener acceso irrestricto a las bibliotecas de

fuentes del programa. o La actualización de las bibliotecas de fuentes del programa y los ítems

asociados, y la emisión de las fuentes del programa para los programadores sólo se deberían realizar después de haber recibido la apropiada autorización.

o Los listados del programa se deberían mantener en un ambiente seguro. o Se debería mantener un registro de auditoría de todos los accesos a las

bibliotecas de fuentes del programa. o El mantenimiento y copiado de las bibliotecas fuentes del programa debería

estar sujeto a procedimientos estrictos de control de cambios. Procedimientos del

control del cambio A.12.5.1 Se debería controlar la

implementación de los cambios mediante el uso de procedimientos formales para el control del cambio.

• Se debe considerar: o Mantener un registro de los niveles de autorización acordados. o Asegurar que los cambios sean presentados por los usuarios autorizados. o Revisar los procedimientos de control e integridad para asegurar que no se

vean comprometidos por los cambios. o Identificar todo el software, información, entidades de base de datos y

hardware que requieran enmiendas. o Obtener la aprobación formal para propuestas detalladas antes de comenzar el

trabajo. o Asegurar que los usuarios autorizados acepten a los cambios antes de la

implementación. o Asegurar que el conjunto de documentación del sistema esté actualizado al

completar cada cambio y que la documentación antigua se archive o se elimine.

o Mantener un control de la versión para todas las actualizaciones del software. o Mantener un registro de auditoría para todas las solicitudes de cambio. o Asegurar que la documentación de operación y procedimientos de usuarios

sean cambiados conforme sean necesarios para seguir siendo apropiados. o Asegurar que la implementación de los cambios se realicen en el momento

adecuado y no disturbe los procesos institucionales involucrados.


77



Revisión técnica de la aplicación después de cambios en el sistema

A.12.5.2 Cuando se cambian los sistemas de operación, se deberían revisar y probar las aplicaciones de negocio críticas para asegurar que no exista un impacto adverso sobre las operaciones institucionales o en la seguridad.

• Se debe considerar: o Revisar los procedimientos de control e integridad de la aplicación para

asegurar que no se hayan visto comprometidos por los cambios en el sistema de operación.

o Asegurar que el plan y el presupuesto de soporte anual abarque las revisiones y pruebas del sistema resultantes de los cambios en el sistema de operación.

o Asegurar que la notificación de los cambios en el sistema de operación sea provista con tiempo para permitir realizar las pruebas y revisiones apropiadas antes de la implementación.

o Asegurar que se realicen los cambios apropiados en los planes de continuidad del negocio.

Restricciones sobre los cambios en los paquetes de software

A.12.5.3 No se deberían fomentar modificaciones a los paquetes de software, se deberían limitar a los cambios necesarios y todos los cambios deberían ser estrictamente controlados.

• Cuando se necesita modificar un paquete de software se deberían considerar los siguientes puntos: o El riesgo de comprometer los controles incorporados y los procesos de

integridad. o Si se debería obtener el consentimiento del vendedor. o La posibilidad de obtener del vendedor los cambios requeridos como

actualizaciones del programa estándar. o El impacto de si como resultado de los cambios, la organización se hace

responsable del mantenimiento futuro del software. Filtración de

información A.12.5.4 Se deberían evitar las

oportunidades para la filtración de información.

• Se deberían considerar los siguientes puntos para limitar la filtración de la información; por ejemplo, a través del uso y explotación de los canales encubiertos (covert channels): o Escanear el flujo de salida de los medios y las comunicaciones en busca de

información escondida. o Enmascarar y modular la conducta del sistema y las comunicaciones para

reducir la probabilidad de que una tercera persona pueda deducir la información a partir de dicha conducta.

o Hacer uso de los sistemas y el software considerados de la más alta integridad; por ejemplo, utilizando productos evaluados.

o Monitoreo regular de las actividades del personal y del sistema, cuando sea permitido bajo la legislación o regulación existente.

o Monitorear la utilización del recurso en los sistemas de cómputo. Desarrollo de

software abastecido externamente

A.12.5.5 El desarrollo del software abastecido externamente debería ser supervisado y monitoreado por

• Cuando el software es abastecido externamente, se deberían considerar los siguientes puntos: o Contratos de licencias, propiedad de códigos, derechos de propiedad


78



la organización. intelectual. o Certificación de la calidad y exactitud del trabajo llevado a cabo. o Contratos de depósito en custodia en el evento de la falla de una tercera

persona. o Derechos de acceso para a auditoría de la calidad y seguridad del trabajo

realizado. o Requerimientos contractuales para la funcionalidad de calidad y seguridad del

código; o Prueba antes de la instalación para detectar códigos maliciosos y Troyanos.

Control de las vulnerabilidades técnicas

A.12.6.1 Se debería obtener oportunamente la información sobre las vulnerabilidades técnicas de los sistemas de información que se están utilizando, la exposición de la organización a dichas vulnerabilidades evaluadas, y las medidas apropiadas tomadas para tratar los riesgos asociados.

• Se deben seguir los siguientes lineamientos: o La organización debería definir y establecer los roles y responsabilidades

asociadas con la gestión de la vulnerabilidad técnica; incluyendo el monitoreo de la vulnerabilidad, evaluación del riesgo de la vulnerabilidad, monitoreo de activos y cualquier responsabilidad de coordinación requerida.

o Se deberían identificar los recursos de información que se utilizarán para identificar las vulnerabilidades técnicas relevantes y mantener la conciencia sobre ellas para el software y otras tecnologías.

o Estos recursos de información deberían actualizarse en base a los cambios en el inventario, o cuando se encuentran recursos nuevo o útiles.

o Se debería definir una línea de tiempo para reaccionar a las notificaciones de vulnerabilidades técnicas potencialmente relevantes.

o Una vez que se identifica la vulnerabilidad técnica potencial, la organización debería identificar los riesgos asociados y las acciones a tomarse; dicha acción podría involucrar el parchado de los sistemas vulnerables y/o la aplicación de otros controles;

o Dependiendo de la urgencia con que se necesita tratar la vulnerabilidad técnica, la acción a tomarse debería realizarse de acuerdo a los controles relacionados con la gestión de cambios o siguiendo los procedimientos de respuesta ante incidentes de seguridad de la información.

o Si es posible el parche, se deberían evaluar los riesgos asociados con instalar el parche (los riesgos impuestos por la vulnerabilidad se deberían comparar con el riesgo de instalar el parche).

o Los parches de deberían probar y evaluar antes de instalarlos para asegurar que sean efectivos y no resulten efectos secundarios que no se puedan tolerar.


79



Ges

tión

de

un in

cide

nte

en la

seg

urid

ad d

e la

in

form

ació

n

Reporte de eventos en la seguridad de la información

A.13.1.1 Los eventos de seguridad de la información deberían ser reportados a través de los canales apropiados lo más rápidamente posible.

• Se debería establecer un procedimiento formal para el reporte de eventos en la seguridad de la información, junto con un procedimiento de respuesta y de notificación de incidentes, estableciendo la acción a tomarse al recibir un reporte de un evento en la seguridad de la información. Se debería establecer un punto de contacto para el reporte de eventos en la seguridad de la información Se debería asegurar que este punto de contacto sea conocido a través de toda la organización, que siempre esté disponible y sea capaz de proporcionar una respuesta adecuada y oportuna.

Reporte de las debilidades en la seguridad

A.13.1.2 Se debería requerir que todos los usuarios funcionarios, personal a honorarios y terceros de los sistemas y servicios de información tomen nota de y reporten cualquier debilidad de seguridad observada o sospechada en el sistema o los servicios.

• Todos los usuarios funcionarios, personal a honorarios y terceros deberían reportar estos temas ya sea a su jefe directo o directamente al proveedor de su servicio lo más rápidamente posible para evitar incidentes en la seguridad de la información. El mecanismo de reporte debería ser fácil, accesible y estar disponible lo más posible. Ellos deberían ser informados que no deberían, en ninguna circunstancia, tratar de probar una debilidad sospechada.

Responsabilidades y procedimientos

A.13.2.1 Se deberían establecer las responsabilidades y los procedimientos para asegurar una respuesta rápida, efectiva y metódica ante los incidentes de la seguridad de la información.

• Se deben considerar los siguientes lineamientos: o Se deberían establecer procedimientos para manejar los diferentes tipos de

incidentes en la seguridad de la información, incluyendo: o Fallas del sistema de información y pérdida del servicio. o Código malicioso. o Negación del servicio. o Errores resultantes de data incompleta o inexacta. o Violaciones de la confidencialidad e integridad. o Mal uso de los sistemas de información. o Además de los planes de contingencia normales, los procedimientos también

deberían cubrir: o Análisis e identificación de la causa del incidente. o Contención. o Planeación e implementación de la acción correctiva para evitar la recurrencia,

si fuese necesario. o Comunicaciones con aquellos afectados por o involucrados con la recuperación


80



de un incidente. o Reportar la acción a la autoridad apropiada. o Se debería recolectar y asegurar rastros de auditoría y evidencia similar,

conforme sea apropiado para: o Análisis interno del problema. o Uso como evidencia forense en relación a una violación potencial del contrato

o el requerimiento regulador o en el caso de una acción legal civil o criminal; por ejemplo, bajo la legislación sobre el mal uso de computadoras o protección de data.

o Negociación para la compensación de los proveedores del software y servicio. o Se deberían controlar formal y cuidadosamente las acciones para la

recuperación de las violaciones de la seguridad y para corregir las fallas en el sistema; los procedimientos deberían asegurar que:

o Sólo el personal claramente identificado y autorizado tengan acceso a los sistemas vivos y la data.

o Se documenten en detalle todas las acciones de emergencia realizadas. o La acción de emergencia sea reportada a la dirección y revisada de una manera

adecuada; o La integridad de los sistemas y controles comerciales sea confirmada con una

demora mínima. o Se deberían acordar con la dirección los objetivos para la gestión de incidentes

en la seguridad de la información, y se deberían asegurar que aquellos responsables de la gestión de incidentes en la seguridad de la información entiendan las prioridades de la organización para el manejo de los incidentes en la seguridad de la información.

Aprender de los incidentes en la seguridad de la información

A.13.2.2 Se deberían establecer mecanismos para permitir cuantificar y monitorear los tipos, volúmenes y costos de los incidentes en la seguridad de la información.

• Se debería utilizar la información obtenida de la evaluación de los incidentes en la seguridad de la información para identificar los incidentes recurrentes o de alto impacto.

Recolección de evidencia

A.13.2.3 Cuando una acción de seguimiento contra una persona u organización después de un incidente en la seguridad de la información involucra una acción legal (ya sea civil o criminal); se debería recolectar, mantener y presentar

• Se deberían desarrollar y seguir los procedimientos internos cuando se recolecta y presenta evidencia para propósitos de una acción disciplinaria manejada dentro de una organización.


81



evidencia para cumplir con las reglas de evidencia establecidas en la(s) jurisdicción(es) relevante(s).

Ges

tión

de

la c

onti

nuid

ad d

el n

egoc

io

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

A.14.1.1 Se debería desarrollar y mantener un proceso institucional para la continuidad del negocio en toda la organización el cual trate los requerimientos de seguridad de la información necesarios para la continuidad de la institución.

• El proceso debe reunir los siguientes elementos claves de la gestión de continuidad del negocio: o Entender los riesgos que enfrenta la organización en términos de la

probabilidad y el impacto en el tiempo, incluyendo la identificación y priorización de los procesos críticos.

o Identificar todos los activos involucrados en los procesos críticos. o Entender el impacto que probablemente tendrán las interrupciones causadas

por incidentes en la seguridad de la información (es importante encontrar las soluciones para manejar los incidentes que producen impactos menores, así como los incidentes graves que pueden amenazar la viabilidad de la organización), y establecer los objetivos institucionales de los medios de procesamiento de la información.

o Considerar la adquisición de una póliza de seguro adecuada que pueda formar parte de todo el proceso de continuidad del negocio, y de la gestión del riesgos operacionales.

o Identificar y considerar la implementación de controles preventivos y mitigantes adicionales.

o Identificar los recursos financieros, organizacionales, técnicos y ambientales suficientes para tratar los requerimientos de seguridad de la información identificados.

o Garantizar la seguridad del personal y la protección de los medios de procesamiento de la información y la propiedad organizacional.

o Formular y documentar los planes de continuidad del negocio que aborden los requerimientos de seguridad de la información en línea con la estrategia acordada para la continuidad del negocio.

o Pruebas y actualizaciones regulares de los planes y procesos establecidos. o Asegurar que la gestión de la continuidad del negocio esté incorporada en los

procesos y estructura de la organización; se debe asignar la responsabilidad del proceso de gestión de la continuidad del negocio en el nivel apropiado dentro de la organización.


82



Continuidad del negocio y evaluación del riesgo

A.14.1.2 Se deberían identificar los eventos que pueden causar interrupciones a los procesos Institucionales, junto con la probabilidad y el impacto de dichas interrupciones y sus consecuencias para la seguridad de la información.

• Los aspectos de la seguridad de la información en la continuidad del negocio se deben basar en la identificación de los eventos (o secuencia de eventos) que pueden causar las interrupciones en los procesos críticos de la organización; por ejemplo, fallas en el equipo, errores humanos, robo, fuego, desastres naturales y actos de terrorismo. Esto debe ir seguido por una evaluación del riesgo para determinar la probabilidad e impacto de dichas interrupciones, en términos de tiempo, escala del daño y período de recuperación.

Desarrollar e implementar los planes de continuidad que incluyan la seguridad de la información

A.14.1.3 Se deberían desarrollar e implementar planes para mantener o restaurar las operaciones y asegurar la disponibilidad de la información en el nivel y en las escalas de tiempo requeridos después de la interrupción o falla de los procesos institucionales críticos.

• El proceso de planeación de la continuidad del negocio debe considerar lo siguiente: o Identificar y acordar todas las responsabilidades y los procedimientos para la

continuidad del negocio. o Identificar la pérdida aceptable de la información y los servicios. o Implementación de los procedimientos que permitan la recuperación y

restauración de las operaciones institucionales y la disponibilidad de la información en las escalas de tiempo requeridas; se debe prestar particular atención a la evaluación de las dependencias internas y externas y de los contratos establecidos.

o Los procedimientos operacionales que se han de seguir en espera de la culminación de la recuperación y restauración.

o Documentación de los procesos y procedimientos acordados. o Educación apropiada del personal en los procedimientos y procesos acordados,

incluyendo el manejo de crisis. o Pruebas y actualización de los planes.


83



Marco Referencial de la planeación de la continuidad del negocio

A.14.1.4 Se debería mantener un solo marco referencial de los planes de continuidad del negocio para asegurar que todos los planes sean consistentes, tratar consistentemente los requerimientos de seguridad de la información e identificar las prioridades para las pruebas y el mantenimiento.

• La estructura para la planificación de la continuidad del negocio debe abordar los requisitos de seguridad de la información identificados y considerar los siguientes aspectos: o Las condiciones para la activación de los planes que describen el proceso a

seguir (por ejemplo, la forma de evaluar la situación y quién se va a involucrar) antes de activar cada plan.

o Los procedimientos de emergencia que describen las acciones por realizar tras un incidente que ponga en peligro las operaciones del Servicio.

o Los procedimientos de respaldo que describen las acciones por realizar para desplazar las actividades esenciales de la institución o los servicios de soporte a lugares temporales alternos y para devolver la operatividad de los procesos de la organización en los plazos requeridos.

o Los procedimientos operacionales temporales a seguir mientras se terminan la recuperación y la restauración.

o Los procedimientos de reanudación que describen las acciones a realizar para que las operaciones del Servicio vuelvan a la normalidad.

o Una programación de mantenimiento que especifique cómo y cuándo se realizarán pruebas al plan y el proceso para el mantenimiento del plan.

o Actividades de concientización, educación y formación diseñadas para comprender los procesos de continuidad del negocio y garantizar que los procesos siguen siendo eficaces.

o Las responsabilidades de las personas, que describan quién es responsable de la ejecución de cada componente del plan. Si se requiere, se deben nombrar suplentes.

o Los activos y recursos críticos necesarios para ejecutar los procedimientos de emergencia, respaldo y reanudación.

Prueba, mantenimiento y re-evaluación de los planes de continuidad del negocio

A.14.1.5 Los planes de continuidad del negocio deberían ser probados y actualizados regularmente para asegurar su actualización y su eficacia.

• Las pruebas del plan de continuidad del negocio deben asegurar que todos los miembros del equipo de recuperación y otro personal relevante estén al tanto de los planes y su responsabilidad con la continuidad del negocio y la seguridad de la información, y que conozcan su papel cuando se ejecute el plan. Es conveniente utilizar una variedad de técnicas para garantizar que los planes funcionarán en condiciones reales. Éstas deben incluir: o La prueba sobre varios escenarios de desastre (analizando las disposiciones de

recuperación con ayuda de ejemplos de interrupciones). o Las simulaciones (particularmente para la formación del personal en sus

funciones de gestión de crisis/post-incidentes).


84



o Las pruebas de recuperación técnica (garantizando que los sistemas de información se pueden restaurar eficazmente).

o Las pruebas de recuperación en un lugar alterno (ejecutando procesos institucionales en paralelo con las operaciones de recuperación fuera de la sede principal.

o Las pruebas de los recursos y servicios del proveedor (asegurando que los servicios y productos proporcionados externamente cumplirán el compromiso contraído).

o Los ensayos completos (probando que la organización, el personal, el equipo, las instalaciones y los procesos pueden hacer frente a las interrupciones).

Cum

plim

ient

o

Identificación de la legislación aplicable

A.15.1.1 Se debe definir explícitamente, documentar y actualizar todos los requerimientos estatutarios, reguladores y contractuales relevantes, y el enfoque de la institución para satisfacer esos requerimientos, para cada sistema de información y su organización.

• Se deben definir y documentar los controles y responsabilidades individuales específicas para satisfacer estos requerimientos. En las instituciones del Estado, habitualmente estas responsabilidades están instaladas en las divisiones/departamentos/unidades o encargados jurídicos. Por tal razón es importante que estén representados en el Comité de Seguridad de la Información y que participen en la validación de las medidas que éste adopte.

Derechos de propiedad intelectual (IPR)

A.15.1.2 Se deben implementar los procedimientos apropiados para asegurar el cumplimiento de los requerimientos legislativos, reguladores y contractuales sobre el uso del material con respecto a los cuales puedan existir derechos de propiedad intelectual y sobre el uso de productos de software patentado.

• Se debe considerar lo siguiente: o Una política de cumplimiento de los derechos de propiedad intelectual y

publicación que defina el uso legal de los productos de software e información. o Sólo adquirir software a través de fuentes conocidos y acreditados para

asegurar que no sean violados los derechos de autor. o Mantener el conocimiento de las políticas para proteger los derechos de

propiedad intelectual y las medidas disciplinarias aplicables a su transgresión. o Mantener un registro de los activos e identificar todos aquellos protegidos por

el derecho de propiedad intelectual. o Mantener prueba y evidencia de la propiedad de las licencias, discos originales,

manuales, etc. o Implementar controles para asegurar que no se exceda el número máximo de

usuarios permitidos. o Chequear que sólo se instalen softwares autorizados y productos con licencia. o Proporcionar una política para mantener las condiciones de licencias en forma

adecuada. o Proporcionar una política para eliminar o transferir software a terceras partes. o Utilizar las herramientas de auditoría apropiadas.


85



o Cumplir con los términos y condiciones del software e información obtenidos de redes públicas.

o No duplicar, convertir a otro formato o extraer de registros comerciales (audio, vídeo), aparte de los permitidos por el derecho de autor.

o No copiar; completamente o en parte; libros, artículos, reportes u otros documentos; aparte de aquellos permitidos por el derecho de autor.

Protección de registros institucionales

A.15.1.3 Se deben proteger los registros importantes de pérdida, destrucción, falsificación en concordancia con los requerimientos estatutarios, reguladores, contractuales y de negocio.

• Los registros deben ser clasificados según su tipo, entregando directrices sobre su retención, almacenamiento, tratamiento y eliminación, contemplando un calendario de retenciones para cada tipo, un inventario de información clave y los controles para la protección de los registros y la información contra pérdida, destrucción o falsificación.

Protección de la data y privacidad de la información personal

A.15.1.4 Se debe asegurar la protección y privacidad de los datos conforme lo requiere la legislación, regulaciones y, si fuesen aplicables, las cláusulas contractuales relevantes.

• Se debe desarrollar e implementar una política de protección y privacidad de los datos. Esta política debe ser comunicada a todas las personas involucradas en el procesamiento de información personal. Se debe considerar la ley 19628 y 20285 y otras que se considere relevantes en la materia.

Prevención del mal uso de los medios de procesamiento de la información

A.15.1.5 Se debe disuadir a los usuarios de utilizar los medios de procesamiento de la información para propósitos no autorizados.

• La dirección debe aprobar la utilización de los medios de procesamiento de la información. Cualquier uso de estos medios para propósitos no-institucionales u otro no autorizado, será visto como un uso inapropiado de los recursos, lo que debe ser informado a la jefatura a cargo para que considere la acción disciplinaria correspondiente en el marco legal. Los funcionarios deben conocer el alcance de su acceso permitido y de los lugares que son supervisados para detectar usos no autorizados. Para esto se sugieren prácticas como la entrega de una autorización escrita que debe firmar el funcionario, o que al conectarse éste al puesto de trabajo, un mensaje de advertencia le señale que se trata de un acceso restringido, por tanto se da por enterado y debe tomar los resguardos que corresponda, de acuerdo a las políticas definidas (control de acceso, pantalla limpia, etc.)

Regulación de controles criptográficos

A.15.1.6 Los controles criptográficos se deben utilizar en cumplimiento con todos los acuerdos, leyes y regulaciones relevantes.

• Se deben tomar las siguientes consideraciones: o Las restricciones sobre la importación –y si corresponde, exportación- de

hardware y software para realizar funciones criptográficas. o Las restricciones sobre la importación –y si corresponde, exportación- de

hardware y software diseñado para agregarle funciones criptográficas. o Restricciones sobre la utilización de la codificación.


86



o Métodos obligatorios o discrecionales para que las autoridades de los países tengan acceso a información codificada para garantizar su confidencialidad.

Cumplimiento con las políticas y estándares de seguridad

A.15.2.1 Las jefaturas deben asegurar que se lleven a cabo correctamente todos los procedimientos de seguridad dentro de centro de responsabilidad para asegurar el cumplimiento de las políticas y estándares de seguridad.

• Cuando una jefatura detecta algún incumplimiento debe determinar sus causas, evaluar la necesidad de acciones correctivas, implementarlas, revisar dicha acción mediante su registro e informarlo a las entidades auditoras independientes.

Chequeo del cumplimiento técnico

A.15.2.2 Los sistemas de información deben chequearse regularmente para ver el cumplimiento de los estándares de implementación de la seguridad.

• El chequeo del cumplimiento técnico debe ser realizado manualmente (respaldado por las herramientas de software apropiadas, si fuese necesario) por un ingeniero de sistemas experimentado y/o con la asistencia de herramientas automatizadas que generen un reporte técnico a ser interpretado por parte de un especialista.

• Las pruebas de intrusión o evaluaciones de vulnerabilidad (ethical hacking) deben ser planificadas, documentadas y repetibles, para cuidar la seguridad del sistema.

• Cualquier verificación de cumplimiento técnico debe ser realizada por personal competente y autorizado o bajo su supervisión.

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

A.15.3.1 Las actividades y requerimientos de auditoría que involucran chequeos de los sistemas operacionales deben ser planeados y acordados cuidadosamente para minimizar el riesgo de interrupciones en los procesos.

• Se deben observar los siguientes lineamientos: o Acordar los requerimientos de auditoría con la autoridad. o Acordar y controlar el alcance de los chequeos. o Los chequeos deben limitarse a un acceso de “sólo lectura” al software y los

datos. o Sólo se debe permitir un acceso diferente al de “sólo lectura” para copias

aisladas de los archivos del sistema, los cuales se puedan borrar cuando termine la auditoría, o se les pueda proteger apropiadamente si existe la obligación de mantener dichos archivos como parte de los requisitos de la documentación de auditoría.

o Identificar explícitamente y disponer los recursos para realizar los chequeos. o Identificar y acordar los requerimientos para procesos especiales o adicionales. o Monitorear y registrar todos los accesos para producir un histórico de

referencia; considerar rastros de referencia con impresión horaria para los datos o sistemas críticos.

o Documentar todos los procedimientos, requerimientos y responsabilidades. o La(s) personas(s) que llevan a cabo la auditoría deben ser independientes a las

actividades auditadas.


87



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

A.15.3.2 Se debe proteger el acceso a las herramientas de auditoría de los sistemas de información para evitar cualquier mal uso o trasgresión posible.

• Las herramientas de auditoría de los sistemas de información, por ejemplo, software o archivos de datos, deben estar separadas de los sistemas en producción y de desarrollo y no mantenerse en las bibliotecas de cintas o áreas de usuario, a no ser que se les proporcione un nivel apropiado de protección adicional.

Fuente: Adaptado de NCH-ISO 27002.Of2009

ANEXO IV: Plan de Auditorías El objetivo de este capítulo es entregar recomendaciones a las instituciones en el ámbito de la auditoría. En el marco de la etapa 4 del PMG/MEI SSI se solicitan revisiones al Sistema, estas no necesariamente deben ser auditorías, no obstante, para la mantención del SSI es recomendable planificarlas en lo sucesivo. Un plan de auditorías en términos básicos, describe lo siguiente: • La planificación del programa de auditorías. • La implementación del programa. • La selección de los equipos de auditoría y actividades de auditoría. • El seguimiento y revisión. • La mejora del programa.

El siguiente gráfico muestra las etapas para llevar a cabo el proceso de Gestión de Auditoría. Figura N° 6: Etapas en el proceso de gestión de auditoría

Fuente: Elaboración propia en base a la NCh-ISO 19011 - 2003

Una forma de enfrentar una auditoría corresponde al desarrollo de las siguientes actividades:

• Definición (inicio) de la auditoría. • Revisión de la documentación. • Preparación de actividades de auditoría in situ. • Realización de las actividades. • Preparación, aprobación y distribución de los resultados de la auditoría. • Finalización de la auditoría. • Realización del as actividades de seguimiento de la auditoría.


89

El siguiente gráfico muestra el ciclo de actividades en una auditoría. Figura N° 7: Ciclo de actividades de auditoría

Fuente: Elaboración propia en base a la NCh-ISO 19011 - 2003


90

ANEXO V: Activos de Información y la Normativa NCh-ISO 27001 Los Activos de Información corresponden a todos aquellos elementos relevantes en la producción, emisión, almacenamiento, comunicación, visualización y recuperación de información de valor para la institución. De esta forma podemos distinguir 3 niveles básicos de activos de información: • La Información propiamente tal, en sus múltiples formatos (papel, digital, texto, imagen,

audio, video, etc.) • Los Equipos/Sistemas/infraestructura que soportan esta información • Las Personas que utilizan la información, y que tienen el conocimiento de los procesos

institucionales. Dado que los activos de información poseen valor para la organización, necesitan por tanto, ser protegidos adecuadamente para que la misión institucional (o “negocio” en términos normativos) no se vea perjudicada. Esto implica identificar para cada activo sus riesgos asociados, detectar vulnerabilidades y establecer los controles de seguridad que sean necesarios para mitigarlos, tanto a nivel de gobierno institucional y de gestión de procesos, como a nivel de tecnologías de la información utilizadas. El Sistema de Seguridad de la Información (SSI) establece distintos controles tanto a nivel de gobierno y gestión, como de tecnologías de la información, con el objeto de garantizar que los activos de información cumplan con preservar las siguientes condiciones: • La Integridad: La información está completa, actualizada y es veraz, sin modificaciones

inapropiadas o corrupción. • La Confidencialidad: La información está protegida de personas/usuarios no autorizados. • La Disponibilidad: Los usuarios autorizados pueden acceder a las aplicaciones y sistemas

cuando lo requieran para utilizar la información apropiadamente al desempeñar sus funciones. Las nuevas tecnologías, el desarrollo del conocimiento, la liberación de las comunicaciones y la posibilidad de acceso libre a diversos aplicativos, requieren de un sistema que permita gestionar la seguridad de la información, lo cual consiste en la realización de las tareas necesarias para garantizar los niveles exigibles en la organización, dentro del ámbito de protección de las condiciones de integridad, confidencialidad y disponibilidad de la información, como principio clave. Según el Decreto Supremo N° 83 / 2004 del Ministerio Secretaría General de la Presidencia (desde ahora en adelante DS-83), la Norma Chilena Oficial NCh-ISO 27001.Of2009, como también lo establecido en la Ley N° 20.285, y otras normativas presentes en el SSI del PMG/MEI, las exigencias y recomendaciones que se proveen, presentan desafíos en cuanto a la necesidad de garantizar estándares mínimos de seguridad en el uso, almacenamiento, acceso y distribución de información, por lo que es necesario que cada uno de los órganos del Estado cumpla con estas normativas a través de la implantación de un Sistema de Seguridad de la Información.


91

El DS-83, provee de un marco regulatorio para incorporar mayores niveles de seguridad a la información de los servicios públicos, sin embargo, su principal objetivo apunta al documento electrónico para facilitar la interoperabilidad en el Estado. Dado que el documento electrónico constituye sólo una parte de la información relevante a proteger, es que el Sistema de Seguridad de la Información debe abarcar progresivamente a todos los Activos de Información asociados a los procesos de provisión de las instituciones públicas, valiéndose de los dominios que establece la NCh-ISO 27001. Tabla N°5: Descripción de objetivos generales por cada dominio de seguridad Dominio: Política de seguridad Este dominio consiste en proporcionar a la institución la dirección y soporte para la seguridad de la información en concordancia con los requerimientos institucionales y las leyes y regulaciones pertinentes. La alta dirección debe establecer claramente el enfoque de la política en línea con los objetivos institucionales y demostrar su apoyo y su compromiso con la seguridad de la información, a través de la emisión y mantenimiento de un documento de Política General de Seguridad de la Información en toda la organización. Dominio: Organización de la seguridad de la información La finalidad de este dominio es establecer un marco referencial a nivel directivo para iniciar y controlar la implementación de la seguridad de la información dentro de la institución. La dirección debe aprobar la política de seguridad de la información, asignar los roles de seguridad a los comités y designar al encargado de seguridad mediante una resolución, el cual debe coordinar y revisar la implementación de la seguridad en toda la institución. Si fuese necesario, se debe establecer una fuente de consultoría sobre seguridad de la información que esté disponible dentro de la institución. Se deben desarrollar contactos con los especialistas o grupos de seguridad externos, incluyendo las autoridades relevantes, para mantenerse actualizado con relación a las tendencias mundiales, monitorear los estándares, evaluar los métodos y proporcionar vínculos adecuados para el manejo de los incidentes de seguridad de la información. Se debe fomentar un enfoque multidisciplinario para la seguridad de la información.


92

Dominio: Gestión de activos El objetivo de este dominio es implementar y mantener una apropiada protección de los activos institucionales. Todos los activos deben ser inventariados y contar con un propietario nombrado. Los propietarios deben identificar todos los activos y deben asignar la responsabilidad por el mantenimiento de los controles apropiados. La implementación de controles específicos puede ser delegada por el propietario conforme sea apropiado, pero el propietario sigue siendo responsable por la protección de los activos. Adicionalmente se debe asegurar que la información reciba un nivel de protección adecuado. La información debe ser clasificada para indicar la necesidad, prioridades y grado de protección esperado en su manejo. La información puede ser pública o secreta –también se denomina “reservada”- (Ley 20.285), y contar con diferentes grados de importancia dentro de la institución. Algunos activos pueden requerir un nivel de protección adicional o manejo especial dependiendo de su criticidad y riesgo. Se debe utilizar un esquema de clasificación de información para definir un conjunto apropiado de niveles de protección y comunicar la necesidad de medidas de uso especiales. Dominio: Seguridad de los recursos humanos Lo que busca este dominio es que antes de la contratación, se debe asegurar que los funcionarios, personal a honorarios y terceros entiendan sus responsabilidades, y sean idóneos para los roles para los cuales son considerados; y reducir el riesgo de robo, fraude y mal uso de los medios. Las responsabilidades de seguridad deben ser definidas y claramente comunicadas a los candidatos antes de la contratación en descripciones de trabajo adecuadas y en los términos y condiciones del empleo. A su vez, se debe realizar la verificación de los antecedentes de dichos candidatos, de acuerdo con las leyes, regulaciones y normas éticas pertinentes y en proporción a los requisitos del cargo y de la información a la cual tendrá acceso, y los riesgos que se emanen de la clasificación de dicha información. Los funcionarios, personal a honorarios y terceros usuarios de los medios de procesamiento de la información deben firmar un acuerdo sobre sus roles y responsabilidades con relación a la seguridad. Durante las labores se debe asegurar que los funcionarios usuarios, contratistas y terceras personas estén al tanto de las amenazas y de la pertinencia de la seguridad de la información, de sus responsabilidades y obligaciones, y estén equipados para apoyar la política de seguridad organizacional en el curso de su trabajo normal, para reducir el riesgo de error humano e incidentes de seguridad. Se debe proporcionar a todos los usuarios, funcionarios, personal a honorarios y terceras personas un nivel adecuado de conocimiento, educación y capacitación en procedimientos de seguridad y uso correcto de los medios de procesamiento, activos y servicios de información para minimizar los posibles riesgos de seguridad. Se debe establecer un proceso disciplinario normal para manejar las fallas en la seguridad.


93

Además se debe asegurar que los funcionarios, contratistas o terceros que sean desvinculados o cambien su relación laboral, lo hagan de una forma adecuada, implementando medidas para que todo equipamiento sea devuelto y se eliminen todos los derechos de acceso de dicho funcionario desvinculado. Dominio: Seguridad física y del ambiente Este dominio consiste en prevenir el acceso no autorizado, daño e interferencia a las instalaciones de la institución y a la información. Los equipos de procesamiento de información crítica o sensible de la institución se deben mantener en áreas seguras, protegidos por un perímetro de seguridad definido, con barreras apropiadas de seguridad y controles de entrada. Éstos deben estar físicamente protegidos del acceso no autorizado, daño e interferencia. Es necesaria la protección de los equipos, incluyendo los portátiles usados fuera de las dependencias, para reducir el riesgo de acceso no autorizado a datos y para prevenir la pérdida o daño. Se pueden necesitar controles especiales para protegerlos de riesgos o accesos no autorizados, y salvaguardar las instalaciones de apoyo, tales como el suministro eléctrico y la infraestructura de cables. Dominio: Gestión de las comunicaciones y operaciones El objetivo de este dominio es crear procedimientos y responsabilidades operacionales de manera de asegurar la operación correcta y segura de los medios de procesamiento de la información. Cuando sea pertinente, se debe implementar la segregación de deberes para reducir el riesgo de negligencia o mal uso deliberado de los sistemas. Los sistemas operativos, los sistemas de aplicación y los medios de procesamiento de la información son vulnerables a la introducción de códigos de software malicioso, como virus de cómputo, virus de red, códigos troyanos y “bombas lógicas”. Los usuarios deben estar al tanto de los peligros de los códigos maliciosos. Se deben introducir controles para evitar, detectar y eliminar los códigos maliciosos y controlar los códigos móviles a través de antivirus, de manera de proteger la integridad del software y la integración. Se deben establecer los procedimientos de rutina para implementar la política de respaldo acordada y la estrategia para tomar copias de respaldo de la data y practicar su restauración oportuna. Se debe asegurar la protección de la información que viaja por correo electrónico y su infraestructura de soporte. La gestión segura del correo electrónico, requiere de la cuidadosa consideración de la información que es transmitida, su confidencialidad, implicancias legales, monitoreo y protección. También se pueden requerir controles adicionales para proteger la información confidencial que pasa a través de redes públicas.


94

Dominio: Control de Acceso La finalidad de este dominio es asegurar que el acceso del usuario es debidamente autorizado y evitar el acceso no autorizado a los sistemas de información. Se deben establecer procedimientos formales para controlar la asignación de los derechos de acceso a los sistemas y servicios de información. Los procedimientos deben abarcar todas las etapas en el ciclo de vida del acceso del usuario, desde el registro inicial de usuarios nuevos hasta la dada de baja de los usuarios que ya no requieren acceso a los sistemas y servicios de información. Cuando sea apropiado, se debe prestar atención especial a la necesidad de controlar la asignación de derechos de acceso privilegiados, lo que permite a los usuarios superar los controles del sistema. La cooperación de los usuarios autorizados es esencial para una seguridad efectiva. Los usuarios deben estar al tanto de sus responsabilidades para mantener controles de acceso efectivos, particularmente con relación al uso de claves secretas, su no divulgación y la seguridad del equipo asignado a él. Se debe implementar una política de escritorio y pantalla limpios para reducir el riesgo de acceso no autorizado o daño a los papeles y medios de almacenamiento de la información. Deben implementarse controles efectivos de manera de evitar el acceso no autorizado a los servicios de la red. Se debe controlar el acceso a los servicios de redes internas y externas. El acceso del usuario a las redes no debe comprometer la seguridad de los servicios de la red. Se deben utilizar medios de seguridad para restringir el acceso a los sistemas operativos a los usuarios no autorizados. De igual forma debe ocurrir con la información contenida en los sistemas de aplicación y al utilizar dispositivos móviles para trabajar de forma remota. Dominio: Adquisición, desarrollo y mantenimiento de los sistemas de información Aquellas instituciones que desarrollen software internamente o, en su defecto, encarguen su elaboración a un proveedor calificado, se debe garantizar que la seguridad sea una parte integral de los sistemas de información y se incluya en la etapa de formulación del software. Los sistemas de información incluyen sistemas de operación, infraestructura, aplicaciones de negocio, servicios y aplicaciones desarrolladas por el usuario. El diseño e implementación del sistema de información que soporta el proceso de negocio puede ser crucial para la seguridad. Se deben identificar y acordar todos los requerimientos de seguridad antes del desarrollo y/o implementación de los sistemas de información en la fase de requerimientos de un proyecto; y deben ser justificados, acordados y documentados como parte de las formalidades para un sistema de información.


95

Dominio: Gestión de incidentes en la seguridad de la información El objetivo de este dominio es asegurar que las debilidades y eventos de seguridad de la información asociados a sistemas de información son comunicados de manera de permitir tomar acciones correctivas a tiempo. Se debe establecer un procedimiento formal para informar los eventos de seguridad de la información, junto con la respuesta al incidente y un procedimiento de escalamiento, precisando la acción que se tomará al momento de recibir un informe de un evento de seguridad de la información. Estos procedimientos deben ser de conocimiento de todos los funcionarios de la organización. A su vez, se debe asegurar la aplicación de un enfoque constante y eficaz de gestión de incidentes de seguridad, estableciendo las responsabilidades y procedimientos para manejar los eventos y debilidades de seguridad de la información con eficacia, una vez que han sido informados. Se debe aplicar un proceso de mejora continua en la gestión general de incidentes de seguridad de la información. La evidencia requerida, cuando corresponda, debe ser recogida asegurando la conformidad con los requisitos legales. Dominio: Gestión de la Continuidad del Negocio El objetivo de este dominio es considerar los aspectos de la seguridad de la información de la gestión de la continuidad operativa de manera de hacer frente a las interrupciones de las actividades institucionales y proteger los procesos críticos de los efectos de fallas importantes o desastres en los sistemas de información y asegurar su reanudación oportuna. Se debe implementar el proceso de gestión de la continuidad del negocio para minimizar el impacto sobre la institución y lograr recuperarse de la pérdidas de activos de información (lo cual puede ser resultado de, por ejemplo, desastres naturales, accidentes, fallas del equipo y acciones deliberadas) hasta un nivel aceptable a través de una combinación de controles preventivos y de recuperación. Este proceso debe identificar los procesos institucionales críticos e integrar los requerimientos de gestión de la seguridad de la información de la continuidad del negocio con otros requerimientos de continuidad relacionados con aspectos como operaciones, personal, materiales, transporte y medios. Las consecuencias de los desastres, fallas en la seguridad, pérdida del servicio y la disponibilidad del servicio deben estar sujetos a un análisis del impacto en el negocio. Se deben desarrollar e implementar planes para la continuidad del negocio para asegurar la reanudación oportuna de las operaciones esenciales. La seguridad de la información debe ser una parte integral del proceso general de continuidad del negocio, y otros procesos importantes dentro de la organización. La gestión de la continuidad del negocio debe incluir controles para identificar y reducir los riesgos, además del proceso general de evaluación de riesgos, debe limitar las consecuencias de incidentes dañinos y asegurar que esté disponible la información requerida para los procesos institucionales.


96

Dominio: Cumplimiento El objetivo de este domino consiste en evitar los incumplimientos de cualquier ley, estatuto, regulación u obligación contractual legal y de cualquier requisito de seguridad a los cuales puede estar sujeto el diseño, operación, uso y gestión de los sistemas de información. Se debe contar con asesoría sobre los requisitos legales específicos en el departamento jurídico de la institución, o a través de profesionales del derecho calificados. De la misma, forma se debe asegurar que los sistemas cumplen con las normas y políticas de seguridad de la organización, a través de revisiones regulares y auditorías que comprueben el cumplimiento de normas aplicables a la implementación de la seguridad y controles documentados. Se deben establecer controles para salvaguardar los sistemas en producción y la integridad de las herramientas de auditoría durante las auditorías del sistema de información, y evitando el mal uso de ellas. Fuente: Elaboración propia a partir del estudio de las normativas ISO 27000.


97

ANEXO VI: Normativa vigente El siguiente corresponde al listado de la normativa vigente relacionada con el SSI:

• Ley N°19.553, febrero 1998. Concede asignación de modernización y otros beneficios que

indica. Ministerio de Hacienda. • Decreto N°475. Reglamento Ley 19.553 para la aplicación del incremento por Desempeño

institucional del artículo 6° de la Ley y sus modificaciones. • Ley N°20.212, agosto de 2007. Modifica las leyes N° 19.553, N° 19.882, y otros cuerpos

legales, con el objeto de incentivar el desempeño de los funcionarios públicos. Ministerio de Hacienda.

• Ley N°19.799, abril de 2002. Sobre documentos electrónicos, firma electrónica y los servicios de certificación de dicha firma. Ministerio de Economía.

• DS N°181. Reglamento Ley 19.799 sobre documentos electrónicos, firma electrónica y la certificación de dicha firma.

• Instructivo Presidencial Nº 05, mayo de 2001: Define el concepto de Gobierno Electrónico. Contiene la mayor parte de las instrucciones referidas al desarrollo de Gobierno Electrónico en Chile.

• Instructivo Presidencial Nº 06, junio de 2004: Imparte instrucciones sobre la implementación de la firma electrónica en los actos, contratos y cualquier tipo de documento en la administración del Estado, para dotar así de un mayor grado de seguridad a las actuaciones gubernamentales que tienen lugar por medio de documentos electrónicos y dar un mayor grado de certeza respecto de las personas que suscriben tales documentos.

• DS N°77. Norma técnica sobre eficiencia de las comunicaciones electrónicas entre órganos de la Administración del Estado y entre éstos y los ciudadanos.

• DS N°81. Norma técnica para los órganos de la Administración del Estado sobre interoperabilidad de documentos electrónicos.

• DS N°158. Modifica D.S. N° 81 sobre norma técnica para la interoperabilidad de los documentos electrónicos.

• DS N°83. Norma técnica para los órganos de la Administración del Estado sobre seguridad y confidencialidad de los documentos electrónicos.

• DS N°93. Norma técnica para minimizar la recepción de mensajes electrónicos masivos no deseados en las casillas electrónicas de los órganos de la Administración del Estado y de sus funcionarios.

• DS N°100. Norma técnica para el desarrollo de sitios web de los órganos de la Administración del Estado.

• Ley Nº 20.285, agosto de 2008. Regula el principio de transparencia de la función pública y el derecho de acceso a la información de los órganos de la administración del Estado. Ministerio Secretaría General de la Presidencia.

• Instrucción General N°2, mayo de 2009, del Consejo para la Transparencia: Designación de Enlaces con el Consejo para la Transparencia.

• Instrucción General N°3, mayo de 2009, del Consejo para la Transparencia: Índice de Actos o Documentos calificados como secretos o reservados.

• Instructivo Presidencial N°08, diciembre de 2006: Imparte instrucciones sobre Transparencia Activa y Publicidad de la Información de la Administración del Estado.


98

• Circular Nº3, enero de 2007: Detalla las medidas específicas que deben adoptar los servicios y dispone los materiales necesarios para facilitar la implementación del instructivo presidencial sobre transparencia activa y publicidad de la información de la Administración del Estado.

• Ley Nº 19.880, mayo de 2003: Establece bases de los procedimientos administrativos que rigen los actos de los órganos de la administración del Estado. Ministerio Secretaría General de la Presidencia.

• Instructivo Presidencial N°4, junio de 2003: Imparte instrucciones sobre aplicación de la Ley de Bases de Procedimientos Administrativos.

• Ley N° 19.628, agosto de 1999. Sobre protección de la vida privada y datos personales. Ministerio Secretaría General de la Presidencia.

• Ley Nº 17.336, octubre de 1970: Sobre propiedad intelectual. Ministerio de Educación Pública.

• Ley Nº 19.223, junio de 1993: Sobre delitos informáticos. Ministerio de Justicia. • Ley Nº 19.927, enero de 2004: Sobre delitos de pornografía infantil. Ministerio de Justicia. • Guía Metodológica del Sistema Gobierno Electrónico. • Guía Metodológica del Sistema Seguridad de la Información.

Para comprender en detalle el alcance de la legislación, revisar documentación en sitio Web: http://www.dipres.gob.cl, sección Sistema Seguridad de la Información.


Documents

GUÍA METODOLÓGICA 2012