Bueno podríamos concluir el tema de continuidad de negocio sin hablar de los planes de continuar el
negocio como tal y el plan de recuperación de desastres es decir el BCP Business continued plan y el
DRP Disaster Recovery.
Lo primero es aclarar cuál es la diferencia entre estos dos.
Hay muchas diferencias sutiles si las quieren ver así pero creo que la que más nos diferencia es el
problema es el que realmente intentan solventar en este caso el BCP lo que intenta solventar problemas
con continuidad del negocio es decir un ejemplo muy clásico no tenemos el pago de planilla.
Bueno se nos cayó el servidor donde nosotros hacemos el pago automático o el depósito de la planilla
o de los cheques de los nuestros empleados.
Cuando se cayó el sistema igual el negocio el negocio otra vez palabras clave tienen que continuar.
Es decir yo lo que voy a hacer es girar cheques lo que voy a hacer es pagar en efectivo etcétera etcétera.
Entonces el BCP es lo que se enfoca es en el negocio es decir no importa la tecnología en este momento
se me cayó el sistema de facturación hay que facturar entonces a mano se me cayó la planta telefónica
va a recibir correos o a recibir whatsapps se me cayó etcétera etcétera.
Sea no intento restablecer la tecnología sino que el negocio continúe.
Por el contrario el DRP si se basa en la tecnología de DRP lo que busca es restablecer la tecnología
que se cayó es decir bueno se cayó el sistema de facturación bueno qué tenemos que hacer.
Tenemos que contratar un enlace redundante.
Tenemos que solventar este problema tenemos que poner esta política en el fãtbol.
Tenemos que movernos al sitio alterno tenemos que regresar del sitio alterno al sitio principal es decir
todo lo que tenga que ver con tecnología.
Entonces en palabras muy sencillas BCP es negocio de repes tecnología verdad.
Luego tenemos los eventos que pueden romper la funcionalidad eventos muy básicos.
No tenemos los errores y las omisiones que típicamente son considerados los más comunes tenemos los
desastres naturales por ejemplo terremotos huracanes inundaciones sunami etcétera etcétera.
Si tenemos que tomar en cuenta por ejemplo hoy en día estamos viviendo la pandemia del coronavirus que
es un desastre lo podríamos categorizar como desastre natural pero si tenemos que tener planes de respuesta
ante eso también verdad.
Por ejemplo lo que se está implementando hoy en día es el JOMO Hafiz el teletrabajo o la tele con las
videoconferencias etcétera.
Tenemos que tener un plan de continuidad.
Luego tenemos los problemas eléctricos de verdad es decir se cae la electricidad y ya no tenemos electricidad
en videos anteriores de los tipos de falla de electricidad en este caso podríamos tener.
PS Es una planta eléctrica para poder continuar.
Luego tenemos las temperaturas por temas de humedad verdad muchas veces no consideramos esto cuando
se coloca un datacenter de repente hay humedad en el ambiente verdad podría causar problemas eléctricos
y también podría causar cualquier clase de interferencia en los datacenter.
Luego tenemos los problemas lamentablemente de terrorismo o sabotaje o cualquier tipo relacionado a
las guerras verdad que así pasan.
Recordemos el lamentable 9 11 en Nueva York.
Fue un impacto a nivel mundial verdad que se dio entonces sí tenemos que tomarlo muy en cuenta yo creo
que a raíz del 9 11 que salieron muchas regulaciones y leyes tanto estadounidenses como internacionales
para poder evitar este tipo de problemas pues intentar anticiparse a esto verdad.
Luego están los atacantes que están motivados por temas financieros.
Hay redes que crimen organizado en cuanto a ciberseguridad se le conoce verdad.
Ya hay redes conocidas internacionalmente que se dedican a eso atacar a personas o empresas por dinero
Orda una especie de mercenarios si así lo quieren ver y luego luego tenemos problemas con el personal.
Es decir por ejemplo otra vez en este caso la pandemia que estamos viviendo hoy en día del coronavirus
o del Kobi 19 hace que muchas personas estén posiblemente con enfermedad o que muchas personas realmente
no puedan llegar al trabajo o que tengan familiares enfermos y por eso deban quedarse en cuarentena
etcétera etcétera.
La pérdida de personal tienen que ser algo que tengamos que tomar en cuenta por ejemplo el vicepresidente
y el presidente de la compañía no viajen si van en un viaje de negocios o siempre viajan juntos pues
que no viajen en el mismo avión o que no vayan en el mismo carro porque si lamentablemente le pasa algo
a alguien pues ahí está el otro que puede asumir el rol.
Entonces también tenemos que tomar en cuenta eso.
Eso se ve un poco frío un poco calculador pero bueno hay que tomarlo en cuenta.
De igual forma Varda luego que hay un proceso para activar el DRP o el BCP que es muy básico a muy alto
nivel.
Otra vez puede cambiar puede modificarse pueden agregarle pasos estos solo son buenas prácticas y el
primer paso es básicamente activación del equipo es decir nosotros tenemos un equipo para poner en marcha
el BCP y el de repe la siguiente fase es seguir el BCP DRP como tal que en este caso responder.
Luego tenemos la comunicación.
Esto es clave.
Debemos de saber cómo comunicar un desastre y tan siquiera si es un desastre como tal verdad.
Cómo nos comunicamos con el público con los stakeholders ya sea clientes proveedores partners etcétera
etcétera.
Es clave durante un desastre a través de la historia podemos leer muchos ejemplos de muchos desastres
y tal vez la magnitud o el impacto del desastre fue alto pero la forma en la que se manejó hacia el
público pudo mitigar un poco ese impacto hacia la imagen el negocio entonces esto también es clave.
Luego tenemos el amor el famoso perdón RCA que aquí lo que se busca es encontrar la causa raíz de lo
que sucedió y la reconstrucción verdad como se había dicho en videos anteriores.
No podemos decir que un desastre o un incidente se acabó en su totalidad hasta que no estemos operando
de forma normal en nuestro sitio principal verdad estar operando de forma normal en un sitio alterno
no se considera el haber ya pasado un desastre y luego lo queremos ver como una especie de proyecto
tenemos que seguir algunos pasos organizados para desarrollar el BCP aparte de ponerlo en práctica y
aparte desarrollar todos los pasos lo acabamos de ver para ponerlo en práctica y ahora pero cómo lo
desarrollamos desde cero.
Supongamos que no tenemos absolutamente ningún documento relacionado a BCP o de repe.
Lo primero es la iniciación de un proyecto pero esto es como común con cualquier proyecto.
Se lo presentamos a Junta obtenemos aprobación de junta obtenemos recursos obtenemos etcétera etcétera.
Recuerden que éste como cualquier otro proyecto si no tiene la aprobación de junta directiva o de Hoppus
management es muy difícil que se vaya realmente a lanzar o que vaya a sobrevivir mucho tiempo.
Posiblemente podamos escribir un par de documentos pero se quedan ahí en la gaveta para nunca ser utilizados.
Entonces teniendo el proyecto iniciasen o la iniciación del proyecto pasamos a intentar ver cuáles son
nuestros activos más críticos.
Para esto hay un análisis que se llama bisnes impact analysis o análisis de impacto en el negocio que
lo que busca es ver literal eso qué tanto se va a haber impactado en negocios si perdemos x z activo
es decir por ejemplo si nosotros somos un Commerce o vendemos cosas en línea o vendemos nuestros productos
en línea pues obviamente el servidor web podría podría ser un activo que cause mucho impacto al negocio.
El servidor de base de datos que soporta este servidor web el enlace de datos que soporta ese servidor
web el firewall que está en frente de ese servidor web etcétera etcétera.
Todo lo que sea relacionado a ese modelo de negocio va a ser de alto impacto y aquí es donde empezamos
nosotros a ver el análisis.
Ahora bien no solo es pérdida de la información aunque de impacto va a tener sino cuánto tiempo nos
podríamos permitir estar abajo.
Recuérdese que los riesgos los podemos mitigar pero siempre existe un riesgo residual el cual queda
después de cualquier mitigación.
Entonces en el caso que realmente se dé un problema cuánto tiempo nos permitiríamos estar abajo.
Aquí vienen dos conceptos clave no sólo para el día a día de seguridad informática sino para el examen
que es el RTO y el RPA RTO significa recovery time objete o tiempo de recuperación objetivo verdad y
como su nombre lo dice es eso cuánto tiempo podría estar abajo la forma de calcularlo puede ser cualitativa
y cuantitativa como habíamos visto anteriormente.
Una forma por ejemplo cualitativa o intentando pasar de forma cualitativa cuantitativa puede ser bueno
supongamos el ejemplo del e-commerce.
Yo vendo 50 productos por minuto y en promedio la transacción o cada venta es de 5 dólares por ejemplo.
Entonces hago la multiplicación y me da un resultado.
Entonces yo decía bueno yo a cada hora o cada dos horas yo vendo 200 mil dólares.
Yo en mi negocio podría permitirse perder 50 mil dólares y si pierdo 200 mil dólares cada dos horas
pues posiblemente sí podría permitirme perder 50 mil dólares entonces 30 minutos podría ser mi RTO un
ejemplo.
Pero recuerden que volviendo al ejemplo del ecommerce no es lo mismo la venta posiblemente en febrero
o marzo que la venta cerca de las fiestas.
Por ejemplo las fiestas de fin de año Navidad etcétera etcétera.
Podría ser que tenga un pico en mis ventas entonces ahí los 30 minutos o los 50 mil dólares posiblemente
no se van a llegar a los 30 minutos si no siguen en 5 minutos.
Entonces RP significa Recovery Point objetivo y está más relacionado a la cantidad de información que
podría permitir perder.
Por ejemplo yo podría permitir perder dos transacciones tres transacciones cinco transacciones.
Yo podría permitirse perder un día de información de esas transacciones en la base de datos que me podría
perder.
Podría permitir perder un mes.
No sé es la cantidad de información que me podría permitir perder.
Entonces la combinación de estos pues un poco más de respaldo en cuanto al tiempo que podría permitirme
estar abajo o como se le conoce el MTD Maximón Tour down time o máximo tiempo tolerable de estar abajo.
Luego tenemos controles preventivos o estrategias de preventivos es decir bueno ya nos pasó el desastre
que hacemos ahora.
Para esto tenemos los sitios alternos o los sitios de recuperación donde tenemos varias categorías pero
digamos que las tres más básicas están los sitios calientes los sitios tibios o los sitios fríos o al
final Goldschmidt Warm Sight y outside.
Qué significa esto.
Es la cantidad.
Esto cada cada cada cita el turno conforme vayamos agregando o quitando dispositivos para que se parezca
al ambiente de producción que puede tener una denominación específica.
Por ejemplo un Colsanitas un sitio frío podría ser bueno si tengo energía eléctrica y tengo conexión
a internet pero eso es todo lo que tengo es un sitio frío ahí tendría que llevarme los servidores yo
tendría que ir a uno de los equipos de trabajo etc etc etc..
Luego tenemos un sitio tibio o Worm que aquí lo que dice es bueno entonces aquí ya tengo un par de servidores
de repente y los más críticos tengo un par de plantas una planta telefónica tengo un servidor de correo
un par de laptops etcétera etcétera.
Parqueo para los usuarios.
Bueno algo así y outside pues es básicamente un sitio espejo ahí donde tenemos todos los servidores
básicamente un ambiente de producción ahí en espejo con nuestro ambiente de producción real verdad nuestro
ambiente de producción primaria.
Ahora bien por qué vamos a decidir un sitio frío sobre un sitio caliente si estamos diciendo que con
un sitio caliente tenemos photographs casi al 100 por ciento.
Esto no es nada barato de mantener es muy costoso entonces algunas empresas dicen Bueno yo estoy mitigando
el riesgo entonces lo que voy a hacer es reducir riesgos sí a un nivel no tan bajo pero es lo que me
puedo permitir pagar con un sitio frío.
Algunas empresas incluso dicen Bueno yo ni siquiera me puedo permitir pagar un sitio frío y lo que se
hizo es que se hacen reciproca agreements o acuerdos de reciprocidad con otras empresas es decir el
banco hoy el banco be no se pueden permitir pagar ni siquiera un sitio frío ni siquiera un Calcis.
Lo que hacen es que se juntan y dicen bueno si a ti te pasa algo tú te vienes a operar a mis instalaciones
y si a mí me pasa algo me voy a operar a tus instalaciones.
Si a mí no me parecen creo que es una locura que muchas empresas hacen eso lo que pasa es algo que se
da y esa es una solución que podríamos considerar en algún momento.
Y obviamente no podemos hablar de sitios redundantes y tocar la famosa nube si la nube provee muy buena
redundancia o un muy buen fold tolerancia a nuestro ambiente de producción pero recuérdense otra vez
la nube es simplemente la computadora de alguien más podríamos tener ese as para términos de confidencialidad
y privacidad.
Pero bueno al final es la computadora de alguien más.
Entonces hay que tomarlo en cuenta nada más verdad y bajo la sombrilla del BCP tenemos algunos planes
que podríamos dividir los digamoslo así para que un proyecto para crear para que el proyecto de creación
del BCP no se vuelva un proyecto inmenso interminable y que cuando al fin terminemos de crearlo ya es
obsoleto porque a introdujimos una nueva tecnología la empresa borla entonces por ejemplo tenemos planes
como business Recovery Plan que otra vez viene regions rizomas un plan o recorrés recuperación no recuperación
sino que resumir el negocio básicamente sea volverlo a poner en marcha.
Tenemos por ejemplo Continuity of operations plan que lo que provee son procedimientos por ejemplo para
mantener la organización o mantener los procesos esenciales de la organización.
Luego tenemos Continuity of support plan Aichi con contenido DisciPPlina es decir un plan de contingencia
de Hite es decir nosotros como Hite por ejemplo podríamos decir bueno yo sé que los servidores más críticos
para mí son el de contabilidad el de clientes el del e-commerce.
Entonces yo voy a tener mi propio plan para saber que si se me cae un enlace para estos servidores pues
yo voy a resumir o voy a continuar operando de esta forma.
Luego tenemos un plan de ciber incidentes tenemos un plan de pers para el personal es decir cómo voy
a evacuar al personal en caso exista una disrupción de algún medio o algo por el estilo y así tenemos
muchos planes en los que podremos resumir yo creo que les mencioné los más comunes o los que más o menos
se usan casi todo el tiempo para no quedarnos en un proyecto enorme e interminable para crear un BCP.
Pero bueno siempre tenemos que tomar en cuenta que la meta final es crear el BCP luego tenemos los árboles
de llamadas que para esto nos sirve saber a quién llamar en el momento de una emergencia cuando las
papas se nos están quemando como diríamos coloquialmente acá no sabemos a quién llamar no sabemos quién
es el responsable quién es el que va a tomar las decisiones.
Entonces tener un árbol de mamá es muy importante para saber si se cae este enlace y yo sé que tengo
que llamar a tal persona si se cae o pasa algo en el edificio es que tengo que llamar a tal persona.
Si pasa algo me tengo que llamar a la policía si pasa algo tengo que llamar a los bomberos etcétera
etcétera.
Y luego tenemos por último los backups qué tipos de backups podríamos tener nosotros ya tomando en cuenta
el RTO.
Se acuerdan que en el video anterior les dijo que no tenía sentido tener decir cuánto tiempo te podrías
escarabajo a no.
Y la respuesta es siempre media hora 15 minutos o mucho menos.
Ah bueno y entonces cada cuánto haces backup.
Ah bueno una vez a la semana.
No no no hace mucho verdad.
Entonces ahora que ya nosotros sabemos cuál es nuestro RTO tenemos diferentes opciones para hacer nuestro
backup.
Por ejemplo lo más común es el full backup Shaki pues no hay nada más que agregar más que decir que
es un backup de todo guarda toda la información en una base de datos toda la información al final todo
lo que pueda hacer un backup lo hacemos en el backup lo tenemos los backups incrementales y esto se
acepta como un incremento del último backup full.
Ahora tenemos un Zul por ejemplo podríamos hacer un Churba copa el domingo y de lunes a viernes puedes
implementar el incremental verdad entonces para restaurar un backup incremental necesitamos copia de
cada uno de esos días es decir si yo quiero por ejemplo mi sistema se cayó el viernes yo quiero restaurar
el backup pues yo tendría que restaurar del jueves del miércoles del martes del lunes y el domingo.
Luego tenemos el diferencial el que acabamos de ver es el incremental y ahora tenemos el diferencial
que opera en una manera similar al incremental pero por una diferencia muy clave verdad el archivo que
hace backup es el archivo que cambio nada más.
Es decir si yo tengo cinco archivos y el domingo le hice backup pero el lunes solo cambio uno pues solo
hago backup de verdad y para restaurarlo lo único que necesitamos es el último backup el último full
backup y el último backup diferencial por ejemplo volvemos al ejemplo de que se me cayó la base de datos
se me cayó el sistema el día viernes que quiero regresar el backup de toda esa semana sólo tendría que
restaurar el del jueves y el del domingo.
Y luego tenemos muchas otras opciones.
Electronic boletin Journalism etc etc etc. podríamos decir bueno yo no puedo hacer backups full porque
el ancho de banda se me acaba yo lo voy a hacer durante las noches yo lo voy a hacer lo voy a hacer
por pedazos yo lo voy a hacer un pedazo a mediodía un pedazo medianoche realmente o podría incluso decir
Bueno mi rto es casi cero mi arte o podría ser dos minutos un minuto 30 segundos.
Aquí lo que tendríamos que hacer es básicamente un espejo cuando una transacción se guarda en mi sitio
principal.
También se guarda en el sitio alterno básicamente y bueno así tenemos muchas opciones de backups.
Creo que el fútbol el incrementar el diferencial son las tres más comunes pero no hace sentido a comprar.
Obtener una solución de backups.
Si ni siquiera tenemos un RTO definido si ni siquiera tenemos un bisnes Impact análisis definido como
para saber que si puedo permitir perder y que no me puedo permitirme perder y cuánto tiempo puedo estar
abajo.
Hay muchas empresas que dicen a mi mi rto es casi cero de verdad son dos segundos un segundo milésimas
de segundos y no puedo ni siquiera permitirme ese trabajo.
Pero ni eso no. Entonces aquí lo que sea la tecnología ha ido evolucionando y hay un tema nuevo que
se llama hiper Convergencia y esto es básicamente y de verdad esto es un tema muy extenso y que posiblemente
no les venga una pregunta en el examen pero es un tema que vale la pena investigar y en poquísimas y
resumidas palabras la hiper convergencia es tener redundancia pero no sólo de datos no sólo de enlaces
no sólo de backups no sólo de máquinas virtuales sino de todo hay algunas tecnologías de convergencia
que implementan la tecnología Reith con bits de paridad pero a nivel de máquina virtual es decir mi
máquina virtual no necesariamente está en un espacio o en un disco específico sino que puede estar distribuida
en cinco o seis discos la máquina virtual que estoy utilizando entonces a la hora de que un disco falle
pues la máquina igual sigue funcionando porque está distribuida en los discos lo único que hace un fail
over hacia otro disco y la máquina virtual sigue como si nada.
Y así tenemos redundancia de datos redundancia de información enlaces y lo mágico de esto es que puede
ser dentro de un solo apañas dentro de un solo equipo un work crujió e Intel creo que andan ahí peleándose
por la cabeza de este nuevo mercado pero si es una tecnología que vale la pena investigar y que podríamos
tomar en cuenta para temas de backups o temas de continuidad del negocio.
Y por supuesto después nuestro BCP y de repe finalizado o concluido o ya ya realizamos nuestra documentación
o no podemos dejar de probarlos.
De hecho muchas regulaciones no solo piden que existe un BCP sino que se haga un real o una prueba una
vez al año o dos veces al año.
Bajo esta perspectiva tenemos varios tipos de test.
Por ejemplo el test donde sólo hacemos un checklist es decir bueno tenemos seguridad para el edificio
si tenemos seguridad en el data center si hay candados en el data center si hay algún supresor de fuego
en el datacenter si etc etc. Es un checklist más que todo.
Luego tenemos un walkthrough que es básicamente un bulto o digamos que ponemos escenarios donde decimos
bueno qué pasaría si si sucede esto.
Así se puede porque en la sección tal decimos que vamos a responder de tal forma en la sección tal le
decimos que nos va a ir de tal forma etcétera etcétera como ir un paso más allá que un simple checklist
digámoslo así.
Luego tenemos un test de simulación que eso ya es interrumpir tal vez algún servicio o decir bueno vamos
a cerrar este puerto para ver qué es lo que se va a hacer.
Hay una herramienta que a mí me gusta mucho pero que necesita mucha madurez en cuanto a veces de repes
se refiere y es una herramienta que utilizan Netflix que se llama Kheos Mankiw o el mono del caos y
esto obedece a una tendencia que se llama la ingeniería del caos y lo que dice es esto.
Este QE2 monjil lo que hace es de repente introducir un poco de entropía en el sistema.
De repente voy a cerrar un puerto para ver qué pasa de repente voy a a a bajar el servicio de la base
de datos para ver cómo se reacciona otra vez.
Esto es básicamente ponernos el pie y tropezar con nosotros mismos.
Si funciona muy bien para actualizar BCP es para derrepente para parar realmente testear que nuestra
continuidad esté funcionando como lo esperamos pero otra vez requiere mucha madurez de parte del negocio
para poder implementar este tipo de herramientas.
Luego tenemos la prueba en paralelo es decir si en dado caso nosotros tenemos un data center que es
un espejo podríamos interrumpir ese datacenter y ver cómo reaccionaríamos o de repente decir Bueno vámonos
al sitio alterno a operar para ver si realmente el sitio alterno está o puede aguantar la carga de un
día a día.
Y luego tenemos la interrupción total aquí se lo conoce como el famoso botón Lasorda ir al servidor
y apagarlo.
No lo recomiendo pero bueno es un estilo de prueba.
Esto ya es la última prueba que podríamos hacer porque realmente si mide la fortaleza o que también
se realizó un BCP luego tenemos el mantenimiento del plan solo para mencionar este plan pues se tiene
que mantener por lo menos una vez al año una vez cada seis meses o cada vez que se introduce una tecnología
nueva en la organización es decir de repente el BCP lo hicimos cuando teníamos un árbol y dos máquinas
y ahora ya tenemos 50 laptops ya tenemos tres Farewell tenemos un PC tenemos un RPG etcétera etcétera
pues es momento de actualizar nuestro BSP verdad.
No es un plan que se tenga que hacer una única vez y dejarlo guardado para eterna eterna historia o
eterno recuerdo sino que se tienen que estar actualizando constantemente.
Ahora bien como casi todo en esta vida de seguridad tenemos algunos frameworks que nos pueden ayudar
para crear o para tener una guía de cómo realmente tenemos que crear qué pasos tenemos que seguir.
Buenas prácticas más que nada por ejemplo tenemos latinista SP 800 en 34 bueno Lannes está metida en
casi todo lo que tenga que ver con ciberseguridad.
Qué es un plan para la contingencia una guía.
Más que todo para los sistemas del sector federal pero sí que lo podemos acceder porque está accesible
al público.
La ISO que obviamente no se puede quedar atrás con la 27 mil 31 verdad que nos provee un detalle o un
framework de cómo poder implementar un BCP y luego tenemos también la ISO 23:22 1301 que viene de un
Breach British Standard o Bs verdad que casi todas las hizo bien entre dos veces y luego tenemos el
Bci de Piscis Continuity Institute verdad que está que ellos publican buenas prácticas o gains de cómo
podríamos nosotros crear nuestro nuestro BCP verdad y esas son algunos frameworks que podríamos utilizar.
Obviamente no se reduce a esos tres nada más o a esos cuatro que vimos pero sí que nos pueden ayudar
mucho para poder crear y darnos una dirección si no tenemos un BCP definido.
Y bueno eso es todo amigos.
Espero les ha gustado y nos vemos muy pronto.