lunes, 29 de junio de 2009

Ser o No Ser... esa es la cuestión

Hace ya algún tiempo que vengo detectando ciertas irregularidades o desconocimiento en el mundo profesional en cuanto a las denominaciones que se otorgan tran la obtención de ciertas certificaciones, véase CISA, CISM, Lead Auditor 27001, ...

Todas y cada una de estas certificaciones tienen, por decirlo de alguna manera, dos hitos. El primero es pasar un examen que acredita que dispones de los conocimientos necesarios y el segundo es la presentación de los justificantes necesarios para que la correspondiente organización promotora del certificado te los reconozca y te otorgue finalmente dicho certificado y la denominación correspondiente.

En la etapa en la que se dispone del examen y no de la Certificación se debe indicar que se dispone del documento acreditativo de haber pasado el examen correspondiente incluyendo (Exam Pass). Por tanto mientras no haya confirmación de la correspondiente organización de que la verificación de los méritos profesionales es suficiente, aquel que ha pasado el examen debería considerarse como CISA Exam Pass, CISM Exam Pass o IRCA Lead Auditor Exam Pass, pero el caso es que habitualmente eso de poner el Exam Pass queda muy largo y hay a quien se le pasa...

Esta mañana he estado echando un vistazo a los requisitos que se solicitan para ser IRCA Lead Auditor ISO 27001 y aquí os pongo parte de la información que IRCA facilita en este documento:

Educación
  • Secundaria, como mínimo.
Experiencia laboral
  • Cinco Años, o 4 años con un título universitario o terciario
  • dos años de experiencia en temas relacionados con seguridad en al información
Formación en auditorías
  • Curso de Lead Auditor ISO 27001 certificado por el IRCA o una alternativa aceptable
Experiencia en Auditorías
  • Cuatro Auditorías como auditor "en entrenameinto", totalizando 20 días de los cuales 10 deben ser en las intalaciones de la organización auditada.
  • Tres auditorías como auditor líder "en entrenamiento", totalizando 15 días, de los cuales 10 deben ser en las instalaciones de las organizaciones auditadas.
Para otras certificaciones se requieren, al igual que para ésta, requisitos de experiencia que hayan sido validados por la organización que ha de conceder la certificación (ISACA en caso de CISA y CISM). Es por esto que me gustaría llamar la atención sobre el hecho de que pasar el examen no autiraza a aquel que lo pasa a disponer de la denominación si antes no ha acreditado el resto de requerimientos.

Por último decir que IRCA dispone de un Directorio Online donde se puede acudir para saber si alguien que pone en su tarjeta que es IRCA Lead Auditor 27001 es realmente lo que dice ser.

Salu2!

jueves, 25 de junio de 2009

la No Conformidad Mayor sobre la No Conformidad

Ya estamos aquí de nuevo...

...Hace algún tiempo, durante una auditoría interna, mantuve una conversación con uno de mis compañeros de trabajo sobre las No Conformidades que puede poner la Entidad de Certificación durante su Auditoría.

La cuestión aquí está en que, por lo general, cuando existe una No Conformidad (en adelante NC) localizada durante la Auditoría Interna, en teoría, la Entidad de Certificación no podrá abrir una NC si se ha generado la correspondiente Acción Correctiva (en adelante AC), y se ha asignado el plazo para su resolución, aún cuando a fecha de la auditoría de certificación no se haya cerrado tal AC.

Ahora bien, esto no es del todo cierto. Supongamos que durante la Auditoría Interna se ha localizado un NC por incumplimiento de la LOPD (quien redacte esa NC dependerá del procedimiento de Auditoría Interna correspondiente), símplemente, no se ha hecho hasta el momento de la auditoría interna absolutamente nada al respecto de la protección de datos de carácter personal y esto supone un incumplimiento del control 15.1.4. A quien corresponda tal responsabilidad generará la NC y de ésta se derivará una AC a la que se le asignará un plazo posterior a la de la Auditoría de Certificación (esto es un supuesto ilustrativo).

