Desarrollo de algunos objetivos de control del SGSI

  • Silvia Garre Gui

    Silvia Garre Gui

    Ingeniera Superior en Telecomunicaciones por la Universitat Politècnica de Catalunya. Directora área TIC Departamento de la Vicepresidencia, y de Economía y Hacienda (CTTI – Generalitat de Catalunya). Certificada en CRISC (Risk and Information Systems Control) y CISM (Information Security Manager) por ISACA.

  • Antonio José Segovia Henares

    Antonio José Segovia Henares

    Ingeniero en Informática, e Ingeniero Técnico en Informática de sistemas por la UOC. Experto en Seguridad de la Información, hacker ético y profesional experto cualificado en el RGPD. Desde el 2010, cualificado como Auditor Líder en ISO 27001, y cualificado también en otros esquemas como ISO 27018, ISO 22301, e ISO 20000, por varias entidades certificadoras. Blogger y ponente de webinars sobre la Seguridad de la Información a nivel mundial.

  • Arsenio Tortajada Gallego

    Arsenio Tortajada Gallego

    Ingeniero Superior en Informática por la Universitat Autònoma de Barcelona. Consultor/Auditor de Seguridad de la Información en diferentes organizaciones. Certificado CISA/CDPP/ISO 27001 y ISO 22301 Lead Auditor. Ha impartido cursos y seminarios sobre seguridad informática en diferentes instituciones.

PID_00275349
Tercera edición: septiembre 2020
© de esta edición, Fundació Universitat Oberta de Catalunya (FUOC)
Av. Tibidabo, 39-43, 08035 Barcelona
Autoría: Silvia Garre Gui, Antonio José Segovia Henares, Arsenio Tortajada Gallego
Producción: FUOC
Todos los derechos reservados
Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada, reproducida, almacenada o transmitida de ninguna forma, ni por ningún medio, sea este eléctrico, mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escrita del titular de los derechos.

Índice

Introducción

En el módulo anterior se han presentado cuáles son los pasos para implantar un SGSI, tomando como referencia las normas de la familia ISO 27000, en concreto la ISO/IEC 27003 – Guía para la implementación de un sistema de gestión de seguridad de la información.
Este módulo se centrará en desarrollar aspectos clave para incidir en algunos de los objetivos de control de la norma, como son el marco normativo o la organización de la seguridad de la información. Ambos son aspectos relativamente sencillos a simple vista, pero que, no obstante, son pasos previos que requieren de un esfuerzo importante de toda la organización, ya que con frecuencia implican cambios que deben ser convenientemente gestionados para "derribar" ciertas barreras que, de lo contrario, complicarán considerablemente la implantación del SGSI.
Se abordará también el planteamiento de un caso concreto de política o norma, como es la de clasificación de la información, que es la base para gran parte del resto del marco normativo, y que es nuevamente una tarea ardua por implicar un cambio en la forma de trabajo habitual del personal.
A continuación se presentan algunas reflexiones sobre las características que debería tener una herramienta para gestionar el SGSI.
Por último, se proporcionan algunas nociones sobre las auditorías de certificación, de mucha utilidad en caso de que la compañía desee obtener la certificación, bien como garantía interna de buena gestión, bien de cara a terceros, como sello de una buena gestión de la seguridad de la información.

Objetivos

Los objetivos que persigue el presente módulo son:

  1. Profundizar en algunos aspectos imprescindibles para el buen desarrollo de un SGSI.

  2. Saber en qué consiste el marco normativo de la seguridad, cómo desarrollar normas y guías de buenas prácticas y en qué consiste una política de seguridad de la información.

  3. Profundizar en el ámbito de la organización de la seguridad de la información. Entender qué estructuras son necesarias y cuál es el modelo de relación imprescindible con el resto de la compañía.

  4. Sentar las bases para una política de clasificación de la información.

  5. Conocer en qué consiste una auditoría de certificación de SGSI para poder prepararse en caso de desear la certificación.

1.Desarrollo de un marco normativo de seguridad de la información

En el módulo anterior veíamos que dentro de la fase de Planificación del SGSI, concretamente en las subfases P.I. Definir la Política de Seguridad, y P.IV. Definir políticas de alto nivel, se debe disponer de una normativa común de seguridad que regule las líneas maestras sobre cómo va a trabajar toda la organización en materia de seguridad de la información.
Por tanto, es necesario establecer un marco normativo que ampare cualquier acción llevada a cabo en materia de seguridad de la información que, como veremos, debe estar aprobado por la Dirección.
Sin embargo, antes de iniciar el desarrollo de ese marco normativo, es necesario hacer una reflexión sobre qué va a contener dicho marco normativo, qué tipos de documentos incluirá, cómo se desarrollarán, con qué objetivos y estructura, quién será el responsable de hacerlo y cuál será el proceso de cada uno de los documentos antes de su aprobación.
La adopción de un método sistemático y claro aporta, como veremos, diversos beneficios.

1.1.La pirámide jerárquica de documentación

Un aspecto tan básico como la terminología es una cuestión a resolver en primera instancia, puesto que facilitará que los diferentes tipos de documentos que se vayan creando se clasifiquen correctamente desde el primer momento, se elaboren teniendo en cuenta un conjunto de consideraciones importantes para cada uno de ellos y permitirá que quien los lea tenga muy claro si su carácter es o no normativo.
De no hacerlo, lo que ocurrirá es que los diferentes departamentos de la compañía irán elaborando documentación, la nombrarán según parezca más conveniente a su responsable y seguirán una estructura más o menos parecida, pero no homogénea, que complicará la lectura e interpretación de dichos documentos. Antes de darnos cuenta existirán en la compañía normas, normativas, políticas, guías, procesos, procedimientos, flujos, libros blancos, libros normativos, manuales, instrucciones, manuales de operación, recomendaciones, experiencias..., siendo prácticamente imposible establecer jerarquías y dependencias entre ellos.
En el mundo de la seguridad de la información, como en otros, suele utilizarse la pirámide jerárquica de documentos:
La pirámide documental
La pirámide documental
Cuanto más arriba en la pirámide, más directrices generales y/o estratégicas y menor nivel de concreción. Asimismo, mayor estabilidad, es decir, poca variación en los documentos, y necesidad de aprobación por parte de la Dirección.
Por el contrario, cuanto más abajo en la pirámide, mayor nivel de detalle, orientación a personal más especializado, mucha necesidad de actualización de la documentación y aprobación a niveles inferiores.
Por norma general, un documento de nivel superior se desarrolla en documentos de nivel inferior.
Veamos un posible esquema de desarrollo del marco normativo:
Ejemplo de estructura de políticas y normas
Ejemplo de estructura de políticas y normas
Si lo traducimos a un posible caso práctico:
m1809_m4_014.gif
En la literatura se pueden encontrar otros planteamientos de pirámide, con mayor o menor número de niveles. Lo importante, no obstante, no es escoger éste o aquel modelo, sino adoptar uno, el que más se ajuste a las prácticas de la organización, darlo a conocer, implantarlo y mantenerlo.
Para cada tipo de documento es importante definir:

  • Tipo de información que debe contener (nivel de detalle).

  • Nivel de obligatoriedad en el cumplimiento. Así pues, una norma será de obligado cumplimiento, mientras que una guía será una recomendación de buenas prácticas.

  • Quién debe aprobar el documento.

  • A quién se debe divulgar.

Es habitual encontrar marcos normativos en los que por debajo de la política de seguridad de la información cuelgan las políticas que se corresponden con los diferentes dominios de la ISO.
De ahora en adelante, para referirnos a un documento del marco normativo, independientemente de su tipología, nos referiremos a un estándar.
En el mundo de las tecnologías de la información y las comunicaciones (TIC), un estándar es un acuerdo documentado que contiene criterios precisos o especificaciones, válidos para ser utilizados consistentemente como reglas, directrices o definiciones de características y tareas, que aseguren que ciertos productos, sistemas, procesos o servicios son adecuados a su propósito, y por tanto, el término estándar, engloba cualquiera de los tipos de documentos definidos en la pirámide jerárquica.
Un estándar puede cubrir cualquier área TIC para la cual se detecte una necesidad. En el ámbito del SGSI hablaremos del marco normativo de seguridad de la información, pero el marco normativo puede definir estándares sobre temas muy diversos, como comunicaciones, plataformas de acceso a servicios, plataformas de prestación de servicios, utilización de servicios, gestión de servicios (definición y construcción de software, bases de datos, interfaces de usuario, control del funcionamiento, consecución de objetivos, cuadros de mando, gestión de incidencias, contratación de personal...), cumplimiento legal, etc.
En la elaboración de los estándares se pueden tener en cuenta aspectos muy diversos y el enfoque que se les dé dependerá de la necesidad concreta a la que se pretenda dar respuesta. Por tanto, un estándar podrá abordar, por ejemplo, temas funcionales (relación del usuario con las TIC), físicos (sobre el entorno y los equipos), de seguridad (física, lógica, operativa, legal...), de integración (interoperatividad entre sistemas), de calidad, de seguimiento y control, etc.
Definamos a continuación los cuatro tipos de documento que recoge la pirámide jerárquica propuesta:
1.1.1.Políticas

  • Contenido. Recogen directrices estratégicas, de alto nivel, bajo las cuales se amparará cualquier acción en materia de seguridad de la información. Todo documento de nivel inferior debiera desarrollar una política. Si se desea, se pueden definir políticas de primer y segundo nivel.

    En seguridad de la información, la política por excelencia es la política de seguridad de la información.

  • Carácter normativo de los controles especificados. Son de obligado cumplimiento dentro del ámbito descrito en la propia política, excepto que el propio ámbito recoja alguna excepción.

  • Aprobación. La política de seguridad de la información y en general, las políticas de primer nivel, debieran ser formalmente aprobadas por la Dirección de la compañía.

  • Divulgación. A todo el personal.

