Atentado de Boston y APTs

Según se han ido sucediendo las noticias relativas al atentado de la Maratón de Boston y las averiguaciones posteriores no he podido evitar la tentación de establecer una analogía entre los hechos de Boston (o el terrorismo en general) y las APTs informáticas. Y la pregunta que surge a continuación es clave: ¿Es válido ese paralelismo? Y si fuera así... Podrían realimentarse ambos mundos?

Analicemos el paralelismo. Para empezar, el punto de partida de una APT es un "troyano" que conseguimos introducir en el sistema de la víctima. En el mundo físico, el sistema objetivo sería el entorno a atacar, en este caso Boston (o EEUU, cada uno que lo interprete como quiera). Las personas serían las aplicaciones que corren en ese sistema, y por lo tanto tendríamos dos formas de "infectar" el sistema: introduciendo directamente un software malicioso tipo "virus" (terrorista proveniente del exterior) o "troyanizando" una aplicación del sistema ("convirtiendo a la causa" a un ciudadano local, al más puro estilo homeland).

Al igual que en el mundo informático, los países están preparados para proteger el perímetro de la red (frontera) y controlar las entradas (firewalls), pero la capacidad de detección de terroristas externos que tienen estos sistemas es muy limitada, ya que generalmente se limita a firmas (identidades específicas que se chequean) y heurística básica (análisis de los datos del propio viaje -origen, destino, motivos del mismo, y cosas así). El resultado es que los "virus" sencillos se pueden llegar a detectar, pero las APTs más sofisticadas (personas "troyanizadas" o incluso malware durmiente con puertas traseras) suelen colarse. Además, al igual que en los sistemas de información, no sólo podemos infectarnos por la red. Los pendrives (inmigración ilegal o no controlada, cuerpos diplomáticos, etc.) también pueden llevar alguna aplicación maliciosa en su interior, consciente o inconscientemente.

En el mundo TIC se suelen poner sistemas IDS en la red interna, para tratar de detectar ataques que hayan podido superar la protección perimetral. Sin embargo, en el mundo físico no hay (oficialmente) demasiados recursos destinados al "espionaje" interno, más allá de la labor policial habitual. En cualquier caso, normalmente un IDS tampoco suele ser capaz de detectar la actividad de una APT...

Las APTs son difíciles de detectar porque su actividad es esporádica. Suelen ser aplicaciones "durmientes", que realizan una actividad aparentemente normal (o ninguna) hasta que, por un motivo determinado, activan su payload malicioso y lo ejecutan, realizando la fechoría en cuestión. Este funcionamiento es muy similar al de cualquier célula terrorista, y la dificultad de su detección estriba en identificar el detonante para su activación, que potencialmente puede ser cualquier cosa. Las autónomas pueden activarse con una cuenta atrás, un hito específico, una fecha, etc., mientras que otras dependen de la recepción de una orden externa desde un nodo de comando y control (C&C). Estas son algo más detectables, pero también mucho más flexibles, ya que pueden ser reprogramadas. En cualquier caso, esas comunicaciones llevadas al mundo físico son prácticamente imposibles de detectar, dada la infinidad de medios existentes y la poca capacidad de supervisión de los mismos.

Y por último, las APTs actúan. Roban la información, hacen estallar la bomba... Este suele ser el momento en el que son detectadas, cuando el incidente se materializa. El problema es que en este momento ya no sirve de nada, su acción no ha podido ser evitada. En ese momento es cuando empieza la "desinfección"... si es que han sido detectadas. Si no es así, podrán continuar con su actividad.

Hasta aquí la exposición. Ahora vuelvo a lanzar la pregunta, para la que no tengo respuesta. ¿Puede servir el conocimiento adquirido en cualquiera de ambos mundos para mejorar la lucha contra amenazas físicas y cibernéticas? Hay algún tipo de iniciativa de colaboración en este sentido? Seguro que un buen guionista sabe cómo hacerlo...

Publicada la norma UNE 71020:2013 - Modelo incremental para la ISO 20000

La semana pasada se publicó la norma española UNE 71020:2013 - Modelo de conformidad incremental basado en la norma UNE-ISO/IEC 20000-1.

Esta norma es, en resumidas cuentas, un modelo de adopción de la norma ISO 20000 por niveles, que establece dos niveles intermedios antes de llegar a cubrir todas las exigencias recogidas en la ISO 20000-1.

