Hace unos días publiqué un post sobre un error de un administrador de sistemas que había provocado pérdidas millonarias. Podría parecer una simple anécdota, pero las estadísticas dicen que este tipo de incidentes son más habituales de lo que podríamos pensar.
Para suscribir esta última afirmación me remito a esta noticia de hace algunos días, donde se hacen eco de un informe del IT Policy Compliance Group que afirma que los errores humanos son la causa del 75% de los incidentes cuyo resultado es la pérdida de datos sensibles. Es decir, que de cada 4 veces que se pierden datos sensibles, 3 es por culpa de un error humano, y una de ellas se debe a vulneraciones de las políticas de seguridad establecidas.
Para tratar de resolver estos problemas, el informe hace algunas sugerencias. Unas son tecnológicas, como implementar medidas técnicas que limiten la posibilidad de cometer esos errores. Otras son de personal, donde nos encontramos con la contramedida más clásica de todas, la formación (y una de las más efectivas si se hace bien, no lo olvidemos). Pero el informe también propone medidas de gestión de la seguridad "pura", como es que las empresas identifiquen su información más sensible. Parece algo obvio, pero sin embargo es sorprendente la cantidad de organizaciones que hay en las que la información no está clasificada, y en las que cuando se pregunta por la información crítica, cada persona tiene una respuesta distinta.
En resumen, el informe no descubre nada nuevo, pero pone de manifiesto que la mayor parte de los incidentes de seguridad son de origen humano, y nos recuerda que para atajarlos no basta con los controles más clásicos, sino que es necesario implementar medidas de gestión global de la seguridad de la información si queremos alcanzar realmente los niveles de riesgo deseados. Aunque si no seguimos los consejos, siempre nos queda la posibilidad de asumir riesgos de pérdida de información valorados en millones de euros...
29 marzo 2007
28 marzo 2007
Políticas de seguridad
Una de las preguntas más habituales a la hora de tratar de llevar a la práctica la seguridad suele ser cómo desarrollar políticas de seguridad. Realmente suele ser uno de los apartados en los que es más complicado encontrar documentación útil en Internet, ya que normalmente los consultores guardan con celo ese tipo de documentación, que refleja parte de su KnowHow adquirido a lo largo de los años. Por éso, creo que el link que dejo a continuación puede ser útil, si no para servir de modelo de creación de políticas, sí como referencia para su redacción:
http://www.27001-online.com/secpols.htm
En esta dirección se puede encontrar un listado de políticas organizadas por capítulos, y para cada una un pequeño índice del contenido que se debe regular en cada una de ellas. Como cualquiera puede comprobar, la estructura no sigue la misma organización que los controles de la norma ISO 27001, pero creo que este es uno de los puntos fuertes de esta lista, ya que están organizadas de una forma más práctica y con la que probablemente muchas organizaciones se sentirán más cómodas, debido a que se asemeje más a su organización y funcionamiento interno.
En resumen, esta puede ser una guía de trabajo para todo aquél que quiera adentrarse en el desarrollo de políticas de seguridad y no sepa por dónde empezar. Y si se quiere que la documentación desarrollada sea compatible con ISO 27001, no hay más (ni menos) que identificar la correspondencia entre ellas y los apartados y controles de la norma. Y que conste que no es algo tan trivial como parece...
http://www.27001-online.com/secpols.htm
En esta dirección se puede encontrar un listado de políticas organizadas por capítulos, y para cada una un pequeño índice del contenido que se debe regular en cada una de ellas. Como cualquiera puede comprobar, la estructura no sigue la misma organización que los controles de la norma ISO 27001, pero creo que este es uno de los puntos fuertes de esta lista, ya que están organizadas de una forma más práctica y con la que probablemente muchas organizaciones se sentirán más cómodas, debido a que se asemeje más a su organización y funcionamiento interno.
En resumen, esta puede ser una guía de trabajo para todo aquél que quiera adentrarse en el desarrollo de políticas de seguridad y no sepa por dónde empezar. Y si se quiere que la documentación desarrollada sea compatible con ISO 27001, no hay más (ni menos) que identificar la correspondencia entre ellas y los apartados y controles de la norma. Y que conste que no es algo tan trivial como parece...
27 marzo 2007
Incidencias de seguridad de la información de Internet
Tengo la sensación de que, en estos últimos tiempos, cada vez son más frecuentes las noticias de seguridad relacionadas con servidores DNS. Por poner un par de ejemplos, hace menos de dos meses se llevó a cabo un grave ataque contra los DNS root servers, y no era el primero. Y hace menos de una semana se publicó una vulnerabilidad de los servidores DNS de Windows 2000 por la que "permiten" que cualquier usuario modifique los registros DNS de la organización sin necesidad de proporcionar ninguna credencial de acceso.
Estos dos sucesos son especialmente importantes por los servicios a los que afectan. De hecho, podríamos llegar a decir que el servicio DNS es uno de los dos servicios que soporta la información de configuración de la red, junto con el rutado. Al menos, de cara a los usuarios, ya que sin él no seríamos capaces de utilizar Internet. Por tanto, estamos ante dos incidencias de seguridad de la información, y de una información que puede ser crítica. Además, los ejemplos parecen de libro: uno relativo a la disponibilidad y el otro referente a la integridad. Ya sólo nos faltaría un ejemplo para la confidencialidad, aunque en el caso de los servidores DNS en Internet este caso no tenga sentido, ya que es información que debe ser accesible públicamente.
En resumen, creo que es necesario estar atentos a este tipo de noticias, que aunque no suelen aparecer en las portadas de los periódicos, siempre nos debe servir para recordar que los incidentes de seguridad de la información no son tema exclusivo de las empresas, y que todos podríamos llegar a sufrir sus efectos.
Estos dos sucesos son especialmente importantes por los servicios a los que afectan. De hecho, podríamos llegar a decir que el servicio DNS es uno de los dos servicios que soporta la información de configuración de la red, junto con el rutado. Al menos, de cara a los usuarios, ya que sin él no seríamos capaces de utilizar Internet. Por tanto, estamos ante dos incidencias de seguridad de la información, y de una información que puede ser crítica. Además, los ejemplos parecen de libro: uno relativo a la disponibilidad y el otro referente a la integridad. Ya sólo nos faltaría un ejemplo para la confidencialidad, aunque en el caso de los servidores DNS en Internet este caso no tenga sentido, ya que es información que debe ser accesible públicamente.
En resumen, creo que es necesario estar atentos a este tipo de noticias, que aunque no suelen aparecer en las portadas de los periódicos, siempre nos debe servir para recordar que los incidentes de seguridad de la información no son tema exclusivo de las empresas, y que todos podríamos llegar a sufrir sus efectos.
22 marzo 2007
La psicología de la seguridad
Hoy he dedicado una buena parte de la tarde a terminar de leer un artículo de Bruce Schneier que habla sobre la psicología de la seguridad (el artículo es extenso). En resumen, el texto versa sobre las diferencias que existen entre la seguridad real, calculable matemáticamente, y la percepción que las personas tienen sobre dicha seguridad, que está afectada por factores subjetivos.
El artículo refleja los problemas que pueden ocasionar las divergencias entre la seguridad real y la sensación de seguridad, ya que pueden llevar a valorar de forma errónea riesgos y contramedidas hasta el punto de sentirnos inseguros en una situación segura, y viceversa.
Posteriormente el artículo profundiza en las distintas causas que pueden provocar estas divergencias, y realiza un análisis de cada una de ellas aportando una gran variedad de ejemplos y estudios que las ilustran. Sin embargo, de todo el contenido del artículo me quiero quedar exclusivamente con unos pocos elementos, más interesantes desde el punto de vista de la temática del blog:
El artículo refleja los problemas que pueden ocasionar las divergencias entre la seguridad real y la sensación de seguridad, ya que pueden llevar a valorar de forma errónea riesgos y contramedidas hasta el punto de sentirnos inseguros en una situación segura, y viceversa.
Posteriormente el artículo profundiza en las distintas causas que pueden provocar estas divergencias, y realiza un análisis de cada una de ellas aportando una gran variedad de ejemplos y estudios que las ilustran. Sin embargo, de todo el contenido del artículo me quiero quedar exclusivamente con unos pocos elementos, más interesantes desde el punto de vista de la temática del blog:
- El primero, que la seguridad real y la sensación de seguridad son dos cosas distintas, y que pueden existir importantes divergencias entre ambas provocadas por factores subjetivos.
- El segundo, que para conseguir seguridad es necesario realizar concesiones, que podrán ser de distinto tipo (dinero, funcionalidad, libertad, conveniencia, ...).
- El tercero, que las concesionesdeberían ser proporcionales a la seguridad real que conseguimos con ellas, pero que este cálculo se complica al existir diferencias entre la concesión real y la concesión percibida, derivadas de sobrevalorar o infravalorar las contramedidas.
- El cuarto, que distintas herramientas como la economía del comportamiento, la psicología de la toma de decisiones, la psicología del riesgo y la neurociencia pueden ayudar a explicar las divergencias entre la realidad y la percepción, identificando las tácticas que utiliza la mente humana para desarrollarlas.
- Y el último, que estas tácticas pueden ser utilizadas "para el bien" o "para el mal", aprovechándolas para ajustar la percepción a la realidad, para conocerlas y superarlas o para forzar la percepción de determinados riesgos o contramedidas en función de intereses ilícitos.
En resumen, un artículo instructivo que profundiza no sólo en la psicología de la seguridad sino en las repercusiones y utilidades que puede tener el conocimiento de sus bases. Como siempre, la moneda tiene dos caras...
Amenazas reales
Ayer la versión española de The Inquirer nos "obsequiaba" con esta noticia. Un error de un técnico de sistemas provoca una pérdida de datos valorada en 38000 millones de dólares. Sin duda alguna, un incidente de seguridad de impacto muy alto. ¿Qué conclusiones podemos sacar si analizamos el hecho?
El artículo afirma que un técnico borró una determinada información por error. Es una de las amenazas estándar de cualquier guía: errores en la administración de sistemas. Estaba bien gestionado el riesgo asociado a ella?
El valor de la información es, por lo que parece, muy alto. ¿Cuál es la probabilidad de ocurrencia de la amenaza? A priori debería ser baja... con un técnico "estándar". Pero en este caso es un técnico que no sólo ha borrado la información por error, sino que ha terminado formateando el disco en el que residía la copia de seguridad. En caso de que hubiera sido un técnico suficientemente capacitado, no parece viable este resultado. Por tanto, tenemos que suponer que aparenta ser un técnico de bajo nivel de cualificación. Por tanto, la probabilidad debería ser media o alta.
¿Cuál es la vulnerabilidad de los datos frente a la amenaza? ¿Cuáles son las protecciones existentes? En principio, había 3 copias de la información: la original, la copia de seguridad y las cintas de backup. Por lo tanto, la vulnerabilidad parece baja. Con lo cual, el resultado final parece llevarnos a que el nivel de riesgo en este caso sería de nivel bajo, usando una escala de 5 valores y calculando el nivel de riesgo como valor x amenaza x vulnerabilidad.
La pregunta es: ¿Era necesario tratar ese riesgo con contramedidas adicionales? Es aceptable un nivel de riesgo bajo? Esa es una decisión de empresa, pero en este caso deberíamos asumir que sí (pese a que con activos de tan alto valor económico alguien pudiese pensar que sólo debería ser aceptable un nivel de riesgo muy bajo), ya que no tenemos más datos para valorarlo.
Entonces, si asumimos que la gestión del riesgo se ha llevado a cabo de la forma correcta, dónde ha estado el problema? Pues parece que en este caso el gran problema es el tema del que tanto se habla últimamente en este mundillo: la monitorización, medida y seguimiento de los controles establecidos. Y en este caso, llevados a una contramedida muy concreta: verificar los backups. Esa operación que tantas veces se suele obviar, y que los consultores no nos cansamos de repetir cuando hablamos de backups y continuidad...
De todos modos, el resultado podría haber sido peor. En este caso, el plan de contingencias ha surtido efecto: aunque haya habido que invertir 220000 dólares en ponerlo en práctica, la copia en papel ha permitido no perder definitivamente la información, que ha vuelto a ser introducida en los sistemas. De todos modos, en casos como estos es donde se aprecia realmente el valor de contramedidas más sencillas, como puede ser la de dar suficiente formación a los técnicos o la de contratar a técnicos de mayor perfil de cualificación.
El artículo afirma que un técnico borró una determinada información por error. Es una de las amenazas estándar de cualquier guía: errores en la administración de sistemas. Estaba bien gestionado el riesgo asociado a ella?
El valor de la información es, por lo que parece, muy alto. ¿Cuál es la probabilidad de ocurrencia de la amenaza? A priori debería ser baja... con un técnico "estándar". Pero en este caso es un técnico que no sólo ha borrado la información por error, sino que ha terminado formateando el disco en el que residía la copia de seguridad. En caso de que hubiera sido un técnico suficientemente capacitado, no parece viable este resultado. Por tanto, tenemos que suponer que aparenta ser un técnico de bajo nivel de cualificación. Por tanto, la probabilidad debería ser media o alta.
¿Cuál es la vulnerabilidad de los datos frente a la amenaza? ¿Cuáles son las protecciones existentes? En principio, había 3 copias de la información: la original, la copia de seguridad y las cintas de backup. Por lo tanto, la vulnerabilidad parece baja. Con lo cual, el resultado final parece llevarnos a que el nivel de riesgo en este caso sería de nivel bajo, usando una escala de 5 valores y calculando el nivel de riesgo como valor x amenaza x vulnerabilidad.
La pregunta es: ¿Era necesario tratar ese riesgo con contramedidas adicionales? Es aceptable un nivel de riesgo bajo? Esa es una decisión de empresa, pero en este caso deberíamos asumir que sí (pese a que con activos de tan alto valor económico alguien pudiese pensar que sólo debería ser aceptable un nivel de riesgo muy bajo), ya que no tenemos más datos para valorarlo.
Entonces, si asumimos que la gestión del riesgo se ha llevado a cabo de la forma correcta, dónde ha estado el problema? Pues parece que en este caso el gran problema es el tema del que tanto se habla últimamente en este mundillo: la monitorización, medida y seguimiento de los controles establecidos. Y en este caso, llevados a una contramedida muy concreta: verificar los backups. Esa operación que tantas veces se suele obviar, y que los consultores no nos cansamos de repetir cuando hablamos de backups y continuidad...
De todos modos, el resultado podría haber sido peor. En este caso, el plan de contingencias ha surtido efecto: aunque haya habido que invertir 220000 dólares en ponerlo en práctica, la copia en papel ha permitido no perder definitivamente la información, que ha vuelto a ser introducida en los sistemas. De todos modos, en casos como estos es donde se aprecia realmente el valor de contramedidas más sencillas, como puede ser la de dar suficiente formación a los técnicos o la de contratar a técnicos de mayor perfil de cualificación.
19 marzo 2007
Valorando amenazas
Muchas veces, a la hora de llevar a cabo análisis de riesgos de forma artesanal (sin el soporte de una herramienta), una de las principales dificultades suele aparecer a la hora de dar valores a las amenazas y las vulnerabilidades. Evidentemente, un análisis de riesgos no tiene por qué ser realizado por un experto en seguridad, pero probablemente todo el mundo desee llegar a un resultado tan válido como el que pueda obtener uno.
Existen multitud de técnicas aplicables para simplificar esta tarea, pero una que puede resultar bastante útil puede ser la utilización de la metodología DREAD. Esta técnica, desarrollada para valorar amenazas dentro de un proceso de desarrollo de aplicaciones y sistemas seguros, puede ser utilizada para realizar una priorización de amenazas sencilla y objetiva. En base a cinco parámetros, la metodología sirve para realizar un rápido análisis de la "importancia" de la amenaza, obteniendo un valor que nos permita identificar el factor de riesgo asociado a la misma.
En lugar de explicar la metodología, creo que es más conveniente recurrir a algunas referencias que lo hagan por mí. En primer lugar, una referencia a la metodología realizada por la propia OWASP, y en segundo un artículo en el que aparece explicada. Es suficiente? En caso contrario, siempre queda google...
Existen multitud de técnicas aplicables para simplificar esta tarea, pero una que puede resultar bastante útil puede ser la utilización de la metodología DREAD. Esta técnica, desarrollada para valorar amenazas dentro de un proceso de desarrollo de aplicaciones y sistemas seguros, puede ser utilizada para realizar una priorización de amenazas sencilla y objetiva. En base a cinco parámetros, la metodología sirve para realizar un rápido análisis de la "importancia" de la amenaza, obteniendo un valor que nos permita identificar el factor de riesgo asociado a la misma.
En lugar de explicar la metodología, creo que es más conveniente recurrir a algunas referencias que lo hagan por mí. En primer lugar, una referencia a la metodología realizada por la propia OWASP, y en segundo un artículo en el que aparece explicada. Es suficiente? En caso contrario, siempre queda google...
15 marzo 2007
Herramientas de apoyo a las politicas de seguridad
Hace algunos días leí un artículo que me llamó la atención. Hablaba sobre la conveniencia de utilizar herramientas que automaticen la revisión de cumplimiento de las políticas de seguridad de la compañía. El artículo se enfoca principalmente en las ventajas que aportan las herramientas cuando hay que verificar las políticas contra distintas normas. Sin embargo, creo que hay otros motivos que deben tenerse en cuenta, y que muchas veces suelen ser más determinantes a la hora de tomar estas decisiones.
La primera, y desde mi punto de vista, la más importante en la práctica, es la capacidad que aporta una herramienta a la hora de mantener actualizadas las políticas de la organización. Un simple checklist automatizado tiene muchas más posibilidades de ser rellenado que el mismo checklist en formato tabla. Inexplicablemente, algo dinámico motiva más a la hora de utilizarlo que el mismo contenido en versión estática. Y mantener actualizado el cumplimiento normativo quizás pueda ser tedioso, pero es imprescindible...
Otro de los motivos para optar por una herramienta son las ventajas que ofrece tener un lugar centralizado y multi-usuario para ubicar toda la información relativa a dicho cumplimiento. Una herramienta puede ser accesible por varias personas, con varios perfiles, para distintos fines... pero todos accediendo al mismo repositorio. Desde el responsable de seguridad al auditor, pasando por los directores o los técnicos. Porque todo el que tenga implicaciones en las normativas chequeadas tendrá que conocerlas y actualizarlas...
Y el último de los motivos que quiero destacar, para no extenderme, es la capacidad de registro de cambios que ofrecen este tipo de herramientas. Es uno de los aspectos más duros de cumplir en la práctica, y no sólo a nivel de cambios en la documentación, sino también a la hora de llevar un registro de las distintas formas en las que se cumplen los controles. Nuevos procedimientos, distintas formas de implementar los mismos controles en distintos entornos... Muchas particularidades, que de forma manual sería difícil mantener al día.
En definitiva, las herramientas suelen existir por una razón muy sencilla: facilitan las cosas. Y cuando los fabricantes les dan un coste económico, y hay empresas dispuestas a comprarlas, tiene que ser porque realmente son útiles, no? De todos modos, no olvidemos algo: las herramientas ayudan, pero lo importante es saber hacer las cosas, y entender la lógica que subyace. No debemos cometer el error de volvernos dependientes de ellas.
La primera, y desde mi punto de vista, la más importante en la práctica, es la capacidad que aporta una herramienta a la hora de mantener actualizadas las políticas de la organización. Un simple checklist automatizado tiene muchas más posibilidades de ser rellenado que el mismo checklist en formato tabla. Inexplicablemente, algo dinámico motiva más a la hora de utilizarlo que el mismo contenido en versión estática. Y mantener actualizado el cumplimiento normativo quizás pueda ser tedioso, pero es imprescindible...
Otro de los motivos para optar por una herramienta son las ventajas que ofrece tener un lugar centralizado y multi-usuario para ubicar toda la información relativa a dicho cumplimiento. Una herramienta puede ser accesible por varias personas, con varios perfiles, para distintos fines... pero todos accediendo al mismo repositorio. Desde el responsable de seguridad al auditor, pasando por los directores o los técnicos. Porque todo el que tenga implicaciones en las normativas chequeadas tendrá que conocerlas y actualizarlas...
Y el último de los motivos que quiero destacar, para no extenderme, es la capacidad de registro de cambios que ofrecen este tipo de herramientas. Es uno de los aspectos más duros de cumplir en la práctica, y no sólo a nivel de cambios en la documentación, sino también a la hora de llevar un registro de las distintas formas en las que se cumplen los controles. Nuevos procedimientos, distintas formas de implementar los mismos controles en distintos entornos... Muchas particularidades, que de forma manual sería difícil mantener al día.
En definitiva, las herramientas suelen existir por una razón muy sencilla: facilitan las cosas. Y cuando los fabricantes les dan un coste económico, y hay empresas dispuestas a comprarlas, tiene que ser porque realmente son útiles, no? De todos modos, no olvidemos algo: las herramientas ayudan, pero lo importante es saber hacer las cosas, y entender la lógica que subyace. No debemos cometer el error de volvernos dependientes de ellas.
14 marzo 2007
Sucesos de seguridad
A veces, las cosas más sencillas acaban pareciendo las más complicadas. Una de ellas suele ser lo relativo a la gestión de sucesos de seguridad. Incidentes, eventos, incidencias, fallos... Un montón de términos que a veces se confunden, se entremezclan, y que a los encargados de tratar con ellos dan más quebraderos de cabeza de los que debieran. Y sin embargo, las cosas suelen ser más sencillas de lo que parecen...
Por un lado, tenemos las incidencias de seguridad. Entendidas, sencillamente, como que "ha pasado algo relacionado con la seguridad". Qué ha pasado? Tenemos tres opciones. La primera es que haya pasado "algo malo". Hemos tenido un problema, algo ha fallado. Técnicamente, una amenaza ha conseguido explotar una vulnerabilidad sobre un activo. Y qué hay que hacer? Simplemente, arreglarlo. A eso se le llama corrección.
Otra opción es que la incidencia haya quedado "en nada". Ha sucedido un evento, pero no ha llegado a ser incidente. Una amenaza que nos ha atacado pero finalmente no se ha materializado, una vulnerabilidad nueva que ha aparecido, pero que aún no ha sido explotada... Lo que haya sucedido todavía no nos ha hecho ningún daño. Aunque si no hacemos nada, podría llegar a causarlo. Qué hay que hacer? Evitarlo antes de que suceda: corregir aquello que acabamos de descubrir que está mal, antes de que pase nada (acciones correctivas) o reforzar nuestras medidas de protección, por si acaso (acciones preventivas).
Todavía tenemos una tercera opción. Lo que ha pasado es que hemos descubierto que nuestros controles no funcionan bien. No es que haya pasado algo malo, sino que hemos encontrado un fallo en nuestro sistema de gestión. La incidencia, en este caso, se cataloga como no conformidad, y lo que tendremos que arreglar en este caso es el control en sí, mediante las acciones correctivas correspondientes.
Por último, existe otro tipo de entrada que puede dar lugar a este tipo de acciones. En este caso yo no lo catalogaría como incidencia, ya que no es que "haya pasado algo", sino que alguien realiza una aportación (sugerencia, comentario, ...). En este caso, la aportación (realizada por cualquier persona de la organización) puede ser una propuesta de mejora (lo que desencadenaría la correspondiente acción preventiva si así se considera) o puede "levantar alguna liebre", descubrir algún fallo que deba ser resuelto, mediante las correspondientes acciones correctivas.
Y no olvidemos que una corrección puede conllevar, en su tratamiento a posteriori, una acción correctiva para resolver la causa que ha provocado el incidente. Y que a su vez las acciones correctivas también pueden desencadenar acciones preventivas que ayuden a optimizar las protecciones existentes en relación al origen de los hipotéticos incidentes. En el fondo, todo está relacionado, no?
08 marzo 2007
Pensando en la seguridad
Hace ya algún tiempo, en VNUnet publicaron un artículo (1-2-3-4-5-6) en el que relataban los resultados de un estudio realizado por McAfee en relación a las empresas y la seguridad. En resumidas cuentas, el artículo venía a decir que las empresas tienen importantes debilidades en materia de seguridad de la información. Las causas son la incapacidad de responder adecuadamente a las exigencias legales en materia de seguridad, el excesivo coste que supondría el hacerlo, la dificultad de llevarlas a la práctica, el número insuficiente de especialistas para poder hacerlo y la gran repercusión en imagen que tienen los incidentes relacionados con la seguridad.
La verdad es que el artículo plantea un panorama duro para las empresas en general... y optimista para las consultoras que se dediquen a ello :-) . El estudio es estadounidense, donde SOX está teniendo bastante impacto en materia de seguridad de la información, así que es posible que este panorama no se vea directamente reflejado en el tejido empresarial europeo o latinoamericano. Sin embargo, dice un refrán que "cuando veas las barbas de tu vecino cortar, pon las tuyas a remojar". Así que creo que no es mala idea ver lo que está sucediendo en aquellos lares, y que las empresas de por aquí se vayan preparando desde ahora, para que cuando lleguen medidas similares el impacto que supongan sea mucho menor... Y que nadie dude de que, tarde o temprano, todas las empresas medianamente potentes deberán adoptar medidas similares. Bien por ley, o bien por exigencias de mercado. Pero mucho me temo que todo llegará...
La verdad es que el artículo plantea un panorama duro para las empresas en general... y optimista para las consultoras que se dediquen a ello :-) . El estudio es estadounidense, donde SOX está teniendo bastante impacto en materia de seguridad de la información, así que es posible que este panorama no se vea directamente reflejado en el tejido empresarial europeo o latinoamericano. Sin embargo, dice un refrán que "cuando veas las barbas de tu vecino cortar, pon las tuyas a remojar". Así que creo que no es mala idea ver lo que está sucediendo en aquellos lares, y que las empresas de por aquí se vayan preparando desde ahora, para que cuando lleguen medidas similares el impacto que supongan sea mucho menor... Y que nadie dude de que, tarde o temprano, todas las empresas medianamente potentes deberán adoptar medidas similares. Bien por ley, o bien por exigencias de mercado. Pero mucho me temo que todo llegará...
Calidad no es igual que Gestión
En muchas ocasiones, al nombrar la calidad la gente piensa automáticamente en los sistemas de gestión. Supongo que el mérito se debe a la archiconocida ISO 9001. Esa norma define un sistema de gestión de la calidad. Sin embargo, deberíamos ser capaces de diferenciar las dos partes: el sistema de gestión y el componente de calidad. Los motivos para tener clara esta distinción son diversos, pero yo me voy a quedar con uno en particular: hay muchas normas que definen sistemas de gestión para distintos fines (seguridad de la información, medio ambiente, ...), y si somos capaces de identificar los componentes del sistema de gestión tendremos al alcance de la mano la integración de todos ellos.
Y qué es el sistema de gestión? Como alguien me ha dicho alguna vez, el sistema de gestión es el motor. Es la forma de trabajar, lo que permite que la calidad (en este caso) se gestione de forma adecuada. En resumen, el sistema de gestión es el ciclo PDCA. Y por tanto se compone de:
Y qué es el sistema de gestión? Como alguien me ha dicho alguna vez, el sistema de gestión es el motor. Es la forma de trabajar, lo que permite que la calidad (en este caso) se gestione de forma adecuada. En resumen, el sistema de gestión es el ciclo PDCA. Y por tanto se compone de:
- Plan: Políticas, objetivos, metas, planes, ...
- Do: Procesos, difusión, formación, gestión documental, registros, ...
- Check: Auditorías, mediciones, gestión de incidencias, no conformidades, revisión por la dirección, ...
- Act: Correcciones, acciones correctivas, acciones preventivas, ...
Estos elementos (junto con algún otro) forman el sistema de gestión, y por tanto serán comunes en cualquier norma que defina un SGx. Es más, serán los elementos principales de un SGI (Sistema de Gestión Integrado).
Y si quitamos el sistema de gestión a la ISO 9001, qué nos queda? Pues sencillamente, la calidad. La calidad es, formalmente, el grado en el que las características de los productos/servicios cumplen con unos requisitos. Qué requisitos? Los del cliente. Es decir, que podemos entender la calidad, sencillamente, como "satisfacer al cliente". Evidentemente, la ISO 9001 introduce otra serie de elementos propios, entre los que podemos identificar como más significativos la selección de proveedores o las encuestas de satisfacción. Además, también regula las líneas generales bajo las que se deben desarrollar los procesos productivos. Sin embargo, creo que lo más destacable desde el punto de vista de la calidad propiamente dicha es la orientación al cliente.
En definitiva, podemos resumir que las principales aportaciones de la ISO 9001 son dos: ser la primera norma de gran difusión que define un sistema de gestión e introducir la orientación al cliente como referencia principal para los procesos productivos. Y aunque a día de hoy ambos conceptos se hayan podido ver degradados, la próxima revisión de la norma puede ayudar a que vuelvan a cobrar la significancia que tuvieron durante su redacción.
01 marzo 2007
Póngame una de SLAs!
Últimamente, eso de los SLAs (Service Level Agreements) se ha convertido en un tema de conversación tan habitual que parece algo que sirvan en los bares de tapas. El problema es que la terminología se ha trivializado tanto que en muchas ocasiones se utiliza el término de forma incorrecta.
Un SLA debe ser, en primer lugar, un acuerdo. En caso contrario estaríamos, como mucho, ante un SLI (de Imposition). Debe ser un acuerdo en todos los sentidos, desde el precio hasta los elementos a valorar. Vamos, que el contrato particular del ADSL nunca será un SLA, aunque nos garanticen un cierto ancho de banda o nos regalen el primer mes de cuota si no funciona bien. ¿O alguien piensa que el operador de banda ancha va a negociar el contrato con los particulares?
Evidentemente, un SLA tiene que incluir niveles de servicio (que por algo aparecen la S y la L). Pero... qué es una disponibilidad del servicio de asistencia técnica del 99%? ¿Significa que casi siempre que llamo me cogen el teléfono? ¿Tanto si llamo a las 10 de la mañana como a las 12 de la noche? El SLA tiene que definir no sólo el servicio en sí, sino sus características, cómo se calcula el indicador, en qué periodo se mide...
Normalmente, los SLAs incluyen penalizaciones si no se alcanzan los compromisos. Pero... es suficiente? Si en lugar del 99% me dan una disponibilidad del 50%, las penalizaciones me resarcen de los perjuicios causados? Y si por culpa del incumplimiento pierdo clientes? Un SLA también debería incluir un mínimo garantizado, que me asegure que la curva de penalización realmente me compensa.
Y otro apartado que debería incluir todo SLA son las condiciones adicionales. Y aquí es donde la mayoría de los mal llamados SLAs fallan. No es suficiente con especificar en el contrato todos los apartados anteriores. Hay otros aspectos como el seguimiento, la gestión de cambios en los servicios prestados, la resolución de conflictos o los roles y funciones de proveedor y cliente que deberían estar especificados. Contemplan estos aspectos los SLAs del bar de tapas?
En resumen, un SLA es un contrato en el que, en el caso ideal, todas las situaciones que se puedan dar en relación a la prestación del servicio han sido contempladas y reguladas. Sobre todo, un contrato en el que se contemple no sólo qué hacer cuando todo va bien, sino que tenga en cuenta cómo actuar cuando todo va mal. ¿El objetivo final? Que los problemas graves entre cliente y proveedor se puedan resolver como amigos, porque hemos acordado en el SLA cómo se deben resolver situaciones que, en otro caso, quizás llegasen a los tribunales.
Un SLA debe ser, en primer lugar, un acuerdo. En caso contrario estaríamos, como mucho, ante un SLI (de Imposition). Debe ser un acuerdo en todos los sentidos, desde el precio hasta los elementos a valorar. Vamos, que el contrato particular del ADSL nunca será un SLA, aunque nos garanticen un cierto ancho de banda o nos regalen el primer mes de cuota si no funciona bien. ¿O alguien piensa que el operador de banda ancha va a negociar el contrato con los particulares?
Evidentemente, un SLA tiene que incluir niveles de servicio (que por algo aparecen la S y la L). Pero... qué es una disponibilidad del servicio de asistencia técnica del 99%? ¿Significa que casi siempre que llamo me cogen el teléfono? ¿Tanto si llamo a las 10 de la mañana como a las 12 de la noche? El SLA tiene que definir no sólo el servicio en sí, sino sus características, cómo se calcula el indicador, en qué periodo se mide...
Normalmente, los SLAs incluyen penalizaciones si no se alcanzan los compromisos. Pero... es suficiente? Si en lugar del 99% me dan una disponibilidad del 50%, las penalizaciones me resarcen de los perjuicios causados? Y si por culpa del incumplimiento pierdo clientes? Un SLA también debería incluir un mínimo garantizado, que me asegure que la curva de penalización realmente me compensa.
Y otro apartado que debería incluir todo SLA son las condiciones adicionales. Y aquí es donde la mayoría de los mal llamados SLAs fallan. No es suficiente con especificar en el contrato todos los apartados anteriores. Hay otros aspectos como el seguimiento, la gestión de cambios en los servicios prestados, la resolución de conflictos o los roles y funciones de proveedor y cliente que deberían estar especificados. Contemplan estos aspectos los SLAs del bar de tapas?
En resumen, un SLA es un contrato en el que, en el caso ideal, todas las situaciones que se puedan dar en relación a la prestación del servicio han sido contempladas y reguladas. Sobre todo, un contrato en el que se contemple no sólo qué hacer cuando todo va bien, sino que tenga en cuenta cómo actuar cuando todo va mal. ¿El objetivo final? Que los problemas graves entre cliente y proveedor se puedan resolver como amigos, porque hemos acordado en el SLA cómo se deben resolver situaciones que, en otro caso, quizás llegasen a los tribunales.
Valorando con criterio
Uno de los elementos fundamentales a la hora de llevar a cabo un análisis de riesgos es la valoración de los activos. Sin embargo, también suele ser uno de los apartados más difíciles. ¿A qué se debe? Fundamentalmente, la dificultad estriba en dos apartados: Entender el motivo de la valoración y asignar un valor de forma objetiva.
La primera parte es conceptual. En un análisis de riesgos, un activo es “cualquier cosa con valor para la organización”, y esto puede ir desde la imagen o la marca hasta los edificios en los que se ubica, pasando por los servicios o productos que desarrolla, el personal de la organización o los equipos informáticos, entre otros ejemplos. Y cada uno de estos activos debe ser valorado.
¿Qué es el valor? Es la importancia que tiene ese activo para la organización. No debemos pensar directamente en su coste económico, sino en la función que ese activo desarrolla en la organización. Un tornillo en sí mismo no tiene mucho valor, pero si es el que sujeta el ala de un avión, creo que todos entenderemos que el valor de ese tornillo es muy elevado (sobre todo, lo apreciarán los que vayan dentro del avión).
¿Qué hay que valorar? En un análisis de riesgos de seguridad de la información lo que se valora es la seguridad de los activos en relación a la información (y negocio) que sustentan. En este caso, no se trata de entender la importancia de que se caiga el tornillo, sino de que la información pierda su confidencialidad (se divulgue), pierda su integridad (se modifique) o pierda su disponibilidad (no se pueda acceder a ella cuando se necesita). Se puede entender fácilmente a nivel particular con un ejemplo: las nónimas. ¿Cuánto nos importa que alguien se entere de lo que cobramos? ¿O que en la nómina aparezca un 0 de menos? ¿O que no tengamos las nóminas cuando las tenemos que presentar para pedir un crédito?
El ejercicio a nivel empresarial es similar. El problema es que a la hora de asignar valores no es tan sencillo ponerse de acuerdo. ¿Cómo se puede resolver? En primer lugar, pidiendo que la valoración la realice la alta dirección. Buscamos la opinión “de empresa”, no las opiniones particulares. Y guste o no, la opinión de empresa viene dictada por la dirección. Así que deben ser ellos los que deben valorar. Y la valoración no debe ser arbitraria, sino que tiene que ser objetiva (lo más objetiva posible) y repetible.
Para conseguir objetivizar las opiniones tenemos que asignar criterios de valoración. ¿Cuál es la escala de “importancia” de la organización? Pensemos en el avión. ¿Por qué es importante el tornillo? ¿Porque se cae el ala? En realidad no, en realidad es importante por las consecuencias finales que tiene la caída del ala: pérdida de vidas humanas. Ya tenemos un criterio de valoración. Y ese criterio vale para cualquier activo: sea el que sea, e indistintamente del motivo que lo cause, si el resultado final es la pérdida de vidas humanas, ese activo tendrá un valor muy alto.
En nuestras empresas tendremos que hacer lo mismo. La dirección tendrá que hacer el ejercicio de identificar los criterios a tener en cuenta, y posteriormente tendrá que asignar distintos niveles. Si las pérdidas económicas es un criterio de valoración, no será lo mismo perder 10 € que perder 100 ó 1000. El resultado final debe ser una tabla que identifique por filas los criterios de valoración (pérdidas económicas, incumplimientos legales, deterioro de imagen, impactos operativos, …) y por columnas los niveles (por ejemplo, bajo-medio-alto), de modo que cada nivel sea equiparable entre los distintos criterios.
¿Y cuál es la ventaja de todo esto? Que si conseguimos que la dirección valide una tabla de criterios, ya no será necesaria su participación directa a la hora de valorar la enorme cantidad de activos que probablemente habremos identificado. Bastará con indicar que el activo “tornillo” tiene un valor “alto” porque en el criterio “daños personales” encaja en el contenido de la casilla “pérdida de vidas”, que está en la columna de "alto". Seguro que la dirección valida esta valoración, ya que los criterios los han puesto ellos. Y además, cualquiera que conozca lo suficiente el negocio (siempre y cuando sepa que de ese tornillo depende el ala del avión, y que del ala depende que el avión se caiga) podrá repetir el año que viene el mismo análisis y llegar a resultados similares, de modo que habremos conseguido que el análisis sea repetible. Objetivo cumplido!
La primera parte es conceptual. En un análisis de riesgos, un activo es “cualquier cosa con valor para la organización”, y esto puede ir desde la imagen o la marca hasta los edificios en los que se ubica, pasando por los servicios o productos que desarrolla, el personal de la organización o los equipos informáticos, entre otros ejemplos. Y cada uno de estos activos debe ser valorado.
¿Qué es el valor? Es la importancia que tiene ese activo para la organización. No debemos pensar directamente en su coste económico, sino en la función que ese activo desarrolla en la organización. Un tornillo en sí mismo no tiene mucho valor, pero si es el que sujeta el ala de un avión, creo que todos entenderemos que el valor de ese tornillo es muy elevado (sobre todo, lo apreciarán los que vayan dentro del avión).
¿Qué hay que valorar? En un análisis de riesgos de seguridad de la información lo que se valora es la seguridad de los activos en relación a la información (y negocio) que sustentan. En este caso, no se trata de entender la importancia de que se caiga el tornillo, sino de que la información pierda su confidencialidad (se divulgue), pierda su integridad (se modifique) o pierda su disponibilidad (no se pueda acceder a ella cuando se necesita). Se puede entender fácilmente a nivel particular con un ejemplo: las nónimas. ¿Cuánto nos importa que alguien se entere de lo que cobramos? ¿O que en la nómina aparezca un 0 de menos? ¿O que no tengamos las nóminas cuando las tenemos que presentar para pedir un crédito?
El ejercicio a nivel empresarial es similar. El problema es que a la hora de asignar valores no es tan sencillo ponerse de acuerdo. ¿Cómo se puede resolver? En primer lugar, pidiendo que la valoración la realice la alta dirección. Buscamos la opinión “de empresa”, no las opiniones particulares. Y guste o no, la opinión de empresa viene dictada por la dirección. Así que deben ser ellos los que deben valorar. Y la valoración no debe ser arbitraria, sino que tiene que ser objetiva (lo más objetiva posible) y repetible.
Para conseguir objetivizar las opiniones tenemos que asignar criterios de valoración. ¿Cuál es la escala de “importancia” de la organización? Pensemos en el avión. ¿Por qué es importante el tornillo? ¿Porque se cae el ala? En realidad no, en realidad es importante por las consecuencias finales que tiene la caída del ala: pérdida de vidas humanas. Ya tenemos un criterio de valoración. Y ese criterio vale para cualquier activo: sea el que sea, e indistintamente del motivo que lo cause, si el resultado final es la pérdida de vidas humanas, ese activo tendrá un valor muy alto.
En nuestras empresas tendremos que hacer lo mismo. La dirección tendrá que hacer el ejercicio de identificar los criterios a tener en cuenta, y posteriormente tendrá que asignar distintos niveles. Si las pérdidas económicas es un criterio de valoración, no será lo mismo perder 10 € que perder 100 ó 1000. El resultado final debe ser una tabla que identifique por filas los criterios de valoración (pérdidas económicas, incumplimientos legales, deterioro de imagen, impactos operativos, …) y por columnas los niveles (por ejemplo, bajo-medio-alto), de modo que cada nivel sea equiparable entre los distintos criterios.
¿Y cuál es la ventaja de todo esto? Que si conseguimos que la dirección valide una tabla de criterios, ya no será necesaria su participación directa a la hora de valorar la enorme cantidad de activos que probablemente habremos identificado. Bastará con indicar que el activo “tornillo” tiene un valor “alto” porque en el criterio “daños personales” encaja en el contenido de la casilla “pérdida de vidas”, que está en la columna de "alto". Seguro que la dirección valida esta valoración, ya que los criterios los han puesto ellos. Y además, cualquiera que conozca lo suficiente el negocio (siempre y cuando sepa que de ese tornillo depende el ala del avión, y que del ala depende que el avión se caiga) podrá repetir el año que viene el mismo análisis y llegar a resultados similares, de modo que habremos conseguido que el análisis sea repetible. Objetivo cumplido!
Suscribirse a:
Entradas (Atom)