1.1.2.Normas y guías

  • Contenido. Las normas y guías se generan cuando se considera importante a nivel de toda la compañía que se siga una misma solución o un proceso homogéneo para una necesidad determinada con el objetivo de optimizar recursos, la eficiencia y/o la seguridad de la organización.

    Las guías y normas desarrollan las políticas en temas más concretos y específicos. Así pues, en el ejemplo anterior, la política de control de acceso físico se desarrollaba a través de la norma de control de acceso al CPD y salas técnicas, y de la norma de control de acceso al edificio.

  • Carácter normativo. Las normas son de obligado cumplimiento, mientras que las guías son recomendaciones de buenas prácticas. En el ámbito de la seguridad de la información, todo lo que pueda ser dictado como norma es más efectivo. No obstante, no siempre es posible redactar una norma e implantarla de inmediato, bien por la dificultad del proceso de aprobación (caso típico en una administración pública en que una aprobación puede requerir de meses), bien porque se trata de aspectos no suficientemente consensuados, bien porque la organización no está preparada y se necesita un tiempo de adaptación. En ese caso, es preferible aprobar una guía y darla a conocer para que la organización se vaya familiarizando y se inicie la gestión del cambio que se requiera, que aprobar una norma que nadie cumplirá y que lo único que hará será generar rechazo no sólo hacia ésta, sino hacia todo el marco normativo. Una buena práctica es publicar guías, dando a conocer el plazo de adaptación previo a su paso a norma.

    Las normas y guías se desarrollan en procedimientos y manuales/instrucciones.

    En el caso de las guías, la aplicación parcial o total de las buenas prácticas vendrá determinada por un análisis de la conveniencia/proporcionalidad entre los beneficios que aporta o la reducción del riesgo que supone la aplicación de las recomendaciones, y el coste/esfuerzo que supone su aplicación en cuanto a implantación y gestión del cambio.

    Cualquier excepción a la aplicación íntegra de las guías o normas debe ser previamente aprobada por el responsable que corresponda. Deberá existir, por tanto, un procedimiento de gestión de excepciones.

  • Aprobación: La Dirección o un comité por ésta designado.

  • Divulgación: A todo el personal especificado en la propia guía/norma.

1.1.3.Procedimientos

  • Contenido. Presentan un conjunto de acciones a llevar a cabo para conseguir un determinado objetivo. Normalmente intervienen actores de diferentes áreas o departamentos, por lo cual, suele ser necesaria la adaptación de los procedimientos cuando se producen cambios organizativos en la compañía. Los procedimientos dan soporte a la implantación de una norma o guía, por lo cual las normas/guías acostumbran a referenciar procedimientos en su redacción. Son posibles ejemplos de ello un procedimiento de recepción de visitas, de solicitud de servicios, de gestión de incidencias, de escalado de peticiones...

  • Carácter normativo. Los procedimientos son de obligado cumplimiento.

  • Aprobación. Suelen ser elaborados y aprobados por la persona responsable del mismo.

  • Divulgación. A todas las personas implicadas en el mismo.

1.1.4.Manuales/Instrucciones

  • Contenido. Son listas de tareas o instrucciones detalladas para realizar determinadas acciones o utilizar herramientas concretas. Acostumbran a depender del entorno tecnológico, por lo cual, deben ser adaptados cuando se producen cambios de producto o versión. Por ejemplo, manuales de uso de herramientas, instrucciones de configuración de software, de actualización de parche, etc.

  • Los manuales o instrucciones vienen generalmente proporcionados por los fabricantes y distribuidores de productos. No obstante, pueden también generarse internamente, sobre todo en el entorno de la operación o explotación de los sistemas de información y telecomunicaciones, en cuyo caso deberán ser aprobadas por el responsable que corresponda.

  • Carácter normativo. Suelen ser de obligado cumplimiento.

  • Aprobación. Por el responsable correspondiente.

  • Divulgación. A las personas que deben llevar a cabo la actuación.

1.1.5.Otros documentos
El marco normativo puede llevar asociados otros tipos de documento, como por ejemplo:

  • Formularios. Son plantillas (en formato electrónico o papel) destinadas a generar un documento que persigue una finalidad concreta. Corresponden a modelos de contratos, cartas, solicitudes, registros, que una vez cumplimentados adquieren validez, generalmente, mediante la firma de aceptación del documento. Generalmente van asociados a normas/guías o procedimientos. Por ejemplo, solicitud de alta de usuario, aceptación de obligaciones por parte de personal externo, solicitud de excepción de seguridad, etc.

  • Experiencias. Recogen proyectos llevados a cabo en departamentos o áreas de la organización, o en otras compañías de la matriz, que pueden resultar de interés, ya que pueden ayudar a formarse una opinión, especialmente en aquellas áreas en las que no existan estándares, ya sea porque la tecnología no está suficientemente madura, o porque resulta difícil conseguir el consenso.

1.2.El ciclo de vida de un estándar

El ciclo de vida de un estándar se divide en seis fases:

  • Determinación de la necesidad

  • Creación

  • Discusión

  • Aprobación

  • Difusión y ajuste

  • Mantenimiento y revisión

El planteamiento general es que, a partir de la detección de una necesidad, se elabora una propuesta de solución por un grupo de trabajo; esta propuesta es debatida públicamente en un grupo de discusión, se eleva a aprobación definitiva y finalmente es divulgada. Una vez cerrado este proceso, se inicia una nueva fase de seguimiento y observación del estándar, que provocará su actualización o modificación cuando los cambios o las nuevas realidades así lo requieran.
El proceso de elaboración de estándares parte de una filosofía iterativa: en las fases de creación y discusión se refinan los resultados hasta que se considera que el producto está listo; después de un período de mantenimiento y revisión del estándar, se puede volver a empezar con el proceso de creación de una nueva versión que progresivamente mejore el estándar y lo adecue a las nuevas realidades. A partir de esta nueva versión se repiten consecutivamente las fases de discusión, aprobación y difusión del mismo.
El ciclo de vida de un estándar
El ciclo de vida de un estándar
1.2.1.Determinación de la necesidad
El primer paso es determinar qué aspectos de la seguridad de la información deben ser cubiertos, definiendo los beneficios esperados y la necesidad y ámbito a cubrir, especialmente cuando el estándar tiene carácter normativo. Esta fase es impulsada por el responsable del sistema de gestión de los estándares.
En esta fase es preciso designar a una persona que coordine todo el proceso de definición, así como el equipo de trabajo con el que el coordinador trabajará, y el equipo de discusión a quienes se someterá el documento antes de su aprobación. Designar el coordinador y equipo de trabajo implica, por supuesto, la correspondiente dotación con recursos suficientes para llevar a cabo la tarea asignada.
Responsable del sistema de gestión de los estándares

  • Función. Es la persona responsable de controlar el marco general de estándares, velar por el desarrollo del marco de trabajo establecido, controlar versiones, garantizar un proceso de revisión periódico y consensuar cambios en el marco de trabajo cuando se reciban requerimientos en este sentido. Esta figura simplemente vela por que los estándares se mantengan actualizados en el tiempo, implicando en cada momento a los actores necesarios. Por tanto, no es indispensable que tenga un perfil técnico, dado que no debe tener un conocimiento profundo del contenido de los estándares.

  • Composición. La responsabilidad del sistema de gestión se puede dividir en diferentes ámbitos de actuación. El responsable de cada área de actuación será responsable del ciclo de vida de los estándares que caigan en su órbita. Así pues, podría haber un responsable de estándares TIC, estándares de seguridad de la información, estándares de calidad, etc.

1.2.2.Creación
Una vez claros el alcance y los beneficios que se esperan obtener, el grupo de trabajo elabora una propuesta de documento. Para ello, se analizan posibles experiencias dentro de la organización, y el estado del arte de la tecnología si se considera necesario.
El objetivo de esta fase es disponer de una primera versión del estándar. Las tareas de esta fase las realiza el grupo de trabajo que establece internamente el proceso de creación y discusión interna del documento (mediante reuniones, foros, correo electrónico...). Para ello es útil disponer de herramientas de colaboración.
Durante esta fase es importante analizar el impacto de implantación del estándar, ya sea económico, organizativo..., puesto que será uno de los aspectos clave para la aprobación del mismo.
Cuando el coordinador considera que se ha alcanzado un documento correcto y con el suficiente consenso, se abre la fase de discusión.
Coordinador del estándar
Función. Es responsable del proceso global de definición del estándar.

  • Coordina el equipo de trabajo y el equipo de discusión.

  • Decide cuándo el estándar pasa de una fase a otra.

  • Es responsable de garantizar el traspaso de conocimiento necesario al equipo de mantenimiento y revisión.

  • Forma parte del equipo de difusión y hace propuestas en cuanto al material divulgativo.

