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.
    Departamento 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

    Autor: 
    Antonio Martínez Jiménez  
    Dpto. Consultoría


    Continuidad de Negocio para Pymes

    Las amenazas y la ciberdelincuencia no discriminan entre grandes compañías y pymes, pero ¿están las pymes preparadas para hacer frente a estos riesgos? .

    Históricamente, cuando se pensaba en la continuidad de negocio se tendía a pensar en disrupciones de carácter natural (como incendios, inundaciones, etc.), sin embargo, en el mundo actual, donde la utilización de proveedores y sistemas informáticos es vital para las operaciones diarias de las organizaciones, el rango de amenazas ha aumentado. La delincuencia cibernética busca información allá donde esté disponible, no importa el tamaño de la empresa ni la información que puedan conseguir, ya que con esta información siempre se va a poder hacer negocio, ya sea a través del cifrado de dispositivos y servidores mediante ransomware, o bien vendiendo la información obtenida en la Deep Web.

    No prever estos riesgos, o incluso menospreciarlos, puede suponer un error crítico para la viabilidad de las organizaciones. Si bien la gran mayoría de las organizaciones disponen de planes de prevención de riesgos laborales y planes evacuación de sus colaboradores en caso de incendio, no se considera cómo estos riesgos afectan a uno de los principales activos de la organización: la información, cuya perdida pone en riesgo, no sólo la continuidad inmediata de la operativa de la empresa, sino cualquier posibilidad de continuarla en el futuro.

    Además de no prever estos riesgos, el coste, la indisponibilidad de personal o la reducida probabilidad de crisis son las principales razones por las que las pymes no se plantean la implantación de un sistema de gestión de continuidad de negocio. Estos Planes de Continuidad de Negocio sirven para mejorar la preparación que tienen las organizaciones ante diferentes tipos de incidente que provoquen interrupciones en las actividades de dicha empresa, recuperando a la mayor brevedad posible las actividades más críticas, aunque esto puede extrapolarse a todas las actividades de la Organización.

    Muchas empresas disponen de un Plan de Recuperación ante Desastres (DRP por sus siglas en inglés) en prevención de la indisponibilidad de sus sistemas informáticos, pero un Plan de Continuidad de Negocio va más allá, identificando diferentes escenarios de crisis que puedan afectar a la organización, tomando como fuentes, no sólo la indisponibilidad tecnológica, sino también posibles indisponibilidades de las oficinas físicas, los recursos humanos, o los proveedores que ofrecen servicios críticos para la organización; priorizando la criticidad de las diferentes operaciones y estableciendo planes de recuperación, todo ello acompañado de la definición de una estrategia de pruebas y de concienciación de los colaboradores más críticos, haciendo que el Plan de Continuidad de Negocio sea realmente útil y productivo para las empresas.

    Existen diferentes formas de prepararse para establecer un sistema de gestión de la continuidad de negocio, pero ¿cuáles son los pasos que debe seguir una organización para implantar uno?.
    1. Identificar los objetivos y operaciones de la propia organización. Es necesario tener claro cuáles son los objetivos que queremos conseguir y en qué debemos establecer los focos de atención.

    2. Identificar y evaluar los principales escenarios y amenazas que afectan a la Organización, sean del tipo que sea, desde amenazas naturales hasta amenazas provocadas, considerando cualquier activo de la empresa (activos humanos, tecnológicos, infraestructura, etc.). Este análisis de Riesgos será una de las principales bases sobre las que se asentará nuestro Plan de Continuidad de Negocio.

    3. Establecer las actividades críticas. En muchas ocasiones, y si la empresa es muy pequeña, la Dirección suele conocer de antemano cuales son las actividades más críticas para su negocio. No obstante, es recomendable establecer una metodología objetiva, que considere diferentes aspectos a los que afectaría una posible disrupción de dicha actividad (requisitos de otros departamentos, impacto en la reputación financiera, o, por supuesto, impacto económico que supondría). Esta fase, denominada BIA por sus siglas en inglés (Business Impact Analysis) es junto con el Análisis de Riesgos otra de las etapas más críticas y que mayor cuidado hay que tener al efectuarlas, pues todas las estrategias y procedimientos que desarrollemos irán enfocadas a la protección de las actividades más críticos y se focalizarán en los riesgos más graves que se hayan detectado.

    4. Considerando estas fuentes, ya se pueden establecer cuáles serán las estrategias de recuperación que se establecerán para la Organización, en función del presupuesto y de los tiempos de respuesta que se hayan establecido.

    5. Establecimiento de un Plan de Comunicación, en el que se identifiquen claramente los roles involucrados, así como actores internos y externos que puedan verse afectados por una disrupción en el negocio.

    6. Diseñar un Plan de Formación, en el que se identifiquen los cursos y concienciaciones necesarias para que todos los colaboradores conocen las formas de actuar y su papel en caso de una disrupción.

    7. Pruebas: Si un Plan no se pone en práctica, la probabilidad de que funcione bien cuando sea necesario es muy reducida. Establecer un Plan de Pruebas adecuado, en el que se evalúen los tiempos de respuesta y el conocimiento de los involucrados en el Plan puede suponer un hecho diferencial para la consecución de nuestros objetivos.

    8. Las organizaciones cambian de forma constante (rotación de personal, apertura de nuevas instalaciones, cambios en sistemas informáticos, etc.), por lo que es necesario mantener el Plan de Continuidad actualizado, mediante revisiones periódicas y con la retroalimentación del propio plan de pruebas.

    9. Vuelta a la Normalidad: Toda crisis llega a su fin y un Plan de Continuidad debe continuar hasta que los procesos de negocio vuelven a operar con normalidad. Por ello, existe una fase adicional a considerar, que es la de identificar los procedimientos y comunicaciones que se deben seguir para volver a operar dentro de esta normalidad. Se deberán establecer los canales de comunicación para informar a los equipos afectados, así como, diseñar los procedimientos para volver a utilizar los activos primarios y devolver los sistemas de recuperación a su estado normal.
    Como puede observarse, este tipo de sistemas van más allá de la implantación de estrategias y planes de respuesta, si no que se trata de un proceso constante y cíclico, siendo necesario un esfuerzo constante por parte de la Organización para mantenerlo operativo. Siguiendo estos pasos, obtendremos un sistema de gestión de continuidad de negocio completo y con un ciclo de vida basado en la mejora continua, tal y como se define en los principales estándares y buenas prácticas.

    ¿Y qué ventajas ofrece este Sistema Gestor de la Continuidad de Negocio?
    • El primero y más importante, anteponerse a los desastres y disrupciones; la gestión proactiva y preventiva de las amenazas es vital para 
    • Reducción de pérdidas. Al tomar medidas con tiempos de respuesta ajustados y dar una operativa continua, se puede minimizar la pérdida de clientes, así como evitar o reducir sanciones de las instituciones regulatorias.
    • Ventaja competitiva. Disponer de un Plan de Continuidad de Negocio puede suponer una ventaja frente a los competidores, así como una fuente de confianza para inversores.

    Si bien implantar un Plan de Continuidad de Negocio es un proyecto costoso en recursos y monetario para las empresas (considerando que, además del coste de lanzamiento e implantación, tiene que mantenerse vivo, derivando recursos de forma constante para su actualización y mejora), se debe tener en cuenta que cualquier Organización, grande o pequeña, se encuentra en riesgo y se enfrentan a posibles desastres si no se encuentran preparadas y no son capaces de realizar sus servicios o entregar sus productos a raíz de un incidente. Una aproximación muy útil para pequeñas empresas es la de abordar su Plan de Continuidad de Negocio por etapas, pudiendo hacerse esta aproximación de diferentes formas, ya sea focalizándose en unos pocos procesos de negocio o bien limitando los escenarios de crisis que se van a considerar y para los que se plantearán estrategias de recuperación. Sea cual sea la aproximación que se utilice, se debe ver este tipo de proyectos como una inversión y no como un coste, ya que no contar con un Plan de Continuidad de Negocio probado o no establecer los procedimientos y documentación adecuados puede suponer un coste incluso mayor al del propio Sistema Gestor de Continuidad de Negocio.

    Referencias
    ISO 22301:2012 – Societal Security – Business continuity management systems: https://www.iso.org/standard/50038.html
    Introducción a la continuidad de negocio del Business Continuity Institute: https://www.thebci.org/knowledge/introduction-to-business-continuity.html

    Autor: 
    Antonio Martínez Jiménez  
    Dpto. Consultoría

    Crónica No cON Name 2017

    Este año hemos tenido la oportunidad de volver a asistir a la última edición del congreso No cON Name, el congreso público de seguridad informática más longevo de España (nacido en 1999, en Palma de Mallorca), cuya última edición se llevó a cabo en 2015. Durante el discurso inaugural, la organización remarcó que la edición de 2016 no se llevó a cabo por dificultades de financiación y que actualmente se están buscando nuevos formatos que puedan encajar con el congreso, con el objetivo de evitar la repetición de ponentes y charlas en las diversas “Cons” que se realizan en España. A continuación, os dejamos un breve resumen de las presentaciones que se realizaron durante su primera jornada.

    "Win API hooking by using DBI: log me, baby!" (Ricardo J. Rodríguez)

    Ricardo J. Rodriguez empezó su charla con una definición e introducción a los frameworks DBI. Esencialmente estos son capaces de controlar que sucede durante la ejecución de un binario.

    Posteriormente se centró en el DBI Pin desarrollado por Intel en 2005. Pin tiene la característica de vincularse a procesos que se encuentran en marcha y tiene soporte para las arquitecturas 32 y 64 bits en Windows y Linux e Itanium sólo en Linux.

    Existen 3 tipos de APIs en PIN: las básicas, que implementan funcionalidades básicas y son independientes de la arquitectura, las específicas de la arquitectura (opcodes y operands), y las APIs basadas en llamadas que proporcionan rutinas que definen donde y qué se instrumentaliza.

    Pin proporciona dos modos de análisis o instrumentalización: JIT mode, donde una copia del binario se modifica al vuelo y el binario original nunca es ejecutado y el Probe mode, donde las instrucciones de la aplicación son modificadas y se insertan saltos (trampolines) para alterar el funcionamiento normal de la aplicación instrumentalizada.

    Pin destaca de otros frameworks DBI por su granularidad. Más allá de la instrumentalización básica a nivel de bloque o instrucción, Pin proporciona instrumentalización de eventos a nivel de rutinas, grupos de bloques (traces), durante la creación o destrucción de hilos y en la carga y descarga de imágenes, llamadas de sistema, .... Y aún más importante, Pin proporciona las funciones necesarias para acceder a datos importantes cuando estos eventos ocurren.

    La charla terminó con algunas instrucciones sobre cómo configurar Pin en entorno Windows y dos ejemplos de uso de Pin.

    "WinregMITM: Inyectando código remotamente en el registro de Windows" (Santiago Hernández Ramos)

    Santiago ofreció una fantástica presentación sobre un problema de seguridad en el protocolo WinReg debido a un fallo en su implementación. WinReg es un protocolo cliente/servidor que proporciona gestión remota del registro de Windows. Éste se apoya en otros protocolos como SMB, RPC para llevar a cabo su cometido.

    En el protocolo WinReg, el cliente y el servidor negocian una sesión a través del protocolo RPC. Para que las llamadas RPC sean seguras hay que construir previamente un contexto de seguridad. Seis niveles de autenticación pueden establecerse según el contexto de seguridad haya negociado. Los niveles de autenticación van del 0 (ninguna protección) al 6 (integridad y cifrado). El encargado de implementar los niveles de autenticación que el contexto de seguridad exige es el proveedor de seguridad.

    Cuando un cliente inicia la conexión con el servidor mediante WinReg, se le asocia un contexto de seguridad de nivel de autenticación 6. Si durante la conexión se produce un error el contexto de seguridad es desechado. Un error puede ser algo tan sencillo como el uso de credenciales incorrectas para autenticarse con el servidor de WinReg.

    Un fallo en la implementación del protocolo WinReg permite que tras el error en la conexión se establezca un nuevo contexto de seguridad con nivel de autenticación 0. La comunicación a partir de ese momento se realiza en claro y sin integridad.

    El trabajo de Santiago no termina ahí si no que escribe la herramienta WinregMITM para aprovechar esa vulnerabilidad. Tras envenenar la cache ARP del cliente y servidor la aplicación  WinregMITM permite romper la conexión existente entre cliente y servidor para forzar la reconexión sin cifrado. A partir de entonces la aplicación será capaz de ver y manipular la conversación entre ambos. En este punto sólo hay que esperar a que el cliente realice un cambio en el servidor para cambiar el valor introducido legítimamente por el valor deseado por el atacante.

    El ataque no es trivial ya que debido al cambio de la clave de registro realizado por el atacante el tamaño del paquete cambia. Esto afecta tanto a los campos de control de las capas inferiores (SMB y/o RPC) cómo al número de secuencia de sesión TCP que se basa en la longitud del paquete. WinregMITM es capaz de filtrar los paquetes específicos, modificar los campos necesarios, recalcular los campos de control y los números de secuencia TCP para terminar reconstruyendo el paquete y reenviarlo evitando así que la conexión se rompa.

    "¿Dónde has estado? Encontrando evidencias en tu móvil" (Alex Ribot)

    La charla de Alex nos descubre distintas fuentes y métodos para encontrar información de posicionamiento en dispositivos móviles.

    El conocido sistema de geolocalización GPS ha sido mejorado con AGPS (Assited-GPS). Éste proporciona posicionamiento en interiores, a pesar de hacerlo con menor precisión en tales circunstancias, aprovechando la información relativa a la celda de telefonía y las señales WiFi cercanas. Este método ahorra batería y necesita sólo 2 satélites GPS para lograr una localización precisa. El rango de error en la precisión mediante posicionamiento por celda de telefonía se estima entre los 25 y los 1000 metros. Usando WiFi el rango se reduce de los 10 a los 100 metros. Por último el sistema por GPS va desde los 7,8 a los 16 metros.

    Tanto iOS como Android tienen en sus acuerdos de privacidad cláusulas que solicitan el consentimiento para transmitir, coleccionar, procesar y usar los datos de localización que nuestros dispositivos envían. Las API encargadas de proporcionar información de posicionamiento son la Core Location para iOS y la Google’s Fused Location o la Android  Location API en Andoid.

    Las fuentes de datos para obtener la geolocalización son múltiples. A nivel de tarjeta SIM tenemos varios identificadores o códigos de área que son almacenados en la propia tarjeta: LAC (Location Area Code), FPLMN (Forbidden Public Land Mobile Network).

    A nivel de sistema operativo la información guardada en el sistema de ficheros no es normalmente accesible y a menudo hay que rootear el dispositivo o sacar un dump de la memoria. En Android existe una base de datos SQLite con las redes WiFi y los IDs de las celdas (codificados en Base64) que el dispositivo ha captado. También podemos encontrar un historial con los SSSID, algunos BSSID y sus correspondientes passwords a los que el móvil se ha conectado. En IOS tenemos principalmente las Frequent Locations, una base de datos SQLlite que retiene las ubicaciones aproximadamente durante 1 día, ficheros con algunos datos de geolocalización históricos, y archivos de preferencias plist en formato binario de difícil interpretación y la Location cache, con información de posicionamiento por celdas (1 semana aprox.) y por WiFi (4 días aprox.)

    A nivel de aplicación, existen múltiples aplicaciones que pueden almacenar información de geolocalización para desarrollar correctamente su actividad o para otros fines como mostrar publicidad. Evidentemente cada app necesita su correspondiente permiso para poder acceder a la posición del dispositivo.

    A nivel de usuario, los dispositivos se pueden configurar para que se almacene la ubicación en los metadatos de imágenes y videos. Otras fuentes como imágenes tomadas en sitios públicos conocidos o conversaciones por chat o email donde se revela la ubicación son también válidos.

    Para finalizar, a nivel de Cloud, tanto IOS como Android posibilitan la localización de los dispositivos en caso de robo o pérdida, y especialmente Android proporciona un historial de localizaciones vinculado a la cuenta Gmail del dispositivo.

    "Atacando implementaciones Whitebox Cryptography" (Jordi Ventayol)

    Jordi, comenzó su presentación describiendo las principales diferencias entre los diferentes tipos de implementaciones criptográficas. En primer lugar, describió el tipo Whitebox, en el cual el criptoanalista dispone del control total y toda la información acerca del sistema criptográfico. En segundo lugar, describió el tipo Greybox, en el que ya no se dispone del control del sistema, y únicamente de datos relativos a los tiempos de ejecución de los algoritmos, al consumo eléctrico del dispositivo criptográfico, del campo magnético generado, etc. Finalmente, describió el tipo Blackbox, en el que únicamente se dispone de la información de las entradas y las salidas del sistema. La ponencia nos sitúa en el primero de los tipos.

    Posteriormente, Jordi explicó que las implementaciones Whitebox son utilizadas en dispositivos HCE (Host Card Emulation), generalmente incluidos en smartphones para poder realizar pagos de forma equivalente a los realizados con tarjetas (basadas en la tecnología SIM).

    Finalmente, y a través de varios ejemplos, expuso los principales mecanismos de protección en entornos Whitebox. Entre ellos, se encuentran el uso de tablas de búsqueda (look-up tables) para embeber la clave de cifrado, la introducción de aleatoriedad en dichas tablas, el enmascaramiento y la ofuscación tanto del código como de los datos.

    "IoT - The New Big Brother" (Luis Enrique Benitez)

    Luis Benítez, miembro del Departamento de Auditoría de Internet Security Auditors, puso sobre la mesa cómo los distintos dispositivos conectados recopilan información de los hábitos de uso y consumo de sus usuarios. Luis expuso que durante los últimos años ha estado analizando distintos dispositivos y que en todas ellas ha detectado carencias en la seguridad en mayor o menor grado.

    Algunos ejemplos son una Smart TV que recaudaba información; un grupo de canales en particular no solo recaudaba información cuando se accedía a su contenido sino que también envía datos técnicos del dispositivo, la lista de canales sintonizados y el orden en que estos se encontraban, remarcando además que dicha información era enviaba cada 4 segundos.

    También habló de dispositivos para monitorizar el consumo energético. En este caso detectó un fallo en la plataforma web que permitía acceder a los datos de consumo en tiempo real de cualquier usuario. Comentaba Benítez que esto permitiría realizar un perfil exhaustivo del usuario. Interpretando los datos de consumo se podrían llegar a deducir hábitos como la hora en que el usuario se despierta o cuando está durmiendo o fuera de casa. A esto hay que sumarle que entre los datos recaudados estaban las coordenadas GPS de donde se encontraba instalado el dispositivo y el nombre que el usuario le había asignado.

    Posteriormente habló de una lavadora smart, la cual enviaba información cada 30 segundo del estado del lavabo. Una vez comprendido la lógica de la aplicación le permitía emular las peticiones recibiendo en su dispositivo móvil mensajes ininterrumpidos de que su ciclo de lavabo había terminado. También mostro serias carencias de seguridad en el portal del fabricante, el cual permitía gracias a un fallo de seguridad crear un usuario con rol de administrador.

    Luis cerró su ponencia hablando de la plataforma Smart City SENTILO, la cual contaba con múltiples deficiencias de seguridad.

    Las conclusiones de la charla son sobre todo dos: la necesidad de integrar la seguridad desde el principio en el desarrollo de las aplicaciones y la necesidad de una certificación de dispositivos IoT que proporcionen un mínimo de garantías en cuando al diseño y a las actualizaciones.

    "El badUSB se juntó con el wifi... Y se lió parda" (Ernesto Sanchez y Joel Serna)

    Ernesto y Joel, realizaron una breve introducción a los famosos dispositivos denominados BadUSB. Estos dispositivos, son dispositivos que intentan hacerse pasar por simples unidades de almacenamiento USB, pero que presentan funcionalidades ocultas. En su ponencia, presentaron su experiencia en el desarrollo de uno de estos dispositivos, con la novedad de incorporar WiFi.

    En primer lugar, Ernesto y Joel hablaron sobre la funcionalidad de estos dispositivos para evadir los antivirus de los sistemas a los que son conectados. Describieron como es posible lograrlo, forzando al sistema a reconocer el dispositivo como HID (Human Interface Device -como un ratón, teclado, etc-) en lugar de memoria USB, con el objetivo de evitar que el antivirus proceda al análisis de su contenido y pueda descubrir el malware almacenado. Esta funcionalidad, la implementaron a través del módulo ATMEGA32U4.

    Posteriormente, detallaron la mejora que llevaron a cabo al incluir un módulo WiFi al dispositivo, para poderlo controlar remotamente a través de la carga de scripts. Esta mejora, la implementaron a través del módulo ESP8266. A su vez, comentaron la existencia de otros proyectos en esta línea, como por ejemplo WiDucky.

    Finalmente, Ernesto y Joel expusieron las dificultades de su trabajo a la hora de incorporar un módulo SD adicional, con el objetivo de permitir al dispositivo su reconocimiento de nuevo como unidad de almacenamiento (para evitar el rechazo del mismo por parte del usuario), una vez anulado el antivirus del sistema objetivo.

    Autores: 
    Carlos Antonio Sans García - Dpto. Consultoría
    Francesc Guitart - Dpto. Sistemas

    El (ISC)2 introduce las pruebas adaptativas computarizadas (Computerized Adaptive Testing) al examen CISSP

    A partir del 18 de diciembre de 2017 el Consorcio Internacional de Certificación de Seguridad de Sistemas de Información (International Information Systems Security Certification Consortium) o (ISC)2 pondrá en funcionamiento las pruebas adaptativas computarizadas (Computerized Adaptive Testing o CAT) al examen CISSP, inicialmente en los exámenes ofrecidos en idioma inglés e introduciendo de forma paulatina la misma técnica a los demás idiomas en los que se puede presentar la prueba a lo largo del primer trimestre de 2018.

    Este es uno de los cambios más significativos en el examen de esta certificación, luego de que en 2012 el examen migró de su modelo de presentación en papel (Paper Based Testing - PBT) a la presentación por ordenador (Computer-Based Testing - CBT).

    ¿En qué consiste la tecnología de pruebas adaptativas computarizadas?

    Actualmente, el examen de la certificación CISSP (Certified Information Systems Security Professional) se realiza a través de un examen compuesto de 250 preguntas fijas y lineales que el candidato debe contestar en un tiempo máximo de 6 horas. Al finalizar la prueba, se computan los resultados y si se obtiene una calificación superior a 700 puntos sobre 1000, el candidato aprueba.

    Mediante las pruebas adaptativas computarizadas el criterio de presentación de las preguntas al candidato varía de forma considerable respecto al modelo lineal. Ahora, cada pregunta es seleccionada con base en la respuesta de la pregunta anterior, maximizando la precisión del examen de acuerdo con el siguiente algoritmo iterativo:
    1. Se busca la pregunta óptima entre una base de datos de preguntas disponibles, de acuerdo con la estimación actual de la capacidad del candidato.
    2. La pregunta seleccionada es presentada al candidato, quien la responde de forma correcta o incorrecta.
    3. La estimación de la capacidad se actualiza, con base en todas las respuestas anteriores.
    4. Los pasos 1 al 3 se repiten hasta que se cumple un criterio de finalización.

    Los criterios de finalización se aplican en el siguiente orden:
    1. Regla de intervalo de confianza: una vez que se cumple la duración mínima del examen (100 preguntas), el examen finalizará cuando la estimación de capacidad del candidato excluya el punto de aprobación con una confianza estadística del 95%. Para los candidatos con estimaciones de capacidad que excedan estadísticamente el estándar de aprobación, el examen estará aprobado. Para los candidatos que tienen estimaciones de capacidad que estén estadísticamente por debajo del estándar, el examen será reprobado.
    2. Regla de la longitud máxima del examen: si no se ha invocado previamente la regla de intervalo de confianza antes de llegar a las 150 preguntas, entonces la estimación de la capacidad del candidato se evaluará con respecto al estándar de aprobación. Si durante los últimos setenta y cinco (75) elementos operacionales respondidos la estimación de la capacidad del candidato está constantemente por encima del estándar de aprobación para cada elemento, entonces el resultado del examen es aprobado. Si en algún punto sobre los últimos setenta y cinco (75) elementos operacionales la estimación de la capacidad del candidato cae por debajo del estándar de aprobación, el resultado será reprobado. La evaluación de la estimación de capacidad con relación al estándar de aprobación no tiene en cuenta el intervalo de confianza.
    3. Regla Run-out-of-time (R.O.O.T.): si la regla de intervalo de confianza no se ha invocado antes del tiempo máximo del examen (3 horas), la estimación de la capacidad del candidato se evaluará con respecto al estándar de aprobación. Si durante los últimos setenta y cinco (75) elementos operacionales respondidos la estimación de la capacidad del candidato está constantemente por encima del estándar de aprobación, entonces el resultado del examen es aprobado. Si en algún punto sobre esos setenta y cinco (75) ítems la estimación de la capacidad del candidato cae por debajo del estándar de aprobación, el resultado es un error. Si el candidato no responde setenta y cinco (75) elementos operacionales dentro del tiempo máximo del examen (3 horas), el candidato automáticamente suspenderá el examen.


    ¿Cuáles son las ventajas del nuevo modelo de pruebas adaptativas computarizadas?

    Los criterios de elección de un examen tipo CAT sobre un examen lineal son los siguientes:


    • Confiabilidad: Los exámenes del tipo CAT permiten una forma más precisa y eficiente de evaluar las capacidades del candidato, ya que permite la adaptación de las preguntas a cada individuo en particular.
    • Optimización del tiempo: En vez de emplear 6 horas para responder la totalidad de las preguntas del examen, se requerirán solamente 3 horas (como máximo) y solamente respondiendo un subconjunto de preguntas escogidas de acuerdo a la capacidad del candidato. 
    • Seguridad en las preguntas: En un examen lineal, el candidato estaba expuesto a 250 preguntas. Si no aprobaba, era muy probable que en un segundo intento muchas de esas preguntas volvieran a aparecer en su examen. Con el nuevo modelo CAT, la probabilidad de repetición es mínima, ya que la exposición de preguntas al candidato se minimiza dependiendo de sus capacidades.

    ¿Cuáles son las diferencias entre el modelo CAT y el modelo lineal?

    A continuación, se presentan las principales diferencias entre ambos modelos:


    CISSP Lineal
    CISSP CAT
    Cantidad de preguntas
    250 preguntas (con 25 preguntas de prueba no contabilizadas ni explícitamente identificadas).
    Entre 100 y 150 preguntas (con 25 preguntas de prueba no contabilizadas ni explícitamente identificadas).
    Tiempo máximo disponible para contestar
    6 horas
    3 horas
    Criterio de aprobación
    700 sobre 1000 puntos
    El examen termina cuando se puede determinar con una confianza del 95% que el rendimiento de un candidato está por encima o por debajo del estándar de aprobación, sin importar el número de ítems respondidos o transcurrido la cantidad de tiempo de la sesión de examen.
    ¿Se cuenta el tiempo de descansos (breaks)?
    SI
    SI
    ¿Se permite la revisión/cambio de preguntas ya contestadas?
    SI
    NO
    ¿Se presentan preguntas organizadas por dominios?
    NO
    NO, las preguntas se esquematizan con base en las respuestas previas del candidato.
    Precio
    699 USD
    699 USD

    ¿Cómo debo prepararme para presentar el examen de la certificación CISSP en formato CAT?

    La preparación del candidato no debe variar respecto a la presentación del examen en formato lineal. No obstante, si es importante tener en cuenta algunos puntos:
    • Debido a que no se permite la revisión de preguntas ya contestadas (ya que el algoritmo ajusta la pregunta futura con base en la respuesta inmediatamente anterior) el candidato deberá estar completamente seguro de su respuesta antes de avanzar.
    • Ya que la adaptación de las preguntas a la capacidad del candidato es la característica clave de este nuevo modelo, el estudio se debe focalizar en aquellos dominios del CBK en los que el candidato se siente con menos confianza.
    • Debido a que el tiempo de presentación del examen y la cantidad de preguntas se acortan, es importante gestionar muy bien el tiempo y no bloquearse en una pregunta.
    ¿En dónde puedo obtener más información al respecto?

    El (ISC)2 ha publicado una guía y preguntas de uso frecuente (FAQ) en su sitio web, con relación al cambio del examen al formato CAT. Esta información puede ser consultada en la siguiente URL: https://www.isc2.org/Certifications/CISSP/CISSP-Cat

    Finalmente, ¿el examen en formato CAT es más difícil que en formato lineal?

    En principio, no. Como tal, en ambos formatos se parte de la premisa en la que se debe superar un umbral de aprobación. Este umbral en el formato lineal se evalúa al final de las 250 preguntas, mientras que en el formato CAT se va evaluando en cada pregunta con base en un estándar de aprobación.
    Por otro lado, tanto las preguntas del examen lineal como del examen CAT provienen del mismo banco global de preguntas. Es decir: no se tendrán preguntas exclusivas para ninguno de los dos formatos del examen.

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