Mucho ha llovido desde que se empezó a hablar de la ISO 20000 por niveles. Yo mismo valoraba esta posibilidad allá por 2008, como una vía para "aligerar" la adopción de la ISO 20000 sobre todo para las PYMEs. Y sin embargo, el tiempo, que es en el fondo quien puede dar o quitar la razón, en este caso me la ha quitado. No sólo es que la mayor parte de empresas certificadas en España en ISO 20000 sean PYMEs, sino que he vivido de forma directa la experiencia de la adopción de la ISO 20000 en múltiples PYMEs y os puedo asegurar que en absoluto han necesitado un modelo de este tipo.

Y en ese caso, cuál es el motivo de que haya seguido adelante el desarrollo de esta norma? Pues desde mi punto de vista el argumento principal es precisamente el contrario, las grandes empresas. Los cambios organizativos y operativos que requiere la adopción de un sistema de gestión de servicios certificable bajo ISO 20000 son infinitamente más sencillos de realizar en una PYME que en un gran departamento de TI, tanto por flexibilidad interna como por posibles impactos en los servicios prestados, más críticos cuanto mayor sea su dimensión. Para estos casos, la existencia de niveles intermedios "oficiales" puede suponer una gran diferencia a la hora de subdividir los proyectos y tener metas intermedias que impulsen un proyecto de cambio que bajo otro planteamiento puede ser excesivamente complejo. No perdamos de vista que el hasta ahora gran éxito de los proyectos ITIL en grandes corporaciones se basaba precisamente en éso, en abordar proyectos más pequeños y específicos, y por tanto con resultados más rápidos y tangibles.

Por otro lado, creo que este modelo de referencia puede ser muy útil para organizaciones que, sin tener un departamento TIC demasiado potente, cuenten con un cierto grado de madurez en su gestión interna corporativa y quieran mejorar la calidad de sus TIC sin encorsetarse demasiado. Estoy pensando, sobre todo, en empresas del sector industrial y productivo en general, en los que las TIC "apoyan" al negocio pero no son el "core" del negocio. En este tipo de organizaciones, plantearse un nivel 1 de madurez puede ser una meta mucho más interesante que la de desarrollar un sistema de gestión de servicios completo y certificable...

Por qué digo esto? Echándole un vistazo a los niveles (visión simplificada y "redondeada") creo que quedará más claro:

• Nivel 1 = Núcleo del Sistema de gestión (básico) + Seguridad (básico) + Proveedores + Incidentes + Problemas + Configuración (básico) + Cambios (básico) + Entregas (básico).
• Nivel 2 = Núcleo del Sistema de gestión (completo) + Seguridad (completo) + Niveles de servicio + Informes + Continuidad y disponibilidad (básico) + Financiero + Capacidad + Proveedores + Clientes (básico) + Incidentes + Problemas + Configuración (completo) + Cambios (completo) + Entregas (completo).
• Nivel 3 = ISO 20000 completa (se completan todos los procesos y se añade el diseño y transición de servicios.

Así que ya sabéis, si queréis profundizar un poco más en este planteamiento de la ISO 20000 por niveles... ya tenéis un estándar a vuestra disposición. 

Herramientas para ISO 20000

Una de las dudas más habituales a la hora de pensar en la ISO 20000 suele ser la de si es necesario disponer de herramientas específicas para su implantación. Y aunque la respuesta "de libro" debiera ser que no, la realidad es que en muchos casos se hace casi imprescindible disponer de alguna herramienta que facilite las tareas a realizar, sobre todo si queremos ser eficientes y eficaces a la hora de realizarlas. Otra cosa muy diferente sería valorar qué herramientas en cuestión se pueden utilizar, ya que hay desde herramientas gratuitas y de código libre hasta herramientas con precios al alcance de sólo unos pocos privilegiados, cada una de ella con sus ventajas y sus inconvenientes. Pero como no pretendo llegar a eso, a continuación va un listado de "tipos" de herramientas que se pueden utilizar, y para qué ámbitos son útiles:

• Herramientas de monitorización: Son prácticamente imprescindibles para los procesos de gestión de la capacidad y gestión de la continuidad y disponibilidad, ya que permiten monitorizar de forma automática la disponibilidad y capacidad de los sistemas. Además, pueden facilitar los procesos de gestión de niveles de servicio y de informes, en función de los parámetros en base a los cuales hayamos definido la calidad de nuestros servicios. 
• Herramientas de ticketing: Aunque la gestión de incidentes y peticiones de servicio pudiera hacerse de manera cuasi-manual, la utilización de una herramienta de ticketing se hace prácticamente imprescindible en el momento en el que queramos automatizar dicha gestión y sobre todo obtener indicadores de dicho proceso. En función de los parámetros en base a los que hayamos definido la calidad de nuestros servicios, estas herramientas también pueden facilitar los proceso de gestión de niveles de servicio y de informes. Además, en muchos casos la gestión de problemas también se automatiza mediante la misma herramienta de ticketing, incrementando su utilidad. 
• Herramientas específicas para CMDB: Aunque una CMDB se podría implementar con una base de datos relacional normal y corriente, las herramientas específicas para CMDB facilitan tanto el trabajo que su utilización acelera enormemente la implementación del proceso de gestión de la configuración, haciéndose muy aconsejables si no imprescindibles. Además, estas herramientas normalmente suelen tener capacidad para integrarse con las herramientas de ticketing, incrementando enormemente su funcionalidad. 
• Herramientas de soporte a la gestión: Aunque no sean imprescindibles, cada vez están surgiendo en el mercado más herramientas que implementan diferentes procesos de la ISO 20000, normalmente bajo un planteamiento ITIL-compliant. Este tipo de herramientas facilita la gestión de los procesos, y sobre todo mejora enormemente la capacidad de gobierno de los mismos, gracias a su potencial de obtención de indicadores y métricas asociadas. 
• Herramientas de inventariado automático: No son herramientas imprescindibles para la ISO 20000, pero las herramientas de auto-descubrimiento e inventariado de la infraestructura TIC facilitan la gestión de los activos, sobre todo en los casos en los que la infraestructura TIC es numerosa. Además, las herramientas de CMDB suelen tener interfaces con estas, facilitando la gestión de la configuración. 
• Herramientas de administración TIC: Tampoco son herramientas imprescindibles para la ISO 20000, pero al facilitar la administración centralizada de la infraestructura (sistemas y/o comunicaciones) permiten una implantación más sencilla y eficaz de los procesos de gestión de la configuración y gestión de la entrega. Además, este tipo de herramientas suele permitir su integración con otras señaladas anteriormente. 

En definitiva, las herramientas "clásicas" en la gestión TIC facilitan la adopción de un Sistema de Gestión de Servicios certificable bajo ISO 20000, y muchas de ellas han ido evolucionando e incorporando los módulos específicos necesarios para cumplir con las exigencias de la ISO 20000, o al menos definiendo las interfaces necesarias para su integración con este tipo de herramientas. A día de hoy ya existe un amplio y completo catálogo de soluciones, de modo que el uso de este tipo de herramientas sólo dependerá de cada organización, y de la selección que quiera hacer en función de sus intereses y posibilidades.

Las dashcam y la LOPD

Seguro que a estas alturas todo el mundo ha visto alguno de los vídeos en los que aparece el meteorito que la semana pasada cayó en Rusia. Y la grabación de estas imágenes ha sido posible porque parece que en Rusia son muy habituales las dashcams, o cámaras de parabrisas, que son unas cámaras que se instalan en el interior del coche para ir grabando lo que sucede delante de nosotros mientras vamos conduciendo.

Reconozco que la idea de tener una dashcam se me ha ocurrido en innumerables ocasiones, incluso antes de conocer su existencia, sobre todo cuando el conductor de delante te hace una pirula y piensas "si esto se hubiera grabado, menudo puro le iba a caer". Por supuesto, en mi imaginación las dashcams eran mucho más completas, por éso de la deformación profesional:   Módulo GPS integrado para posicionamiento y fechado de fuente externa, memoria read-only para evitar la manipulación de las grabaciones, sistema completo certificado por Common Criteria...   Vamos, un sistema totalmente inexpugnable a nivel legal. No vaya a ser que el de la pirula se libre!

No obstante, puestos a ser realistas, y teniendo en cuenta que en la práctica probablemente no fuese necesaria tanta fortaleza legal para que la grabación en cuestión fuese admitida en un juicio corriente, la idea de la dashcam actual parecería suficiente. Sin embargo, me asalta una duda legal: ¿Es compatible la idea de la dashcam con nuestra LOPD?

Por un lado, parece que la videovigilancia debería ser la última solución, y no tengo claro si en este caso se podría considerar un medio excesivo. Por otro, entiendo que quien tuviera una dashcam debería llevar pegado el cartelito amarillo en el parabrisas (sería gracioso encontrarse con un coche así, la verdad). Pero la duda que más me asalta es la relacionada con la aplicabilidad de la LOPD. Mi idea general simplificada era, básicamente, que la LOPD no aplicaba a personas físicas, por aquello del Artículo 2.a. Sin embargo, hay resoluciones y sentencias que sancionan a personas físicas por grabar el exterior. ¿Es por el "exclusivamente personales o domésticas"? Al final, no me termina de quedar claro...

¿Hay algún jurista en la sala capaz de aclararme si podré instalarme una dashcam?

La LOPD lo permite TODO

En los últimos meses estamos asistiendo a una creciente aparición en prensa de una gran diversidad de documentos que destapan multitud de escándalos: Gürtel, Noos, Bárcenas, ... En todos ellos acaban publicándose documentos cuasi-privados en los que aparecen, como era de esperar, datos personales, entre otra información.

Ante estos hechos ya empiezan a aparecer, y cada vez con más volumen, posicionamientos en contra de la publicación de este tipo de documentos argumentando para ello la protección que la LOPD otorga a este tipo de información. ¿Se puede o no se puede, desde el punto de vista de la LOPD, publicar esa información?

Partiendo del planteamiento de interés legítimo, apoyándome en argumentaciones mucho más consistentes que las que pueda hacer yo, y sin olvidarme del derecho a la información, entiendo que estos argumentos carecen de rigor jurídico, y que no hay ningún problema para publicar este tipo de documentos pese a que incluyan datos personales.

No obstante, el objetivo del post de hoy no era el de profundizar en si se puede o no se puede publicar esa información, sino recordar que LA LOPD LO PERMITE TODO. Así, en mayúsculas. ¿Se pueden publicar datos personales de nivel alto en Internet? SI. ¿Se pueden difundir a los cuatro vientos, por cualquier medio? Por supuesto que SI. Lo único que necesitamos es el consentimiento del afectado.

De hecho, tendríamos que estar aburridos de ver publicados y difundidos datos personales de nivel alto sin el más mínimo problema. ¿Acaso la pertenencia de Mariano Rajoy al Partido Popular no es un dato personal, y de nivel alto? ¿O que Jesús Vázquez sea gay? Por supuesto que sí. ¿Están vulnerando la LOPD quienes lo publican? Claro que no. Simplemente, tienen el consentimiento del afectado.

En resumidas cuentas, la LOPD permite algo tan "duro" como publicar en Internet o a través de cualquier medio de comunicación el historial médico completo de cualquier persona. Tan sólo necesitamos su consentimiento explícito para difundirlo de forma indiscriminada a toda la sociedad. ¿Somos capaces de conseguirlo? Entonces la LOPD lo permite. Otra cosa es que no contemos con dicho consentimiento...

En definitiva, lo que quiero transmitir con esta "reducción al absurdo" es que la LOPD no tiene por qué ser impedimento para nada. Por lo tanto, no hagamos de la LOPD la excusa para no publicar una cierta información, cuando en muchos casos el motivo principal suele ser otro bien distinto...

Conceptualizando en Gestión de Crisis y Resiliencia

El post de hoy no está escrito por mí, es una contribución de Jose Miguel Sobrón, miembro de ASIS International y el responsable de la Unidad de Sistemas de Gestión de Resiliencia Organizacional del Department of Safety and Security de Naciones Unidas. Espero que os guste!

Esta es la era de la preparación (preparedness era) hay que estar listos para todo lo que venga. Antes éramos reactivos y ahora somos proactivos. Ahora además tenemos que ser resilientes, para todo también. En toda esta tendencia y obsesión por “estar listos”, ¿qué pasa con continuidad de negocio? ¿Y con gestión de crisis?

A veces la rutina nos confunde y nos hace olvidar el significado real que a las palabras damos, y el porqué de ese mismo significado. Esta es una confusión o polémica muy habitual sobre el huevo y la gallina, o lo que es lo mismo, si fue antes Continuidad de Negocio o Gestión de Crisis o viceversa, o cual de las dos regula a cual.

Si hay algo que esta arrasando en todas las grandes corporaciones a nivel mundial y que se está extendiendo como la pólvora, eso es el concepto de Resiliencia, definida de mil maneras, pero simplificándola a cualquier áreas de estudio, como capacidad de resistir cualquier impacto y conectarlo con las maneras posibles de volvernos a levantar y continuar. Así es en multitud de áreas. Recomiendo por lo exquisito y extenso del estudio un análisis muy concienzudamente detallado llevado a cabo por el US Department of Homeland Security (DHS, grosso modo nuestro Ministerio del Interior) en el Journal ofHomeland Security and Emergency Management, vol 6, Issue 1-2009-Art 83.

En este nuevo mundo global de Resiliencia Corporativa (Organizational Resilience) existe mucha confusión creada a veces por intereses obvios de mercado e influencia de varias tendencias y a veces solo por confusión de la terminología. Si inicialmente el primer paso de gigante en continuidad lo dio la presentación del BS25999 (1-2), el modelo que integraba todo bajo BCM (Gestión de continuidad de negocio) no cubre todas las áreas, a pesar de tener un amplio apoyo y marco experimental en Reino Unido, la misma Unión Europea y algunos países. Es más, vista la escasa acogida actual y la reorientación del mercado hacia la familia ISO 31000 e ISO 28000, los grandes defensores del modelo británico han reaccionado con celeridad y han aunado fuerzas con ASIS International (que sigue el modelo ISO) para elaborar un producto de Gestión de Continuidad de Negocio (Business Continuity Management) “conjunto”, suma de las dos tendencias, para crear una sola alrededor de las familias de estándares de ISO (ASIS/BSI Business Continuity Management Standard - 2010). Sabia elección, porque siempre es mejor aunar que litigar. Muchos de los que practican el modelo británico se han visto y se ven en una situación incómoda, por aquello de que a todos nos cuesta un trocito de ego reconocer que hay que tomar otro camino contrario o diferente al que practicábamos desde hace un tiempo. Merece la pena dejar el ego atrás, sin duda.

El modelo basado en ISO 31000 es mucho más integral y explora un marco que no deja resquicio alguno. Además es relativamente multinacional y compila el esfuerzo inicial australiano y neozelandés, con el impulso del Sudeste Asiático y el reciente apoyo incondicional de Estados Unidos y la mayor parte de países europeos.

En ese marco de ISO 31000 la Gestión de Crisis sí es el pilar fundamental, que no el único, y los demás son absolutamente no solo necesarios sino completamente complementarios. En el ámbito de ISO31000 y en íntimo contacto se localiza el impulso creado y mantenido por ASIS International para Resiliencia Corporativa (acabamos de publicar el ultimo estándar aprobado por ANSI sobre el modelo demadurez de Resiliencia Corporativa). En ese paraguas monumental que es la Resiliencia, cabe todo, pero hace falta un hilo conductor que lo regule y coordine, y ese hilo conductor debe de estar en lo más alto de la cadena de Mando o Gestión si lo preferís.

Empezaré explicando por qué cuando acudimos a la definición se ve mucho mas claro el concepto. Al hilo de esto, permitirme de nuevo recomendaros un sumario sobre el PAS (Publicly Available Section) 200:2011 Crisis Management-Guidance and Good Practice llevado a cabo por Regester Larkin, que recoge bastantes puntos interesantes y también críticos sobre el estudio de Reino Unido (el PAS completo es de pago y creo que cuesta alrededor de 100 libras esterlinas).

Gestión de Crisis como su propio nombre indica hace referencia a dos cosas absolutamente claras en cualquier organización por grande o pequeña que sea: Gestión conecta con el Jefe Ejecutivo o el Consejo Directivo o los dos; y Crisis es una palabra que hemos desgastado y contaminado de tanto usarla. Una crisis no es un incidente ni un problema, es una situación muy, pero que muy complicada que se desarrolla en un ambiente inestable, complejo e inesperado, de desconocidas consecuencias (a veces “black swans”) y que pone en alto riesgo cualquiera de nuestros activos o pasivos más importantes, nuestras instalaciones y personal y nuestra reputación; y por ende hace peligrar la existencia de la propia organización en su estado actual. Podéis hacer una comparativa en uno de los últimos papeles de Marzo del BCI (CM What is and howis it delivered, 2012 BCI).

Las crisis, como los riesgos, no son malas por naturaleza, pueden serlo si nos pilla sin preparar pero pueden ser grandes oportunidades en las que fortalecer y consolidar los cimientos de la Resiliencia Corporativa. Os dejo un link de una definición escalable de cómo Gestión de Crisis conecta conResiliencia Corporativa, que hace poco llevamos a cabo cuando colabore con un par de buenas amigas del Fondo de Población (UNFPA) para finalizar su Plan de Continuidad de Negocio.

Todos tenemos problemas, pero de eso a una crisis hay un trecho, distancia que a veces no queda clara por falta de definición. Se trata en definitiva de una escala temporal que comienza con la localización un problema de desconocido impacto y consecuencias. El problema original se convierte en incidente cuando requiere una intervención de nuestro mecanismo de –primera- respuesta sea el que sea. Cuando la cosa se pone fea y parece ser que el sexto sentido del que responde le dice que esto no tiene muy buena pinta, pues ¿que hace?, lo de siempre, llama al jefe. Y el Jefe es quien declara si hay o no hay crisis. Eso ha sido así contado un poco en “Román paladino” o español de andar por casa.

En el Sistema de Gestión de la Resiliencia Corporativa (ORMS del inglés), el Sistema de Gestión de Incidentes (Incident Command System, ICS; que es básicamente nuestro servicio de seguridad y/o de emergencias internas, incluyendo médicos, psicólogos, encargados de instalaciones y recursos humanos de apoyo) se encarga de estimar la cuantía y calidad del impacto recibido (irrelevante, limitado, relevante, severo y extremo/critico). En cuanto tiene una somera idea de ello, determina si lo puede solucionar por si mismo, lo debe de monitorizar y avisar a alguien para alertar por si acaso o lo lanza al siguiente o más alto supervisor si se trata de un problema grave o gravísimo. También el ICS dispone de mecanismos que son automáticos, como evacuaciones sanitarias, evacuaciones de edificios, et al. que basados en determinados protocolos no precisa de autorización previa por la emergencia de que se trate.

Esto pone en alerta a los mecanismos de gestión de crisis que se preparan para lo peor y esperan lo mejor. Estos mecanismos o están en si mismos compuestos por los mas altos directivos o tienen línea directa con ellos y el consejo de Dirección. Una vez declarada la crisis por la autoridad interna que corresponda, sea el CEO o el equipo de gestión de crisis (CMT), se determinan las medidas a llevar a cabo: seguir monitorizando, activar el plan de continuidad (business continuity), recuperación de desastres (IT Disaster Recovery) o lo que haga falta en función de la situación. Hemos pasado en poco tiempo de un problema a un desastre o incluso una catástrofe. Estos dos últimos en realidad se ven venir inmediatamente, no los eventos en si mismos que son impredecibles pero si sus consecuencias y la magnitud del impacto recibido. Por eso hay que prepara mecanismos que disminuyan al mínimo la respuesta inicial, por limitada y exigua que sea, y que aceleren la integración del modo crisis en el mecanismo de gestión integral. Aquí se hace ver la valía de conectar y coordinar la preparación mediante un marco global como es la Resiliencia Corporativa. Rompemos los silos en la preparación y estamos preparados para la respuesta.

Con todo lo anterior vemos que aunque haya procesos que puedan automatizarse y producirse en aislamiento, el flujo regular obliga a pasar de un escenario a otro escalable en envergadura desde el ICS hasta Gestión de Crisis, y es Gestión de Crisis (conectado al mas alto escalón de mando) quien activa Continuidad o recuperación de desastres e indica como se van a llevar a cabo y cuales operaciones de recuperación, así como la relocalización si fuera precisa.

La conclusión final nos lleva a determinar que efectivamente gestión de crisis juega un papel de coordinación que facilita enormemente la toma de decisiones al más alto nivel y que encaja a la perfección con el concepto de Resiliencia Corporativa. Esto no desmerece en absoluto el papel indispensable que ha jugado la Continuidad de Negocio desde los 90 y las enormes contribuciones que han permitido madurar el modelo hasta el estado actual. Desde el entorno de respuesta inmediata de un negocio de pequeña o mediana entidad, las barreras o diferencias entre gestión de crisis y continuidad de negocio siguen siendo muy difusas o difíciles de identificar, en grandes empresas o instituciones la cosa esta muy clara, la apuesta es resiliencia.