Composición. Suele asumir el rol una persona especialista en la materia o con suficiente conocimiento general como para asumir la coordinación.
Grupo de trabajo
Función. Creación de un estándar consensuado para presentarlo al grupo de discusión.
Composición. El coordinador del estándar, alguna otra persona perteneciente al área del coordinador, representantes de las áreas más directamente implicadas, RR. HH. siempre que el estándar afecte al personal, asesoría jurídica si la temática lo requiere y expertos en la materia si existe la oportunidad. El grupo debiera estar formado por 6/7 personas como máximo.
1.2.3.Discusión
Durante esta fase se expone la propuesta de documento a un colectivo más amplio de la organización (idealmente con representatividad general), con el objetivo de enriquecerlo con aportaciones, incorporar algún punto de vista que quizás no se había tenido en consideración en la fase anterior y, sobre todo, validar la aplicabilidad en la organización de todo aquello recogido en el estándar.
El coordinador se encarga de recoger todos los comentarios aportados por el grupo de discusión y debatirlos con el grupo de trabajo. En principio, tanto si las aportaciones son aceptadas como si no, se debiera dar respuesta a todos los comentarios recibidos.
Cuando el coordinador considera que el documento es apto para aprobación, el estándar queda pendiente de aprobación y concluye esta fase.
Cuando el coordinador envía el documento a validar al grupo de discusión es importante indicar el plazo disponible para enviar comentarios, y realizar un recordatorio unos días antes de que expire dicho plazo. Un plazo recomendable sería de quince días, procurando no superar las tres semanas.
Por otro lado, es importante solicitar respuestas por parte de los destinatarios, tanto si tienen comentarios que realizar como si están conformes con el documento.
Es recomendable que el coordinador guarde registro de todos los comentarios y respuestas producidas durante esta fase.
Grupo de discusión
Función. Validación del estándar, análisis de aplicabilidad a la compañía y aportación de comentarios. Aprobación consensuada antes de enviar el estándar a aprobación.
Composición. Representación de todos los departamentos / áreas de la compañía (incluidos RR. HH. y asesoría jurídica), expertos invitados si existe la oportunidad y personal de proveedores a los que pueda afectar la implantación del estándar si es el caso.
1.2.4.Aprobación
En esta fase se lleva a cabo la aprobación formal del documento por parte del organismo a quien corresponda. El documento se envía previamente al órgano aprobador, que podrá solicitar modificaciones. Una vez realizadas, se somete a aprobación, determinando la fecha de entrada en vigor del mismo.
Cuando el órgano aprobador esté a alto nivel (comité de dirección, por ejemplo), será preciso hacer una presentación que resuma los objetivos del estándar, ámbito de aplicación, impacto de implantación del mismo (ya sea o no económico) y las personas participantes en los grupos de trabajo y discusión.
1.2.5.Difusión y consolidación
Una vez aprobado, se deberá hacer llegar el documento a todos aquellos afectados definidos en el ámbito de aplicación del estándar, para darlo a conocer y poder iniciar el seguimiento de su implantación.
La difusión del estándar se debe considerar como una acción en positivo en la que se hace énfasis no sólo en los aspectos normativos o de recomendación, sino también en todos los beneficios que aporta a la organización el hecho de disponer de un estándar.
Algunos de los canales que se pueden usar para la difusión son:

  • Publicación en la intranet, en un espacio dedicado.

  • Emisión de notas (correo electrónico, circular interna...) relativas a la publicación del nuevo estándar, con enlace al mismo.

  • Inclusión de la noticia en chats o foros corporativos.

  • Acciones presenciales en ámbitos sensibles y clave.

  • Sesiones formativas.

Para la difusión, suele ser útil contar con personas clave en cada área de la organización, que serán las que se encarguen de divulgar de forma efectiva y recordar la existencia de los estándares en su ámbito.
Desde el momento de la aprobación y en paralelo a su difusión, los usuarios afectados pueden emitir quejas, consultas, sugerencias o incluso requerimientos no cubiertos por el estándar, para que se tengan en cuenta en nuevas versiones del mismo.
Es importante que los usuarios conozcan este proceso de validación de la implantación y lo utilicen. Para ello, puede ser útil habilitar buzones de correo o personas de contacto a quienes dirigir estas aportaciones. Es habitual que se focalicen en los canales de soporte a usuario, que centralizarán la recogida de comentarios y los harán llegar al coordinador del estándar, quien decide si es preciso iniciar un ciclo de revisión, o bien si se puede esperar a versiones posteriores. En este último supuesto, el estándar pasa a la fase de mantenimiento y revisión, el equipo de trabajo se disuelve y el equipo de soporte pasa a hacerse cargo del mismo, bajo la supervisión del responsable del sistema de gestión.
A nivel formal, superar la fase de difusión y consolidación significa que el estándar ha sido contrastado por la experiencia y su contenido pasa a ser consolidado y estable.
1.2.6.Mantenimiento y revisión
Los estándares no deben entenderse como documentos cerrados, sino que son documentos vivos inmersos en un proceso de mejora.
Desde el momento en que el estándar se publica, un equipo deberá velar por los siguientes aspectos:

  • Dar respuesta a preguntas y dudas que de la implantación del estándar se deriven.

  • Mantener la infraestructura que sostiene la publicación y difusión de los estándares y publicaciones afines.

  • Velar por la correcta implantación del estándar.

  • Prestar atención a posibles cambios organizativos o tecnológicos que obliguen a una modificación del estándar, comunicando la necesidad al responsable del sistema de gestión de los estándares.

  • Proponer cambios en el contenido o redacción del estándar, en función de incidencias, problemas o malentendidos detectados.

  • Llevar un registro de todas las posibles modificaciones que se deberán contemplar en versiones posteriores.

En caso de disponer de un documentalista, es importante que participe en el proceso de estructuración y gestión documental de los estándares.

1.3.Contenido mínimo de un estándar

Es importante definir el formato de un estándar y cuál va a ser su contenido y estructura mínima antes de ponerse a redactar. Disponer de una plantilla ofrece diferentes beneficios:

  • Un formato común permitirá a quien lo lee identificar a simple vista que se trata de un estándar.

  • Exponer la información siempre en el mismo orden facilitará encontrar lo que se busca.

  • Una terminología común, facilita la comprensión a quien lo lee.

  • Evitará que se olviden aspectos importantes en la redacción.

  • Ofrece una imagen de coherencia y orden, que refuerza el peso del documento.

La estructura de un estándar no es una lista cerrada. A continuación presentamos una propuesta que se podrá tomar como referencia, y adaptar a la casuística y cultura propia de cada organización.
En principio, cualquier estándar debiera contener los apartados que se exponen a continuación. Dependiendo del tipo de estándar, no obstante, pueden crearse diferentes plantillas. Así pues por ejemplo, en un procedimiento será bastante habitual que exista un flujograma. Este puede considerarse como un apartado adicional o como parte del desarrollo del procedimiento, pero de una forma u otra se deberá establecer que todo procedimiento deberá contener un flujograma.
Del mismo modo, algunos estándares más técnicos pueden estructurar el contenido de una forma común, y puede establecerse también una plantilla común para ellos. Por poner un ejemplo, toda guía de securización de un entorno tecnológico, posiblemente deba referirse a aspectos como la configuración inicial, el control de acceso, la monitorización o la auditoría, y estas podrían ser secciones predefinidas en la plantilla de este tipo de estándar.
Aparte de definir unos apartados mínimos, debiera crearse un estándar de notación para indicar que una palabra se encuentra en el glosario de términos, marcar de forma diferenciada un documento referenciado o cómo proceder en caso de que un determinado apartado no aplique.
Veamos pues una propuesta de contenido de plantilla mínima de estándar.
1) Encabezado / pie del documento
Habitualmente, aparecerá:

  • Logo de la compañía.

  • Tipo de estándar: política, norma, guía, etc.

  • Codificación del estándar.

    La codificación debiera reflejar como mínimo el tipo de estándar, una numeración y el número de versión.

  • Número de página y número total de páginas.

  • Número de versión.

  • Estado del documento: aprobado, en discusión, en revisión, etc.

  • Si se considera necesario, protección del estándar contra copia no autorizada. En este sentido, son de mucha utilidad las licencias Creative Commons para la protección de obras con muy diferentes alternativas. Así pues, por ejemplo, en el caso de las administraciones públicas, en que es relativamente habitual publicar abiertamente el marco normativo, es habitual el tipo de licencia Creative Commons que autoriza la copia y mejora de los estándares, pero no la obtención de beneficios económicos.

2) Objetivo y motivación
Con qué finalidad se emite el estándar. Cuál es el origen o causa de su emisión.
3) Ámbito y vigencia

  • Ámbito. Se refiere por un lado a quién va dirigido el documento, a ser posible, especificado en forma de perfiles. Por ejemplo: jefes de proyecto, operadores, técnicos de sistema, usuarios en general, etc.

    Por el otro, se refiere a cuál es el ámbito de aplicación: toda la corporación, sólo una compañía de la corporación, un edificio de la compañía, una fábrica, etc.

    Y si es posible también al tipo de recurso afectado. Por ejemplo, todos los servidores de red, todas las comunicaciones entre sedes, etc.

    En caso de existir alguna limitación o restricción sobre la aplicabilidad de alguno de los controles, es aconsejable incluirlo también en este apartado.

  • Vigencia. Se especifica cuándo entra en vigor el estándar y si se concede un período de adaptación al mismo.

4) Cumplimiento legal y de estándares de seguridad
Hace referencia a la normativa legal aplicable, o a estándares reconocidos. En este apartado, podría llevarse control de cuáles son los apartados de la ISO 27002 a los que se da cobertura.
5) Descripción
Tal y como ya se ha comentado, este apartado puede desglosarse en diferentes apartados, que variarán en función del tipo de estándar.
Es en este punto, donde se describen las medidas de seguridad que especifica el estándar, ya sean normas o recomendaciones. En el caso de políticas o normas, puede darse el caso de recoger tanto normas como recomendaciones, en cuyo caso, debe quedar claro si se trata de uno u otro tipo de medida o control.
Esto se puede conseguir por ejemplo a través de la notación de los controles:

  • Normas

    • N1

    • N2

  • Recomendaciones

    • R1

    • R2

6) Control
Es la descripción de quién y cómo va a llevar a cabo el control de cumplimiento del estándar. En los estándares con carácter normativo, si no existe algún tipo de control, difícilmente el estándar se respetará.
Siempre que se produzca una incidencia relacionada con la política/norma es aconsejable realizar una revisión de cumplimiento y completitud del documento.
Es habitual que el control se realice en dos niveles.

  • Seguimiento periódico. Es un seguimiento mensual o trimestral, a partir de indicadores, informes de cumplimiento de los principales aspectos de la política/norma.

  • Auditoría periódica. La auditoría de los estándares no es una fase propiamente dicha del ciclo de vida de los estándares, pero es una actividad paralela indispensable por varios motivos:

    • Permite conocer el grado de implantación del estándar y, por tanto, la efectividad del mismo y reportarlo a la Dirección.

    • Permite controlar la correcta gestión de las excepciones.

    • Permite conocer aquellos incumplimientos que se repiten recursivamente y que, posiblemente, requieran de una revisión.

    • Proporciona reflexiones y aportaciones de mejora para posteriores versiones.

    • Permite detectar vulnerabilidades de la organización.

    • Proporciona a los usuarios responsables de cumplirlos la certeza de que los estándares están para cumplirlos y que no son "decorativos".

Como bien dice el proverbio:

"Ninguna ley va a servir, si no hay quien la haga cumplir".

