Tinfoleak v2.3

Tinfoleak v2.3tinfoleak es una herramienta open-source catalogada dentro de las disciplinas OSINT (Open Source Intelligence) y SOCMINT (Social Media Intelligence) que automatiza la extracción de información de Twitter y facilita su análisis posterior para la generación de inteligencia.

Tomando como entrada un identificador de usuario, unas coordenadas geográficas o palabras clave, tinfoleak analiza el timeline de Twitter para extraer grandes volúmenes de datos y mostrar información útil y estructuradas para el analista de inteligencia.

Tinfoleak está incluida en múltiples distribuciones Linux: Kali1, CAINE2, BlackArch3 y Buscador4. Actualmente, es la herramienta open-source más completa para el análisis de inteligencia en Twitter.

Tinfoleak está publicada bajo la licencia CC-BY-SA-4.05.

Tinfoleak puede extraer la siguiente información:

• Información sobre la cuenta de un usuario
• Actividad de un usuario
• Información sobre cuentas protegidas
• Aplicaciones desde las que se publica contenido
• Dispositivos utilizados para publicar contenido
• Frecuencia de uso de las aplicaciones y dispositivos utilizados para publicar contenido
• Información sobre hashtags utilizados por los usuarios
• Información sobre menciones realizadas por los usuarios
• Información sobre “likes” realizados por los usuarios
• Análisis y búsquedas sobre el contenido publicado
• Frecuencia de palabras más utilizadas por los usuarios
• Información y descarga de contenido multimedia
• Información sobre metadatos asociados al contenido multimedia
• Lugares visitados por los usuarios
• Rutas seguidas por los usuarios y duración de la estancia en cada ubicación
• Lugares más visitados por los usuarios
• Obtención de identidades digitales de los usuarios en otras redes sociales
• Información sobre usuarios geolocalizados
• Información sobre usuarios etiquetados en fotografías
• Información sobre seguidores en Twitter
• Información sobre amigos en Twitter
• Información sobre listas creadas por un usuario o listas donde se han incluido al usuario
• Información sobre colecciones creadas por los usuarios
• Extracción de conversaciones entre usuarios

Nueva versión: tinfoleak v2.3

Como novedades, esta versión incorpora las siguientes funcionalidades:

  • Extracción de información de cuentas protegidas en Twitter (parámetro “—pro”)
Identificación de cuenta protegida:


Extracción de seguidores:


Extracción de amigos y tuits:

  • Análisis de listas creadas por un usuario o listas donde se han incluido al usuario (parámetro “-l” o “—lists”)

Listas donde se ha incluido al usuario analizado: 

  • Análisis de colecciones creadas por un usuario (parámetro “-c” o “—collections”)

Colecciones creadas por el usuario analizado:

  • Análisis de la actividad de un usuario (parámetro “-a”)

  • Incorporación de gráficas para complementar los resultados
Asimismo, se han incluido otros cambios menores:
  • Nuevo atributo añadido a la búsqueda de contenido en tweets (parámetro “—find”)
    permite analizar contenido filtrando por nombre de aplicaciones
  • Se han incluido ejemplos de uso de los parámetros en la página de ayuda (parámetro “-h”)
  • Se han incluido ejemplos de objetivo de análisis en la ejecución de tinfoleak sin parámetros
  • Mejoras en el informe HTML
  • Solución de fallos
Tinfoleak v2.3 puede descargarse desde el repositorio de Github:
Referencias:

1- Kali Linux: https://www.kali.org/

Vicente Aguilera participará en CONAND - Andorra

El próximo miércoles 7 de febrero Vicente participará en la mesa redonda: Ciberterrorismo, en el evento CONAND que se llevará a cabo en Andorra.

Moderador:
o César Marquina. CSO (Andorra Telecom).

Participantes:
o Maria Àngels Moreno Aguirre. Jueza del Principado de Andorra
o Carlos Fragoso. Digital Forensincs, Incident Response / CyberThreat Intelligence (One eSecurity)
o Vicente Aguilera
o Javier Ignacio Zaragoza Tejada. Fiscal de la Fiscalía Provincial de San Sebastián

