Protegiendo procesos de negocio

¿Existe el plan B?

Introducción

Niklas Luhmann (1979) nos comenta que la confianza es un mecanismo de reducción de la complejidad, destacando la relación entre la noción de confianza y las nociones de riesgo y expectativa. En el uso de la tecnología, hay ciertos riesgos que son implícitos y otros no son tenidos en cuenta por que hay una idea de que ciertas amenazas no van a impactar a ciertas industrias o procesos. La famosa frase de que a “nosotros esto no nos va a pasar”, genera que los procesos de negocio que contengan tecnología como soporte no cuenten con las protecciones adecuadas.

Hoy en día la mayoría de las organizaciones no protegen sus procesos de negocio en cuanto a continuidad y calidad de servicio y/o producto. Vamos a observar cierto nivel de cuidado en los procesos de algunas organizaciones que tienen encima la vara de “cumplimiento” (compliance), y ese requerimiento en muchas ocasiones, no protege al ciento por ciento el proceso, si no, es más bien, una medida precautoria ante un incidente y que el que solicita el nivel deseado de cumplimiento le dé la razón o lo apruebe.

Por otro lado, la tecnología está cada vez más inmersa en los procesos de las organizaciones y la filosofía del “plug and play” de los ’90 cada vez más radicalizado. Post pandemia, tanto los usuarios finales como las organizaciones, han comenzado a usar más la tecnología (nube, IA, automatización de procesos, etc), empujado por cuestiones de contexto, pero en ese proceso de sumar cada vez más recursos tecnológicos, muy pocas veces se preguntan:”…y si falla, ¿qué hacemos?…”.

Una confianza explicita en el uso de la tecnología y no evaluar los riesgos provoca lo que viene sucediendo en las organizaciones en los últimos años.

Procesos de negocio

Los procesos de negocio son el conjunto de actividades o tareas estructuradas con el objetivo de producir un servicio o producto específico para un cliente o mercado en particular. Estas actividades pueden ser internas o externas dentro de una organización y son esenciales para la generación de valor y la eficiencia operativa.

Aunque la Real Academia Española (RAE) no proporciona una definición específica para “procesos de negocio“, podemos definir “proceso” como un conjunto de fases sucesivas de un fenómeno natural o de una operación artificial. Aplicado al contexto de los negocios, se refiere a las series de actividades o tareas que se realizan de manera consecutiva para lograr un objetivo determinado. Un proceso de negocio, por lo tanto, puede definirse como una secuencia de actividades, tareas o acciones organizadas con el propósito de alcanzar un objetivo específico dentro del ámbito comercial o empresarial. Estos procesos son fundamentales para la eficacia y la eficiencia de una organización, y su adecuada gestión es crucial para el éxito y la sostenibilidad en el mercado.

Vamos a tocar sobre todo el punto que mencionamos en el párrafo anterior, donde decimos “adecuada gestión”, no siempre se cumple y cada vez menos en términos tecnológicos si hablamos de aspectos de Ciberseguridad.

Protegiendo Procesos de Negocio – Plan B

En el contexto de los procesos de negocio, un Plan B o contingencia se refiere a un conjunto de medidas alternativas diseñadas para garantizar la continuidad operativa en caso de que el plan principal falle. Estos planes son esenciales para mitigar riesgos y minimizar el impacto de eventos inesperados que podrían interrumpir las operaciones normales de una organización. Si queremos analizar algunos componentes básicos, podemos decir que posee los siguientes componentes:

1. Análisis de Riesgos: Es fundamental identificar los posibles riesgos que podrían afectar los procesos de negocio. Esto incluye evaluar tanto las amenazas internas como externas, así como el impacto potencial de cada riesgo.
2. Priorización de Procesos Críticos de Negocio: No todos los procesos de negocio tienen el mismo nivel de importancia. Es vital priorizar aquellos procesos que son críticos para la operación y la supervivencia de la organización. Esto permite enfocar los recursos y esfuerzos en las áreas que más lo necesitan.
3. Identificación de Recursos Alternativos: Un buen Plan B debe identificar recursos alternativos que puedan ser utilizados en caso de una contingencia. Esto incluye personal, tecnología, infraestructura y proveedores que puedan ser movilizados rápidamente.