Cuando el Auditor de Certificación llega a las instalaciones del auditado, comprobará las no conformidades, en concreto verá el incumplimiento legal y hará el rastreo hasta la acción correctiva correspondiente. Una vez visto que el plazo está asignado y a fecha de la auditoría no se ha solventado dicha no conformidad pondrá una NC Mayor y se acabó el sello (al menos de momento). Digo al menos de momento porque la certificadora puede dejar un plazo prudencial para que la empresa auditada presente evidencias del cierre de dicha no conformidad mayor, solicitando en dicho momento su certificación.


La comentada anteriormente no es la única situación en la que se puede poner una NC sobre una NC ya detectada por la auditoría interna sino que existen muchas más, tantas como situaciones que supongan un riesgo evidente para la seguridad de la Organización y que puedan, por ende, constituir una NC mayor, sobre las cuales se haya levantado una NC fruto de la auditoría interna y cuya AC no se haya cerrado a fecha de la Auditoría de Certificación (valga como ejemplo el que expuse en este post).

Esta circunstancia hace patente una necesidad latente de trasladar al Auditado a la entrega del informe de Auditoría Interna la importancia de cerrar determinadas acciones correctivas antes de la fecha de realización de la Auditoría de Certificación. Subrayar las No Conformidades más importantes puede hacerse de varias formas pero quizá una que puede ayudar a familiarizar al Auditado con la Auditoría de Certificación es la distinción entre NC mayores y NC menores en el correspondiente documento descriptivo del procedimiento de Auditoría Interna, dando una nueva arma al auditor para señalarle al auditado, "usted tiene que cerrar esto antes de la Auditoría de Certificación y al resto puede asignarles un plazo que vaya más allá de la fecha en que ésta se realice".

Otro aspecto que resulta de relevancia es la planificación de dicha Auditoría Interna. Si durante dicha auditoría se encuentran varias NC mayores que deben cerrarse antes de la Auditoría de Certificación y la Interna no se ha planificado con la suficiente antelación, el tiempo de reacción ante las NC mayores interpuestas en la Auditoría Interna será muy corto. Los planes de acción a llevar a cabo ante una NC mayor puede variar en dificultad y tiempo necesario para su realización de forma que es conveniente planificar con el suficiente adelanto la Auditoría Interna con el objeto de disponer de una ventana de tiempo más amplia para reaccionar ante las NC mayores.

Salu2!

(post corregido a instancias de comentarios en el mismo por un anónimo que me hicieron ver dos partes en las que la información carecía del rigor necesario. Gracias a Anonimo por sus comentarios)

martes, 23 de junio de 2009

Una Buena Metodología de Análisis de Riesgos II

******************************************************
Una buena Metodología de Análisis de Riesgos I
Una buena Metodología de Análisis de Riesgos II
******************************************************

[...]

Algunas de las metodologías que he podido examinar pierden la trazabilidad de cual es la propiedad de la información (Confidencialidad, Integridad, Disponibilidad) que nos lleva a un determinado valor de riesgo de forma que se hace difícil aventurar cual puede ser la mejor solución si no tenemos claro qué propiedad es la que quiero proteger para un determinado activo de información. En otros casos, se hace la media de los valores recogidos en el BIA y este valor se utiliza en un segundo paso para el cálculo del riesgo, creando un falso valor de riesgo.

Esto, que en un principio es algo obvio, crea al auditor un dilema, sin duda alguna pone en peligro la seguridad de la información, se está evaluando mal el riesgo de la organización creando un modelo de riesgo que no refleja fielmente la realidad de la organización, sin embargo, no hay armas. La inexistencia de un vínculo entre 27001 y 27005 deja al auditor sin argumentos más allá de "esta metodología es inadecuada".