Desgraciadamente, el mundo de la seguridad de la información funciona bastante "a golpe de control", es decir, que no existe la concienciación generalizada de que la seguridad es necesaria para que sea aplicada de forma global y proactiva, sino que es necesario establecer normas de obligado cumplimiento y controlar que se respeten.
Por tanto, es importante que el área de la compañía sobre la cual recaiga la función auditora o de control interno incluya dentro de su plan de auditorías el cumplimiento de los estándares de forma sistemática, y que más o menos cada dos años haga un repaso general del marco normativo completo.
Obviamente, los informes de auditoría deberán ser facilitados como mínimo al responsable del incumplimiento y a su responsable directo, al responsable de seguridad de la información y al responsable del sistema de gestión de estándares. Será responsabilidad del responsable de seguridad de la información analizar el porqué de los incumplimientos y hacer un seguimiento del plan de acción establecido para su corrección, reportando periódicamente la situación a Dirección.
7) Penalizaciones
Son acciones de penalización o consecuencias en caso de incumplimiento.
8) Divulgación
Identificación del responsable de la divulgación y medios a través de los cuales se realiza.
9) Revisión
Hace referencia a la fecha de la próxima revisión prevista y causas o supuestos por los cuales se deberá hacer una revisión antes de la fecha prevista.
Cuanto más abajo en la pirámide de documentación, mayor frecuencia de revisión.
10) Glosario de términos
Es la definición de terminología utilizada en la redacción del documento, para aclarar conceptos o evitar ambigüedades (términos técnicos, conceptos muy propios de la compañía o sector, abreviaturas...).
11) Documentación referenciada
Es la relación de documentos a los cuales se ha hecho referencia a lo largo del mismo: políticas, normas, procedimientos, manuales, etc. Si es posible, la documentación será referenciada a través de su código y nombre, pero no de su versión, para evitar la actualización del estándar ante cambios de versión en los documentos referenciados.
12) Palabras clave
Es la relación de términos que pueden servir para localizar el documento en caso de búsqueda (muy útil en gestores documentales).
13) Histórico del documento
Cada vez que se produce un cambio de versión se hace una breve descripción de los cambios introducidos y el motivo de estos, para facilitar el seguimiento de versiones.
En caso de que el estándar sustituya otro estándar ya obsoleto, se deberá hacer constar en este apartado.

1.4.Ficha del estándar

Aparte de la plantilla de estándar, es recomendable tener una ficha del estándar, como un documento aparte, en que se recoja información como:

  • Clasificación del estándar.

    Seguramente, a la hora de publicar los estándares, los agruparemos por tipología. Por ejemplo: operación, administración, arquitectura, de usuario, etc.

  • Fechas del ciclo de vida: fechas previstas y reales de inicio y fin de cada fase.

  • Componentes de los grupos de trabajo y discusión.

  • Comentarios recibidos y respuestas dadas. Dentro de esta información suelen ponerse de manifiesto algunas vulnerabilidades de los sistemas, por lo que la ficha se conservará como un documento de carácter restringido.

  • Cualquier otra información relevante sobre el estándar que no deba formar parte del documento publicado.

1.5.La redacción del estándar

Existe amplia literatura sobre el marco normativo y la redacción de estándares que puede ser consultada. En este módulo sólo haremos una introducción a los aspectos clave, a través de 10 reglas de oro, o consejos prácticos a tener en cuenta a la hora de redactar un estándar.
1) Respetar el orden de redacción de los apartados y reflexionar sobre cada uno de ellos. Antes de desarrollar el contenido del estándar, es muy importante tener claro el motivo por el cual se desarrolla y a quién va dirigido. Vale la pena dedicar un tiempo a pensar sobre estos aspectos, dado que son determinantes para el contenido.
Por otro lado, hay apartados como el de Control o Penalizaciones, que suelen ser complicados, pero es preciso dedicar un tiempo a pensar en ellos. En ocasiones, es mejor no poner un control si después no vamos a ser capaces de hacerle el seguimiento.
En cuanto a las penalizaciones, variarán en función del tipo de compañía, pero en cualquier caso, se deben establecer y consensuar con la Dirección para recibir su apoyo en caso necesario.
2) No copiar un estándar de otros. La literatura e Internet están repletos de estándares de todo tipo publicados por compañías y administraciones públicas. Basarse en otros estándares para redactar los de nuestra compañía es correcto, dado que nos sirven de punto de partida y nos facilitan la labor. No obstante, copiarlos sin realizar las reflexiones que comentábamos en el punto anterior, y sin adaptarlos a la casuística y cultura de nuestra compañía es un error, que puede llevar el estándar al fracaso.
3) El contenido debe ser suficiente. Un documento pobre en contenido no justifica el esfuerzo de llevarlo a aprobación. Muy posiblemente pueda incluirse en otro estándar o agruparse con otros conceptos, para crear un estándar con mayor contenido.
4) Pensar antes de empezar si el estándar será o no de obligado cumplimiento. El vocabulario y tiempo verbal que se utiliza en la redacción varía según si se trata de una norma o una recomendación.
5) Estructurar bien el contenido. El apartado "Descripción", en el que se desarrolla el estándar, debe estar bien estructurado, de manera que se agrupen los controles que tienen algo en común, y se ordenen siempre de mayor a menor importancia, y de menor a mayor nivel de detalle (primero lo general, para bajar después al detalle).
6) Cada control debe ser un punto auditable por sí mismo. En estándares de carácter normativo, es muy importante que cada control sea independientemente auditable, lo cual facilitará enormemente la función auditora y permitirá un seguimiento más sencillo del nivel de cumplimiento. De esta forma, cuando llegue un auditor y audite el control "N15", por poner un ejemplo, debe ser capaz de decir si es o no conforme, sin ambigüedades. Es decir, en ningún caso podrá decir "se cumple la primera parte del control, pero no la segunda".
Ello puede suponer tener mayor número de controles, pero redundará en claridad y efectividad en el seguimiento.
7) Utilizar un lenguaje sencillo y no cometer faltas ortográficas ni erratas de redacción. Utilizar un lenguaje directo, frases cortas y estructuras gramaticales sencillas y poco rebuscadas, comprensibles para todos aquellos a quien va dirigido el documento. Prestar atención a los correctores ortográficos.
8) No dar nunca por supuesto que se conocen las abreviaturas. Por obvia que resulte, es recomendable que siempre que una abreviatura aparece por primera vez se detalle su significado, y que siempre se recoja en el "Glosario de términos".
9) Como mínimo una lectura de principio a fin sin interrupciones, como si fuera la primera vez que lo leemos. No dar por finalizada la redacción del documento hasta que no se haya conseguido leer el documento como mínimo una vez sin interrupciones de principio a fin, bajo la perspectiva de alguien que se encuentra con el documento por primera vez. Adoptar esta mentalidad puede poner en alerta de que se están dando por supuestos algunos temas que no son obvios, o que se están dejando de explicar cuestiones complementarias que son necesarias para la comprensión del estándar.
10) Someter siempre el documento a discusión, y hacerlo con espíritu abierto y humilde. Es muy bueno recibir comentarios a un estándar, por poco relevantes que parezcan, y prestar atención a todos y cada uno de ellos, puesto que ello puede poner en la pista de temas mal explicados, no considerados..., por lo que es necesario recibir todos los comentarios con espíritu positivo y abierto. En cuanto al espíritu humilde, seguramente, quien revisa un documento no es del todo consciente del esfuerzo que supone escribir un estándar desde cero, que sin duda es mucho más complejo que revisarlo, por lo que es posible que sus comentarios carezcan de cierta sensibilidad hacia el autor, pero el autor también debe ser consciente de ello, y no tenerlo en cuenta, sino sacar el máximo partido de los comentarios recibidos.

2.Política de seguridad de la información

El estándar por excelencia en un sistema de gestión de la seguridad es, sin duda, la política de seguridad de la información, ya que constituye el primer nivel de la pirámide jerárquica en seguridad de la información.
Como ya se ha comentado con anterioridad, el objetivo de dicha política es establecer las directrices en seguridad de la información, alineadas con los objetivos del negocio y la legislación aplicable, todo ello refrendado y con el compromiso de la Dirección de la compañía.
La ISO 27002 en su apartado 5 hace una descripción detallada de cuál debe ser el contenido de la política de seguridad de la información y de los principales aspectos de su revisión.
A continuación se comentan algunos aspectos importantes a tener en consideración en el momento de redactarla:

  • A la política de seguridad de la información le aplica todo lo expuesto anteriormente sobre el ciclo de vida, el contenido mínimo (o plantilla de estándar) y las diez reglas de oro para su redacción, de lo cual se deducen algunos de los puntos expuestos a continuación.

  • No se puede copiar la política de otra compañía. Se trata de exponer los objetivos de seguridad, al servicio de alcanzar los objetivos del negocio, por lo que difícilmente la política de una empresa automovilística tendrá mucho que ver con la de una empresa alimentaria, por poner un ejemplo.

    Se debe por tanto personalizar a la casuística propia, e incorporar todas aquellas leyes o normas sectoriales que sean de aplicación, y a las que se deberá dar cumplimiento, y que justificarán muchas de las medidas de seguridad que se deban implantar en la compañía.

    Asimismo, si la compañía ha decidido acceder a la certificación del SGSI, o simplemente tomar una norma internacional como guía de buenas prácticas, es interesante destacarlo en este documento.

  • Debe ser aprobada al más alto nivel de la compañía. La Dirección debe conocer, aprobar y firmar su contenido, y dar a conocer su compromiso con ella al resto de la compañía. Por ello, cuando la política sea aprobada, es interesante que la difusión provenga de la propia Dirección, para que todo el personal tenga claro quién es su principal promotor.

  • Debe ser divulgada a todo el personal de la compañía y terceras partes con acceso a información.

    Por ello debe ser un documento generalista, que no entre en mucho detalle, que dé la mínima información necesaria, y que no utilice una terminología muy técnica, ni haga referencia a nombres de personas o productos concretos.

  • La política no debe ser un documento extenso; debiera bastar con un par de páginas como máximo, ya que de lo contrario difícilmente será leída por todo el público a quien va destinada.

  • La política debe describir qué entiende la compañía por seguridad de la información, generalmente haciendo referencia a la confidencialidad, integridad y disponibilidad de la información de la compañía, aunque se puede incluir también la autenticidad, privacidad e incluso la trazabilidad, tal y como hace el Esquema Nacional de Seguridad (RD 3/2010).

  • Necesariamente, la política debe hacer mención a la organización de la seguridad de la información y describir brevemente cuáles son los principales organismos o cargos en materia de seguridad de la información, con una breve descripción de sus funciones y referenciando en todo caso, otro documento en el que se recoge una descripción detallada de funciones.

  • La política debe recoger la necesaria implicación de todo el personal para trabajar de una forma segura.

  • Asimismo, debe referenciar el marco normativo que la despliega, haciendo, si es posible, una breve descripción del contenido de cada una de dichas normas o políticas de segundo nivel.

  • Se debe revisar anualmente y anualmente ser aprobada o corroborada por la Dirección, acción de la cual se debe guardar registro (a través de un acta de reunión firmada, por ejemplo).

    Asimismo, puede requerir de una revisión antes del plazo previsto en ciertas situaciones como podrían ser la materialización de un importante incidente de seguridad o cambios organizativos relevantes.