Y el jueves 8 de febrero, presentará su ponencia: “Presente y futuro del ciberterrorismo”

Descripción de la conferencia:

La evolución de la tecnología comporta, inherentemente, su abuso con múltiples finalidades. La presentación tratará el incremento en la dependencia de la tecnología y las motivaciones por parte de los cibercriminales. ¿Cómo afecta el ciberterrorismo a la sociedad actual? ¿Cómo será su evolución e impacto en paralelo con la evolución de la tecnología? ¿De qué manera los gobiernos y la sociedad en su conjunto se están preparando ante las nuevas ciberamenazas? Estas y otras cuestiones serán tratadas durante la exposición.

Para más información sobre el evento:
https://conand.ad/

Nuevo plazo para registrar las bases de datos personales en Colombia

El 18 de enero se publicó un nuevo decreto en relación con el registro de las bases de datos personales ante la Superintendencia de Industria y Comercio, este es el Decreto 090 del 18 de enero de 2018, por el cual se modifican los artículos 2.2.2.26.1.2 y 2.2.2.26.3.1 del Decreto 1074 de 2015 – Decreto Único Reglamentario del Sector Comercio Industria y Turismo.

Dentro de las consideraciones existe una que se había anticipado en un artículo anterior: seguimos con un porcentaje de responsables que han hecho su registro menor al 25% (misma cifra argumentada los decretos anteriores), es decir, volvemos a la alarmante conclusión de que la Superintendencia no ha cumplido con su labor de socialización y divulgación de acuerdo al mandato de ley y, teniendo en cuenta que este es el tercer aplazamiento, se puede prever que exista un cuarto o quinto ya que no se ven intenciones de parte de la Superintendencia por cambiar o mejorar los programas de difusión que, por lo visto, tampoco están siendo monitoreadas por los entes de control.

Ahora, para hacer que el universo de aplicación de la obligación de registro y vigilancia se vea más pequeño y poder mostrar un cumplimiento más grande, además, enmascarándolo con la campaña anti-trámites (ver imagen tomada de www.sic.gov.co), se ha decidido exonerar del registro a algunos tipos de entidades. Con esto la Superintendencia presentará un porcentaje de cumplimiento de registro de base de datos significativamente mayor al 25% sin haber realizado una gestión diferente (y probablemente sin aumentar el número de bases de datos registradas). Desafortunadamente a día de hoy la SIC1 no ha dado cifras sobre el número de empresas que han registrado sus bases de datos, desagregando esta información en los rangos o criterios que hoy está usando para hacer la reducción del universo, ni está dando la magnitud de cada uno de los rangos. La no publicación de estas cifras nos hace presumir que los porcentajes de declaración de bases de datos que se publicarán en próximas fechas estén desvirtuados por el hecho que el universo de afectados por la obligatoriedad de registro se haya reducido drásticamente, y no tanto por la cantidad de registros realizados, por lo que el factor determinante para hacer subir los porcentajes de declarantes no será que las declaraciones se hayan realmente incrementado de un día para otro tras la publicación de este nuevo decreto.

Para hacer la reducción del universo se usan algunos criterios de definición de micro, pequeña y mediana empresa que vienen de la Ley 905 de 2004, estos son:
  • Mediana empresa: activos totales entre 100.000 y 610.000 UVTs2 .
  • Pequeña empresa: activos totales entre 501 y 5.000 SMMLV3.
  • Microempresa: activos totales menores a 500 SMMLV.


De acuerdo con el nuevo decreto, serán objeto de inscripción en el Registro Nacional de Bases de Datos, aquellas empresas que son responsables y caigan dentro una de las siguientes características:
  • Sociedades y entidades sin ánimo de lucro con activos superiores a 100.000 UVTs.
  • Personas jurídicas de naturaleza pública.
Y los plazos se ajustan así:
  • 30 de septiembre de 2018: Sociedades y entidades sin ánimo de lucro con activos superiores a 610.000 UVTs.
  • 30 de noviembre de 2018: Sociedades y entidades sin ánimo de lucro con activos totales entre 100.000 y 610.000 UVTs.
  • 31 de enero de 2019: Personas jurídicas de naturaleza pública.