Un Plan B no es efectivo si no se prueba regularmente. Realizar simulacros y pruebas periódicas ayuda a identificar posibles fallas y áreas de mejora, asegurando que el plan sea viable y eficaz cuando sea necesario.

En resumen, un Plan B o contingencia para procesos de negocio es una herramienta crucial para la gestión de riesgos. Al identificar y prepararse para posibles interrupciones, las organizaciones pueden asegurar la continuidad de sus operaciones y mantener la calidad del servicio o producto ofrecido a sus clientes. Un enfoque proactivo y bien planificado en la contingencia no solo protege los intereses de la organización, sino que también fortalece la confianza de los clientes y otros stakeholders en su capacidad para enfrentar desafíos imprevistos.

Amenazas a los Procesos de Negocio

Para asegurar la continuidad y el éxito de las operaciones comerciales, es fundamental identificar y mitigar las amenazas que pueden afectar los procesos de negocio. Estas amenazas pueden ser diversas y provienen de múltiples fuentes, pero vamos a hacer foco en dos que son dolores para las organizaciones:

1. Errores Humanos: Los errores humanos son una de las causas más comunes de interrupciones en los procesos de negocio. Estos pueden incluir desde descuidos en la ejecución de tareas hasta malas decisiones estratégicas. La capacitación adecuada y la implementación de protocolos rigurosos pueden ayudar a mitigar estos riesgos. Si hablamos de Ciberseguridad, escuchamos o leemos de manera cada vez más frecuente que una organización fue víctima de un ciberataque y que todo empezó por que alguien abrió un correo electrónico (phishing) y realizó acciones que si lo pensaba fríamente no lo haría. La confianza desmedida de los usuarios, la poca capacitación sobre las amenazas en ciberseguridad, el crecimiento de la IA, provoca que el 90% de las organizaciones afectadas en sus procesos, fuera por un error de una persona que provoca sin querer un incidente.
2. Fallas Técnicas – vulnerabilidades: Las fallas en la tecnología y los sistemas de información pueden causar interrupciones significativas. Esto incluye desde fallas en el hardware hasta problemas de software. Es crucial contar con sistemas de respaldo y planes de recuperación ante desastres para minimizar el impacto de estas fallas. La ausencia de mantenimiento puede provocar el surgimiento de vulnerabilidades que obviamente serán explotadas tarde o temprano por los ciberdelincuentes. Hoy no contar con una robustez en los recursos tecnológicos que participan en los procesos de negocio, pueden provocar un “jaque mate” a la organización.

¿A dónde vamos?

Si nos viene acompañando hasta aquí en la lectura de esta nota, observará que hemos hablado de procesos de negocio, plan de continuidad y amenazas (tratando de no profundizar en todas ellas que podríamos escribir un libro). Ahora bien, a donde queremos llegar con todo esto: las organizaciones no están preparadas para responder ante ciertas situaciones.

Si hablamos de fallas técnicas, que mejor ejemplo de lo que paso con CROWSTRIKE en el 2024, en donde la ausencia de un control de desarrollo y despliegue de la solución FALCON (antimalware) paralizó los procesos de negocios de muchas organizaciones generando pérdidas millonarias. No fue un ciberataque, simplemente alguien no valido o controló una solución que estaba por ser desplegada a millones de ordenadores en el mundo. Como consecuencia, millones de usuarios se enojaron con Microsoft porque sus sistemas operativos no dejaban de mostrar pantallas azules y la corrección era netamente manual. Ahora bien, si yo llevo mi auto a una estación de servicio y el operador del surtidor pone un combustible que no es aceptado por mi vehículo, debo hacerle un juicio ¿al que me vendió el mismo?, ¿al fabricante?, ¿al que me expendió el combustible?, ¿a la petrolera?. Es el debate hoy en día de este caso, y simplemente el responsable es: “la organización que no cuidó de sus procesos de negocio”. La organización afectada fue la que eligió la tecnología, desplegó la misma, pero no analizó si la misma fallaba como iba a soportar sus operaciones y productos. Entendamos, que esto afectó a aeropuertos, hospitales, bancos, y toda organización pública o privada que tenia un Ms Windows y la solución de Crowdstrike instalada en sus equipos.

