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!