Amedeo Maturo

Protección de Datos y Administración Electrónica

Auditoría de la Seguridad de la Información

La situación que voy a describir es bastante común en el tejido empresarial de Alicante; pero no deja de ser llamativa, así que aquí van algunas reflexiones sobre la Auditoría de la Seguridad de la Información.

La llamada

Hola, te llamo de la empresa xxx. Acabo de comprarme esta solución informática (rellenen con “nuevo servidor“, ERPCMR o cualquier otro acrónimo molón) y me gustaría que hiciera una Auditoría de Seguridad“.

Lo primero que piensas (pero no dices) es: “¿Ahora?” ¿Para qué hemos estado hablando horas y horas sobre las necesidades de consultarme antes de hacer las cosas y no después?

Pero, como eres un profesional de la protección de datos (esa categoría tan sufrida), te lo callas y te vas para el cliente, a ver qué diablos se ha comprado.

Cómo deberían de haberse hecho las cosas

Las notas que viene a continuación no son invenciones mías, sino las normas básicas dictadas por el sentido común y recogidas en el CISA Review Manual 2013 (aunque no optéis por la certificación CISA, es una lectura muy recomendable).

Utilizando una de las frases más manidas de la Historia, “una imagen vale más que mil palabras“.

(Los pasos indicados en el Manual CISA son más, pero considero que esta reducción puede ser más ágil y puede responder más rápidamente a las necesidades de la típica empresa de Alicante)

1. Revisión de las Estructuras Existentes

Antes de lanzarse a comprar el último modelo de lo que sea, hay que sentarse y ver en qué falla nuestro actual sistema. ¿Ya no responde a nuestras necesidades? ¿Necesitamos nuevas funcionalidades? ¿Cuáles? ¿Estamos usando una tecnología obsoleta? ¿Tenemos problemas de almacenamiento/conectividad/otros?

Si no ponemos por escrito lo que tenemos, ¿cómo vamos a ser capaces de comprar algo nuevo (y, supuestamente, mejor)?

2. Análisis y Diseño

Es la hora de sentarse y ver qué queremos comprar. Lógicamente, deberíamos de haber aprendido de las conclusiones del paso anterior. Puede que, simplemente, tengamos un problema de almacenamiento, y, para solucionarlo, no necesitamos un monstruo de estas proporciones.

3. Borrador de Necesidades

Hay que poner por escrito cuáles son las necesidades que queremos cubrir con la nueva adquisición. Podemos tener incluso opiniones completamente divergentes (el informático quiere una cosa y el jefe ha visto no sé qué en la empresa de su vecino y quiere uno igual. Si están pensando que estas situaciones no son habituales, well… think again).

4. Aprobación de Necesidades

Este documento formal es fundamental, porque en él se recogen todas las necesidades que queremos cumplir, definiendo:

  • las características de lo que queremos comprar;
  • cómo y cuándo nos lo deben entregar;
  • qué cambios se registrarán en nuestra empresa;
  • si será necesaria formación para la nueva herramienta;
  • si las medidas de seguridad son acordes a nuestras necesidades (y, de paso, acorde con el R.D. 1720/2007).

5. Proof Of Concenpt (POC)

Uso el término anglosajón, porque la traducción como “prueba de concepto” no me parece acertada y no se me ocurre nada mejor. ¿De qué se trata? En esta fase, ya deberíamos tener un número cerrado de posibles soluciones y proveedores. Lo ideal es que dispusiéramos de un prototipo, para llevar a cabo un análisis de resultados, para ver si lo que nos proponen se adapta a nuestras necesidades.

¿Que no disponemos de un modelo de prueba? Es lo normal; además, los proveedores suelen ser reacios a presentarnos un prototipo, sin que ello afecte al precio final de sus servicios. ¿Qué hacemos?

Con las ofertas encima de la mesa, valoramos los siguienes parámetros y vemos como éstos encajan en nuestras necesidades:

  • Las características básicas de seguridad;
  • El correcto funcionamiento de las medidas de auditoría de lo que compramos (ya sabéis: usuario/contraseña, cambios, logs, perfiles, permisos, etc.);
  • Características legales del contrato (por ejemplo, esas cláusulas de confidencialidad que nunca están de más);
  • Las medidas de implementación, que se ajustan a nuestras necesidades;
  • Prestaciones y flexibilidad;
  • Precio.

El precio viene al final, aunque evidentemente, no es el factor menos importante en la toma de decisiones.

Conclusiones

Si seguimos estos pasos, ya no será necesaria esa “llamada” de “Vente pa’ ca“, porque, en realidad, ya sabemos qué hemos comprado y cómo funciona. Sólo se tratará de verificar que las condiciones pactadas contractualmente responde a lo entregado (casi na’).

Categoría: audit methodology, Auditoría LOPD, CISA, confidencialidad, Protección de Datos, R.D. 1720/2007, RD 1720/2007, Seguridad de la información

Etiquetas: , , , ,

Deja un comentario

Archivos

Temas