La aprobación de una política de seguridad de la información y, en general, de un marco normativo es un proceso habitualmente largo, y especialmente en el ámbito de la Administración pública o de grandes corporaciones, por lo que es uno de los primeros pasos a acometer junto con la definición de la organización de seguridad. No tener la política de seguridad aprobada no debe ser impedimento para seguir progresando en la implantación del SGSI, pero es importante no abandonarla, ya que es el pilar de todo el proceso de gestión de la seguridad de la información.

3.Organización de la seguridad de la información

La organización de la seguridad de la información es una de las primeras tareas a abordar en la implantación del SGSI. Todos los esfuerzos en materia de seguridad de la información serán inútiles o muy poco eficaces si la compañía no tiene claro quién tiene autoridad, sobre qué aspectos y quién es responsable de qué tareas o ámbitos.
Es por tanto necesario crear una estructura interna con responsabilidad directa sobre la seguridad de la información. Dicha estructura será muy variable en función del tamaño y tipo de compañía, pero sea cual sea, las funciones deben estar claras y deben ser atribuidas a personas concretas, ya sea con dedicación exclusiva o parcial.
Nuevamente, resulta indispensable que la estructura organizativa y la asignación de funciones de seguridad sea aprobada y apoyada por la Dirección para dotar a las personas con responsabilidad en la materia con la autoridad y el tiempo necesarios para ejercer sus funciones dentro de la compañía.
A continuación se expone una posible estructura organizativa de seguridad de la información, habitual en muchas organizaciones.
Posible estructura organizativa en seguridad de la información
Posible estructura organizativa en seguridad de la información
Esta estructura organizativa revela que la seguridad de la información implica a toda la compañía y a todo su personal, ya sea a nivel estratégico, ya sea a nivel más táctico u operativo.
A continuación se describen las funciones de cada una de las responsabilidades u órganos definidos, así como algunos comentarios sobre quién o quiénes es recomendable que asuman la función.

3.1.El Comité de Dirección de la compañía

Las funciones en materia de seguridad de la información del Comité de Dirección de la compañía son las siguientes:

  • Hacer de la seguridad de la información un punto de la agenda del Comité de Dirección de la compañía.

  • Nombrar a los miembros de un Comité de Seguridad de la Información y darles soporte, dotarlo de los recursos necesarios y establecer sus directrices de trabajo.

  • Aprobar la política, normas y responsabilidades generales en materia de seguridad de la información.

  • Determinar el umbral de riesgo aceptable en materia de seguridad.

  • Analizar posibles riesgos introducidos por cambios en las funciones o funcionamiento de la compañía para adoptar las medidas de seguridad más adecuadas.

  • Aprobar el Plan de seguridad de la información, que recoge los principales proyectos e iniciativas en la materia.

  • Realizar el seguimiento del cuadro de mando de la seguridad de la información.

Las decisiones tomadas por el Comité de Dirección en materia de seguridad de la información deberán quedar recogidas en acta.

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

Las decisiones en materia de seguridad de la información son tomadas de forma consensuada por un grupo formado por diferentes responsables dentro de la compañía.
Las funciones en materia de seguridad de la información del Comité de Seguridad de la Información son las siguientes:

  • Implantar las directrices del Comité de Dirección.

  • Asignar roles y funciones en materia de seguridad.

  • Presentar a aprobación al Comité de Dirección las políticas, normas y responsabilidades en materia de seguridad de la información.

  • Validar el mapa de riesgos y las acciones de mitigación propuestas por el responsable de seguridad de la información (RSI).

  • Validar el Plan de seguridad de la información o Plan director de seguridad de la información y presentarlo a aprobación al Comité de Dirección. Supervisar y hacer el seguimiento de su implantación.

  • Supervisar y aprobar el desarrollo y mantenimiento del Plan de continuidad de negocio.

  • Velar por el cumplimiento de la legislación que en materia de seguridad sea de aplicación.

  • Promover la concienciación y formación de usuarios y liderar la comunicación necesaria.

  • Revisar las incidencias más destacadas.

  • Aprobar y revisar periódicamente el cuadro de mando de la seguridad de la información y de la evolución del SGSI.

Dependiendo del tamaño de la compañía, puede ocurrir que el Comité de Seguridad tenga los mismos integrantes que el Comité de Dirección, pero en grandes compañías, o en la Administración pública, suele ser un órgano aparte, dependiente del Comité de Dirección.
El Comité de Seguridad de la Información suele tener representación de diversas áreas de soporte, así como de las principales unidades de negocio (aquellas que están sometidas a mayores riesgos).
La composición es muy variable, pero habitualmente consta de un grupo de miembros permanentes y de invitados según la temática.
Componentes habituales del Comité de Seguridad de la Información
Componentes habituales del Comité de Seguridad de la Información
1) Miembros permanentes. Los miembros permanentes son el director de RR. HH., el director de Organización, el director de Tecnologías de la Información y Comunicaciones, Seguridad Física (en caso de existir de forma diferenciada), el responsable de seguridad de la información, y responsables de las áreas de negocio más críticas y/o sensibles (unidades con altos riesgos, con distribución territorial...).
2) Miembros por invitación. Son los representantes de otras unidades, como Asesoría Jurídica, Auditoría, Control...
En cuanto a la frecuencia de reunión, al inicio de la implantación del SGSI es conveniente que el Comité de Seguridad se reúna con frecuencia (2 semanas / 1 mes). Una vez superadas las dos primeras fases del SGSI (Planificar/Hacer), puede ser suficiente con una reunión cada 2/3 meses, y siempre que sea necesario en caso de crisis.

3.3.Responsable de seguridad de la información (RSI)

La designación de un responsable de seguridad de la información (RSI) es la única vía para avanzar de forma organizada y paulatina en seguridad de la información, ya que garantiza que hay alguien para quien la seguridad de la información es una prioridad.
Las funciones en materia de seguridad de la información de los RSI son coordinar las acciones orientadas a garantizar la seguridad de la información en cualquiera de sus formas (digital, óptica, papel...) y en todo su ciclo de vida (creación, mantenimiento, distribución, almacenaje y destrucción), para protegerla en términos de confidencialidad, privacidad, integridad, disponibilidad, autenticidad y trazabilidad.
Todo ello se concreta en:

  • Implantar las directrices del Comité de Seguridad de la Información de la compañía.

  • Elaborar, promover y mantener una política de seguridad de la información, y proponer anualmente objetivos en materia de seguridad de la información.

  • Desarrollar y mantener el documento de Organización de la seguridad de la información en colaboración con el área de Organización/RR. HH., en el cual se recogerá quién asume cada una de las responsabilidades en seguridad, así como una descripción detallada de funciones y dependencias.

  • Desarrollar, con el soporte de las unidades correspondientes, el marco normativo de seguridad y controlar su cumplimiento.

  • Actuar como punto focal en materia de seguridad de la información dentro de la compañía, lo cual incluye la coordinación con otras unidades y funciones (seguridad física, prevención, emergencias, relaciones con la prensa...), a fin de gestionar la seguridad de la información de forma global.

  • Promover y coordinar entre las áreas de negocio el análisis de riesgos de los procesos más críticos e información más sensible, y proponer acciones de mejora y mitigación del riesgo, de acuerdo con el umbral aceptable definido por el Comité de Dirección. Elevar el mapa de riesgos y el Plan de seguridad de la información al CSI.

  • Controlar la gestión de riesgos de nuevos proyectos y velar por el desarrollo seguro de aplicaciones.

  • Revisar periódicamente el estado de la seguridad en cuestiones organizativas, técnicas o metodológicas. Esta revisión ha de permitir proponer o actualizar el Plan de seguridad de la información, incorporando todas las acciones preventivas, correctivas y de mejora que se hayan ido detectando. Una vez aprobado dicho plan y el presupuesto por el CSI, el RSI deberá gestionar el presupuesto asignado y la contratación de recursos cuando sea necesario.

  • Coordinar acciones con las áreas de negocio para elaborar y gestionar un Plan de continuidad de negocio de la compañía, basado en el análisis de riesgo y la criticidad de los procesos de negocio, y la determinación del impacto en caso de materialización del riesgo.

  • Velar por el cumplimiento legal (LOPD, RD 3/2010 Esquema Nacional de Seguridad, Basilea, SOX...), coordinando las actuaciones necesarias con las unidades responsables.

  • Definir la arquitectura de seguridad de los sistemas de información, monitorizar la seguridad a nivel tecnológico (gestión de trazas, vulnerabilidades, cambios...), hacer el seguimiento de los incidentes de seguridad y escalarlos al CSI si corresponde.

  • Elaborar y mantener un plan de concienciación y formación en seguridad de la información del personal, en colaboración con la unidad responsable de la formación en la compañía.

  • Hacer seguimiento y revisar los incidentes de seguridad, escalándolos al CSI si corresponde.

  • Coordinar la implantación de herramientas y controles de seguridad de la información y definir el cuadro de mando de la seguridad. El RSI debe analizar y mantener actualizado dicho cuadro de mando, presentándolo al CSI con la periodicidad que se establezca.