Esto genera un problema de dimensiones mayúsculas, introduciendo desde el inicio una metodología que ciclo tras ciclo va a estar dando un modelo de riesgo equivocado y por ende, priorizando mal, asignando mal los recursos, provocando costes innecesarios y ocultando los verdaderos problemas de seguridad. Esto se extenderá en el tiempo a no ser que se cambie de metodología, lo que nos haría perder una linea clara de cómo hemos ido mitigando los riesgos más importantes para abordar los siguientes en la siguiente iteración. Aunque bien visto, quizá sea el mal menor.

Lo cierto es que las enfermedades que acechan a un SGSI son innumerables desde su concepción y puesta en marcha. Es un engranaje perfecto en el que el error de uno de los componentes puede dar al traste con el sistema completo por lo que su concepción e implantación determinará un rumbo que puede guiar bien hacia la seguridad o dejar a la organzación en algunos aspectos incluso peor que estaba.

Salu2!

******************************************************
Una buena Metodología de Análisis de Riesgos I
Una buena Metodología de Análisis de Riesgos II
******************************************************

lunes, 22 de junio de 2009

Una Buena Metodología de Análisis de Riesgos I

******************************************************
Una buena Metodología de Análisis de Riesgos I
Una buena Metodología de Análisis de Riesgos II
******************************************************

No cabe ninguna duda que el proceso de Gestión del Riesgo es el corazón del SGSI y que si esto no funciona bien, se producirá una falsa sensación de seguridad. Dentro de este proceso, hay un talón de aquiles; La Metodología de Análisis de Riesgos que está, en muchos casos distorsionando la realidad y provocando que la organización se desvíe con respecto a los riesgos más importantes.

Durante el tiempo que llevo Auditando me atrevería a decir que he visto una metodología por cada consultora que realizaba la implantación y es que en esto, como en otras cosas, no hay consenso y eso perjudica claramente la seguridad de la información. Tampoco ayuda el hecho de que la propia norma de referencia ISO 27001 no exponga claramente cuales tienen que ser los requisitos que debe cumplir dicha metodología, encontrándose éstos definidos en ISO 27005 y desvinculados de ISO 27001, que trata este tema en su sección 4.2.1.c de manera algo escueta.

Especificar una metodología de evaluación de riesgos adecuada para el SGSI, las necesidades de negocio identificadas en materia de seguridad de la información de la empresa y los requisitos legales y reglamentarios

Todo lo anteriormente mencionado da pie a que cada cual desarrolle una metodología que considere "adecuada para el SGSI" pudiendo provocar un mal diagnóstico y un modelo de riesgo de la empresa equivocado.

[...]

******************************************************
Una buena Metodología de Análisis de Riesgos I
Una buena Metodología de Análisis de Riesgos II
******************************************************

viernes, 12 de junio de 2009

Pérdida de Datos provoca Consecuencias Irreparables

Desgraciadamente en ocasiones ocurren cosas como esta:
Una vulnerabilidad de día cero en la versión 2.0.7992 del software HyperVM / Kloxo de la compañía india LxLabs ha podido ser la puerta de entrada para un ataque informático que ha ocasionado el borrado total de datos de 100,000 servidores web virtuales operados por la empresa Vaserv, con base en el Reino Unido, y sus subsidiarias CheapVPS y FSCKVP. Las dos últimas fueron aniquiladas en su totalidad y puestas fuera de línea. La destrucción de los datos se propagó además a sus respaldos, al parecer. Las personas atacantes, tras conseguir el control total de los servidores, ejecutaron al parecer el comando "rm -rf" para provocar un borrado recursivo de todos los archivos. El dueño de la empresa LxLabs, K T Ligesh, de 32 años, se suicidó horas horas después del suceso. Slashdot también se hace eco de la noticia. Una de las personas responsables del ataque llegó a publicar en WebHostingTalk parte de la información de cómo logró acceso y la forma en la que actuó posteriormente, aunque el mensaje ha sido eliminado por la administración del sitio.
Es lamentable cómo en ocasiones el aumentar el ego de unos acaba con la vida de otros. Lamentable, sencillamente lamentable. No puedo evitar sentir cierta envidia por los que vivieron la época en la que la ética de los Hackers dominaba el mundo, solo les motivaba su propio conocimiento, saber más y más y no tenian intención de hacer daño. Hoy, tenemos que vivir con hechos como este que provocan la consternación y repulsa de cualquiera con dos dedos de frente.

