[08/08/2024] El pasado 19 de julio, organizaciones de todo el mundo se vieron afectadas por una actualización de la compañía de seguridad Crowdstrike en Windows, lo que dio como resultado la interrupción del servicio para millones de clientes y empleados. Los problemas técnicos inmediatos ya han sido superados, pero no así las consecuencias que produjo este acontecimiento. Ahora las empresas tienen que reforzar sus políticas para hacer frente a futuras caídas y su impacto sobre clientes y empleados; es decir, reforzar la continuidad del negocio.
Un grupo de cuatro analistas de Gartner -los especializados en banca- se reunieron en un webinar para identificar los impactos que se pueden esperar de este tipo de eventos sobre la industria financiera y las acciones que se podrían tomar para mitigar sus consecuencias, en caso se presente otro evento similar -algo que, con seguridad, ocurrirá-. Benjamin Seesel, vicepresidente de Asesoría; Peter Ryan, analista director sénior; Pete Redshaw, analista vicepresidente; y Jeff Casey, analista director senior, de Gartner, fueron los que participaron en este evento.
La caída
Aquel día, poco después de comenzaron a aparecer las pantallas azules en las computadoras, CrowdStrike lanzó un comunicado señalando que esto se debía a una fallida actualización en el sistema operativo, y que la solución era hacer un reboot de la máquina en modo seguro o de forma manual.
Muchas empresas sintieron el impacto. Seesel sostuvo que 8,5 millones de computadoras se vieron afectadas a nivel mundial, se cancelaron más de cinco mil vuelos comerciales, se afectó a servicios de emergencia, hospitales y servicios gubernamentales, y se estima que las compañías estadounidenses de la lista Fortune 500 experimentaron pérdidas financieras estimadas en más de 5,4 mil millones de dólares.
Aunque fueron muchos los tipos de compañías que se vieron afectadas, los bancos particularmente deben encontrarse preparados para enfrentar situaciones complicadas, de acuerdo con el analista. Una de estas situaciones es el incremento en los fraudes; los ciberdelincuentes pueden aprovechar eventos como la pasada caída para lanzar varios tipos de ataques.
Ante ello, sostuvo el analista, los bancos deben revisar a sus socios tecnológicos. Los CIO deben pedir evaluaciones detalladas de ellos, particularmente sobre su estado, y solicitar que estos socios los acompañen durante las caídas. Igualmente es muy importante comunicarse con los otros ejecutivos -especialmente con el CEO- y con los grupos de interés externos. Nunca va a ser demasiada la información que se pueda proporcionar a estas personas; todos los stakeholders deben tener la misma información sobre la situación.
Pero también hay algunas acciones que los CEO podrían tomar en el mediano plazo; es decir, durante lo que reste del año. Una de ellas es coordinar con el directorio; el CEO debe esperar que se le pida una presentación ante el directorio para destacar las acciones que se toman contra la caída. También es necesario realizar actividades con los clientes, la disponibilidad y la responsabilidad son características que los clientes esperan de sus bancos.
Igualmente, la institución también debe evaluar la forma en que su actual tecnología soporta estas circunstancias; además, es necesario llevar a cabo actividades regulatorias, es decir, enfocarse en cuán dependiente es la empresa de sus proveedores, qué tan alto es el riesgo de concentración -concentrar muchas operaciones en uno o pocos proveedores-, y cuáles son los planes de continuidad del negocio. Finalmente, se tiene que observar si los proveedores de tecnología también fueron impactados por la caída y cuál ha sido el nivel de ese impacto.
Las reacciones
Por su parte, Casey señaló que se puede esperar algo de tranquilidad luego de la caída, pero que debajo de esa tranquilidad se puede estimar que hubo muchos tiempos extras que se tuvieron que dar en los equipos de soporte tecnológico. Además, los CEO van a tener que prepararse para contestar las preguntas que, con seguridad, van a surgir en las próximas reuniones de los directorios.
Redshaw, más bien, destacó el hecho de que las empresas se hayan reestablecido del incidente en forma y en tiempos oportunos; algo que, sin duda, tiene que ver con el compliance de las organizaciones. No se produjo un 'cataclismo' por lo que ocurrió aquel viernes. Ciertamente, hay mucho trabajo por hacer para evitar que este tipo de incidentes se repita, pero también si estos ocurren -y es muy probable que vuelvan a ocurrir- hay que conocer cómo está preparada la empresa para continuar con el negocio.
Una segunda meditación que propuso el analista fue la probabilidad de que la siguiente caída no se parezca a la que se acaba de sufrir, o que incluso se pueda tratar de un ataque. Y el tercer punto a considerar es que se debe esperar repercusiones; las futuras actualizaciones, una transacción que no se haya realizado antes, grandes cantidades de personas retornando de vacaciones, todos estos eventos podrían generar algún tipo de evento similar.
Finalmente, Ryan indicó que, aunque hubo problemas, no se produjo la caída total del sistema de pagos.
Lo que deberían hacer los CEO
El incidente merece la atención del directorio y por ello el CEO debe prepararse para explicar lo que sucedió, cómo se afrontó y cómo se afrontará en caso se repita un incidente similar. Casey indicó que, aunque es bueno explicar lo que sucedió, el CEO debe enfocarse en explicar cómo se va a prevenir eventos similares. Es importante comunicar al directorio lo que se va a hacer en caso de un evento similar, es necesario señalarles que o no va a ser riesgoso debido a las medidas que se van a tomar -y señalar, por supuesto, las medidas- o decir que sí va a ser riesgoso, pero que para afrontar ese riesgo se van a tomar ciertas medidas.
Una de las medidas propuestas por Casey, y que son generales a todas las instituciones bancarias, es una auditoria de la resiliencia; es decir, revisar las estrategias de resiliencia que se han previsto; además, es necesario mostrar lo que se ha aprendido del incidente y cómo -en base a ese aprendizaje. se va a responder en el futuro. Igualmente, es necesario examinar cuán concentrada está la compañía en determinados proveedores o cuán dependientes es de ellos. Una vez realizado ese examen, es necesario realizar una estrategia de diversificación para mitigar los riesgos. Adicionalmente, el analista hizo énfasis en que hay que recordar al directorio que las inversiones que se realizan en entrenamiento y en soporte para TI son fundamentales para afrontar este tipo de crisis.
Por su parte, Ryan indicó que generalmente el equipo de TI se encuentra sumergido en actividades cotidianas que insumen mucho tiempo. 'Mantener las luces prendidas' requiere incluso, en ocasiones, de horas extras de trabajo. Entonces, luego de ocurrido el incidente no se puede pasar a un momento de asignación de culpas; más bien se debe reconocer el momento por el que ha pasado el equipo, felicitarlos porque pudieron volver a poner el banco en línea y, en las semanas siguientes, meditar sobre las lecciones aprendidas.
En cuanto a los pagos -la especialidad de Ryan- señaló que hay que distinguir entre los pagos en batch y los pagos en línea. Los primeros pudieron manejarse adecuadamente ya que la caída no afecta tanto a estos pagos; no es el caso de los pagos en tiempo real, que son 24x7 y, por tanto, tienen una ventana de tiempo en la que se puede producir un evento de caída que no se pueda controlar. Ante ello, hay que pensar en alternativas de resiliencia, como optar por proveedores de nube que puedan manejar una caída. Algo interesante que mostró la reciente caída es que este tipo de proveedores prácticamente no se vieron impactados, algo que si sucedió con los proveedores de pagos mediante tarjeta. Entonces, si se busca resiliencia los CEO deberían meditar sobre el uso de este tipo de proveedores.
Finalmente, Redshaw señaló que una de las cosas que se han hecho evidentes en las últimas décadas es que ningún proveedor es una isla, ni siquiera los grandes como Microsoft o CrowdStrike. Ahora todos están interconectados, los bancos ya no hacen muchas de sus cosas in house y, por tanto, muchos de los problemas ocurren de forma externa; se busca mucho la seguridad dentro, se hace mucho testing interno, pero pueden producirse puntos de falla en el ecosistema y, por ello, no se puede ver dónde se podría producir la siguiente falla.
Jose Antonio Trujillo, CTOPerú