Dependiendo de la compañía, es posible que alguna de las funciones enumeradas no sean atribuidas al RSI, lo cual no tiene por qué ser un problema siempre y cuando la función esté asignada a alguien y exista comunicación y una gestión coordinada entre responsables.
El RSI puede delegar algunas de sus funciones en segundas personas, pero continúa siendo el último responsable de las mismas y se debe asegurar que se llevan a cabo correctamente.
El RSI debe comunicarse con todo el negocio, pero debe existir estrecha relación con unidades como RR. HH. y Organización (seguridad relativa al personal y procedimientos transversales), área TIC (seguridad en la operación, seguridad en el desarrollo de nuevos sistemas de información, seguridad en las comunicaciones...), seguridad física, etc.
Algunas observaciones sobre el cargo
Es altamente recomendable que la función de RSI sea asumida por personal interno. El porcentaje de dedicación a las funciones de seguridad del RSI dependerá de la problemática, dimensiones y necesidades de cada organización. En compañías con un cierto tamaño, es habitual que el RSI gestione un equipo de profesionales de seguridad, bien sean internos, bien externos (ubicados en instalaciones propias o de forma remota).
Para que el RSI pueda desarrollar sus funciones, es preciso dotarle de los recursos humanos y/o técnicos necesarios.
La función de RSI debiera recaer sobre una persona con buenos conocimientos de la organización y su negocio, de manera que sea capaz de encontrar el equilibrio adecuado entre seguridad de la información y la máxima rentabilización de la tecnología al servicio de los intereses y objetivos de la organización.
Para mantener una correcta segregación de funciones y evitar conflictos de interés, la responsabilidad del RSI no debiera ser asumida por el director TIC, ni por cualquier otra persona con funciones que le permitan tomar decisiones técnicas u operativas relacionadas con los sistemas de información.
El RSI debe tener un perfil dialogante e integrador, saber trabajar en equipo y ser capaz de convertirse en interlocutor entre los equipos técnicos y los equipos de negocio.

3.4.Delegado de protección de datos

El vigente Reglamento general de protección de datos (RGPD, reglamento de la UE 2016/679 ) establece la figura de delegado de protección de datos (conocido como DPD o también como DPO, del inglés Data Protection Officer), que constituye uno de los elementos clave del RGPD, y un garante del cumplimiento de la normativa de la protección de datos en las organizaciones, sin sustituir las funciones que desarrollan las autoridades de control.
El delegado de protección de datos deberá contar con conocimientos especializados de derecho y, obviamente, de protección de datos. Actúa de forma independiente y se le atribuyen una serie de funciones reguladas en el artículo 39 del RGPD, entre las que destacan informar y asesorar, así como supervisar el cumplimiento del citado RGPD por parte del responsable o encargado.

3.5.Otras responsabilidades distribuidas por la compañía

3.5.1.Responsables funcionales de la información
Tienen las funciones siguientes:

  • Clasificar la información de la cual son responsables en función de su criticidad para la compañía en términos de confidencialidad, privacidad, integridad, continuidad, autenticidad, no repudio, trazabilidad e impacto mediático y determinar el uso que de la información se puede hacer y quién puede acceder a ella.

  • Tener conocimiento de la normativa general o sectorial aplicable a la información de la que son responsables, incluida la normativa vigente en materia de protección de datos de carácter personal.

  • Definir los requerimientos de seguridad para el tratamiento de la información, ya sea de forma automatizada o manual, en todo su ciclo de vida (creación, modificación, conservación y destrucción si procede).

  • Hacer seguimiento del estado de la seguridad de los sistemas de información que traten la información de la cual son responsables, y gestionar la mitigación de riesgos dentro de su nivel de decisión.

  • Dar impulso e implicarse en la elaboración de planes de continuidad de negocio, y definir procedimientos alternativos en caso de indisponibilidad del sistema o falta de integridad de la información.

  • Colaborar en la realización de revisiones y auditorías de seguridad de la información.

3.5.2.Personal en general
Todo el personal interno o externo con acceso a la información de la compañía (trabajadores, proveedores en prestación de servicios), tiene la obligación de:

  • Mantener la confidencialidad de la información.

  • Hacer un buen uso de los equipos y de la información a la cual tienen acceso y protegerla de accesos no autorizados.

  • Respetar las normas y procedimientos vigentes en materia de seguridad de la información, y velar por que terceras partes en prestación de servicios también la respeten.

  • Utilizar adecuadamente las credenciales de acceso a los sistemas de información.

  • Respetar la legislación vigente en materia de protección de datos de carácter personal y cualquier otra que sea de aplicación.

  • Notificar, por la vía establecida, insuficiencias, anomalías o incidentes de seguridad y situaciones sospechosas que pudieran poner en peligro la seguridad de la información.

3.5.3.Área de Tecnologías de la Información y Comunicaciones (TIC)
Tienen las funciones siguientes:

  • Cumplir con las políticas, normas y procedimientos en materia de seguridad de la información. Colaborar con el RSI en su definición.

  • Implantar en los sistemas de información los controles de seguridad prescritos, las acciones correctoras establecidas y gestionar las vulnerabilidades detectadas.

  • Requerir la participación del RSI en nuevos proyectos de desarrollo o adaptación/implantación de productos de mercado, especialmente cuando puedan ser críticos en términos de confidencialidad, privacidad, integridad, continuidad, autenticidad, no repudio y trazabilidad, o puedan tener un impacto mediático importante.

  • Requerir la participación del RSI en la implantación o gestión de los cambios de hardware y software.

  • Garantizar la inclusión de la seguridad en todo el ciclo de vida de los datos: creación, mantenimiento, conservación y destrucción, y en los procesos de gestión de hardware y software.

  • Adoptar medidas para proteger la información según su clasificación por parte del responsable de la información.

  • Colaborar con el RSI en la identificación de riesgos y la propuesta de soluciones, y colaborar en las revisiones o auditorías de seguridad que se lleven a cabo.

3.5.4.Área de Seguridad Física
Tienen las funciones siguientes:

  • Proporcionar los medios técnicos necesarios para la protección física de la información, tanto frente a desastres físicos (incendio, inundación, fallos de suministro eléctrico...), como frente a accesos no autorizados. La definición de controles a implantar se debe hacer coordinadamente con el RSI.

  • Disponer de medidas de recuperación de la situación normal de operación de acuerdo con los requerimientos de continuidad establecidos por el negocio.

  • Conocer e implantar los procedimientos de seguridad establecidos en la política de seguridad de la información.

  • El RSI y el responsable de seguridad física deben reportarse mutuamente y a la mayor brevedad los incidentes de seguridad detectados cuando puedan afectar el ámbito de competencia de la otra parte.

  • Implicar al RSI en los proyectos de obra y rehabilitación de edificios, para poder tener en cuenta a priori temas de ubicación de elementos de red y comunicaciones, protección de equipos...

3.5.5.Área de RR. HH.
Tienen las funciones siguientes:

  • Informar a las unidades gestoras de recursos de información sobre cambios / movimientos de personal para poder realizar una buena gestión de recursos: altas, bajas definitivas y temporales, cambios de categoría y/o funciones, cambios organizativos, etc.

  • Trabajar conjuntamente con el RSI en el desarrollo de la política de seguridad de la información en los temas referentes al personal.

  • Aplicar procedimientos disciplinarios en caso de vulneración del marco normativo.

3.5.6.Área de Asesoría Jurídica
Tienen las funciones siguientes:

  • Colaborar con el RSI en la emisión de nuevas políticas y normas de seguridad y en la investigación y resolución de incidentes de seguridad cuando se puedan derivar acciones legales (reclamaciones de terceras partes, acciones contra un trabajador...).

  • Colaborar con el RSI en la definición de cláusulas específicas de seguridad de la información, e incluirlas en los contratos con terceras partes y contratos de personal externo.

  • Informar al RSI de nueva legislación o cambios en la legislación aplicable, que pudieran tener impacto sobre la seguridad de la información, dando soporte en su interpretación.

3.5.7.Otras áreas
Cada área dentro de la compañía deberá colaborar con el RSI para desplegar la seguridad en su ámbito de actuación y conseguir trabajar y hacer trabajar a la organización de forma segura. Así pues, se deberán también identificar funciones de seguridad a nivel de auditoría, seguros, formación, organización, etc.

4.Clasificación de la información

La clasificación de la información es una cuestión muy compleja por un lado, pero esencial por el otro, puesto que es lo que permitirá aplicar controles de seguridad proporcionales a la criticidad del activo a proteger, en este caso, la información; es decir, que permitirá proteger la información en función del valor que ésta tenga para la compañía, focalizando los esfuerzos sobre aquella información de mayor valor.
Es preciso por tanto redactar una política de clasificación de la información, que nuevamente deberá ser aprobada por la Dirección y se deberá dar a conocer a todo el personal de la compañía.
La política de clasificación debe tener en cuenta aspectos como:

  • Definición de qué dimensiones de seguridad se van a tener en cuenta de cara a la clasificación. Como mínimo, confidencialidad, integridad y disponibilidad, aunque podrían considerarse otros criterios: autenticidad, trazabilidad, impacto mediático / visibilidad política, etc.

Es habitual encontrar políticas de clasificación que sólo tienen en cuenta la dimensión de la confidencialidad. No obstante, dependiendo del tipo de negocio, el resto de dimensiones pueden resultar tanto o más importantes que la confidencialidad, en cuyo caso también se deben tener en consideración.

  • Definición del número de niveles de clasificación para cada dimensión y su alineamiento con posibles clasificaciones establecidas por normativa vigente (LOPD, Esquema Nacional de Seguridad...). Es importante que la definición de dichos criterios se realice en lenguaje de negocio (y no lenguaje técnico de seguridad).

  • Definición de los controles de seguridad a aplicar a cada nivel durante el tratamiento de la información a lo largo de todo su ciclo de vida. Obviamente, los controles serán más restrictivos a medida que aumente el nivel de criticidad de la información. En cada caso será necesario definir quién es responsable de la aplicación del control.

  • Quién clasifica la información o quién es su propietario. Tal y como se vio en el apartado de "Organización", son los responsables funcionales del negocio los primeros responsables de su clasificación, puesto que son ellos los que mejor conocen la criticidad de la misma. Es por tanto indispensable su participación en el equipo de trabajo para la definición de esta política.

  • Sistema de etiquetado o marcaje de la información (para cualquier tipo de formato/soporte), con el fin de que cualquier persona que acceda a dicha información sepa a qué nivel pertenece de una forma rápida y sencilla.

