28 mayo 2013

Continuidad de los procesos de negocio y temporalidad

En muchas ocasiones, a la hora de hablar de procesos de negocio, nos solemos olvidar de un pequeño detalle que, sin embargo, es crítico desde muchos puntos de vista: su dimensión temporal. Obviamente, no todos los procesos de negocio tienen la misma duración, periodicidad ni frecuencia de ocurrencia. Los hay que duran segundos mientras otros duran días o meses. Hay procesos diarios mientras que otros muchos son mensuales o incluso anuales. Y por último, no es lo mismo un proceso que se desencadene (instancie, que dirían los programadores) 10 veces al día que uno que lo haga 1 vez al año... aunque ambos procesos tengan la misma duración y periodo.

Estas dos dimensiones temporales van a tener un peso fundamental a la hora de caracterizar los procesos de negocio. Estos aspectos son fundamentales cuando hablamos de Continuidad de Negocio, y sin embargo no se suelen explicitar a la hora de realizar un BIA (Business Impact Analysis, o Análisis de Impacto en el Negocio). De hecho, estos tres serían los parámetros fundamentales para evaluar la "degradación" que provocaría la materialización de una amenaza sobre un proceso de negocio, parámetro que combinado con el "valor" del proceso de negocio (su importancia para la actividad productiva de la organización) nos daría el "impacto" de dicha amenaza. Y si quisiéramos completar el estudio no tendríamos más que evaluar la "probabilidad" de ocurrencia de dicha amenaza y tendríamos como resultado el "riesgo" que supone esa amenaza para ese proceso de negocio, consiguiendo un análisis de riesgos completo.

Pero volvamos sobre el primer análisis. ¿Cómo podríamos parametrizar los procesos de negocio habituales de una organización? Simplificando mucho podríamos decir algo así como:

  • Los procesos de venta son de duración muy variable, en función del producto/servicio vendido, pero en general podríamos pensar que están entre 1 día y 1 mes. No tienen una periodicidad pre-establecida, y su frecuencia de ocurrencia podría ir desde la diaria (o incluso menos) hasta muchas (a veces, miles) veces al día 
  • Los procesos productivos son los de mayor variabilidad, ya que tendriamos desde los de duración de segundos (entrega instantánea de información, como los bancarios o los web) hasta los de duración de días e incluso meses (por ejemplo, la fabricación de maquinaria pesada). No tienen por qué tener una periodicidad establecida, y su frecuencia de ocurrencia depende mucho del producto/servicio producido y de la estrategia de producción (en cadena, en paralelo, secuencial, etc.).
  • Los procesos de gestión económica podríamos pensar que tienen una duración de varios días, en general, una periodicidad mensual y una frecuencia de ocurrencia que puede ser diaria. 
  • Podríamos pensar que los procesos de gestión de personal tienen en general una duración de varios días, una periodicidad variable (dependiendo de las características de la organización puede no tener periodicidad predeterminada) y una frecuencia directamente dependiente del tamaño de la organización. 
Esta caracterización de los procesos puede facilitar el diseño de diferentes estrategias de continuidad en función de la tipología de los procesos de negocio soportados. ¿Encajan vuestras estrategias de continuidad con un análisis de este tipo? ¿Son las soluciones adoptadas coherentes con este planteamiento? Ya tenéis tema para la reflexión...

13 mayo 2013

Análisis de Riesgos para directivos

Muchos responsables de seguridad se quejan de que les resulta difícil conseguir que la dirección revise con detalle (y no hablemos ya de participar en su realización) los análisis de riesgos. ¿Hay alguna forma de conseguir que el ejercicio sea más "natural" para ellos? Creo que sí.

La propuesta que hago a continuación no es excesivamente ortodoxa, pero creo que puede servir para aproximar los análisis de riesgos a un colectivo como es el directivo que puede estar familiarizado con los conceptos que se tratan, pero que les cuesta usar la metodología "clásica". No obstante, los primeros que tendremos que hacer un esfuerzo seremos nosotros, que tendremos que dejar de pensar en riesgos de TI (o de cualquier otro ámbito) y empezar a pensar en riesgos de negocio.

Si hemos superado el primer obstáculo, el resto es sencillo. Sólo hay que seguir unos pequeños pasos que indico a continuación:


  1. Identificar el "negocio" del ámbito que estemos analizando, listando los servicios que presta, o los procesos de negocio que desarrolla, o como queramos llamar a la actividad de negocio que desarrolla ese ámbito. 
  2. Clasificar esos servicios en 3 niveles, en función de su importancia para la organización (llamémosle importancia alta, normal y baja). 
  3. Realizar un análisis DAFO de cada uno de esos servicios, identificando sus Debilidades, Amenazas, Fortalezas y Oportunidades.
  4. Valorar cada una de esas debilidades, amenazas, fortalezas y oportunidades en función de su importancia (llamémosle importancia alta, media o baja).  
  5. Ahora sólo queda que alguien, a nivel más técnico, interrelacione debilidades (aka vulnerabilidades) y amenazas por un lado, y fortalezas y oportunidades por otro, multiplique el valor de cada tripleta (servicio-debilidad-amenaza y servicio-fortaleza-oportunidad)... et voila! Ya tenemos el análisis de riesgos.