El fallo además de tener un impacto por la cantidad de ordenadores afectados, era por el proceso de normalización, no podía desplegarse un proceso automatizado para que lo resolviera, se dependía de personas, recursos humanos que intervinieran y mitigaran el problema. Que confianza nos puede dar , por ejemplo una aerolínea área, si ante un incidente de este tipo, podemos decir que es controlado por que no fue un ciberataque que genera más incertidumbre,  nos pone en una pizarra el estado delos vuelos y nos da el ticket de embarque escritos a mano en un papel símil servilleta descartable.

Si bien el caso mencionado tenemos un claro ejemplo de error humano, también tenemos casos de vulnerabilidades que son explotadas por ciberdelincuentes y afectan la operación de miles de organizaciones día a día. Hoy el ciberdelito es una actividad muy rentable y el año 2025 vamos a ver una escalada muy importante del mismo, sobre todo por el auge de plataformas de IA que dan cada vez más soporte a actividades maliciosas, como también, las organizaciones que descuidan sus datos y aspectos de ciberseguridad con tal de hacer usufructo en alguna plataforma de IA y tener algún beneficio, sin medir los riesgos de subir datos de la organización (todos quieren hacer algo con IA para mostrar que están en la ola).

¿Hacemos una torta?

En base a todo lo mencionado anteriormente, vamos a aseverar que las organizaciones, en muchos casos, carecen de un plan de contingencia, ya sea por un fallo de software o por un ciberataque.

Ahora la pregunta que le hago al lector, es ¿un problema tecnológico? O ¿un problema de procesos?, La respuesta es clara: es netamente un problema de procesos. Algo que no se incorpora a los procesos de negocio, activos tecnológicos que se suman y no se los protege ante cualquier tipo de fallo. Vamos a ver cierto nivel de madurez, en organizaciones que tiene que cumplir con regulaciones (por ejemplo Bancos, Hospitales, etc) o por cumplimientos exigidos por un asociado sin la cobertura total, más bien algo armado para tener y pasar la exigencia.

En el ámbito tecnológico, un “Playbook” es un conjunto de instrucciones detalladas que guían a los equipos a través de procesos específicos para manejar situaciones comunes o críticas. Estos documentos son esenciales para garantizar la consistencia, la eficiencia y la eficacia en la respuesta a eventos que pueden afectar negativamente a la organización.

Si queremos dar un ejemplo de ello, podemos tomar una caja con el preparado para hacer una torta en nuestro hogar. En la parte trasera de la misma vamos a tener los ingredientes (ahora en más vamos a llamarlos REQUERIMIENTOS) y el paso a paso de cómo hacer la rica torta un fin de semana (lo llamaremos PLAYBOOK).

¿Por qué a los ingredientes le llamamos REQUERIMIENTOS? Porque sin ellos no podremos hacer la misma y deberemos improvisar. Por ejemplo, si nos cortan el gas para hacer la misma en el horno, podemos usar un horno eléctrico. Pero si no tenemos agua, no la podremos hacer.

Playbooks

En estos dos últimos años hemos trabajado en esta estrategia, y uno de los puntos fuertes de la metodología de trabajo, es analizar los ingredientes, es decir los REQUERIMIENTOS. Al hacerlo, observamos que las necesidades de los procesos de negocio están muy lejos a lo que provee el área de tecnología y en el caso de un incidente, los procesos de negocio se verían fuertemente afectados.

Los playbooks son vitales en tecnologías de la información (TI) porque:

1. Proporcionan respuestas rápidas y estandarizadas ante incidentes.
2. Mejoran la formación y la capacitación del personal.
3. Reducen riesgos y minimizan el impacto de fallos y ciberataques.
4. Fomentan la mejora continua mediante la revisión y actualización de procesos.

Entonces, definimos a los Playbooks como un conjunto de procedimientos detallados y predefinidos que guían a los equipos de respuesta a incidentes en la detección, investigación y mitigación de amenazas.

¿Por qué implementar Playbooks?