Fuente: barrapunto

Salu2!

miércoles, 3 de junio de 2009

Historia de un SGSI cualquiera: El Sistema de Gestión y la Seguridad de la Información II

*****************************************************************
Historia de un SGSI cualquiera: El sistema de Gestión
y la Seguridad de la Información I

Historia de un SGSI cualquiera: El sistema de Gestión
y la Seguridad de la Información II
*****************************************************************
[...]

El señor Gerente después de consultarlo con la almohada decide que eso de la 27001 no esta aún muy visto y que en su sector no hay casi nadie que la tenga y por tanto puede ser una ventaja competitiva de forma que: "qué leches!, lo vamos a hacer", "pongo a Don YoPuedoConTodo que también es responsable del Sistema de Gestión de la Calidad y el de Medio Ambiente, que hace de comercial, de programador, analista y jefe de proyecto y esto va para delante fijo".

De esta forma y casi sin darse cuenta, llega el día de la auditoría interna, el sistema ya está implantado y la Consultora se ha buscado una colaboración externa para hacer esa auditoría. El Auditor Interno comienza a solicitar documentación del Sistema de Gestión y a ver incoherencias con el funcionamiento de la empresa, partes en amarillo fosforito y otras partes sin instanciar y es que Don YoPuedoConTodo al fin y al cabo es humano y le ha echado a esto los ratos que ha podido y le dejaban libres sus otras 101 tareas.

Al finalizar la Auditoría Interna el Señor Gerente es Informado de la situación por el Auditor Interno, quien le transmite su preocupación y creencia de que la consultora ha hecho bien su trabajo pero ellos no le han podido dedicar el suficiente tiempo, que los procedimientos y normas no se adecuan al día a día de la organización y que hay documentos que no se han instanciado. El Gerente mira a Don YoPuedoConTodo y le dice "Esto hay que solucionarlo pero ya, así que te vas quitando del resto de cosas que tenemos la Auditoría de Certificación dentro de 2 semanas". Don YoPuedoConTodo haciendo honor a su nombre por encima de sus propias posibilidades y en un esfuerzo sobrehumano consigue adaptarlo todo, dejar toda la documentación impecable, pero... los controles están pishí pishá, algunos mejor y otros peor, algunos no están y otros sí, pero el Sistema de Gestión funciona y, al fin y al cabo esto es lo importante, el ciclo PDCA hará el resto de forma que "CERTIFICADO".

El final de la historia es una empresa con un Sistema de Gestión sin Seguridad de la Información durante algún tiempo y un Sello que no refleja lo que realmente hay por detrás.

Pero...
  • ¿Dónde ha estado el problema aquí? El problema aquí es el objetivo del Gerente, conseguir la ISO 27000 por ventaja competitiva. Al final se obtiene pero... ¿para que sirve de puertas para adentro?. Amén de esto ha habido otros muchos problemas, asignación de recursos y colaboración de la organización entre otros.
  • ¿Quien es responsable de esto? ...
  • ¿Cual es el resultado? El resultado es un SG sin SI que irá adquiriendo Seguridad de la Información conforme va rodando el Sistema de Gestión en el mejor de los casos, cuando el señor Gerente apoye el SGSI y crea en él, más allá de la idea del sello inicial. En otro caso lo que tendremos es un SGSI Virtual perfectamente descrito por Javier Cao en su blog.