Con este sencillo ejercicio, que para un directivo puede ser bastante más fácil de llevar a cabo que un análisis de riesgos "de libro", hemos conseguido tener un análisis de riesgos de negocio cuantitativo por un lado y un análisis de potencialidades (no he querido usar oportunidades, que ya se usa, y no se me ocurre un término mejor como antónimo de riesgo) por otro. De este modo no sólo reducimos la complejidad técnica que puede tener un análisis de riesgos, sino que lo aproximamos a la visión de negocio, tanto por utilizar metodologías más propias de este nivel como por desarrollar una visión "en positivo" del análisis de riesgos, al identificar no sólo riesgos a mitigar sino también potencialidades a favorecer, dentro del mismo análisis (de hecho, esta propuesta de análisis de riesgos en positivo ya la planteé en este mismo blog hace algún tiempo).

Obviamente, si lo que estamos buscando es un análisis de riesgos TI probablemente no encontremos bajo este planteamiento una solución válida, aunque... realmente el análisis de riesgos TI es un análisis de riesgos para directivos?

02 mayo 2013

Atentado de Boston y APTs

Según se han ido sucediendo las noticias relativas al atentado de la Maratón de Boston y las averiguaciones posteriores no he podido evitar la tentación de establecer una analogía entre los hechos de Boston (o el terrorismo en general) y las APTs informáticas. Y la pregunta que surge a continuación es clave: ¿Es válido ese paralelismo? Y si fuera así... Podrían realimentarse ambos mundos?

Analicemos el paralelismo. Para empezar, el punto de partida de una APT es un "troyano" que conseguimos introducir en el sistema de la víctima. En el mundo físico, el sistema objetivo sería el entorno a atacar, en este caso Boston (o EEUU, cada uno que lo interprete como quiera). Las personas serían las aplicaciones que corren en ese sistema, y por lo tanto tendríamos dos formas de "infectar" el sistema: introduciendo directamente un software malicioso tipo "virus" (terrorista proveniente del exterior) o "troyanizando" una aplicación del sistema ("convirtiendo a la causa" a un ciudadano local, al más puro estilo homeland).

Al igual que en el mundo informático, los países están preparados para proteger el perímetro de la red (frontera) y controlar las entradas (firewalls), pero la capacidad de detección de terroristas externos que tienen estos sistemas es muy limitada, ya que generalmente se limita a firmas (identidades específicas que se chequean) y heurística básica (análisis de los datos del propio viaje -origen, destino, motivos del mismo, y cosas así). El resultado es que los "virus" sencillos se pueden llegar a detectar, pero las APTs más sofisticadas (personas "troyanizadas" o incluso malware durmiente con puertas traseras) suelen colarse. Además, al igual que en los sistemas de información, no sólo podemos infectarnos por la red. Los pendrives (inmigración ilegal o no controlada, cuerpos diplomáticos, etc.) también pueden llevar alguna aplicación maliciosa en su interior, consciente o inconscientemente.

En el mundo TIC se suelen poner sistemas IDS en la red interna, para tratar de detectar ataques que hayan podido superar la protección perimetral. Sin embargo, en el mundo físico no hay (oficialmente) demasiados recursos destinados al "espionaje" interno, más allá de la labor policial habitual. En cualquier caso, normalmente un IDS tampoco suele ser capaz de detectar la actividad de una APT...

Las APTs son difíciles de detectar porque su actividad es esporádica. Suelen ser aplicaciones "durmientes", que realizan una actividad aparentemente normal (o ninguna) hasta que, por un motivo determinado, activan su payload malicioso y lo ejecutan, realizando la fechoría en cuestión. Este funcionamiento es muy similar al de cualquier célula terrorista, y la dificultad de su detección estriba en identificar el detonante para su activación, que potencialmente puede ser cualquier cosa. Las autónomas pueden activarse con una cuenta atrás, un hito específico, una fecha, etc., mientras que otras dependen de la recepción de una orden externa desde un nodo de comando y control (C&C). Estas son algo más detectables, pero también mucho más flexibles, ya que pueden ser reprogramadas. En cualquier caso, esas comunicaciones llevadas al mundo físico son prácticamente imposibles de detectar, dada la infinidad de medios existentes y la poca capacidad de supervisión de los mismos.

Y por último, las APTs actúan. Roban la información, hacen estallar la bomba... Este suele ser el momento en el que son detectadas, cuando el incidente se materializa. El problema es que en este momento ya no sirve de nada, su acción no ha podido ser evitada. En ese momento es cuando empieza la "desinfección"... si es que han sido detectadas. Si no es así, podrán continuar con su actividad.

Hasta aquí la exposición. Ahora vuelvo a lanzar la pregunta, para la que no tengo respuesta. ¿Puede servir el conocimiento adquirido en cualquiera de ambos mundos para mejorar la lucha contra amenazas físicas y cibernéticas? Hay algún tipo de iniciativa de colaboración en este sentido? Seguro que un buen guionista sabe cómo hacerlo...