• Cualquier organización puede tener sus procesos de negocio afectado en base a lo que comentamos en párrafos anteriores.
• Es necesario contar con un esquema ordenado de procesos de recuperación.
• Permite hacer revisión de muchos puntos de protección de datos.
• Involucrar a distintos actores dentro de la organización. Se debe entender que el proceso de recuperación no depende solo de IT.
• Por cumplimiento de requerimientos normativos.

Requerimientos para armar un Playbook exitoso.

Para llevar a cabo un playbook exitoso, debemos tener todos los ingredientes o al menos definiciones de como trabajar ante ciertas situaciones. Vamos a mencionar los más importantes.

1. Requerimiento 1: Personas

Su plan de respuesta debe identificar, con anticipación, a todas las personas y equipos que deberán participar en un evento. Los roles recomendados incluyen los siguientes:

• Líder de equipo
• Alta gerencia
• Representante legal
• Personal de TI
• Personal de seguridad de TI
• Experto en la materia de ransomware
• Mesa de ayuda
• Personal de Respuesta a incidentes
• Relaciones públicas (para comunicaciones internas y externas)
• Consultores externos, según sea necesario.
• Cumplimiento de la ley, según sea necesario.
• Persona de contacto del seguro de ciberseguridad, si está involucrada.

En organizaciones más pequeñas, muchas de estas funciones podrían estar representadas por una persona o ser desempeñadas por recursos externos. El objetivo es identificar todos los roles y las personas necesarias, con anticipación, e informarles sobre el plan de respuesta, sus objetivos y cómo deben planificar para reservar tiempo para revisarlo, aprobarlo y practicarlo. Estos roles deben estar asignados formalmente.

• Requerimiento 2 : Plan de comunicaciones

No sorprende que muchos de los peores resultados se describan como consecuencia de malas comunicaciones. Por lo tanto, planifique con anticipación. El primer objetivo de comunicación que debe decidirse es cómo todos accederán al plan de respuesta de si es necesario.

Suponga que todos los dispositivos del entorno están comprometidos o fuera de servicio. ¿El plan de respuesta está impreso y almacenado físicamente en el hogar de cada participante? Si es así, ¿puede asegurarse de que cada participante obtenga copias actualizadas cada vez que se actualice? ¿Está almacenado en otro sitio de almacenamiento en línea que no está conectado al entorno principal de la organización al que se puede garantizar que todos los participantes puedan acceder si el dispositivo de la organización que normalmente usan no funciona? ¿Todos tienen claro el rol?

Es importante que la organización tenga un protocolo claro y definido para comunicarse con las partes interesadas en caso de un ataque. Esto incluye los clientes, socios, proveedores y otras partes involucradas en la operación de la organización.

Puntos a tener en cuenta

1. En caso de coordinar sesiones con las partes, que plataforma de comunicación van a usar. (Ms Team, Google Meet, Zoom, WhatsApp, etc).
2. Si la organización suspende el acceso a Internet hasta tanto se resuelva como habilitarlo, como van a usar la plataforma escogida.
3. Dentro del plan se debe contemplar una sesión de kick-off involucrando a las partes indicando aspectos del plan de comunicación, frecuencia, responsable, tipo de comunicación, etc.
4. Con que frecuencia se van a comunicar las partes.
5. Se debe tener en cuenta como involucrar a las partes interesadas de la manera más rápida y eficiente. Debe quedar formalizado el proceso.
6. Se sugiere simulacros para verificar funcionamiento.
7. Requerimiento 3: Plan de relaciones públicas

Un evento que afecte el proceso de negocio tendrá un impacto significativo en las operaciones. Deberá comunicarse con los empleados, clientes, otras partes interesadas, reguladores y, potencialmente, con el “público” a través de contactos directos y canales de medios. Deberá decidir qué comunicar a quién y cuándo. Involucre a un equipo de relaciones públicas (RP) en su plan con anticipación y obtenga su opinión sobre cómo manejar las comunicaciones para cada audiencia. Deben simular algunas plantillas aproximadas para cada tipo de audiencia. El asesor legal, por supuesto, necesita revisar todas las comunicaciones (idealmente de antemano como ejemplos simulados) y trabajar de la mano con relaciones públicas.