Que duda cabe que esta historia tiene muchas y muy honrosas excepciones y que quizá no existan dos empresas con un planteamiento exacto en cuanto a la implantación del SGSI en su organización y las razones que los llevan a hacerlo, lo que si está claro es que el motivo que llevó al desarrollo del SGSI es un factor clave para disponer de Seguridad de la Información desde el comienzo.

Para finalizar me gustaría lanzar preguntas al aire (al blog en este caso) con el único objeto de que sean reflexionadas:
  • ¿Se debe aceptar cualquier punto de partida para un SGSI?
  • ¿Qué está reflejando realmente una certificación en ISO 27001 el primer año si no se tiene especial consideración en el Anexo A?
  • ¿Y si una empresa certificada en ISO 27001 desaparece por un incidente de seguridad durante el primer ciclo?
  • ¿Puede ser la diferencia de criterio en la auditoría un problema o una garantía de un punto de partida adecuado?
Salu2!

martes, 2 de junio de 2009

Historia de un SGSI Cualquiera: El Sistema de Gestión y la Seguridad de la Información I

*****************************************************************
Historia de un SGSI cualquiera: El sistema de Gestión
y la Seguridad de la Información I
Historia de un SGSI cualquiera: El sistema de Gestión
y la Seguridad de la Información II

*****************************************************************

Un Sistema de Gestión de Seguridad de la Información está basado en el famoso ciclo de Deming que ha adoptado esta norma como otras (ISO 9000 e ISO 14000) y que está basado en cuatro fases denominadas como Plan Do Check Act, también conocido como ciclo PDCA. Este ciclo permite la mejora contínua de la seguridad de la información dentro de la organización apoyándose en el sistema de gestión como soporte para dicha mejora.Este Sistema de Gestión, como todo, tiene un principio y es en su construcción donde se hace hincapié en la primera auditoría. Esta rueda que va evolucionando poco a poco, permite a la organización mejorar su seguridad de la información, consiguiendo que la organización vaya poniendo el término Seguridad de la Información junto al de Sistema de Gestión. Lo que a mi me preocupa es si realmente en la primera iteración del SGSI hay Seguridad de la Información más allá de un Sistema de Gestión.

Ésta bien podría ser la historia de un SGSI cualquiera en una empesa cualquiera un día de auditoría cualquiera. Y es que no es lo mismo Sistema de Gestión que Seguridad de la Información. No es lo mismo y no van juntos por mucho que ISO 27001 se empeñe en jutarlos a los dos en el término Sistema de Gestión de Seguridad de la Información, al menos no en la primera iteración del ciclo PDCA.

La Historia podría comenzar un día cualquiera cuando el Gerente de una organización cualquiera escucha el término seguridad de la información e ISO 27001 juntos durante una conversación en el tiempo del almuerzo. "ah!, eso parece interesante!, ¿qué hay que hacer para conseguir esa cerctificación?", sus contertulios le dicen que es recomendable llamar a una consultora para que se encargue del trabajo y que ellos te lo van a a dejar todo prácticamente hecho y el señor Gerente se dispone ni corto ni perezoso a buscar la consultora apropiada, la encuentra y llama; "Hola, soy el señor Gerente, quisiera conseguir la ISO 27001 para mi empresa y me han comentado que vosotros podeis hacer la implantación", a esto le contestan desde la consultora que si, que no hay ningún problema, que ellos le van a dar toda la documentación y que su organización deberá particularizarla para su caso concreto así como implantar las medidas que se consideren adecuadas según sus objetivos, análisis de riesgos y cumplimiento legal, y que el Sistema de Gestión de Seguridad de la Información resultante tendrá que ser administrado y gestionado por ellos. "Bien, ¿cuanto tiempo llevará la implantación?", desde la consultora le apuntan que unos 6 u 8 meses, puede que incluso más, dependiendo de la organización.

[...]