Recientemente vemos como más y más empresas han incorporado buenas prácticas de seguridad, pero sólo entendiéndolas como el hecho de cumplir con una certificación, o para tener un bonito cuadro en la pared y presumir que están certificadas en tal o cual ISO o que ya tienen un curso completado de algún tema particular; pero no para llevar a la práctica esas mejores prácticas de manera efectiva e incorporarlas verdaderamente.
Veamos cómo un simple BIA (Business Impact Analisys) nos puede ayudar a entender el riesgo que puede tener una amenaza de hacktivismo o las fallas tecnológicas en el soporte de la operación de las empresas.
Inicialmente el BIA sólo lo identificamos para el DRP (Disaster Recovery Plan) y, aún cuando se ha incorporado como un importante capítulo en ISO 27001, es un tema tabú que no se ha integrado en las prácticas reales de las empresas en México de manera importante.
En temas de Gobernabilidad es muy importante considerar el análisis de riesgo financiero; en muchas áreas de la empresa lo manejan, sobre todo en las áreas que el tema de planeación y administración financiera de las empresas, pero no lo comparten con la práctica de seguridad de la información, ya que ésta sigue siendo considerada un área “informática” y no de estrategia.
Pero el tema es que una práctica aislada por procesos distintos puede tener mucho que ver con la forma de afrontar una crisis de seguridad o de controlar el presupuesto de las TIC’s.
Entendamos que el BIA, explicado de forma simple, no es otra cosa más que cuantificar cómo podemos perder ingresos o pagar de más, si uno o varios de nuestros sistemas críticos o procesos en la operación del negocio, son afectados por un problema o por un ataque (que no es lo mismo).
Luego, una vez que el negocio sabe cuánto le puede costar –en términos de pérdida económica– la caída de un sistema o varios sistemas críticos, es factible decidir el grado de inversión para mantenerlos y de igual manera cuantificar cuánto costó un ataque perpetrado o una falla en los mismos.
A esto se debe sumar otra posible pérdida, como la de la libertad del representante legal de la empresa por incumplimiento de una Ley, además de las multas generadas.
De esta forma, un ataque como los perpetrados por Anonymus no deben ser considerados sólo como un tema informático, ya que los minutos u horas –y en ocasiones hasta días– de recuperación le cuestan a la empresa afectada y se requiere de un esfuerzo conjunto para poder resolver la crisis en el menor tiempo posible.
Dentro del análisis de riesgos en la implementación de un DRP, el tema del “hacktivismo” ya se ha incorporado como buena práctica y así debe ser tratado por toda la organización, quizá en el mismo contexto de un terremoto o catástrofe natural, donde TODO MUNDO debe saber qué papel debe desempeñar y cómo lo debe ejecutar.
Veamos qué “usos” le podemos dar a la información del BIA en una organización:
Si recorremos los procesos de una organización X que se dedica a la manufactura de Y artículo y que depende la una línea de producción, operación y comercialización que están controladas por diferentes sistemas, veremos más clara la importancia del BIA.
Inicialmente la línea de producción está automatizada y depende de una serie de desarrollos a la medida, que le permite automatizar cada uno de los pasos de su línea de producción. Luego, ésta es alimentada y mantenida a través de un sistema de administración de recursos, inventarios, pedidos, etc., vía un ERP (Enterprise Resource Planning) que dentro de uno de sus módulos se liga al pago de horas de los trabajadores en función de las necesidades de productividad, por medio de un sistema de administración de Recursos Humanos y nómina.
Luego tenemos la parte elegante de la empresa que es la mercadotecnia y la imagen comercial; que si las ventas por internet, que el catálogo de nuevos productos, que si los pedidos y seguimiento de envíos, etc., etc.
Seguimos con los sistemas de control de flujo de ingresos y egresos y los equipos asignados a cada área. Si estos equipos fallan, los sistemas responderán con ineficiencia, ya que no fueron planeados para funcionar ante flujo excesivo de datos en una red plagada de virus o ante un ataque interno de malware introducido por un usuario que llevó la USB de uno de sus hijos para imprimir la tarea, porque en casa se dañó su impresora…
Después, los sistemas de intercambio de información con terceros, como la nómina tercerizada, los bancos, factura electrónica…etc., etc.
Y así poco a poco se va complicando la decisión. ¿A cuál de todas estas “damas en desgracia” deberíamos rescatar primero? ¿Cuánto estamos dispuestos a “gastar” en levantarla en caso de crisis? O mejor aún ¿cuánto estamos dispuestos a INVERTIR para evitar que el negocio deje de operar?
Es aquí donde el BIA nos dice qué es más importante en función del ingreso o de la pérdida de capital de la empresa, y en un sentido de presupuesto nos puede dar indicadores en función de la operación, como por ejemplo, si actualizamos licencias de un sistema que no nos sirve para nada, pero que el área de TI lo considera vital.
Ahora veamos el escenario de una reclamación ante un incumplimiento por parte de un proveedor que se le ha puesto un SLA (Service Level Agreement) y donde sólo se le “castiga” con una mensualidad del servicio que presta, en caso de no cumplir con los niveles de servicio prometidos. La realidad es que en función del papel que juegue en la cadena de producción y las pérdidas directamente relacionadas con su responsabilidad, se debería tasar su retribución económica. El BIA nos puede dar esta información de manera más que confiable.
Agreguemos al SLA la corresponsabilidad en el cumplimiento de la Ley Federal de Protección de Datos Personales en Propiedad de Particulares (LFPDPPP). Pocos proveedores lo podrán resistir y otros deberán mejorar sus propios procesos.
Como podemos ver, el BIA no solo es un simple documento de levantamiento de información para un DRP, sino una parte importante de la gobernabilidad de cualquier empresa, parte de un proceso estratégico de planeación y control de inversiones que debe considerarse como herramienta de un negocio y no sólo como una justificación de TI.