Deben planificar cómo comunicarse si todos los sistemas normales están caídos. Rutinariamente se ve a las víctimas de ciberataque tardar días en reconocer públicamente que ha sucedido algo. Una gran parte de esto es que todos sus sistemas y métodos de comunicación normales están caídos, y no planearon con anticipación que eso sucediera. A menudo, la única pista para el mundo exterior de que algo anda mal es la falta de comunicación de la víctima con nadie. Nadie de la organización víctima responde a los correos electrónicos. A veces, incluso los sistemas telefónicos están caídos.

• Requerimiento 4: Copia de seguridad confiable

Aunque una copia de seguridad por sí sola generalmente no mitigará todo el daño causado, una copia de seguridad confiable, exhaustiva, probada, fuera de línea y actualizada debe ser un requisito fundamental. Desafortunadamente, muchas más organizaciones creen que tienen buenas copias de seguridad de las que realmente tienen buenas copias de seguridad. Su organización necesita confirmar que tiene una buena copia de seguridad. Tiene que ser integral. En resumen, la organización debe tener políticas claras sobre la frecuencia de las copias de seguridad, la ubicación del almacenamiento de las copias de seguridad, y el proceso de recuperación de datos para garantizar el éxito del playbook.

Puntos a tener en cuenta

1. Backup aislado con una red bastión.
2. Pruebas de restauración para medir los tiempos y verificar que estén acordes a lo que necesita el negocio.
3. Contar con versionados seguros.
4. Contar con un procedimiento de revisión de integridad de los datos restaurados.
5. Tener definido el orden de restauración de la información necesaria para restaurar los procesos de negocio. Este es un punto crítico, ya que es un cuello de botella.

• Requerimiento 5: Pago de rescate

Una de las decisiones más importantes que cualquier organización puede tomar con anticipación es si pagar o no el rescate. Nadie quiere pagar una demanda de extorsión, aunque muchas organizaciones, con razón, ven más barato y rápido pagar el rescate. Algunas organizaciones se niegan éticamente a pagar un rescate. Otros están reglamentaria o legalmente prohibidos de pagar un rescate. No hay garantía de que el pago de un rescate resulte en la recuperación de datos, y mucho menos en la recuperación total. Muchas veces debe analizarse el contexto y la situación, pero es fundamental entender el pensamiento de la Dirección o Gerencia General. Hemos visto procesos de recuperación demorados por la ausencia de tomas de decisiones que luego se convirtieron en multas.

• Requerimiento 6: Plan de seguro de ciberseguridad

¿Obtendrá su organización un seguro de ciberseguridad o no? Durante años, el porcentaje de organizaciones que obtuvieron un seguro de ciberseguridad fue en aumento. Hubo grandes beneficios tanto para la compañía víctima como para la industria de seguros por hacerlo. Lamentablemente, el terrible “éxito” del ransomware ha llevado a un aumento drástico en las primas, deducibles más altos, menos cobertura y menos opciones. El seguro de ciberseguridad puede no ser el beneficio financiero que alguna vez fue. Aun así, se recomienda que todas las organizaciones consideren un seguro de ciberseguridad y decidan con anticipación si desean comprarlo.

• Requerimiento 7: Declarar brecha de seguridad

Este punto contempla lo que se necesita para declarar una violación de datos oficiales. Hay leyes y reglamentos que tienen requisitos obligatorios si ocurre una violación de datos oficiales. La mayoría de las organizaciones no quieren declarar que se ha producido una violación de datos oficiales si no es requerido legalmente. En estos días, el porcentaje abrumador de ransomware extrae datos, y eso claramente aumenta las probabilidades de que ocurra un evento de violación de datos. Como se mencionó anteriormente, no todas las filtraciones de datos cumplen con la definición legal de lo que debe informarse como una violación de datos oficiales.

Es posible que los datos robados no hayan sido un tipo de datos cubierto y definido que cumpla con una definición de violación de datos (por ejemplo, PII, PHI, etc.) o no estén cubiertos por un contrato que requiera protección. También existe la posibilidad de que lo robado no fuera tan grave. Decida con anticipación qué factores harán que su organización declare oficialmente que ha ocurrido una violación de datos.