Afortunadamente, encontramos que se mantiene la obligación de cumplir la norma en cuanto al programa de protección de datos personales para todos y que está obligación está vigente desde el momento de la expedición del Decreto 1377 del 27 de junio de 2013. Lo único que se le quitó a las pequeñas y micro empresas fue la obligación de registrar las bases de datos en el RNBD4.

El problema más grande de este planteamiento es que, bajo el criterio de reducir el alcance de vigilancia, se deja de lado el monitoreo de las empresas donde suele haber un mayor desorden y disciplina en el manejo de las bases de datos personales y donde existe una menor cantidad de recursos para llevar el control de estos datos, esto también puede estar excluyendo de declarar a empresas que tienen el manejo de información bastante sensible como por ejemplo datos médicos, información de menores, datos socio-económicos, información sobre raza, religión, situación de desplazamiento, entre otros. Un ejemplo de esta situación se puede ver en la Resolución 13790 de 20165 de la SIC, donde podemos ver que no es un caso hipotético sino un evento de la realidad Colombiana que ya ha sido sancionado; en caso de una brecha en una entidad de este tipo se puede afectar de manera importante a las personas; igualmente, se deja de lado el criterio del volumen de las bases de datos, que podría ser un factor determinante a la hora de tener que hacer el registro de las bases de datos, porque es un hecho que una empresa pequeña puede tener a su cargo cientos de miles de registros, un ejemplo notable es la sanción definida en la Resolución 15339 de 20166 de la SIC. Ahora, como no hay que registrar las bases de datos en muchas empresas ¿Quién va a proteger los derechos de los ciudadanos en referencia al manejo de bases de datos personales y la Superintendencia busca reducir su tarea?

Por otro lado, debemos revisitar el tema de que si los obligados a reportar mantienen la indisciplina y el Gobierno, a través de sus organismos, no obliga al cumplimiento y continúa dando plazos de manera indefinida, seguirá deslegitimando el proceso y devaluando un trabajo que le ha costado mucho esfuerzo al mismo Gobierno para lograr la protección de la información de sus ciudadanos.

Una nota para pensar: tantos aplazamientos pueden significar una falta de visión, un análisis pobre de las causas de los incumplimientos y una planeación inadecuada por parte del Superintendente, ya que la reducción del universo y una ampliación de plazo no va a asegurar que al final del ciclo se logre el objetivo, es necesario plantear estrategias y definir mecanismos que garanticen que el cumplimiento de la norma será efectivo y generará sanciones a quienes no lo hagan.

Volvemos a tener un decreto que se queda corto porque no le da a la Superintendencia herramientas adicionales para mejorar las capacidades de “divulgación y socialización”, y si a la fecha después de dos aplazamientos, estando a punto de culminar el segundo plazo, tenemos que menos del 25% de los responsables han hecho la tarea, ¿Qué hace pensar que en 8 meses lo hará el 75% faltante si la ampliación anterior fue similar y no se logró el propósito?.

A la fecha no se ha visto que la Superintendencia esté cambiando sus mecanismos de difusión, ni que facilite la implementación con recursos adicionales, como, por ejemplo, ofrecer herramientas, plantillas, guías y ejemplos específicos a aquellas empresas que por su tamaño no tienen la capacidad para hacer un análisis juicioso sobre el estado de la protección de datos al interior de las empresas.

Para mayor información sobre el decreto y el proceso de registro de bases de datos visitar la página de la Superintendencia de Industria y Comercio: http://www.sic.gov.co/gobierno-nacional-reduce-universo-de-obligados-a-cumplir-el-registro-de-bases-de-datos-ante-superintendencia-de-industria-y-comercio.

Autor:  Javier Roberto Amaya Madrid
 CISM, ISO 27001 LA, PCI QSA, PCI PCIP
            Dpto. Consultoría 

Vicente Aguilera ponente en CIBERSEG 2018 - Madrid