Ejemplo. Definición de criterios de clasificación para la confidencialidad

Nivel

Descripción

Bajo

  • Información pública o públicamente disponible.

  • Su divulgación no supone un perjuicio para la compañía.

  • Es aquella a la que se otorga libre acceso, dentro y fuera de la compañía, y no requiere medidas de protección de su confidencialidad.

Medio

  • Información a disposición de todo el personal de la compañía a través de la intranet, tablones de anuncios, etc., sin acceso restringido.

  • Información no accesible a terceras partes o entidades ajenas a la compañía.

Alto

  • Es información restringida a un grupo concreto de personas con una identidad concreta y determinada que han sido previamente identificadas y autorizadas (normalmente, mandos intermedios), cuya divulgación podría comportar un incumplimiento grave de legislación, beneficios ilícitos, pérdidas o desprestigio para la compañía (Ej.: información relativa a cambios organizativos y/o de RR. HH., borradores de pliegos de concursos públicos de muy alto importe antes de su publicación...).

  • Toda aquella información asociada al desarrollo de las tareas de una o diversas áreas o partes de éstas y, por tanto, el acceso estará restringido al personal implicado en dichas tareas. Ejemplos:

    • Información relativa a la configuración de sistemas de seguridad tanto físicos (control de acceso) como lógicos (cortafuegos, IDS/IPS).

    • Información de configuración técnica de los diferentes equipos y dispositivos de la infraestructura.

Muy alto

  • Es información altamente restringida, de importancia estratégica, concebida exclusivamente para ser conocida por un grupo muy reducido de personas (normalmente alta dirección), cuya divulgación podría comportar elevadas pérdidas económicas o desprestigio grave para la compañía. Ej:

    • Contratos estratégicos de la compañía. Decisiones de tipo político.

    • Mapas de red o de direcciones IP. Claves de acceso a sistemas de información o dispositivos criptográficos, etc.

    • Secretos industriales.

    • Otros.
El número de niveles dependerá de cada organización y de su actividad de negocio. No obstante, no es recomendable exceder los cinco niveles de clasificación, puesto que la tarea de clasificación puede ser costosa y confusa.
Definiciones habituales muy orientadas a la clasificación en términos de confidencialidad son:
Tres niveles

  • Información pública: como por ejemplo, información comercial de la compañía.

  • Información interna: como por ejemplo la política de seguridad o procedimientos internos de la compañía.

  • Información confidencial: como por ejemplo, información restringida a un grupo reducido de personas (elaboración de presupuestos, nómina de empleados, procedimientos técnicos de copias de seguridad, etc.).

Cinco niveles

  • Información pública: acceso interno y externo.

  • Información interna: acceso únicamente por parte del personal de la compañía.

  • Información restringida: acceso a un grupo concreto, como por ejemplo, el personal de un departamento.

  • Información confidencial: acceso a un grupo reducido y controlado de personas (nóminas, presupuestos...).

  • Información secreta: acceso a un grupo muy específico y controlado de personas: resultados de I+D+i, secretos industriales, etc.

El resultado de una política de clasificación de la información es la definición de los controles de seguridad a aplicar para cada nivel de clasificación. Dichos controles cubrirán los requerimientos de seguridad para cada una de las dimensiones analizadas y, obviamente, deberán también dar cumplimiento a los requerimientos de la legislación vigente.
La naturaleza de cada control de seguridad determinará quién es responsable de su aplicación y en qué momento. Así pues, existirán controles a aplicar a nivel técnico por parte de personal de seguridad o el área TIC (ej.: instalación de antivirus), controles a aplicar desde las áreas de negocio (ej.: definición de accesos requeridos para un determinado usuario), controles a aplicar por los usuarios (ej.: cifrado de información confidencialidad en su transmisión por correo electrónico), etc.
Las fases iniciales de cualquier proyecto son momentos críticos para garantizar la seguridad de la información, y muy especialmente si se trata de proyectos de desarrollo o implantación de sistemas de información. Si la compañía tiene una política de clasificación definida, y al inicio de cualquier proyecto el negocio es capaz de clasificar la información que será tratada, el proceso de análisis de requerimientos de seguridad se simplificará enormemente, puesto que el nivel de clasificación prescribirá directamente los requerimientos de seguridad a aplicar.
De todo ello se deduce que es preciso formar al personal en la política de clasificación. No será preciso que todo el personal conozca al detalle toda la política, sino que todo el mundo deberá conocer su existencia y, dependiendo de la tarea que desempeñe dentro de la compañía, deberá ser formado en aquellas partes de la política que le afecten: los responsables funcionales en los criterios de clasificación/reclasificación, los técnicos de sistemas en los controles de seguridad a aplicar en la operación de sistemas, los jefes de proyectos de desarrollo en todos aquellos controles a tener en cuenta desde un inicio, etc.
El personal en general juega también un papel muy importante a la hora de aplicar determinados controles durante el tratamiento de la información. Por este motivo es habitual y muy recomendable publicar una norma sobre los usos permitidos de la información durante su tratamiento y las medidas de seguridad a aplicar en cada caso.
Ejemplo
Un resumen de este tipo de norma podría recogerse en una tabla de estas características:

Pública

Interna

Confidencial

Papel

Electrónico

Papel

Electrónico

Papel

Electrónico

Etiquetado

Sí

Sí

Sin requerimientos

Sin requerimientos

Sí, con lista de distrib.

Sí, con lista de distribución

Impresión

n/a

Sí

n/a

Sí

n/a

Con control de acceso a la impresora

Archivo (medios fijos)

Sin restricciones

Sin restricciones

Sí

Fuera del alcance de personas ajenas al dept.

Control de acceso

Protegido con llave

Control de acceso
Otros tipos de tratamiento para los cuales establecer los controles a aplicar podrían ser:

  • Archivo (medios extraíbles / portátiles)

  • Copias

  • Transmisión (por fax, por correo postal, por correo ordinario, conversaciones...)

  • Eliminación/borrado/destrucción

  • Acceso (concesión de privilegios de acceso)

  • Divulgación a terceros

  • Trazabilidad

  • Reclasificación

5.Herramientas para un SGSI

Actualmente existen en el mercado diversas herramientas que dan soporte a la implantación de un SGSI.
Generalmente son herramientas web, muy ergonómicas y de fácil navegación, cuyo objetivo final y punto en común es conocer cuál es el estado de la organización respecto del cumplimiento de los controles de la ISO, por lo que todas ellas ofrecen el listado de controles, con opciones de entrada de información para determinar el grado de adaptación, generar informes, etc.
Dependiendo de la herramienta, se ofrecen otras funcionalidades muy orientadas a dar soporte a la implantación del SGSI:

  • Inventario de activos.

  • Análisis de riesgos.

  • Elaboración del plan de seguridad o plan de gestión del riesgo.

  • Seguimiento de planes de acción.

  • Realización de auditorías.

  • Seguimiento de no conformidades.

  • Gestor documental.

  • Flujos de asignación de tareas.

  • Gestión de incidencias.

La selección de una herramienta es una tarea que no se puede realizar con prisas, puesto que hay que seleccionar la herramienta que mejor encaje en la manera de hacer de la organización, teniendo en cuenta aspectos como la estructura de la organización de la seguridad, el nivel de madurez de la seguridad de la información, los recursos disponibles para la actualización y mantenimiento de la misma, la implicación que de otras figuras de la organización la herramienta pueda requerir, etc.
De hecho, si tenemos la posibilidad de empezar la implantación del SGSI por un alcance acotado y reducido, y no existen requerimientos temporales apretados para obtener la certificación, lo más recomendable es empezar sin herramientas, o mejor dicho, confeccionar herramientas sencillas a partir de herramientas ofimáticas. Ello nos permitirá pasar por una primera iteración del SGSI y tener más claro qué esperamos y qué no esperamos de una herramienta.
En cualquier caso, antes de iniciar la selección de una herramienta, es recomendable realizar una pequeña prospección de mercado para saber qué hay en el mercado y en qué horquilla de presupuesto se mueven este tipo de herramientas, con el objetivo de poder presentar el proyecto a Dirección y obtener su visto bueno al proceso de selección de la herramienta.
A continuación se presenta un conjunto de recomendaciones a tener en cuenta a la hora de seleccionar una herramienta, que de hecho son válidas para cualquier tipo de herramienta.

5.1.Antes de ver las herramientas

  • Definir los objetivos que se espera cubrir con la herramienta antes de empezar a ver proveedores y, si es posible, ponerlos por escrito y según una lista priorizada.

  • Tener muy claro cuáles son las normas a las cuales se quiere dar cobertura con la herramienta. Por poner algunos ejemplos: SGSI, LOPD, plan de continuidad de negocio (ISO 2230).

  • Tener en cuenta, si ya se dispone de otras herramientas (de análisis de riesgos, de auditoría, de inventario de activos, de gestión de incidencias...), la capacidad de integración con las mismas, para evitar tener que entrar la información por duplicado.

5.2.Durante la revisión de herramientas disponibles

  • Entender todas las funcionalidades que ofrece la herramienta, y analizar de cuáles de ellas se va a sacar rendimiento y cuáles no van a ser utilizadas.

  • Verificar con el proveedor el nivel de cobertura de cada uno de los objetivos de nuestra lista.

  • Verificar la cobertura de todas las normas a controlar y, en caso de fallo de alguna de ellas, flexibilidad de las herramientas para introducir otros marcos normativos, o modificar los actuales. Este aspecto es especialmente importante en caso de que la herramienta sea extranjera, puesto que la legislación varía de uno a otro país.

  • Solicitar una demostración a partir de un caso práctico, a ser posible, planteado por la propia organización, e implicar, cuando sea posible, a todas aquellas personas que deberán ser usuarias de la herramienta.

  • No olvidar preguntar los requerimientos de plataforma y software (frecuentemente estas herramientas se apoyan sobre bases de datos que requieren de licencia no incluida en el precio de la herramienta).

  • Clarificar las posibilidades de alojamiento de la herramienta (en recursos propios, o bien en recursos del propio proveedor).

  • En función del tamaño de la organización, sondear diferentes alternativas de licenciamiento, en función de lo que resulte más beneficioso para la organización (por usuario, por compañía, tarifa plana, escalado...).

  • Entender el grado de escalabilidad de la herramienta (posibilidad de iniciar su implantación en una empresa del grupo por ejemplo, para ir posteriormente introduciéndola en otras empresas).

  • Entender claramente qué entra y qué no entra en el precio (adaptaciones, configuración y formación inicial...), así como el precio del mantenimiento de las licencias en años posteriores.

