Hacer del SoA una herramienta de gobernanza de la seguridad de la información

Autor: Daniel Gnana, CISA, ISO/IEC 27001:2013 LA, PRINCE2
Fecha de Publicación: 1 March 2018
English

La Organización Internacional de Normalización (ISO) y la norma ISO/IEC 27001: 2013 de la Comisión Electrotécnica Internacional (IEC) han definido los requisitos para un sistema de gestión de seguridad de la información (ISMS). Un ISMS abarca simultáneamente la administración de seguridad de TI y excede los límites estrictos de la infraestructura de TI y el software. De hecho, un ISMS abarca todas las actividades de una organización. Amplía la vista de seguridad a todos los activos, incluidos los activos físicos (por ejemplo, documentos, locales, oficinas) y activos humanos (por ejemplo, empleados, contratistas, proveedores).

Ampliar la vista permite que la organización vea el verdadero estado de todos los activos. Tanto los activos físicos como los humanos pueden albergar, reflejar o transmitir información sensible que puede suponer un riesgo estratégico, reputacional, regulatorio o financiero si se pierde, se deforma, viola o filtra.

Para garantizar el conocimiento de cada aspecto de seguridad de la información, un SGSI requiere que cualquier organización se centre en 14 objetivos de control, que se enumeran en la figura 1. La numeración en la figura 1 comienza en 5, de modo que cada número objetivo de control se alinea con el capítulo ISO relacionado.

Presentando el SoA

La norma ISO/IEC 27001: 2013 revela la Declaración de Aplicabilidad (SoA) como un requisito relacionado con el tratamiento del riesgo de seguridad de la información. Establece, “Produce una declaración de aplicabilidad que contiene los controles necesarios y la justificación para las inclusiones, ya sea que se implementen o no, y la justificación de las exclusiones de los controles”.1

La explicación proporcionada en el estándar, muestra cómo un SoA vincula estrechamente la evaluación de riesgos y el tratamiento de riesgos. Dicho esto, detallar tal enlace supone que la organización previamente realizó una evaluación de riesgos y es consciente de las actuales apuestas, vulnerabilidades y contramedidas actuales disponibles.

Como un SoA cubre 14 temas, como se mencionó anteriormente, se supone indirectamente que la evaluación de riesgos incluye estos temas. Una vez más, esto se aplica a algo más que el reino de TI.

¿Que es lo que sigue? Sorprendentemente, el SoA solo se menciona una vez en la norma ISO/IEC 27001: 2013, lo que conduce a un malentendido frecuente de que el SoA es un documento complementario implementado solo para cumplir con el estándar y nada más.

¿Es el SoA una adición trivial en el estándar ISO/IEC 27001: 2013? Ciertamente no. Si una organización desea utilizar los beneficios reales de la norma ISO/IEC 27001: 2013, que es la de instalar la gobernanza de la seguridad de la información, debe utilizar la SoA en toda su capacidad. El SoA es una herramienta que permite a la alta dirección ver las fortalezas, debilidades y caminos integrales para mitigar el riesgo de información de la organización. Aún más, esta herramienta permite llevar a cabo mejoras de seguimiento para seguridad de información.

Dicho en otros términos, el SoA debe considerarse un instrumento de doble función en lugar de un documento simple. En primer lugar, se puede utilizar como una herramienta de diagnóstico de salud para que la organización proteja su información, y segundo, pilotea los caminos generales para mejorar la salud de la organización.

Decisiones a tomar antes de implementar el SoA

Antes de llevar a cabo el SoA, hay algunas decisiones que la alta gerencia de la organización debe tomar:

  • Confirme el perímetro de la organización—Asegúrese de que el perímetro del SGSI esté bien definido y aprobado por el responsable de la organización como el objetivo para obtener la certificación ISO/IEC 27001: 2013. ¿Qué empresas están interesadas? ¿Hay actividades específicas para enfocarse en esas empresas y, de ser así, en ¿qué países? ¿Quiénes son las partes interesadas?

    Como ejemplo, supongamos que una empresa cuyo negocio principal es proporcionar servicios relacionados con un centro de datos. En tal caso, las preocupaciones principales residen en este perímetro, independientemente de si el la compañía tiene otras oficinas o no. Concretamente, al escanear el SoA, restrinja la seguridad física (tema 11) únicamente al centro de datos.
  • Apunte para un SoA de ganancia rápida— Decide una versión preliminar simple, pero accesible, del SoA en un corto período de tiempo, por ejemplo, dentro de un trimestre. Para cada requisito ISO para mitigar el riesgo de seguridad de la información, esfuércese por obtener primero una idea rápida de las acciones que se llevan a cabo actualmente y que se ajustan a dicho requisito. Obtener una visión rápida de cada uno de los 114 requisitos requiere discernimiento entre completitud y eficiencia. Un SoA desactualizado y obsoleto puede no reflejar la situación actual y no ayuda a la toma de decisiones.
  • Identifique el nivel de empleado apropiado en el cual implementar el SoA—Decidir sobre el perfil del empleado que será capaz de implementar cada medida. Esta función debería poder investigar con suficiente autoridad; aquí están algunas consideraciones a tener en cuenta:
    • Con respecto al perímetro previamente definido, ¿estos objetivos de control (figura 1) y conjunto de medidas son aplicables al SGSI?
    • Después de la investigación, ¿la información obtenida puede considerarse confiable?
    • Según lo calculado, ¿puede la tasa de cobertura de dicha medida considerarse aceptable para la organización, dado el nivel de riesgo?
    • Si la tasa de cobertura es baja y podría requerir un esfuerzo considerable para aumentar la cobertura, ¿puede la organización permitirse permanecer en este punto y aceptar el riesgo?