El próximo jueves 25 de enero en la Universidad de Alcalá, se realizarán las V Jornadas de Seguridad y Ciberdefensa organizadas por el grupo de Ingeniería de Servicios Telemáticos del Departamento de Automática, las Cátedra DARS y las Delegaciones de Estudiantes de la Escuela Politécnica Superior. Estas jornadas tienen como objetivo promover temas relacionados la seguridad y la Ciberdefensa en el ámbito universitario.

En esta oportunidad Vicente participará con la conferencia "Usos y abusos de la inteligencia basada en fuentes abiertas"

Descripción de la conferencia:

En el ámbito militar, el valor de la inteligencia es incuestionable. No sólo para conseguir una ventaja frente al enemigo, sino para evitar que este pueda conseguirla sobre nosotros. Los grandes conquistadores de la historia la utilizaron para conseguir sus propósitos y, hoy en día, la inteligencia ha visto renovado y ampliado su valor, aún más si cabe. Las fuentes abiertas han permitido que la generación de inteligencia no sea una actividad exclusiva de unos pocos afortunados, sino que pueda ser explotada por cualquier persona interesada en sus beneficios.

Para más información sobre el evento:
https://ciberseg.uah.es

Vicente Aguilera ponente en Hack & Beers Vol 3 - Barcelona

El próximo viernes 19 de enero después de mucho tiempo vuelve un nuevo Hack&Beers a Barcelona, que se llevará a cabo en las instalaciones de TeatreNeu , con ponencias como:
  • Selva Orejón con "Protección de la identidad digital"
  • Eduardo Sánchez con "Creando un bot de Geolocalización"
En esta oportunidad Vicente Aguilera participará con la ponencia “Nuestra actividad en RRSS: más allá de los datos”

Para más información sobre el evento:
URL: https://www.eventbrite.es/e/entradas-hack-beers-vol-3-barcelona-41852152916

¿Cómo afecta la nueva versión del Top Ten de OWASP el cumplimiento de PCI DSS v3.2?