5.3.Otras recomendaciones

Por último, es recomendable huir de nuevos desarrollos o herramientas muy recientemente sacadas al mercado; suficientemente compleja es la implementación de un SGSI, como para tener que hacer de "beta tester" de nuevas herramientas.
Como conclusión se podría decir que una herramienta es un soporte muy potente a la implantación del SGSI, siempre y cuando se tenga muy claro qué es lo que se espera obtener de ella, puesto que de esta forma la herramienta estará al servicio de nuestra organización y no nuestra organización al servicio de la herramienta.

6.Certificación del SGSI

La obtención del certificado del SGSI es una decisión propia de cada compañía. Entre otros, los motivos para obtenerlo pueden ser comerciales y de imagen, para mejorar la confianza de los clientes en la compañía, o bien pueden ser simplemente porque la compañía opta por imponerse internamente la obligación de mantener una buena gestión de la seguridad de la información, a través de auditorías externas periódicas.

6.1.El proceso de certificación

Toda auditoría de certificación consta de las siguientes etapas:
Pasos de la auditoría de certificación del SGSI
Pasos de la auditoría de certificación del SGSI
En una auditoría de certificación no se auditan la totalidad de los controles recogidos en la declaración de aplicabilidad de la compañía, sino que se realiza una auditoría por muestreo, seleccionando alrededor de un 30% de los controles que son de aplicación.
Una vez obtenido el certificado, se debe realizar anualmente una auditoría de revisión de cumplimiento del SGSI, de modo que cada tres años se debe haber realizado una revisión completa de los controles, y se renueva la certificación, siempre y cuando no se hayan producido cambios importantes en el SGSI (por ejemplo, la modificación del alcance), en cuyo caso puede ser necesario volver a iniciar el proceso de certificación.
Por tanto, en ciclos de tres años se debe realizar una auditoría total para:

  • Verificar que todos los elementos del SGSI interactúan entre ellos adecuadamente.

  • Comprobar que el SGSI sigue siendo efectivo tras los cambios en las operaciones de la organización.

  • Corroborar el compromiso de la organización por mantener la efectividad del SGSI.

En las auditorías de revisión, la entidad certificadora comprueba que la compañía esté realizando un buen uso del certificado; no hacerlo puede suponer la retirada de la certificación a la compañía.

6.2.Características de la auditoría

Una auditoría de certificación de la norma ISO 27001 cumple con las características de toda auditoría. Se exponen a continuación algunas cuestiones más específicas:

  • Para poder solicitar una auditoría, es requisito previo que el solicitante acredite que:

    • Existe el proceso de revisión interna del SGSI y que está planificado.

    • El SGSI está operativo.

    • Los procedimientos están implantados.

    • Existen registros que lo evidencien (habitualmente se requiere de un mínimo de 6 meses de registros).

  • Es posible auditar el SGSI de forma conjunta con otros sistemas de gestión, como por ejemplo un sistema de gestión de la calidad, o un sistema de gestión de la continuidad del negocio (SGCN).

  • Para la realización de la auditoría, el equipo auditor se centra en:

    • El análisis de riesgos: cómo la compañía analiza sus riesgos y el criterio empleado para determinar si un riesgo es o no significativo.

    • La declaración de aplicabilidad.

    • Los objetivos que persigue la organización.

    • Cómo se monitoriza y mide.

    • Cómo se informa y mejora.

    • Las revisiones realizadas sobre el SGSI.

    • El grado de implicación de la Dirección de la compañía.

    • La coherencia entre la política, el análisis de riesgos, los objetivos, responsabilidades, normas, procedimientos, datos de indicadores, revisiones realizadas y criticidad de la información afectada.

  • El equipo auditor no decide si la compañía debe recibir o no la certificación una vez finalizada la auditoría, sino que lo hace un Comité de Certificación constituido por miembros de la entidad certificadora, entre los cuales no consta ningún miembro del equipo de auditoría.

El Comité de Certificación toma una decisión a partir de:

  • Una explicación de la auditoría, incluyendo un resumen de la revisión documental.

  • El resultado de la evaluación del análisis de riesgos.

  • La gravedad de las no conformidades detectadas.

  • La recomendación del equipo de auditoría.

  • La resolución de no conformidades detectadas en auditorías anteriores.

No conformidad
La ausencia o fallo en la implantación o el mantenimiento de uno o más elementos requeridos por el sistema de gestión, o bien una situación que, basándose en evidencias objetivas, puede suponer una duda razonable sobre la capacidad del SGSI para cubrir los objetivos de seguridad de la compañía o cumplir la política.
Una no conformidad puede ser relativa a la política de seguridad, al estándar de gestión de seguridad de la información, a procedimientos o a requerimientos legales. Se identifican tres tipos de no conformidades, según la criticidad del incumplimiento: no conformidad mayor, no conformidad menor y observaciones. Generalmente se considera no conformidad mayor la ausencia de cualquiera de los controles esenciales que determina la ISO27002. Algunos ejemplos de no conformidad mayor son: ausencia del análisis de riesgos, ausencia de un sistema de gestión de incidentes, ausencia de un plan de continuidad de negocio, ausencia de procedimientos para la gestión de registros, cambios en el SGSI sin aprobación formal, incumplimiento reiterado de un procedimiento, un número elevado de no conformidades sobre una misma sección de la norma o un mismo departamento, etc.

6.3.La auditoría documental

La auditoría documental que se realiza generalmente en las oficinas de la entidad certificadora, consiste en:
Los pasos de la auditoría documental
Los pasos de la auditoría documental

6.4.El plan de auditoría

Una vez finalizada la auditoría documental, y comprobado que la auditoría puede proseguir, el equipo auditor elabora y presenta un plan de auditoría.
El plan de auditoría:

  • Incluye el alcance y objetivo de la auditoría.

  • Identifica requerimientos especiales.

  • Determina la duración y los recursos necesarios tanto por parte del equipo auditor, como por el conjunto de personas de la compañía que deberán atender la auditoría.

  • Selecciona el equipo de auditoría.

  • Incluye una relación de la documentación enviada en la auditoría documental a la entidad certificadora.

  • Establece la muestra de controles que se auditará, para lo cual se da prioridad a las áreas de mayor riesgo, incluyendo:

    • Todos los controles esenciales.

    • Controles que afecten a las actividades más importantes de la compañía.

    • Controles de todas las secciones de la norma.

    • Controles de forma que se auditen todos los departamentos de la compañía involucrados en el SGSI.

    • No conformidades detectadas en auditorías anteriores.

  • Presenta la agenda de las reuniones.

  • Informa sobre el contenido y estructura de los informes que se entregarán al finalizar la auditoría.

6.5.Auditoría in situ

Entre la auditoría documental y la auditoría in situ transcurren de 3 a 6 semanas. La auditoría in situ se realiza en las instalaciones de la entidad que solicita la certificación.
Los objetivos de esta fase de la auditoría son:

  • Confirmar que la compañía solicitante cumple con sus políticas y procedimientos.

  • Comprobar que el SGSI desarrollado es conforme con las especificaciones de la norma que se va a certificar.

  • Verificar que el SGSI está logrando los objetivos que la compañía se marcó.

La auditoría in situ comprende las siguientes actividades:
Los pasos de la auditoría in situ
Los pasos de la auditoría in situ

6.6.El informe de auditoría

El informe de auditoría, que elabora el equipo auditor una vez finalizada la auditoría in situ, incluye como mínimo:

  • Fecha de la auditoría.

  • Equipo auditor.

  • Identificación de la compañía solicitante de la certificación.

  • El alcance y la norma de referencia.

  • Conformidad del SGSI con la norma.

  • No conformidades detectadas.

6.7.Obtención de la certificación

Si la compañía corrige o presenta un plan de corrección de las no conformidades reportadas en el informe de auditoría, la entidad certificadora procederá a emitir el certificado (carta o diploma), que como mínimo incluirá:

  • Nombre y dirección de la organización certificada.

  • Alcance de la certificación.

  • Fecha de emisión del certificado y período de validez.

  • Versión de la declaración de aplicabilidad.

Resumen

En este módulo se han recogido algunas pautas para el desarrollo de algunos de los objetivos de control de todo SGSI.
En primer lugar, se ha abordado la creación del marco normativo de seguridad de la información, describiendo cuál debe ser su estructura y, sobre todo, cuál es el proceso de creación y mantenimiento de estándares, válido para cualquier ámbito y no sólo el de seguridad de la información. Se ha dedicado especial atención a la forma y contenido de la política de seguridad de la información, puesto que constituye la base de todo SGSI.
Otro de los pilares básicos del SGSI se centra en la organización de la seguridad de la información. En este módulo se ha presentado una propuesta de estructura organizativa, en la que es esencial la implicación de la Dirección, la existencia de un Comité de Seguridad de la Información, con participación de diversas áreas de la compañía, y la figura de un responsable de seguridad de la información. Para todos ellos se han especificado cuáles son sus funciones en materia de seguridad de la información, lo cual se ha extendido a las diferentes áreas de la compañía, y al personal en general, puesto que no se puede concebir un sistema de gestión de la seguridad de la información si ésta no forma parte del día a día de toda la organización.
También se ha dedicado un apartado a hablar del proceso de clasificación de la información, que constituye el primer paso para determinar cuán importante es una información para la compañía, lo cual permitirá definir las medidas de seguridad a aplicar en cada caso, dedicando mayores esfuerzos a la protección de aquella información de mayor valor para el negocio.
Finalmente, se ha descrito someramente el proceso de certificación en la ISO 27.001 y los pasos de una auditoría de certificación, dos cuestiones que una persona orientada a la gestión de la seguridad de la información no puede dejar de conocer.