Evite tener un SoA pequeño sin sustancia o sin resultados confiables. Un SoA ineficaz puede suceder después de asignar a alguien cuya falta de autoridad llevará a ejecutar constantemente después de las respuestas correctas. El SoA es un ejercicio difícil y requiere que la persona que lo realiza tenga suficiente antigüedad y autoridad para determinar quién conoce mejor los controles de seguridad de la empresa. La autoridad y la antigüedad también son importantes para convencer a las personas entrevistadas de cooperar para ayudar a la persona que realiza el SoA a determinar el nivel de fiabilidad y completitud de cada respuesta.

Implementando el SoA

Una vez completados los pasos preliminares mencionados anteriormente, hay tres pasos principales para construir un SoA realista y efectivo:

  1. Filtre y mantenga solo los objetivos de control y las medidas correspondientes al alcance de la organización—Primero, con respecto a las actividades de la organización que aspiran a cumplir con el Norma ISO/IEC 27001: 2013, seleccione cada objetivo de control y cada conjunto de medidas que aborden el alcance; consecuentemente, ignorar cualquier objetivo y conjunto de medidas que caigan fuera del alcance, es decir, aquellas que no son aplicables a la organización.

    Por ejemplo, considere una empresa subsidiaria en la que el departamento de recursos humanos (RRHH) de la sede gestiona las relaciones con los proveedores. En tal caso, el objetivo 15, “relaciones con los proveedores”, puede estar fuera del alcance de esa organización, lo que la hace inaplicable en el contexto organizacional.

    Sin embargo, existen objetivos de control (CO) que se ejecutan como constantes universales que son aplicables a cualquier organización:
    • CO 5 (Políticas de seguridad de la información)
    • CO 6 (Organización de seguridad de la información)
    • CO 7 (Seguridad de los recursos humanos)
    • CO 8 (Gestión de activos)
    Una lectura cuidadosa de la norma ISO/IEC 27001: 2013 ayuda a aclarar que los objetivos de control mencionados anteriormente son obligatorios. De hecho, cualquier organización que tenga como objetivo un estándar de este tipo tiene que corregir al menos un nivel alto política de seguridad de la información y un conjunto de responsabilidades para controlar su aplicación en toda la organización. Cualquier organización tiene que gestionar los activos y las partes interesadas; por lo tanto, es necesario identificarlos.
  2. Con la ayuda de los resultados de la evaluación de riesgos, arroje luz sobre las prioridades relacionadas con cada conjunto de medidas—Para poder determinar las respuestas mínimas que se correlacionan con cada conjunto de medidas del SoA, vale la pena analizar la evaluación del riesgo a nivel de la organización y clasificar las prioridades correspondientes (por ejemplo, 1 = bajo riesgo, baja prioridad, 2 = riesgo medio, prioridad media; 3 = alto riesgo, alta prioridad) para pesar cada medida.

    Evite esperar hasta que se complete la evaluación de riesgos perfecta. La perfección es un señuelo y un obstáculo en contra de una exploración rápida exitosa del SoA. Más bien, desarrolle una primera versión considerando qué objetivo de control considera la organización sea un riesgo importante. Si la empresa retoma el ejercicio nuevamente, la segunda versión puede ampliar el alcance de la evaluación de riesgos.
  3. Para cada medida que se considere aplicable a la organización, descríbalo para comprender cómo hasta ahora, la medida se aplica actualmente—Las siguientes pautas están elaboradas con ejemplos extraídos del SoA de una empresa subsidiaria, tema 7, “seguridad de los recursos humanos”, dominio 7.1, “requisito previo al empleo”, requisito 7.1.1., “Examen de antecedentes de los candidatos”. El propósito de estos extractos es proporcionar una visión concreta de qué acciones son posibles. Cada medida aplicable se divide en cinco elementos de la siguiente manera:
    • Alcance de responsabilidades En este contexto subsidiario, dos tipos de responsabilidades son considerado:
      • El departamento de recursos humanos es responsable de contratar personal para contratos fijos o de largo plazo; la investigación de antecedentes del candidato es responsabilidad del departamento de recursos humanos.
      • Cualquier departamento, incluido HR, que esté dispuesto a contratar subcontratistas es responsable de verificar los antecedentes de un candidato.
    • Rechazar el requisito ISO/IEC 27001: 2013 en el contexto organizacional dado el alcance; declinando uno o más artículos para venir después:
      • Requisito 1 (responsabilidad del departamento de recursos humanos)— Antes de contratar personal, se realizarán las siguientes verificaciones para los candidatos considerados: control de identidad, antecedentes penales, educación, credenciales profesionales y contacto de antiguos empleadores.
      • Requisito 2 (responsabilidad de todos los departamentos)—Antes de contratar subcontratistas, las mismas verificaciones mencionadas anteriormente deberían de ser realizado.
    • Examinar cuánto está cumpliendo la organización en cuestión con los requisitos anteriores:
      • Cumplimiento con el requisito 1: 1 (cumplimiento total)
      • Cumplimiento con el requisito 2: 0, 2 la organización ha manejado la verificación personal de los proveedores de los subcontratistas; sin embargo, la organización nunca verifica la realidad y la integridad de dicha verificación.
    • Cálculo de una tasa de cobertura de requisitos:
      • En el contexto de la organización, la tasa de cobertura es del 60 por ciento (Σcumplimientos = 1,2/ΣRequisitos = 2).
    • Mejoras de decisión y fecha límite:
      • Mejoras—primero, la organización debe indicar a sus proveedores qué objetivos de control son requeridos (por ejemplo, identidad, educación, credenciales, referencias). En segundo lugar, la organización debe exigir a los proveedores de sus subcontratistas que proporcionen su documentación del proceso de verificación para garantizar que cumple con los objetivos de control mencionados anteriormente. En tercer lugar, la organización tomará control periódico de la evidencia de verificación del proveedor.
      • Fecha límite—primer trimestre del 2018.