Si se detecta/declara una filtración de datos, ¿cuál es el tiempo máximo que puede transcurrir antes de que la organización víctima deba denunciarlo y a quién se debe denunciar? Una vez más, la alta gerencia y el departamento legal deben tomar esta decisión.

• Requerimiento 8: Personal Internos y Consultores Externos.

¿A quién involucrará en un evento de ciberseguridad? ¿Lo manejará utilizando todo el personal interno o involucrará recursos externos? Si utiliza recursos externos, ¿quiénes serán? Si tiene un seguro de ciberseguridad, ¿está obligado a usar los recursos que dictan o solo se recomiendan los recursos de recuperación? ¿Usará un solo recurso o usará diferentes grupos para diferentes tecnologías y servicios involucrados? La recomendación es asegurarse de que quien sea que involucre tenga experiencia comprobada en responder con éxito a eventos de ciberseguridad. Elija un coordinador de respuesta de ciberseguridad con anticipación y permítale tener las personas necesarias para minimizar el daño, teniendo en cuenta las restricciones presupuestarias, por supuesto. No desea responder al ciberataque por su cuenta o utilizar un grupo externo sin experiencia. Quiere un líder probado que haya estado allí y haya hecho eso. Trate de establecer acuerdos de servicios (SLA) para contar con los recursos externos en tiempo y forma.

• Requerimiento 9: Actualizaciones plataforma.

Las actualizaciones de software y los parches de seguridad son fundamentales para mantener el sistema seguro y reducir las vulnerabilidades que los atacantes podrían explotar. Además, se debe contar con el antivirus actualizado (versión y firmas) en todos los servidores y estaciones de trabajo de la infraestructura de la organización.

1. Requerimiento 10: Checklist

Siempre es bueno tener una lista de verificación resumida disponible para usar, que cubra todos los puntos clave que cualquier participante pueda consultar rápidamente. Aquí hay un ejemplo de lista de verificación rápida:

• Confirme el motivo de la caída de los procesos de negocio.
• ¿El evento de ciberataque requiere una respuesta completa al incidente y la activación del plan de respuesta? Si es por un fallo de software y los proceso están caídos, continúe:
  • Active el plan de respuesta de adecuado ejecutando Playbook.
  • Notifique a la Gerencia General y a otros participantes.
  • Establezca comunicaciones alternativas según lo planeado (si es necesario)
  • Desconecte los dispositivos potencialmente involucrados de la red, incluidas las conexiones inalámbricas
  • Minimice la propagación y el daño iniciales
  • Inicie un plan de comunicaciones de relaciones públicas
  • Determine la versión/familia del ransomware e investigue el comportamiento esperado (si es posible).
  • Determine el alcance de la explotación del ciberataque y analice los daños
    • Ubicaciones, dispositivos, datos y sistemas involucrados, qué está encriptado, ex filtración de datos y credenciales, etc.
  • Póngase en contacto con la compañía de seguros de seguridad cibernética, si está involucrada.
  • Póngase en contacto con el contacto de recuperación de respuesta.
  • Busque puertas traseras y otros programas maliciosos.
  • Determine el alcance del daño inicial y las consecuencias conocidas.
  • Tenga reuniones de respuesta inicial. Decida si se debe pagar el rescate (debe estar definido previamente); si es así, inicie las negociaciones. Inicie la recuperación.
  • Hacer una copia de seguridad de los archivos cifrados para la recuperación de errores/posible descifrado futuro (opcional).
  • Determinar el vector de infección de la causa raíz inicial y mitigar
  • Priorizar la recuperación del sistema en función de la evaluación/necesidades del impacto comercial (BIA)
  • Decidir si el descifrado es posible y deseado, si es así, comenzar
  • Decidir si la restauración de la copia de seguridad es necesario, si es así, comience la recuperación o reconstrucción del sistema
  • Si se pagó el rescate y se recibió la clave de descifrado, pruebe en un sistema de prueba aislado
    • Si la prueba tiene éxito y se desea descifrar usando la clave de descifrado de ransomware, pague el rescate, obtenga el resto de las claves y continúe.
  • Elimine las puertas traseras y otros programas maliciosos.
  • Restaure los sistemas a un estado limpio conocido o de mayor confianza.
  • Cambie todas las credenciales de inicio de sesión posiblemente robadas. recuperación/restauración/reconstrucción
  • Recuperar completamente el entorno
  • Realizar un análisis post-mortem (lo que se hizo bien, lo que se hizo mal, lo que debe cambiarse)
  • Intentar prevenir el próximo ataque
  • Reunión de lecciones aprendidas

