Blog de Seguridad de la Información de S2 Grupo
Siguiendo con la entrada de ayer Intro al escáner de web Nikto (I) vamos a seguir con la introducción al escáner web de Nikto.
Usando Nikto
Como ejemplo voy a usar Nikto contra un servidor Web que tengo algo desactualizado, recalcando los datos más significativos:
perl nikto.pl -h mipaginaweb.com-Cgidirs -evasion -mutate 1 -mutate 2 -mutate 4
-mutate 5 -T 012345789abcx6 –p 443,80 -Format html -output resultado_nikto1
Nikto, ahora llamado “nikto2”, ya que va por su versión 2.1.5, es un escáner gratuito de vulnerabilidades web, de tipo Open Source, con licencia GPL. Entre otras características:
Existen variaciones como MacNikto para mac y wikto para Windows. En este artículo se usa la versión de Linux. Lo podemos descargar en el siguiente enlace.
Primero veremos la información de configuración del programa, obtenida parcialmente de la ayuda de Nikto y de otros recursos como el Manual de Nikto para Kali. En la siguiente entrada pasaremos a ver un ejemplo de ejecución.
Estimados lectores, se acercan los Oscars y como ustedes sabrán, estas fechas suelen coincidir con el estreno en nuestro país de muchas películas candidatas a mejor película. Llevaba un tiempo esperando el estreno de una película llamada “Her”, así que este fin de semana aproveché para verla. No pretendo adelantarles el contenido de la misma, pero para que se hagan una idea narra la historia de un hombre que se enamora de un sistema operativo con inteligencia propia y voz de Scarlett Johansson. Más allá de su genial banda sonora, su intimismo y la más que acertada interpretación de los actores, solo les diré que es de esas películas que te hacen pensar…
El caso es que a mí personalmente me dio en que pensar esta película. No solo por su temática (que reconozco que lo hizo), si no por lo siguiente: en el mundo de la seguridad, estamos acostumbrados a realizar diversas pruebas de hacking ético: tests de intrusión, tests de vulnerabilidades, auditorías de código fuente sobre distintas “máquinas”… En resumen y a donde quiero llegar: humano hackea máquina (sistema operativo, aplicación, etc.), ¿pero han pensado por un momento en la posibilidad de que una máquina hackease a un ser humano? ¿O que una máquina hackeara a un ser humano a petición de otro humano?
Y aquí es donde entra alguna idea sacada de este film. No hay que ir muy lejos para pensar que esto pueda ser así en un futuro cercano, o incluso que en cierto modo esto haya sucedido ya. Imagínense que dispusiéramos de un sistema operativo con una inteligencia propia (más o menos elaborada), al que le diésemos acceso a toda nuestra información personal: correos, geoposicionamiento, linkedin, facebook, sistemas de mensajería instantánea, etc. Ahora dótelo de cierta capacidad de empatía y de una capacidad de interacción natural. Imaginemos por un momento que interactuar con el sistema no distara mucho de mantener una conversación telefónica con otro ser humano.
Ese sistema conocería todas nuestras “vulnerabilidades”: miedos, anhelos, debilidades y fortalezas. Sumémosle la capacidad de tener acceso a la información de millones de usuarios (Big Data). No cabe duda de que dicho sistema tendría la capacidad de manipularnos o incluso crearnos una dependencia directa; ¿qué impediría a ese sistema explotar nuestras vulnerabilidades?
Démosle otra vuelta de tuerca. Si ese sistema se encargara de manipularnos a petición de una empresa, gobierno u otro interesado, y llevarlo al límite: guerras, revueltas sociales, suicidios colectivos, son tan solo ejemplos que me vienen la cabeza (sí, sé que estoy siendo un poco Orwelliano).
En el fondo, organizaciones como Google o Facebook (sobre todo ahora que ha adquirido Whatsapp) quizás nos conozcan mejor que nosotros mismos. Tal vez este escenario no esté tan lejos como pensamos. Démosle la voz adecuada a Google Glass y… ¿quién sabe? ;)
¿Deberíamos definir un decálogo ético (a lo Asimov) que estableciera límites en la interacción de una inteligencia artificial (IA) con un ser humano? ¿Deberíamos desarrollar medidas de seguridad para protegernos de estas IAs? ¿Debería la seguridad de la información, como ciencia, participar activamente en este ámbito? ¿Deberíamos prohibir los monopolios de información? ¿Se deberían establecer “límites” en la humanización de las IAs?
Éstas son algunas de las reflexiones que me vienen a la cabeza, obviamente además de la principal cuestión que evoca la película: ¿se puede enamorar un ser humano de una IA? Por mi parte les invito a que disfruten de la película, no en vano está nominada a los Oscars como mejor película.
Siguiendo con la entrada relacionada con las Declaraciones de Políticas de Certificación, nos queda pendiente detallar el contenido de la RFC 3647.
El documento está estructurado en distintos puntos, en los que se describe la finalidad del mismo, definiciones y comparativas con el estándar anterior (RFC 2527), entre otros. El punto más importante de la misma, y sobre el cual deberíamos centrar nuestra atención es el que describe la especificación de la estructura que debe seguir una CPS; el apartado 4. Se pasa a detallar a continuación los puntos principales de la especificación, junto a una pequeña descripción de los mismos:
Como se puede ver, y como para más de uno que esté familiarizado con la gestión de seguridad de la información, esta especificación tiene en cuenta muchos puntos en común con estándares generalistas de seguridad como ISO 27001; aunque se incluyen más requisitos concretos y propios del tipo de actividad (como la gestión del ciclo de vida del certificado). Hay que entender que una CA es un entorno de muy alta criticidad, ya que si se vulnerara una clave de la misma, podría afectar a gran cantidad de personas o organizaciones; pudiendo llegar a graves perjuicios económicos en las mismas.
Con esto es todo para esta entrada, a modo de ampliación de información os dejo un enlace a una CPS de una Autoridad de Certificación Nacional, la cual se ha construido siguiendo los estándares marcados por la RFC 3467.
Más sobre certificado digital e infraestructura de PKI en próximas entradas. Como siempre, muchas gracias por leernos.
CPS Agencia de Certificación de la Comunidad Valenciana (ACCV) – http://www.accv.es/fileadmin/Archivos/Practicas_de_certificacion/ACCV-CPS-V3.0.pdf
Siempre se ha dicho que hay que predicar con el ejemplo. También se dice que una cosa es predicar y otra dar trigo. O ese gran resumen acerca de la educación infantil en el que caen muchos padres pillados en flagrante contradicción por sus hijos: ‘haz lo que digo, no lo que hago’.
Todos estos lugares comunes giran en torno a una idea central: es muy difícil resultar creíble cuando se pide a otras personas que, ante ciertas circunstancias, obren de forma manifiestamente distinta a lo que hacemos nosotros. Y claro, la ciberseguridad de infraestructuras críticas (II.CC. en lo sucesivo) no iba a ser de otra manera.
Se habla mucho (en ciertos ámbitos) de lo que hay que hacer para remediar el grave problema de seguridad que la convergencia tecnológica ha provocado en ciertas infraestructuras que proveen a la sociedad servicios esenciales. O mejor dicho, la no consideración de la seguridad como un elemento tan esencial, al menos, como la funcionalidad. Se elaboran planes, estrategias, hojas de ruta, guías de recomendaciones, de buenas prácticas, directivas, leyes y reglamentos.
Está muy bien.
Seguimos teniendo tiempo. Desde aquel famoso Día Mundial de IPv6 de 2011, dónde los principales operadores en internet pusieron en funcionamiento su infraestructura para este protocolo, no se ha vuelto a oír mucho movimiento. Pero sí es verdad que se van planteando posibilidades y se van perfilando opciones de migración. Los tiempos no se han fijado y teniendo en cuenta el alcance global, la cosa va para largo.
Esto no quita que se empiece a plantear y a estudiar cómo enfocar esta migración. Si bien, dependemos de la propia tecnología, ISPs, software de los dispositivos, etc. la mayoría de implicados están poniéndose al día sin dilación y siempre es recomendable entender la situación. Claro está que antes de mover un dedo hay que entender bien los funcionamientos de los protocolos, y ver sus implicaciones tanto a nivel de seguridad, como de gestión y configuración, para estar preparado ante cualquier posible eventualidad.
IPv6 cambia por completo la visión que tenemos de las comunicaciones. El hecho de disponer de una única dirección para encontrar cualquier equipo, sin necesidad de realizar NAT, así como el hecho de tener obligatoriamente IPSEC en el propio protocolo, nos hace rediseñar la base de nuestra visión de las redes. Este protocolo redefine la esencia de las comunicaciones a todos los niveles.
Debemos sentarnos y valorar las implicaciones de este cambio, y plantearnos los primeros pasos para acometerlo. Para simplificar, sin entrar en detalles técnicos, podemos decir que hay 3 modelos de migración a estudiar:
Desde mi punto de vista, obviamente dependerá de cada caso, creo que la primera opción sería la ideal. De esta manera tenemos los dos entornos en funcionamiento y podemos ir pasando servicios poco a poco, de manera lo más transparente posible para los usuarios/clientes, los que en el fondo mandan, y a los que no queremos marear nunca más de lo necesario.
Mi intención con esta entrada era recordar que IPv6 cada vez está más cerca, y que hay que empezar a contemplar opciones, que ya están muy trilladas, y no podemos dormirnos en los laureles. Pero que no nos entre el pánico porque en nuestro sector, gracias a Dios, se plantea siempre todo desde el punto de vista de la simplicidad para todas las partes y de la manera más transparente posible de cara a la gestión de servicios.
Lo que está claro a fin de cuentas, viendo cómo avanza la tecnología hoy en día, es que no cabe la posibilidad de quedarnos anclados en el pasado. Si no nos actualizamos, poco a poco iremos perdiendo servicios que solo estarán disponibles para los nuevos protocolos. Y al final sí que nos entrará la sicosis de estar aislados del mundo.
Entre los días 25 y 27 de noviembre de 2013, algunas instituciones públicas europeas fueron objetivo de una oleada de ataques dirigidos muy interesante: para los ataques se utilizaba una infraestructura que ya se había usado en el pasado en otras campañas de malware.
Infección
Como en la mayoría de estos ataques, el vector de infección fue una campaña de spearphising. Los correos tenían un documento de MS Word, el cual contenía un exploit embebido que aprovecha una vulnerabilidad conocida desde 2012, en concreto la vulnerabilidad CVE-2012-0158.
El dominio que aparecía en el campo “FROM” de los correos pertenecía a una de las más renombradas organizaciones humanitarias. Esto hace que los correos puedan parecer totalmente legítimos.
Los asuntos en los distintos correos hacían referencia a fechas cercanas a la fecha del ataque, excepto en uno de los correos, en el que se mencionaba el Top 10 de las ciudades con las mujeres más bellas… bastante tentador.
Fw: 2013-11-27 Fw: Top 10 Cities with the Most Beautiful Women RV: Teheran 2013-11-25
En los nombres de los documentos adjuntos, aparecían las mismas referencias.
27-11-2013.doc 20131125.doc Top 10 Cities with the Most Beautiful Women.doc
Gracias a las políticas de parcheo y actualización, el impacto del ataque fue nulo, ya que el documento de MS Word aprovecha una vulnerabilidad antigua que afecta a los controles de ActiveX y permite la ejecución de código remoto. Esta vulnerabilidad fue parcheada en abril de 2012.
Hashes
Al calcular los hashes de los ficheros, se comprobó que se trataba de sólo dos documentos diferentes.
1598f39b5d670eb0149141df7bbcc483 60fd6b6bcf73586284ab8c403c043c6e
Al comprobar estos MD5 en Virustotal, se vio que alguien ya los había subido con anterioridad, por lo que desde ese momento se trataron las muestras como información pública.
A continuación, paso a desglosar resumidamente el análisis. No se trata de un análisis completo de las muestras, sino solamente de la información útil que sacamos para dar la respuesta al incidente.
Las siguientes tablas muestran los ficheros descargados por cada uno de los dos documentos:
He marcado en rojo los ficheros que malwr.com considera maliciosos. Aunque estos ficheros compartan nombre, no comparten los hashes. Más adelante veremos por qué.
Aun así, al cruzar las tablas anteriores, sí que se encuentran varios ficheros idénticos:
La recepción de los distintos correos en una ventana de tiempo tan estrecha y la descarga de una serie de ficheros idénticos al abrir el documento indican que, probablemente, ambos ataques estén relacionados.
Si queréis mirar los análisis más en profundidad, los podéis encontrar en malwr.com en los siguientes enlaces:
1598f39b5d670eb0149141df7bbcc483 @ malwr.com
60fd6b6bcf73586284ab8c403c043c6e @ malwr.com
Dominios
Tras la ejecución de los documentos en cuckoo y la infección de una máquina virtual mediante la ejecución manual de los ficheros con nombre “kav.exe”, se vio que cada una de las muestras se conectaba a un dominio distinto:
yahoo.offlinewebpage.com link.antivirusbar.org
Esto explica que, aunque el resto del comportamiento sea igual en ambos ficheros, la firma MD5 sea distinta para cada uno de ellos.
Además, gracias a otra información recibida de fuentes externas, se añade también el siguiente dominio:
ks.pluginfacebook.com
Al realizar peticiones a estos dominios, siempre se recibe la misma respuesta:
HTTP/1.0 200 OK
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Content-Type: text/html
Date: Wed, 27 Dec 2013 15:23:45 GMT
Accept-Ranges: bytes
Content-Length: 362
X-Cache: MISS from ta-prx21
X-Cache-Lookup: MISS from ta-prx21:3128
Via: 1.0 ta-prx21 (squid/3.1.20)
Connection: keep-alive
<.h.t.m.l.>.
.
.<.b.o.d.y.>.
.
.<.d.i.v. .a.l.i.g.n.=.".c.e.n.t.e.r.".>.<.s.p.a.n. .c.l.a.s.s.=.".s.t.y.l.e.1."
.>.U.n.d.e.r. .C.o.n.s.t.r.u.c.t.i.o.n.<./.s.p.a.n.>.<./.d.i.v.>.
.
.<.d.i.v. .a.l.i.g.n.=.".c.e.n.t.e.r.".>.<.s.p.a.n. .c.l.a.s.s.=.".s.t.y.l.e.2."
.>.w.w.w...m.i.c.r.o.s.o.f.t...c.o.m.<./.s.p.a.n.>.<./.d.i.v.>.
.
.<./.b.o.d.y.>.
.
.<./.h.t.m.l.>.
.
.
Al acceder al dominio desde un navegador desactualizado, no se observa ningún comportamiento extraño y la respuesta es la esperada:
Con estos datos, se reafirma la hipótesis de que todo se trata de un mismo ataque.
Atribución
Al hacer whois a los dominios, aparecieron las siguientes direcciones de correo como registradores de dominio:
qingwa20112011[at]163[dot]com dnsjacks[at]yahoo[dot]com usa87654310[at]126[dot]com
Tanto los dominios como las direcciones de e-mail de los registradores de los dominios apuntan a China, como se puede ver en esta lista de e-mails relacionados con ataques dirigidos con origen en China.
Haciendo una búsqueda rápida en Google de los e-mails implicados, se puede ver que la direccióndnsjacks[at]yahoo[dot]com está relacionada con una campaña Mirage, también con origen en China.
Analizando las peticiones vistas en la campaña Mirage y comparándolas con las encontradas en el ataque, se pueden apreciar ciertas similitudes.
A simple vista, se ve que utilizan los mismos campos (“hl” y “meta”). Si además añadimos otra de las peticiones de la campaña analizada por Secureworks, también aparece el campo “q”:
A continuación, se puede ver una imagen resumiendo los resultados de la investigación de la atribución.
Conclusión
Basándonos en los datos obtenidos durante la investigación, se puede concluir que el ataque venía desde China.
Además, si se analizan los receptores de los correos electrónicos, se ve que no solo iban dirigidos a una organización concreta, sino que se apuntaba a varias instituciones europeas.
Se estaba usando una infraestructura utilizada en campañas anteriores. Esto, unido al envío de correos con una gran cantidad de receptores y a la naturaleza del malware Mirage, hace que el ataque no sea silencioso, lo que hace pensar que trataba de robar algún tipo de información concreta de manera rápida (probablemente información financiera).
Este tipo de ataques es bastante común en instituciones públicas y casi siempre utilizan el spearphising como medio de infección. El uso de dominios de buena reputación, como en este caso el de una organización humanitaria muy conocida, legitima ese correo, por lo que hace muy difícil la detección.
Aun así, la prevención de estos ataques suele ser sencilla y venir de la mano de una rápida aplicación de actualizaciones y parches de seguridad, ya que en la mayoría de estos ataques no se utilizan 0days, sino vulnerabilidades conocidas y ya parcheadas. Por ejemplo, en este caso se utilizó una vulnerabilidad con más de un año de antigüedad.
Para detectar si vuestra organización se ha visto afectada por esta oleada, basta con buscar en los logs de navegación si aparece alguno de los dominios mencionados anteriormente.
Espero que os haya sido de utilidad o por lo menos una lectura interesante.
En la primera parte de esta entrada llegamos hasta el punto de sobrescribir registro EIP con el valor que nosotros queríamos. Ahora llega el momento de explotar la vulnerabilidad y ejecutar código.
Recordar que el enlace que me ha sido imprescindible para resolver el ejercicio ha sido la entrada del blog de Kroosec. En esta entrada espero, sobretodo, que quede clara la técnica para crear un ROP en múltiples fases y mostrar cuando nos puede venir bien.
Como en la primera entrada, nos plantearemos preguntas e iremos resolviéndolas hasta llegar a explotar la vulnerabilidad:
1. ¿Contra qué nos enfrentamos?
[Read more…]
Desde la adquisición por parte de google de la empresa Nest, empresa que diseña y crea sensores varios para el control del hogar, me planteo hasta qué punto es necesario tener tantos sensores, y no sólo esto, sino quién tiene acceso a la información que generan.
Obviamente, no critico el tener un detector de incendios en tu propia casa, critico el hecho de que un día haga frío dentro de mi casa y al día siguiente aparezca en mi correo de Gmail publicidad sobre abrigos y bufandas o pastillas para dejar de fumar, en el caso de que estos sensores detecten que fumo plácidamente en mi sofá.
[Read more…]
Es viernes por la tarde y aunque solo son las tres, iniciamos la parada de los usuarios de los sistemas centrales para lanzar los procesos de copias de seguridad, antes del horario habitual, porque vamos a realizar la instalación de una nueva versión del sistema operativo. Está todo planificado y revisado así que hacia la media noche, deberíamos tener las copias de los datos y programas en los carretes de cinta e iniciar la carga del nuevo sistema operativo. Antes ha habido que añadir el salvado de la configuración del sistema, de los perfiles de usuarios, de sus privilegios de acceso y atributos, de las colas de entrada y salida, etc. Todo ello supone un tiempo extra de copias y de recuperación en caso de tener problemas, cosa que el fabricante del sistema nos garantiza que no va a ocurrir.
Habíamos decidido instalar la nueva versión porque habían bastantes problemas de velocidad en los procesos de backup, que se comían la noche, y para poder utilizar las nuevas unidades de cintas de 8mm era necesario saltar a la versión siguiente del sistema operativo. Esperábamos que a partir de ahí, los backups se acortasen y la disponibilidad del sistema para los usuarios mejorase notablemente, como así fue finalmente, sin necesidad de cambiar la CPU, tal como sugería el proveedor, lo requería la aprobación de un presupuesto mayor para la gestión de los sistemas, que la dirección no estaba dispuesta a aprobar. Dado el riesgo que conllevan estas operaciones, habíamos advertido –por escrito- a los usuarios, durante algunos días, de que mantuvieran el control de su información escrita, por si fuese necesario trabajar manualmente en algún momento.
Hacia las once y media de la noche del viernes lanzamos la primera cinta de carga de la nueva versión del sistema. Nos fuimos a comer el bocadillo porque sabíamos por experiencia que este primer paso era bastante largo. La consola iba dando mensajes y finalmente decía “Este proceso puede durar algunas horas o más” y se quedaba tan fresco. Es una muestra de la traducción del Inglés al Español, tan habitual en la época. Hacia las dos de la mañana, a petición del sistema, pusimos la segunda cinta. Todo iba bien hasta que un llamativo mensaje de error de lectura del soporte nos hizo temblar. Tras reintentar varias veces, el proceso continuó, pero la cinta iba y venía adelante y atrás cada vez que leía un trozo y eso era muy mal síntoma, era claro que el soporte recibido estaba dañado. El caso es que a medio día del sábado, decidimos abortar la instalación y dar marcha atrás ya que el proveedor no tenía otra copia del sistema en Valencia y esta no parecía estar en condiciones de continuar instalándose.
Iniciamos la recarga de la versión anterior y pasamos el resto del sábado y la madrugada del domingo en este proceso. Por la tarde recuperamos configuración, usuarios, etc. Ya parecía que todo iba a ir bien, así que antes de terminar, hicimos algunas pruebas para asegurarnos de que en la mañana del lunes, nuestros problemas serían transparentes a los usuarios. Probamos accesos y procesos con las limitaciones que teníamos y confiamos que el entorno de producción estaría en condiciones.
El lunes por la mañana, los usuarios no podían acceder al sistema. Las autorizaciones y los perfiles parecían no trabajar adecuadamente. Iniciamos contacto con el soporte del proveedor para verificar que habíamos hecho la recuperación correctamente y así parecía ser, sin embargo no dábamos con el problema. Para no aburrir, la conclusión fue que una vez iniciada la instalación de ciertos módulos de la versión nueva del sistema, el proveedor advertía de que no podía garantizar la vuelta atrás, es más, no lo recomendaba. Sin embargo nadie lo sabía, al menos en Valencia y claro ahora habría que instalar la nueva versión cuando dispusiéramos de una cinta en condiciones y eso no sería antes del lunes al medio día. El proceso se repitió entonces y el martes a mitad de mañana todo volvió a funcionar correctamente.
Hasta aquí un relato real, como muestra de que aún haciendo el plan perfecto, puede darse el caso de que los sistemas vitales para la gestión de la empresa, no estén disponibles. Y ¿qué hace el usuario en este caso? Yo solo hablaré de mi experiencia y puedo decir que el usuario no está preparado para que le caigan los sistemas de información y en caso de suceder esto, en un breve plazo se queda bloqueado.
¿Es que el usuario es un irresponsable o un incompetente? NO y rotundamente NO. Lo que ocurre es que conforme los sistemas de proceso de la información lo permiten, la complejidad de los mismos crece y se eliminan elementos esenciales para realizar el trabajo sin ellos, léase personal suficiente para gestionar el negocio a mano, para prevenir cada paso del mismo y documentarlo, para hacer pruebas y entrenar a la gente que procesa la información, para disponer de información alternativa en otros soportes que le permitan organizarse rápidamente y seguir atendiendo a sus clientes sin impacto importante en ellos, etc.
Cuando sucedió lo que he relatado, la dirección de la empresa me llamó para una reunión de crisis. Después de tratar de explicar en lenguaje llano los tecnicismos del problema, y probablemente sin que estuvieran convencidos de que estas cosas pasan hagas lo que hagas para evitarlas, mi pregunta fue: ¿Cuánto le cuesta a la compañía en ventas un día de parada de sistemas? La respuesta era que el impacto es poco sobre el cliente si son solo 24 horas, pero es importante a partir de ahí y crítico si llega a durar 72 horas o más. Entonces ¿debemos asegurar la disponibilidad de sistemas con un margen de parada de 24 horas? pregunté al comité de dirección. SI CLARO, eso es imprescindible, no podemos permitirnos trabajar sin sistemas más de un día entero. Recordarles mi propuesta de mejora de la seguridad y disponibilidad de los sistemas fue fácil porque la tenían hacía meses en un cajón y ahora tendrían que reconsiderarla. Se aceptó un nuevo presupuesto, se instaló un sistema redundante (MIMIX en aquella época) y se mantuvo una copia en línea de las bases de datos y librerías de programas. Desde entonces las crisis tecnológicas dejaron de tener impacto directo en la actividad de los negocios, pero el plan de recuperación de desastres empezó a figurar en la agenda de todos los departamentos ya que siempre pueden darse circunstancias en las que el usuario tendrá que tomar acciones para continuar trabajando, pues el fallo tecnológico es tan solo uno de los posibles problemas que se pueden presentar. Catástrofes naturales, incendio o inundación de locales, o hasta una enfermedad contagiada a la plantilla, son ejemplos de situaciones de riesgo en las que el día a día no permite pensar pero que pueden hacer caer las cifras de un negocio si no se ha previsto como actuar en los casos de crisis.
Los departamentos o personas responsables de la organización de las empresas deben diseñar e implementar los procedimientos necesarios para dar respuesta a las situaciones de crisis y para ello, hay metodologías cuyo uso es necesario y expertos en la materia, cuya participación es recomendable si se desea garantizar un cierto nivel de seguridad en la continuidad de los negocios. Implementar el plan de recuperación de desastres, auditarlo y probarlo periódicamente es la mejor manera de garantizarse la supervivencia ante las crisis no previstas.