Sirviendo la gobernanza de la seguridad de la información

Por su naturaleza muy detallada, el SoA, con sus 114 medidas que cubren 14 objetivos de control, no puede ser razonablemente entregado para reuniones de gobierno.

Sin embargo, el SoA se convierte en una mina de oro para una síntesis de las debilidades y caminos para lograr objetivos de control. Las Figuras 2 y 3 ayudan a mostrar las posibilidades de síntesis de tasas de cobertura y decisiones. La figura 2 proporciona un ejemplo de mapeo de la tasa de cobertura con cada medida de objetivo de control 7, seguridad de recursos humanos.

La figura 2 muestra que cuando se trata de seguridad de recursos humanos, la organización de muestra aún no ha proporcionado una respuesta adecuada al requisito 7.2.1 Gestión de responsabilidades, que muy probablemente sea un obstáculo para fortalecer las otras medidas relacionadas con los recursos humanos.

Por extensión, dicha síntesis puede aplicarse a otros objetivos de control y proporcionar una visión general de las áreas de riesgo relacionadas con la información y, en consecuencia, puede ayudar a determinar la estrategia de mitigación de riesgos para toda la organización.

La figura 3 ilustra un área específica de preocupación: ¿Cuál es el próximo paso después de evaluar una tasa de cobertura como no satisfactoria? En el ejemplo que se muestra, hay 32 medidas que no están suficientemente cubiertas, de las cuales siete medidas no requerirán acción adicional. Este tipo de decisiones se toman considerando el riesgo residual dada la acción actual con respecto a la medida ISO/IEC 27001: 2013 recomendada. Tal proceso de toma de decisiones no puede llevarse a cabo en la oscuridad; requiere el compromiso de la alta dirección.

Conclusión

Como el SoA es obligatorio, aprovéchelo obteniendo una visión rápida de la cobertura de controles, no solo en el sistema de información, sino también en los eslabones más débiles de la cadena de seguridad, como algunos departamentos que se preocupan menos por TI. Obtener una visión rápida ayuda a una empresa a establecer medidas rápidas y eficientes para mitigar los principales factores de riesgo. Toda esta información ayuda a alcanzar el objetivo final de proporcionar a la alta gerencia una garantía razonable de la idoneidad, idoneidad y efectividad continuas de su SGSI.

Notas finales

1 International Organization for Standardization, ISO 27001:2013, subclause 6.1.3, d), https://www.iso.org/isoiec-27001-information-security.html

Daniel Gnana, CISA, ISO/IEC 27001:2013 LA, PRINCE2
Es el fundador de ISO27K Audit Consulting. Tiene más de 20 años de experiencia en TI, incluida la auditoría y la gobernanza de seguridad. También ofrece cursos de capacitación en auditoría, y ayuda a los proveedores de TI en su viaje para obtener la certificación ISO/IEC 27001: 2013. Él puede ser contactado en danielgnana@gmail.com.