1. Requerimiento 11: Evaluación y mejora continua

La organización debería realizar regularmente una evaluación de la efectividad del playbook  y hacer mejoras y ajustes según sea necesario para asegurar que esté actualizado y sea efectivo. Para medir la efectividad del playbook deben realizar simulacros acotados y sobre escenarios productivos.

Puntos a tener en cuenta

1. Tiempos de respuestas.
2. Compromiso con los involucrados.
3. Tiempos de restauración.
4. Comportamiento de las personas.
5. Eficacia en la comunicación.
6. Eficiencia de las herramientas de reunión.
7. Acciones que corregir.

1. Requerimiento 12: Aspectos Legales

La organización debe verificar aspectos de cumplimiento formal y legal, para entender cómo actuar ante clientes, proveedores, asociados y otros en el caso de un incidente de ciberseguridad.

A continuación, se presentan algunos aspectos legales que deberían abordarse en un playbook:

1. Cumplimiento de las leyes de privacidad: Como la organización recopila, procesa o almacena información personal, es importante cumplir con las leyes de privacidad y protección de datos aplicables. En caso de un ataque de ransomware que involucre la información personal de los clientes, la organización debe informar a las autoridades y a los afectados según lo exija la ley. En caso de irrupción y robo de datos de personas (PII), se debe verificar los requerimientos legales como la Ley 25326 (Ley Protección de Datos Personales de la República Argentina) para este caso.
2. Acuerdos de nivel de servicio (SLA): En caso de que el ataque de ransomware interrumpa los servicios que la organización proporciona a sus clientes, es posible que se violen los acuerdos de nivel de servicio (SLA). La organización debería tener en cuenta estas posibles violaciones y estar preparada para abordarlas en caso de que ocurran. Si debe mantener software o proteger procesos de negocios y hay recursos humanos propios o terceros, debe contar con SLA.
3. Responsabilidad contractual: Si la organización tiene contratos con terceros, es posible que estos contratos establezcan ciertas responsabilidades legales en caso de un ataque de ransomware o fallos tecnicos. La organización debería revisar los contratos relevantes y tener en cuenta estas posibles responsabilidades.
4. Posibles demandas: En caso de un ciberataque, la organización puede enfrentar posibles demandas de los clientes, proveedores u otras partes afectadas. La organización debería tener un plan para abordar estas posibles demandas, incluyendo la contratación de asesoría legal. Un punto que permite proteger a la organización es haciendo la denuncia penal correspondiente, para ello se requiere:
   1. Análisis forense de lo sucedido. Realizar un análisis forense con un Perito Informático y generación de documento con respaldo de un Escribano Publico. Respaldar la información, realizar tres copias suscriptas por el escribano.
   1. Presentación en la Justicia: realizar la denuncia correspondiente, adjuntando el informe forense. La idea no es intentar capturar al ciberdelincuente, si no proteger los procesos de negocio ante demandas, indicando que la organización no está siendo operativa por un ciberataque

Cocinemos un PlayBook

Teniendo los ingredientes, ya podemos armar nuestro proceso de trabajo para recuperar nuestros procesos de negocio. En este punto básicamente es reunir los ingredientes y armar un proceso detallado, y definir el trabajo en equipo para recuperar la operación de los procesos de negocio.

Los pasos para el desarrollo del mismo se basan en los siguientes puntos:

1. Detección y evaluación: cunado un proceso de negocio es afectado, se debe evaluar el motivo, impacto y recursos necesarios para volver a la operación normal. Uno de los puntos más destacados, es que se necesita algún tipo de monitoreo continuo, para que el usuario interno o externo no sea el que emita la alerta y cuando esto ocurra la respuesta de la organización sea que ya se está trabajado en la normalización.
2. Evaluación impacto: en base a esto se analizará las acciones de IT y de toda la organización, en base a lo planificado. No se deben tomar medidas apresuradas y debe trabajarse con el Comité de Crisis (si existiera) o los referentes o los distintos Gerentes de los procesos involucrados. El impacto determinará las acciones a realizar.
3. Recolección de evidencia: es importante entender que paso y como. Esto permite restablecer la operación de una manera diferente y comunicar interna y externamente de manera asertiva.
4. Mitigación: Implementar las medidas de mitigación adecuadas e ir comunicando el proceso para mantener a los usuarios de servicios y/o productos con el nivel de confianza deseado.
5. Restauración de la operación: el proceso de restauración de la operación debe ser ordenado y al finalizar se debe controlar la integridad de los datos y servicios. No lanzar a producción sin una previa verificación para no interrumpir nuevamente el proceso de negocio para una posterior corrección.
6. Evaluacion post incidente: es sumamente importante entender que paso y que acciones son las necesarias para que no vuelva ocurrir. Identifique las áreas de mejora y aspectos a tener en cuenta en los procesos de negocio.

Una mejor manera de cocinar es contar con un proceso tipo diagrama de flujo donde podamos explayar luego las acciones de cada ítem, como se muestra en el dibujo a continuación:

¿Cómo sabemos si es exitoso el proceso confeccionado?

Una vez que contemos con todos los requerimientos y el esquema definido de Playbook, hay que probarlo, es la única manera de saber si lo que se ha confeccionado es lo que requiere la organización. Para hacerlo, se debe sumar a todas las áreas y gerencias que se requiera para llevar a la practica el Playbook.

Probar un Playbook es crucial para garantizar que todas las estrategias y procedimientos establecidos en el documento funcionen como se espera en situaciones reales. Al realizar pruebas, se pueden identificar posibles fallos o áreas de mejora que no son evidentes en la teoría. Además, permite que todos los involucrados en el proceso se familiaricen con sus roles y responsabilidades, lo que facilita una respuesta más eficaz y coordinada en caso de un incidente real.

Las pruebas también proporcionan una oportunidad para evaluar la efectividad de la comunicación interna y externa, asegurando que la información correcta se transmita de manera oportuna. Asimismo, ayudan a verificar que los recursos y herramientas necesarios estén disponibles y en buen estado de funcionamiento.

En resumen, las pruebas del Playbook permiten ajustar y optimizar el plan, garantizando que sea robusto, práctico y alineado con las necesidades de la organización. Sin estas pruebas, un Playbook podría ser ineficaz y dejar a la organización vulnerable en momentos críticos.

Conclusiones

Hemos analizado que los procesos de negocio que poseen recursos tecnológicos como soporte son susceptibles a interrupciones, más allá del tipo de fallo que tenga la tecnología (obviamente que un ciberataque es algo más preocupante). Hoy cualquier tipo de organización puede tener una interrupción, por lo cual, es sumamente necesario contar con un PLAN B ante contingencias. Hemos comentado que ese PLAN B puede ser un esquema de PLAYBOOK, que obviamente requiere un trabajo previo, pero en el análisis de los requerimientos podemos encontrar cosas a corregir y que no están alineadas a los procesos de negocio, como también cuestiones de toma de decisiones que pueden quedar definidas.

Ante un incidente, la organización va a estar mejor preparada ante un incidente y la postura ante la sociedad es mejor, porque va a mostrar un nivel de madurez diferente, que estar poniendo en un pizarrón improvisado el estado de los servicios.  No encarar un proceso de revisión y no tener en cuenta procesos de recuperación de PROCESOS DE NEGOCIO, se limitará a cuestiones técnicas y que dependerá de los recursos y la buena voluntad de su personal, mientras sus procesos están afectados.

Hoy se debe trabajar en procesos, la tecnología es la mejor herramienta, el crecimiento y las nuevas novedades que vienen como sunami a intervenir en las organizaciones, permitirán que estén mejor posicionadas ante una situación.

Su organización está dispuesta a cocinar un bizcochuelo?