Mi bien querido 27001 (¿O debo llamarte BS ISO/IEC 27001:2005?). Mi relación contigo tiene ya varios años. Empecé leyéndote, no entendiéndote y terminando en cursos para que me explicaran a detalle y con ejemplos cómo querías las cosas que en tus párrafos intentabas transmitirme.
Te puedo decir que a la fecha y luego de un par de clases y proyectos prácticos, me siento seguro al afirmar que te entiendo suficientemente bien. Obviamente te veo más con ojos de auditado que de temido auditor.
Quiero empezar diciéndote que me caes bien, pienso que eres útil y que quiero seguir mi relación contigo.
Pero no puedo decir que soy tu incondicional. Tienes algunos detallitos que aquí te quisiera comentar. Espero no te ofendas, sólo es para mejorar nuestra relación (¿No es esto lo que se hace en terapia de pareja?).
Quiero empezar diciéndote que constantemente debo de estar elaborando documentación y mucha de ella, seamos sinceros, está orientada a una certificación donde debo demostrar que te hago caso. Muchos formatos, mucho Office. ¿Crees que se pueda omitir algo? Échale un ojo por ejemplo al 4.3.1 c): escribir procedimientos y controles que soportan al SGSI (Sistema de Gestión de Seguridad de la Información); o al g): documentar procesos para la operación de procesos de seguridad. O bien, mira todo lo que hay que hacer en el 4.3.2 (Control de Documentación).
En fin, sería aburrido enlistar todos los incisos en los que podría haber menos documentación (tiempo que se traduce en hacer más seguridad). De verdad a veces uno se queda con un sabor de Office en la boca y no tanto de seguridad (algunos dejan Office y desembolsan miles de dólares para una costosa solución web que documente y dé seguimiento de una manera más “nice”).
Y ni hablar de los que te siguen sólo por cumplir la norma o esa ley, pero dejando de lado la seguridad de la información. Donde el objetivo principal es documentar y cumplir, no proteger.
Inteligentemente nos obligas a hacer un análisis de riesgos. Y claro, es un eje fundamental en toda la propuesta del SGSI. Nos dices que nos podemos apoyar de otros documentos como el 27005. Ok. Pero he visto que la calidad de este análisis depende de a) quién se integra a desarrollar el análisis y, b) que hagas pentest en esta fase.
Es decir, si durante el análisis de riesgos no hay gente de Seguridad Informática que sepa de amenazas, exploits, tendencias y demás alimañas, simplemente los administradores no verán el bosque y de hecho tampoco verán varios de los árboles. ¿Cómo hacer que lo haga todo un Departamento de TI cuando no tienes un ejército de expertos en seguridad a su lado alimentando el análisis de riesgos? Tal vez sólo algunos administradores cuenten con esa presencia privilegiada y el resto que lo hagan como puedan con un par de guías.
Por otro lado, hacer el análisis de riesgos solamente con escenarios, los típicos “what-if”, suposiciones, cuestionamientos, entrevistas y otras técnicas comúnmente usadas, pues creo que simplemente te quedas corto. Lo que algunos hacen es integrar pequeños trabajos tipo pentest durante este análisis, como para complementar el análisis hecho en Office o usando esa costosa solución web. Al final, yo digo que es al revés: el trabajo en Office es complementario a los hallazgos hechos con pentest y pruebas en vivo. ¿Estoy mal?
Y por cierto, tu manera de identificar y evaluar riesgos que mencionas en el 4.2.1.d) y e) así como en el 27005 es bastante tediosa (¡Uy! Perdón. ¿Yo dije eso?). De hecho, un día navegando descubrí una propuesta del SANS; confieso que me pareció más ágil.
Pasando a otro punto (y aunque sé que es necesario), pero cómo odio que me pidas métricas de efectividad para los controles. ¡Me cuesta tanto trabajo pensar en indicadores útiles! Porque ya sabes, cualquiera puede inventarse 10 métricas inútiles que sirvan para “cumplir”. Es difícil encontrar indicadores que quien los produzca y revise mes a mes de verdad piense que le son de utilidad y que con ellos se tomen decisiones.
Y amigo, otra oportunidad de mejora. Hasta la fecha pienso que toda la parte de “Act” (la última del Plan-Do-Check-Act) descrita en tu punto 4.2.4 “Maintain and Improve the ISMS” está de más o podría ser reducida y simplificada. Siempre me ha costado implementar en la práctica esta parte, de manera que les haga sentido a quienes lo están aplicando.
No quiero seguir más. No vayan a pensar que soy un ignorante por criticar tu metodología probada. Finalmente eres una “buena práctica”. Así lo dicen los consultores de seguridad, numerosos blogs y la Orden Templaria del 27001 que tiene en su haber el trending topic #YoSoy27001.
Tal vez después de todo no te entienda bien y debamos de pasar más tiempo juntos. Sí, eso es, más tiempo juntos.
Nos estamos tuiteando en @FaustoCepeda.
Fausto Cepeda es ingeniero en Sistemas Computacionales por el ITESM. Es Maestro de Seguridad de la Información por la Universidad de Londres (Royal Holloway). Actualmente labora en la Oficina de Seguridad Informática del Banco de México. También cuenta con las certificaciones de seguridad CISSP, CISA, CISM y CEH