Dentro de la comunidad de seguridad de la información, el proyecto OWASP (The Open Web Application Security Project - https://www.owasp.org) tiene un amplio reconocimiento debido a sus aportes en pro de la mejora de los controles para la protección de aplicaciones web. Uno de sus proyectos más importantes es el “OWASP Top Ten Project” (https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project), que, de forma periódica, lista los 10 riesgos más críticos en este tipo de aplicaciones. Este listado se establece con base en múltiples propuestas de firmas especializadas en seguridad de aplicaciones y de entrevistas a más de 500 individuos, cuyos datos son seleccionados y priorizados de acuerdo con estimaciones consensuadas de explotabilidad, detectabilidad e impacto, tanto técnico como al negocio. 

Figura 1. Variables para el cálculo del riesgo en aplicaciones (Fuente: OWASP)

La versión más reciente de este listado - OWASP Top 10 2017  https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf - fue publicada el 20 de noviembre de 2017. Esta nueva versión, a diferencia de su predecesora, la versión 2013 (https://www.owasp.org/images/5/5f/OWASP_Top_10_-_2013_Final_-_Espa%C3%B1ol.pdf), ha tenido en cuenta el impacto de nuevas tecnologías en la industria y los cambios de arquitectura en aplicaciones web, tales como el uso de microservicios escritos en node.js y Spring Boot y el uso de marcos de trabajo web basados en JavaScript (Angular, Bootstrap, Electron y React).

De acuerdo con ello, la priorización de riesgos en esta nueva versión 2017 ha quedado de la siguiente manera, en comparación con la versión del 2013:


 Figura 2. Comparativo de los riesgos del OWASP Top Ten de 2013 y de 2017 (Fuente: OWASP)


Como se puede observar, se han priorizado tres nuevos riesgos (A4, A8 y A10), dos han sido fusionados (A4 y A7 del 2013 en el A5 de 2017) y dos han sido retirados (A8 y A10 del 2013) debido al bajo porcentaje de aplicaciones afectadas hoy en día. Todo lo anterior demuestra que, a pesar del gran esfuerzo realizado para la protección de la infraestructura de aplicaciones web, las amenazas constantemente van evolucionando, quizás más rápido que la propia tecnología.

OWASP Top Ten y PCI DSS

Desde sus primeras versiones, PCI DSS siempre citado a la OWASP como referente para la definición de directrices de codificación segura. Por ello, en el requisito 6.5 “Aborde las vulnerabilidades de codificación comunes en los procesos de desarrollo de software” se citan las guías de la OWASP como mejores prácticas de la industria a ser empleadas para estas acciones, en conjunción con las guías del CERT (https://www.cert.org/secure-coding/publications/index.cfm) y del SANS CWE Top 25 (http://cwe.mitre.org/top25/). 

Teniendo en cuenta la dinámica en términos de riesgos en las aplicaciones web, el PCI SSC fue bastante precavido y por ello dejó en claro que, en el caso de actualización de las mejores prácticas de la industria para la gestión de las vulnerabilidades, éstas deberían primar sobre las identificadas por el propio estándar.

Figura 3. Requisito 6.5 de PCI DSS

 Por otro lado, también se deja en claro lo siguiente:

“A medida que cambian las prácticas de codificación segura aceptadas por la industria, las prácticas de codificación de las organizaciones y la capacitación de los desarrolladores se deben actualizar para abordar nuevas amenazas, por ejemplo, ataques para extraer la memoria.

Las vulnerabilidades identificadas en los Requisitos 6.5.1 al 6.5.10 proporcionan un punto de partida mínimo. Es responsabilidad de la organización informarse sobre las últimas tendencias en vulnerabilidades e incorporar las medidas apropiadas en cuanto a las prácticas de codificación segura”.

Las vulnerabilidades descritas en los requisitos 6.5.1 al 6.5.10 de PCI DSS hacen referencia a los controles mínimos que se deben implementar y que las organizaciones deben incorporar dentro de sus prácticas de codificación segura correspondientes a la tecnología particular de su entorno. A continuación, se relacionan dichos requisitos de PCI DSS y su correspondencia con los Top Ten de la OWASP de los años 2013 y 2017:

Req.
Descripción
Referencia en OWASP Top Ten 2013
Referencia en OWASP Top Ten 2017
6.5.1
Errores de inyección, en especial, errores de inyección SQL. También considere los errores de inyección de comandos de OS, LDAP y Xpath, así como otros errores de inyección.
A1:2013
A1:2017
6.5.2
Desbordamiento de buffer
-        
-        
6.5.3
Almacenamiento cifrado inseguro
A6:2013
A3:2017
6.5.4
Comunicaciones inseguras
A6:2013
A3:2017
6.5.5
Manejo inadecuado de errores
A5:2013
A6:2013
A3:2017
A6:2017
6.5.6
Todas las vulnerabilidades de “alto riesgo” detectadas en el proceso de identificación de vulnerabilidades
A9:2013
A9:2017
6.5.7
Lenguaje de comandos entre distintos sitios (XSS)
A3:2013
A7:2017
6.5.8
Control de acceso inapropiado
A4:2013
A7:2013
A10:2013
A5:2017
6.5.9
Falsificación de solicitudes entre distintos sitios (CSRF)
A8:2013
-        
6.5.10
Autenticación y administración de sesión interrumpidas
A2:2013
A2:2017

Como se puede observar, ninguno de los nuevos riesgos incluidos en la versión 2017 del Top Ten de la OWASP es contemplado por PCI DSS v3.2:

  • A4:2017 – XML External Entities (XXE)
  • A8:2017 – Insecure Deserialization
  • A10:2017 – Insufficient Logging & Monitoring
¿Qué implican estos cambios en el cumplimiento de PCI DSS y cómo se debe proceder?

La priorización de nuevos riesgos a nivel de aplicación previamente no cubiertos por PCI DSS, pero identificados actualmente en la última versión del Top Ten de la OWASP, implica que todas las organizaciones que desarrollen aplicaciones de pago para entornos PCI DSS deben proceder de la siguiente manera:
  • Actualizar la documentación vinculada con el SSDLC (Secure Software Development Life Cycle) para que contemplen la totalidad de los riesgos del Top Ten de la OWASP 2017 – Req. 6.3
  • Actualizar los criterios empleados en la revisión de código (ya sea si se realiza manualmente o empleando herramientas automatizadas) antes de enviarlo a Producción para que cubran estos nuevos riesgos – Req. 6.3.2
  • Actualizar el material de formación en desarrollo seguro incluyendo estos nuevos riesgos y describir sus contramedidas – Req. 6.5
  • Proceder a capacitar a los desarrolladores dentro de los ciclos formativos anuales – Req. 6.5
  • Si se cuenta con aplicaciones web públicas y dependiendo de la opción empleada para protegerlas contra ataques conocidos, actualizar dichos métodos para que contemplen los riesgos de la OWASP Top Ten 2017:

  • o Si se emplean herramientas o métodos de evaluación de vulnerabilidades de aplicación  automáticos o manuales, éstos deben permitir la identificación de los nuevos riesgos.

    o Si se emplea un WAF (Web Application Firewall), esta solución debe ser configurada para que detecte y/o bloquee aquellos ataques vinculados con estos nuevos riesgos.

    Finalmente, se recomienda la revisión de otros proyectos interesantes de la OWASP, como OWASP Proactive Controls (https://www.owasp.org/index.php/OWASP_Proactive_Controls), OWASP Application Security Verification Standard (ASVS - https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project), Software Assurance Maturity Model (SAMM - https://www.owasp.org/index.php/OWASP_SAMM_Project) y OWASP Testing Guide (https://www.owasp.org/index.php/OWASP_Testing_Project), así como las guías  específicas para desarrolladores del OWASP Cheat Sheet Series (https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series).  Se puede encontrar información adicional en los anexos “What’s Next for Developers“, “What’s Next for Security Testers“, “What’s Next for Organizations” y “What’s Next for Application Managers”, que se encuentran al final del documento del Top Ten de 2017.

    Autor: David Eduardo Acosta 
    CISSP Instructor, CISM, CISA, CRISC, CHFI Instructor, CEH, PCI QSA, OPST, BS25999 L.A.
    Dpto. de Consultoría


    Documentación obligatoria en ISO 22301.

    Todos los Sistemas de Gestión que se quieren certificar bajo un estándar ISO, deben cumplir una serie de requerimientos, muchos de ellos enfocados a la documentación del Sistema. En el ámbito documental, y focalizándonos en la ISO 22301 para la definición de un Sistema de Gestión de la Continuidad de Negocio (SGCN), la Organización Internacional de Normalización, no impone límites en la cantidad de documentos que una Organización que se quiera certificar presente ante el auditor, aunque sí exige una documentación mínima que debe ser contemplada. Esta documentación mínima es la siguiente:
    • Contexto de la Organización (Cláusula 4.1): Definir de forma correcta el contexto de la Organización es crítico para cualquier Sistema de Gestión, identificando los principales actores internos y externos que afectarán al Sistema. Concretamente, para establecer el contexto del SGCN, la cláusula 4.1 indica qué se debe:
      • Definir el propósito del SGCN.
      • Identificar los objetivos de la Organización en materia de la continuidad de negocio.
      • Definir los factores de riesgo, internos y externos.
      • Establecer criterios para el riesgo y definir el “apetito por el riesgo” de la Organización.
    • Procedimiento para la identificación de requisitos legales regulatorios (Cláusula 4.2.2): Se debe establecer, implementar y mantener actualizado un procedimiento que permita identificar las regulaciones aplicables a la Organización, así como identificar los cambios que se produzcan; debe contemplar también la comunicación a las partes interesadas.
    • Alcance del SGCN (Cláusula 4.3.1): Debe mantenerse un documento en el que se identifique el alcance del SGCN y que contemple los requerimientos y necesidades de las cláusulas 4.1 y 4.2.
    • Política de Continuidad de Negocio (Cláusula 5.3): La Alta Dirección debe establecer una Política de Continuidad de Negocio que sea apropiada para los objetivos de la Organización y sirva como framework para el SGCN. Además, esta política deberá ser comunicada y estar disponible para todas las partes interesadas que lo requieran.
    • Objetivos de Continuidad de Negocio (Cláusula 6.2): Los objetivos de continuidad de negocio deben estar documentados y ser comunicados al personal para quien sean relevantes. Estos objetivos deben ser coherentes con la Política de Continuidad y deben ser monitorizados de cara a actualizarlos si es necesario.
    • Competencias (Cláusula 7.2): Se debe garantizar que el personal dispone de la competencia adecuada para su función y si es necesario, facilitar su capacitación. La Organización debe mantener evidencias de esto.
    • Plan de Comunicación (Cláusulas 7.4 y 8.4.3): Se debe documentar a quien se debe comunicar una disrupción, incluyendo todas las partes interesadas (ya sean actores internos o externos).
    • Proceso de Análisis de Riesgos e Impacto en el Negocio (Cláusula 8.2.1): Documento en el que se establece el contexto, criterios y evaluación de potenciales riesgos, tratamientos y salidas del proceso.
    • Análisis de Impacto de Negocio (Cláusula 8.2.2): En el que se identifiquen las actividades críticas del negocio y se evalúen el impacto de no realizar dichas funciones.
    • Análisis de Riesgos (Cláusula 8.2.3): El resultado del proceso de análisis de riesgos, identificando los riesgos existentes y cuáles deben ser tratados, de acuerdo a los objetivos de continuidad definidos.
    • Procedimientos de Continuidad de Negocio (Cláusula 8.4.1): Para evitar situaciones de disrupción de la Organización se deben establecer Procedimientos de Continuidad. Estos procedimientos estarán documentados y deberán indicar los principales pasos a seguir por cada rol en caso de disrupción.
    • Respuesta a Incidentes (Estructura de Respuesta a Incidentes - Cláusula 8.4.2): En este documento se reflejan los umbrales que justifican el lanzamiento de los Procedimientos de Continuidad y cómo elegir qué Procedimiento debe ejecutarse.
    • Decisiones de Comunicación (Cláusula 8.4.2): Una Organización debe decidir a qué partes interesadas (incluyendo actores externos) debe comunicar que ha ocurrido una crisis y debe documentar su decisión.
    • Procedimientos de Respuesta a Incidentes (Cláusula 8.4.4): Se debe disponer de procedimientos en los que se expliquen los roles y responsabilidades de los actores involucrados, los procedimientos de gestión de la incidencia, la operativa para la continuidad de las operaciones entre otros requerimientos.
    • Procedimientos de vuelta a la normalidad (Cláusula 8.4.5): Una vez se ha finalizado la contingencia, la vuelta al servicio habitual debe ser lo menos traumática posible para los servicios y colaboradores de la Organización; por ello, se deben establecer y documentar una serie de procedimientos en los que se indique los pasos a seguir para volver a operar de la forma habitual.
    • Resultados de monitorización y evaluación (Cláusula 9.1.1): Como proceso de mejora continua, se deben monitorizar las actividades, analizarlas y evaluarlas. Estos resultados deben guardarse como evidencia del proceso.
    • Evidencia de no conformidades (Cláusula 9.1.1): Cuando se identifiquen elementos adversos o como resultado de las no conformidades detectadas, la Organización tomará las medidas oportunas para mitigar dichas deficiencias y deberá guardar registros de las acciones tomadas como evidencia.
    • Revisión post-incidente (Cláusula 9.1.2): Cuando la Organización sufra un incidente que suponga la activación del Plan de Continuidad, la Organización deberá realizar una revisión del incidente y las acciones tomadas, que deberá quedar documentado como evidencia.
    • Auditoría Interna (Cláusula 9.2): Esta cláusula indica que la Organización debe realizar auditorías internas a intervalos planificados. El informe de la auditoría deberá guardarse como evidencia de que la auditoría se ha realizado.
    • Revisión de la Dirección (Cláusula 9.3): La Alta Dirección debe estar involucrada en el SGCN. Debe revisar el SGCN a intervalos planificados y deben quedar evidencias de dicha revisión.
    • No conformidades y acciones tomadas (Cláusula 10.1): Las no conformidades detectadas como resultado de las auditorías deben ser controladas. Por ello, debe quedar constancia de la evaluación de las no conformidades y las acciones que decidan tomarse.
    • Resultados de acciones correctivas (Cláusula 10.1): Cualquier cambio derivado de las auditorías o fallos detectados en las revisiones que sea implantado debe generar un registro en el que se indique los resultados de dichas acciones.
    Como puede observarse, la cantidad de documentación requerida por el SGCN es muy elevada. A toda esta documentación, debe añadirse además cualquier otra información a la que se haga referencia en la política o el alcance, o cualquier documento que la Organización considere necesaria para la Gestión de la Continuidad de Negocio.


    Existen otros documentos que, si bien no son obligatorios, es muy habitual encontrarlo en los sistemas que se encuentran certificados y ayudan al mantenimiento del SGCN. Algunos de estos documentos son:
    • Plan de Formación (Cláusulas 7.2 y 7.3): Disponer de un Plan de Formación ayudará a identificar las capacitaciones que son necesarias en función de los roles y responsabilidades definidos, así como ayuda a la planificación de las tareas de formación de la Organización.
    • SLA y revisión de SLA con procesos externalizados (Cláusula 8.1): En caso de que existan procesos externalizados, estos deben ser controlados. La mejor forma de control es a través de un contrato con SLA y evidencias de que estos SLA se revisan de forma periódica. En muchas ocasiones, estos SLA son revisados a través de reuniones planificadas a intervalos regulares y son parte de los propios SLA.
    • Plan de Pruebas (Cláusula 8.5): Probar los procedimientos puede ser vital para la Organización. Estas pruebas cumplen una doble función: por un lado, asegurarán que los actores involucrados conozcan sus responsabilidades y los pasos que deben seguir en caso de incidente; por otro, garantiza la viabilidad del procedimiento o detecta fallos en el diseño.
    • Escenarios de incidentes (Cláusula 8.5): Las pruebas que se realizan en el SGCN deben ser adecuadas, para ello se identifican posibles escenarios de crisis sobre los que realizar las pruebas.
    • Revisión e informes de pruebas (Cláusula 8.5): Se recomienda que siempre que se lleve a cabo una prueba se proceda de igual forma que si la Organización estuviese afrontando una contingencia real. Esto incluye una revisión e informe de la prueba realizada, de cara a identificar deficiencias en un proceso de mejora continua.
    • Plan de Actualización (Cláusula 9.1.1): Revisar la documentación de forma periódica permite garantizar que la información está acorde a los objetivos de la Organización, así como se revisan que los procedimientos estén actualizados. Por otro lado, la revisión y actualización de las pruebas y procedimientos garantiza que se dispone de información reciente en caso de que haya que activar el Plan de Continuidad.
    • Programa de Auditoría (Cláusula 9.2): Sirve como evidencia de que la auditoría se encuentra planificada y que ha cumplido con los objetivos establecidos.

    A modo de conclusión, queremos hacer notar que la cantidad de documentación necesaria para disponer de un SGCN certificable es muy extensa. Destacar también que no es obligatorio tener un documento para cada uno de los requisitos, si no que pueden integrarse varios de estos documentos en uno. Es muy importante para un SGCN operativo que se encuentre un equilibrio entre el número de documentos y la cantidad de información que contienen, de forma que dichos documentos sean manejables para la operativa diaria y faciliten su actualización y la revisión por parte de los auditores, sin olvidar que, si la información se encuentra disgregada entre varios documentos, es muy factible que se den inconsistencias entre los diferentes documentos. Por último, añadir que, si se integran varios de estos documentos obligatorios en un único documento es muy importante tener identificado, por parte de los responsables del SGCN, a qué cláusulas hace referencia cada documento, de forma que el auditor sepa dónde encontrará las evidencias que necesita y además facilitará la labor de actualización de los documentos cuando se dé cualquier cambio dentro de la Organización.

    Referencias
    ISO 22301:2012 – Societal Security – Business continuity management systems: https://www.iso.org/standard/50038.html
    Whitepaper de Advisera – Checklist of ISO 22301 mandatory documentation: http://info.advisera.com/27001academy/free-download/checklist-of-iso22301-mandatory-documentation