El objetivo de la gestión de la seguridad

Esta semana tuve la oportunidad de asistir a la charla de Fred Piper durante la VII Jornada Internacional del ISMS Forum (ya os dije que teníais que venir...) y tuve uno de esos momentos reveladores: ya sabéis, ese momento en el que alguien dice algo obvio pero que al verlo escrito negro sobre blanco impacta sobremanera sobre uno.

En concreto, fue una frase de Fred en la que venía a decir algo así como que el objetivo de la gestión de la seguridad era minimizar la suma de dos costes, por un lado, el coste de las medidas de seguridad y, por otro, el de la inseguridad. La verdad es que algo obvio, ¿no? Pero no sé, el caso es que debió recordarme a mis clases de Economía en la Facultad y, como decía el anuncio aquel: "M'a impactao".

¿Cuál es la potencia de esta frase? Bueno, pues que, en el fondo, "reduce" la gestión de las seguridad a un problema matemático: Minimizar el valor de una fórmula como la siguiente, Cs = Cm + Ci donde Cs es el coste total de la seguridad, Cm es el coste de las medidas que establecemos y Ci es el coste de la inseguridad (o de la no-seguridad).

Las dificultades que nos encontramos en el día a día para resolver este "sencillo" problema son diversas:

• Para mi, la principal dificultad es que el coste de la inseguridad es un coste oculto (en muchos casos). Normalmente porque, en realidad, ese coste lo sufren otros (es una externalidad) como pueden ser los casos de software con fallos de seguridad, brechas de seguridad con robo de datos de clientes, empleados... o un proveedor se servicios en la nube con una insuficiente seguridad que ocasiona daños a sus clientes o a los clientes de su cliente...
• Otra dificultad es el componente aleatorio del coste de la inseguridad. Es decir, aunque el software sea inseguro cabe la posibilidad de que no falle o que no se descubra la vulnerabilidad por nadie. Aquí es donde entran en juego los análisis de riesgos que, en teoría, nos deberían ayudar a "estimar" el valor en riesgo (Value at Risk) de forma que el problema de minimización tomara los datos correctos, pero lo de la gestión de la incertidumbre no es nuestro fuerte: subjetividad de las estimaciones, dudosa validez del pasado para predecir el futuro y cisnes negros en general...

Si unimos ambos factores, lo que sucede es que, seguramente, la elección de inversión de seguridad (el único factor sobre el que podemos influir) no será la adecuada, ya que no se habrán tenido en cuenta todos los costes de la inseguridad (bien porque los sufran otros, bien porque todavía no se hayan materializado o porque hayamos errado al calcular el valor en riesgo) provocando, lo que en Economía llamamos, una decisión sub-óptima que minimiza la ecuación utilizada por la organización, pero no la real.

Ya, pero ¿qué podemos hacer? Pues, en mi opinión, la solución pasa por dos aspectos:

1. Incorporar todas las externalidades a la ecuación (por el mecanismos que sea: sanciones, impuestos, etc.)
2. Aprender a gestionar la incertidumbre

¿Qué es difícil? ¡Toma, pues claro! ¿Alguien se pensaba que iba a ser fácil? Eso no tendría ningún mérito...

... ¿Todavía no me sigues en twitter.com/antonio_ramosga?

¿Cómo aplica PCI-DSS a las grabaciones de voz de los Call Centers?

Esta es otra duda recurrente en relación al cumplimiento del estándar PCI-DSS que vamos a tratar de enfocar / solucionar. Concretamente, la duda surge porque en este entorno los datos de los titulares de tarjeta son grabaciones de voz y no el típico dato en un fichero o base de datos. Dicha situación hace que sea necesario interpretar los requerimientos del estándar y adaptarlos a las especificidades de este entorno.

La primera duda que nos podría surgir sería la de si  las grabaciones de voz estarían dentro del alcance del estándar. La respuesta es sencilla, sí, las grabaciones de voz forman parte del denominado CDE - Cardholder Data Environment siempre que se produzca, como mínimo, el almacenamiento del PAN. Otra cosa es que, como ya hemos dicho, no sea un almacenamiento típico y requiera de la interpretación del estándar para su aplicación.

Evidentemente, la siguiente duda sería que "si las grabaciones de voz están dentro del alcance, ¿cómo protejo los datos de los titulares?". Pues bien, aquí es donde tenemos que hacer el esfuerzo de interpretación. Básicamente, podemos encontrarnos con dos casuísticas en las grabaciones de voz: analógicas vs. digitales.

• En el primer caso (grabaciones de voz analógicas), las medidas a establecer serían muy similares a las que aplicaríamos al almacenamiento en papel, es decir, controles de acceso físico y lógico a los soportes.
• En el segundo caso (grabaciones de voz digitales), la cosa se complica porque además de almacenarse la información en ficheros .mp3, .wav o el que sea, las herramientas que se utilizan en estos casos permite realizar búsquedas en dichos ficheros y recuperar información de manera ágil. En estos casos, las medidas son más amplias y, por ejemplo, deberemos aplicar el requerimiento 3.4 y hacer que el "PAN quede, como mínimo, ilegible en cualquier lugar donde se almacene".

Y, finalmente, la madre del cordero: "Pero, si durante el transcurso de la llamada, el cliente me da un dato sensible de autenticación, ¿tengo que eliminarlo o lo puedo archivar?" Para responder a esta pregunta, lo mejor es remitirnos al Council, concretamente a la sección de las FAQ donde encontramos justo esa pregunta: "Are audio/voice recordings containing cardholder data and/or sensitive authentication data included in the scope of the PCI DSS? (5362)". Básicamente lo que nos viene a decir es que:

1. Aplicando el requerimiento 3.2 no se pueden almacenar los datos sensibles de autenticación (ya sabéis, CAV2/CVC2/CVV2/CID) después de la autorización (ni cifrados) y que, por tanto, no se pueden almacenar esta información en ningún tipo de fichero de audito digital si el sistema permite la realización de búsquedas. 
2. Para los casos en los que no se puedan realizar búsquedas, entonces volvemos a lo comentado anteriormente y permiten su almacenamiento con las medidas de control de acceso lógico y físico correspondientes requeridas por el estándar.

En fin, aunque es un poco lioso espero haber sido de ayuda... [y si quedan dudas, ya sabéis, para eso están los comentarios ;-) ]

... ¿Todavía no me sigues en twitter.com/antonio_ramosga?

Carpe Diem | Entradas previas sobre PCI-DSS

Declaración Ministerial de Granada

A través de la ANEI me ha llegado la Declaración Ministerial de Granada acordada el pasado 19 de abril por los Ministros responsables de las Políticas de la Sociedad de la Información de los Estados Miembros de la Unión Europea.

Dado su interés, me gustaría compartir las acciones que recoge en materia de "Uso avanzado de la Internet abierta, seguridad y confianza" que son, nada más y nada menos, 7 de las 29 acciones aprobadas:

5.  Salvaguardar el carácter abierto de Internet, mediante la implementación y la supervisión de la nueva normativa de comunicaciones electrónicas de la UE, en lo relativo a la explotación de redes.  
6.  Incrementar la fortaleza de una Economía Digital Europea inteligente, sostenible e inclusiva, promoviendo en particular:
a.  el uso generalizado de las TIC en la educación y el aprendizaje, por ejemplo mediante la extensión masiva de ordenadores portátiles, así como de contenidos y herramientas digitales interactivos, además de la alfabetización digital de los ciudadanos y la capacitación digital en las empresas, particularmente en las pymes; 
b.  servicios públicos abiertos e inteligentes, tales como la sanidad en línea y la administración electrónica.
c.  despliegue sistemático de las TIC, para afrontar retos claves de la sociedad, tales como el envejecimiento y el cambio climático. 
7.  Explorar la forma de aprovechar las oportunidades del cloud computing para conseguir una mayor productividad y eficiencia,  así como mejoras medioambientales, especialmente para los organismos públicos europeos, para  pequeñas empresas y para determinadas comunidades.
8.  Promover la protección de datos, así como la seguridad y confianza en las redes y de la información, mediante acciones concertadas en la UE en relación con la autenticación electrónica para los consumidores y los negocios en línea, especialmente mediante firma electrónica, DNI electrónico, pago electrónico y seguridad en Internet.
9.  Aumentar la concienciación pública sobre los riesgos de la seguridad en línea, a fin de conseguir una cultura de protección de datos y de privacidad; coordinar medidas en el ámbito de la UE para incrementar la seguridad de las redes y de la información, particularmente a través de ENISA; difundir mejores prácticas; e  invertir en I+D en ciberseguridad y en tecnologías que acrecienten la privacidad.
10. Capacitar a los ciudadanos para que se puedan integrar plenamente en el entorno digital, reforzando su confianza y habilidades para la compra de bienes y servicios en línea.
11. Promover el uso y el acceso a la sociedad de la información con igualdad de oportunidades, particularmente en el caso de los ciudadanos con necesidades especiales, a través de medidas de accesibilidad electrónica, facilidad de uso, mejoras de diseño, promoción del autoempleo facilitado por las TIC e impulsando el uso generalizado de servicios digitales.

La verdad es que están muy bien, pero habrá que ver en qué medidas concretas se traducen...

... ¿Todavía no me sigues en twitter.com/antonio_ramosga?

Eventos ISMS Forum Spain en mayo 2010

La semana que viene la gente del ISMS Forum Spain nos van a tener ocupados. Además de la VII Jornada Internacional que tendrá lugar el día 25 (el martes) y que contará con ponentes de organismos (ambos de primer nivel) como Udo Helmbrecht de ENISA, Irene Mia del World Economic Forum, Christopher Coggrave de HP, Fred Piper de la Universidad de Londres, Joshua Pennell de Cloud Security Alliance o el profesor Joaquim Vilà. Además de tres mesas redondas de altísimo nivel (ver el programa detallado aquí).

Pero, además, el día anterior (lunes, 24 a las 17 horas) tenemos el II Foro DPI que versará sobre los dos años de vida del Reglamento de la LOPD con un debate, de primer nivel en el que intervendrán la Agencia de Protección de Datos de la Comunidad de Madrid, INTECO, la Agencia de Informática y Comunicaciones de la Comunidad de Madrid, MAPFRE y la Agencia Española de Protección de Datos precedido por la introducción de Udo Helmbrecht, Director General de ENISA.

En fin, como os decía, dos eventos imprescindibles que nos mantendrán entretenidos la semana próxima. Nos vemos allí...

... ¿Todavía no me sigues en twitter.com/antonio_ramosga?

Proyecto de Real Decreto para la Protección de las Infraestructuras Críticas

El pasado 30 de abril finalizó el plazo para realizar comentarios al Proyecto de Real Decreto para la Protección de las Infraestructuras Críticas (al que denominaremos, RDPIC) que ha preparado el Centro Nacional para la Protección de las Infraestructuras Críticas (CNPIC). Pues bien, después de haber tenido la oportunidad de revisarlo me gustaría compartir con vosotr@s mis principales conclusiones [además las he resumido para que no quedara una entrada demasiado larga, así que si queréis más, ya sabéis que podéis comentar]. 

Antes de entrar en materia, un comentario previo: Aunque evidentemente este proyecto de RDPIC deberá estar alineado con la Directiva 2008/114/CE, no se trata de realizar una trasposición directa puesto que ésta se circunscribe a la protección de infraestructuras críticas cuando tienen impacto a nivel europeo, mientras que el ámbito geográfico del RDPIC es el territorio nacional. Por tanto, aunque es de esperar cierto alineamiento, más que nada por consistencia, tampoco tiene porque ser total... Dicho esto, vamos allá con mis comentarios:

1.  Ámbito de aplicación

El texto propuesto se limita a la protección en caso de ataques deliberados. En mi opinión, este alcance se queda un poco corto puesto que sabemos que no todos los orígenes de las amenazas son intencionados y que, puestos a proteger, mejor considerar todos los posibles orígenes aunque luego, como es lógico, no tratemos igual todas las amenazas.

2. Especificación de los criterios de criticidad

En el proyecto de RDPIC se enumeran los criterios que han de servir para nominar una infraestructura como crítica (iguales que los de la Directiva... perfecto) pero no se detallan. Si no se especifican dichos criterios estaremos a disposición de la subjetividad del evaluador de turno, algo en lo que todos coincidiremos que hay que tratar de evitar por todos los medios, ¿no?

3. El papel del análisis de riesgos

Aquí, ya sé que no teníamos escapatoria porque también está recogido en la Directiva pero... lo siento, no creo que podamos confiar la protección de las infraestructuras críticas a los análisis de riesgos... No, no soy un hereje, simplemente es que los análisis de riesgos, por una parte, si no definimos criterios claros y medibles, estarán repletos de subjetividades y, por otra, sabemos que existen "cisnes negros" que nunca vamos a contemplar en el análisis si nos limitamos a mirar hacia el pasado.

En definitiva, usemos los análisis de riesgos para gestionar aquellas amenazas que se materializan con cierta asiduidad pero, dejemos también un espacio para considerar eventos de gran impacto aunque, hoy por hoy, nos parezcan poco probables.

Finalmente, el análisis de riesgos, sin más, no nos aporta nada a la protección de este tipo de activos, sino que la herramienta clave será el umbral de riesgo que la Administración decida aceptar como nivel de riesgo tolerable... porque, desde luego, si lo dejamos abierto, no obtendremos una protección ni uniforme, ni coherente (el nivel de protección será el nivel de la infraestructura menos protegida, a.k.a. factor limitante o eslabón más débil de la cadena) [por cierto, me repito... esto ya lo dije comentando el Esquema Nacional de Seguridad].

4. Stakeholders

Ya sé que vivimos en un país complejo (me encanta la definición que le escuché a Ángel Garó: "Somos un país que, en realidad, somos los Juegos Reunidos Geyper") pero el número de actores incluidos en el proyecto de RDPIC hace que sea extremadamente difícil seguir el rol y las responsabilidades de cada uno. En mi opinión se debería incluir algún tipo de representación de la típica matriz RACI para que se pudiera seguir fácilmente y todo estuviera mucho más claro (en especial, el asunto de la supervisión y control).

5. Infraestructuras estratégicas y críticas

Aunque éste es un asunto, claramente, menor, supone un mayor grado de complejidad para el RDPIC, dado que su ámbito son las infraestructuras críticas pero en múltiples ocasiones se habla de infraestructuras, sectores o subsectores estratégicos que, obviamente, es un conjunto mayor que el de las críticas. Ya sé que parece tener poca trascendencia pero he de reconocer que me he liado... y además, tenemos que decidir si queremos proteger las unas o las otras, o todas...

Lectura: "Tribus. Necesitamos que TÚ nos lideres"

Podríamos decir que es el típico libro que nos habla sobre aspectos que te resultan obvios cuando los lees, pero que alguien (tipo Seth Godin) tiene que ponerlos alguna vez negro sobre blanco.

En palabras del propio Seth, una "tribu es cualquier grupo de personas, muchas o pocas, conectadas unas a otras, a un líder y a una idea". Aunque el ámbito de Seth ha sido el marketing, la verdad es que muchos de los aspectos que comenta en esta obra tienen mucho que ver con la estrategia empresarial e incluso la forma de construir equipos de personas.

Después de leerlo, mis ideas sobre el futuro (negro) de las empresas en la era del conocimiento y la mejor posición de las UTP (ya sabéis, Uniones Temporales de Personas) para abordar el futuro salen reforzadas.

Como es habitual en mis entradas sobre lecturas, os adjunto algunos pasajes destacados [os reconozco que he tenido que hacer un gran esfuerzo para no copiar la mitad del libro]:

"Liderar consiste en en crear cambios en los que tú crees".
"Los líderes tienen seguidores. Los directores tienen empleados".

"El objetivo de la compañía es enriquecer al rey (presidente) y mantenerlo en el poder".

"A lo que la gente le tiene miedo no es al fracaso. Es a los reproches. A las críticas".

"Los grandes líderes se centran solo en la tribu. [...] Son generosos. Existen para ayudar a la tribu a encontrar algo, para ayudarla a prosperar".

"... es un error creer que los mejores reclutas de la tribu son los corderos. Los tipos que no hacen más que seguir mecánicamente las instrucciones son decepcionantes".

"... los grandes líderes no pretenden complacer a todo el mundo. Los grandes líderes no rebajan la fuerza de su mensaje para que la tribu sea un poco más grande. [...] una tribu motivada y conectada [...] es mucho más fuerte de lo que sería un grupo más numeroso [...]."

"Acomodarse no es divertido. Es un mal hábito [...]. Los directivos se acomodan constantemente.

"Antes o después las tribus se estancan. [...] Si tu objetivo es hacer posible el cambio [....], si la mayoría está centrada en mantener el status quo [...] lo oportuno es separarse en una nueva tribu [...] Es correcto abandonar la gran tribu, la tribu estancada."

"Ya se trate de un producto, un servicio o una carrera profesional, las fuerzas de la mediocridad se unirán para detenerte."

Como os decía, no descubre América, pero son 123 páginas muy recomendables para animarte a iniciar tú cambio...

Lectura: "Alicia en el País de las Maravillas"

Pues sí, aunque parezca mentira ha sido mi última lectura. Básicamente, por dos motivos. Primero porque no lo había leído [sí, sí, había visto la película de Disney pero no había leído la obra]. Y tengo que reconocer que me ha gustado, la he leído de un plumazo y me he divertido. No lo puedo remediar, me encantan los juegos de palabras [os recomiendo su lectura en inglés], las referencias a sucesos externos de una manera más o menos velada y los razonamientos falaces. Y el libro está repleto de ellos.

Y segundo, porque una mañana hace unos pocos días [afeitándome, que es cuando me pasan estas cosas], me dí cuenta que hay momentos en la vida (tanto personales, como profesionales) que son, a todos los efectos, como un viaje al País de las Maravillas:

• Hay un conejo blanco, que despierta tu curiosidad y te atrae de manera irremediable a la madriguera de entrada al País.
• Durante un tiempo [lo que dura una siesta, y yo soy muy dormilón], vives experiencias increíbles, alucinantes, diferentes a todo lo que has vivido hasta ese momento.
• Cuando despiertas, te das cuenta, de que todo ha sido una ilusión y que aquello fue solo un espejismo, el producto de tu imaginación, de tu inocencia.

En definitiva, lo he leído porque, ya que tenía la sensación de haber realizado un viaje a un País de las Maravillas, quería conocer en detalle cuál había sido el viaje de Alicia.

2ª Edición del Curso de Analista de Riesgos en Seguridad de la Información del ISMS Forum

No sé si lo sabréis, pero el próximo 19 de abril se inicia la Segunda Edición del curso intensivo que organiza el ISMS Forum Spain sobre Análisis de Riesgos en Seguridad de la Información.

Os lo digo porque acabo de recibir un correo de los organizadores diciendo que quedan sólo 2 vacantes y creo que es un curso que merece la pena (no porque yo esté entre los que lo imparten... ;-), qué también) sino por quién lo organiza, por el resto de profesores (todos/as ellos/as con mucha, muchísima experiencia) y por el enfoque práctico y nada dogmático del mismo (vamos, desde el sufrimiento de todos los que hemos lidiado con un análisis de riesgos).

Si estáis interesados, solo tenéis que mandar una carta de motivación y un breve CV a formacion@ismsforum.es que  confirmará la admisión a través de un correo electrónico, e incluirá las instrucciones para realizar el pago de la matrícula.

Espero veros por allí... ¡¡animaros!!

Actualización: Los alumnos han decidido que sea el profesor mejor valorado... gracias a todos y en especial a Adolfo, ya sabes que el mérito es compartido, ¿verdad?

Lectura: Schneier on Security

Tengo que reconocer que me ha costado un poco... leerlo, me refiero. Supongo que debido al hecho de que se trata "simplemente" de una recopilación de ensayos y textos ya publicados, bien en el blog de Bruce o en otros medios. De hecho, el libro te sirve sobre todo para leer artículos "antiguos" porque los más recientes ya los hemos podido leer en su blog, principalmente.

De todas formas leer (o releer) las reflexiones de Bruce siempre está bien porque te hacen pensar sobre la seguridad y sobre todo el por qué de la no-seguridad.

Algunos de las citas que me gustaría compartir con vosotros (traducidas al castellano, claro):

"La seguridad es un intercambio [...] El terrorismo no es diferente. Necesitamos sopesar cada contramedida de seguridad. ¿Merece la pena el coste de la seguridad adicional respecto a los riesgos? ¿Son estas cosas en las mejores en las que gastarnos el dinero?

"La lección es clara (para el ámbito de la privacidad desde el mundo de las tarjetas): Hacer a la parte en la mejor posición para mitigar el riesgo, responsable de dicho riesgo"

"La seguridad debe ser evaluada no basándose en cómo funciona, sino en ćomo falla"

Y artículos que HAY que leer:

• "Sitios web, contraseñas y clientes", publicado en IEEE Security and Privacy, julio/agosto 2004.
• "Una mentalidad de seguridad", publicado en Wired, marzo 2008.
• "Seguridad de una planta química y las externalidades", publicado en Wired, octubre 2007.
• "Usuarios domésticos: Un problema de Salud Pública", publicado en Information Security, septiembre  2007.
• "Separando la propiedad de los datos y la propiedad de los dispositivos", publicado en Wired, 30 de noviembre de 2006.
• "Combatiendo el spam", publicado en Crypto-Gram, 15 de mayo de 2005.

En resumen, un buen compendio de textos sobre seguridad de la información para aquellos que están interesados en esta temática.

¿Aplica PCI DSS a los emisores de tarjetas?

Esta es una de las preguntas más recurrentes de un tiempo a esta parte en relación con el estándar PCI-DSS (ya sabéis, ese en el que se han puesto de acuerdo todas las marcas para volvernos locos a todos... es broma, para elevar el nivel de protección de los datos de tarjetas).

Para abordar la respuesta correctamente, hemos de matizar algunos puntos antes de entrar a responder abiertamente a la cuestión:

1. Como sabéis los que estáis familiarizados con este tema, el PCI Council se "limita" a velar por el estándar y a hacer que los que somos QSA / ASV hagamos bien nuestro trabajo (formación, registro, control de calidad...) pero corresponde a las marcas de tarjeta determinar el modelo de cumplimiento.
2. Las marcas que operan de manera indirecta (VISA y MASTERCARD, que son las que emiten y admiten tarjetas a través de entidades financieras, puesto que el resto de marcas tiene relación directa con poseedores de tarjeta y comercios que las aceptan) han decidido que, aunque todas las organizaciones tienen que cumplir con el estándar, las entidades que forman parte de ellas, no tienen porque demostrar el cumplimiento (es decir, tienen que cumplir pero no tienen que auditarse).
3. El estándar no distingue en ningún sitio entre operativa emisora y operativa adquirente (es decir, cuando pagamos en un comercio). Simplemente dice que todos aquellos sistemas que almacenen, procesen o transmitan datos de titulares de tarjeta  se considera que están dentro del alcance.
4. El estándar prohíbe de manera clara y expresa el almacenamiento de los datos de autenticación sensibles (CAV2/CVC2/CVV2/CID, PIN/PIN block o banda magnética completa) después de la autorización (incluso aunque se cifren) [ya sabéis que no se encriptan].

En mi opinión, es este último aspecto el que nos ha llevado a todos a tener dudas sobre la aplicación del estándar a la operativa emisora, puesto que la autorización es una etapa de la operativa merchant. Esto y el hecho de que en los cursos de preparación como QSA te explican detalladamente la operativa merchant y nada la operativa de emisión.

Pero, en cualquier caso, si leemos exactamente lo que nos dicen no encontramos ningún lugar en el que se nos diga si el estándar aplica o no a la operativa emisora, al contrario, dado que el emisor almacena datos de titulares de tarjeta debería de considerarse incluido en el alcance.

Esto nos deja otra disyuntiva: ¿Cómo voy a cumplir con el estándar si tengo que almacenar datos de autenticación sensibles que, en teoría, están prohibidos? Pues bien, para esto he encontrado la respuesta en la sección de preguntas frecuentes de la web del Council correspondiente al estándar PCI DSS (con ID #9575). En resumen, lo que el Council nos viene a decir es que se pueden almacenar esos datos en el caso de operativa emisora puesto que es imprescindible para el funcionamiento del negocio, pero que el resto de requerimientos del estándar siguen siendo de aplicación. Vamos que la operativa emisora NO está fuera del alcance...

Corolario: Si consideramos el supuesto de un proveedor de servicios, la única diferencia es que tendría que auditarse, puesto que que no es una entidad financiera y por tanto, debe demostrar el cumplimiento aunque podría almacenar los datos de autenticación puesto que la excepción, según el Council, aplica a aquellas entidades que realizan, facilitan o prestan soporte a los servicios de emisión.

Actualización: Presentación en prezi

Más información | PCI Council

En Carpe Diem | Etiqueta PCI-DSS

ISO 27001 vs Esquema Nacional de Seguridad

Me llegaba a través de ISO27000.es un artículo de Manuel Díaz en Estrategia Magazine en el que reflexiona sobre la posible evolución del estándar ISO hacia una norma de obligado cumplimiento.

Lo que me ha llamado la atención del artículo ha sido el hecho de descubrir que en algunos países de Latinoamericana (en concreto, Perú y Colombia), los Gobiernos han tomado la determinación de hacer que esta familia de estándares sea de obligado cumplimiento:

• Para la Administración Pública en el caso de Perú
• Para sectores concretos en Colombia

Y me ha llamado la atención por la diferencia de enfoque con lo que hemos hecho aquí. Me explico: Hace unas semanas veía la luz el Esquema Nacional de Seguridad como norma de seguridad a aplicar en la Administración Pública que, en lugar de centrarse en determinar cuales deberían ser las medidas a aplicar en los distintos sistemas utilizados por la Administración o, al menos, unos criterios objetivos para el análisis de riesgos, ha  creado  una especie de ISO paralela que deja a criterio del que lo aplica la determinación exacta de medidas a aplicar en función de un análisis de riesgos.

¿No habría sido más fácil remitir a la norma para la aplicación de un SGSI? ¿Por qué hemos empleado recursos en desarrollar algo que ya estaba desarrollado? ¿No habría sido más efectivo centrarnos en realizar análisis de riesgos "tipo" para los distintos sistemas y determinar las medidas de seguridad para cada uno de esos "tipos"?

Yo estuve en la RootedCON 2010

Después de 3 días inmerso en el Congreso [sin WiFi, "aquello era Vietnam"] y con un poco de tiempo para haber reposado la experiencia, quería transmitir mi más sincera enhorabuena a los organizadores de la RootedCON 2010. ¿Por qué? Muy sencillo:

• Por la idea: Un congreso como el que hemos vivido era necesario.
• Por la capacidad de convocatoria: No recuerdo otro congreso en el que haya asistido tanta gente con los medios tan justitos de promoción que existían.
• Por la cobertura lograda: Varias televisiones se han hecho eco en sus telediarios (¡prime time!)
• Por la selección de las ponencias: No se han limitado en las profundamente técnicas, sino que han abierto el abanico para cubrir la seguridad en general [en esta estoy especialmente agradecido porque ha significado que mi presencia tuviera lugar... ;-) ].
• Por la frescura: Han conseguido que no fuera un congreso "enlatado", han manejado los problemas con simpatía y sinceridad y dejando a un lado el excesivo formalismo de este tipo de eventos.

En definitiva, que aunque haya cosas que se puedan mejorar (quizás organización de ponencias por temáticas, proceso de registro - ahora ya saben todos los que somos, quizás la logística...) pueden estar orgullosos para ser el primer RootedCON. Ahora bien, han de saber que han puesto el listón muy alto para la #rooted2011...

¡Enhorabuena!

Actualización: Subida la presentación a slideshare...

Teoría de las Limitaciones aplicada a Seguridad de la Información

View more presentations from Antonio Ramos.

Aprender a hacer mejor preguntas

Para los que me sigáis un poco, sabéis que una de mis preocupaciones constantes es cómo ser un buen jefe. Por eso, quería compartir con vosotros el post de John Baldoni en el blog The Conversation - Harvard Business Review que lleva el mismo título que éste.

Según John, todos los líderes tienen algo en común: la necesidad de conectar honestamente con los demás. Y para ello, John propone realizar "buenas" preguntas, lo que se traduce en ciertas actitudes:

• Ser curioso
• Ser claros sobre la finalidad (cómo, por qué, cuándo)
• Demostrar compromiso
• Ser profundo

¿Qué opináis? ¿Os parece importante?

Vía | The Conversation - Harvard Business Review
En Carpe Diem | Estilos de dirección. ¿Cómo ser un buen jefe?, Sugerencias para ser un buen jefe

¿Deberían cobrar las operadoras a Google y similares?

Perdonar por este post un poco [bastante] offtopic y, si me apuras, hasta a destiempo...

Estaba yo pensando, ya sabéis, sobre las declaraciones de Alierta al respecto y he llegado a la conclusión de que sí....de que los operadores deberían cobrar a Google y compañía.

No, no, no alucinéis. Lo que me ha convencido ha sido el argumento de que, dado que Google hace negocio usando "sus" infraestructuras es lógico que las operadoras le cobren de alguna forma. Y os preguntaréis por qué. Pues muy sencillo, porque he seguido aplicando el razonamiento y he llegado a una conclusión que me ha gustado... la comparto con vosotros para escuchar vuestra opinión: Dado que la operadora hace negocio con los usuarios que visitan mi blog, me siguen en twitter o ven mis fotos en Picasa [no es mucho, ya sé, pero oye, algo es...] lo suyo es que las operadoras me paguen de alguna forma por el tráfico que les genero, ¿no?

¿Qué os parece el razonamiento? ¿Justo? ¿Falaz?

¿Dudas sobre seguridad? (o formspring.me)

Vi hace unos días una iniciativa interesante de Security by Default por la que se ofrecían para contestar a las preguntas que sus lectores les hicieran utilizando un "nuevo" servicio denominado formspring.me.

Básicamente este servicio permite a los usuarios que se dan de alta, recibir preguntas y contestarlas utilizando una sencilla interfaz...

Pues bien, como podéis ver por el gadget de la barra lateral, también yo me he apuntado a la iniciativa, así que no os cortéis, podéis hacerme todas las preguntas que deseéis [espero ser capaz de responderlas]: formspring.me/sorani.

Animaros...

La evolución de la seguridad de la información en el Sector Público

Acabo de leer en GCN un artículo que reflexiona sobre algunas de las conclusiones de una encuesta realizada por ISC(2) durante los pasados meses de diciembre y enero. Según esta encuesta, el Gobierno Federal de los EE.UU. puede ser un refugio para los profesionales de la seguridad de la información gracias al mantenimiento, o incluso crecimiento, de sus presupuestos destinados a la seguridad. En concreto:

• Un 44% han visto incrementados sus presupuestos respecto al 2008, frente al 40% que los han visto reducirse.
• Respecto a la evolución del presupuesto para 2010 se espera así: 52% - mantenimiento, 28% - reducción y 20% - incremento.
• En cuanto a las contrataciones (sobre un total de 175), un 58% espera contratar personal de seguridad, destacando el hecho de que un 14% (es decir, 25) esperan contratar 10 ó más personas.

Me ha parecido interesante comentarlo por varias cuestiones. En primer lugar, por la gran diferencia con la situación española donde la reducción es generalizada en todos los estamentos de la Administración Pública (nacional, regional y local). En segundo lugar, porque se comenta la evolución de los perfiles solicitados, dándose cada vez mayor importancia a la monitorización continua y la evaluación de riesgos frente a las certificaciones.

Y finalmente, y no por ello menos importante, porque esta situación me sugiere una reflexión como proveedor de servicios de seguridad:

• ¿Qué ocurre con el sector privado si el sector público sigue creciendo?
• ¿Quedarán las empresas sólo para dar servicio al sector privado?
• ¿Deben conformarse las empresas privadas con actuar como cantera del sector público? Si es así, ¿qué incentivos tendrían las empresas para formar a esos profesionales?
• ¿Os imagináis que incluso alguna de estas agencias públicas se dedicará a dar servicio al resto del sector público? [Que conste que no me considero un liberal radical que apueste por la reducción del sector público a su mínima expresión... nada más lejos de la realidad]

Se admiten comentarios...

Vía | Government Computer News

¿Acabará el Cloud Computing con la industria de seguridad?

Según Seth Godin, el Axioma Wordperfect establece que "Cuando la plataforma cambia, el líder cambia". Y la verdad es que hay unos cuantos ejemplos: plataformas de videojuegos, música, libros...

Recordando las previsiones de Gartner sobre el futuro de los departamentos de TI, ¿pensáis que el Cloud Computing acabará con los proveedores de servicios de seguridad? ¿Será el cloud computing la killer application de la industria de seguridad?

Se admiten comentarios, puntos de vista, opiniones...

Vía| Seth Godin

Ciberataques contra PYMEs

Uno de los retos principales con los que me he enfrentado en mi vida profesional ha sido el de intentar llevar servicios de seguridad "avanzados" (algo más que firewalls y antivirus) al mundo de las PYMEs. Y digo que ha sido uno de mis retos principales porque no he tenido demasiado suerte.

¿Los motivos? Normalmente porque los responsables / dueños de esas PYMEs hacen su análisis de riesgos [de cabeza] y te espetan: "Pero... ¿quién va a estar interesado en atacarnos a nosotros?". Vamos, que consideran que la probabilidad de que pase algo es tan baja que no le sale a cuenta la medida de seguridad que propones para el nivel de riesgo resultante.

Pues bien, parece que eso está cambiando y que va a haber que replantearse la posibilidad de que pequeñas empresas sean objetivo de ciberataques. ¿Por qué lo digo? Pues, por la noticia que leo en SANS de que PYMEs irlandesas han notificado recientemente que han sido objeto de ciber-extorsiones con un mecanismo muy sencillo y poco innovador: su datos habían sido cifrados por los secuestradores que les han pedido un "rescate" por la clave de cifrado... os suena, ¿verdad? Además, lo "hábil" de estos tipos es que previamente ya se habían encargado de inutilizar el sistema de copias de respaldo [y por supuesto, nadie se había dado cuenta, porque nadie lo estaba monitorizando, claro...].

Es cierto que el rescate no es muy alto, 700$, pero lo indudable es que cambia radicalmente el escenario... ¿cambiarán las PYMEs sus planteamientos para enfrentar este nuevo escenario?

Ya veremos... Ya os contaré.

Vía | SANS NewsBites

Más información | Silicon Republic y The Independent

Juego limpio

Aunque yo no voy a estar en la RSA Conference, me sumo al deseo de Will Gragido en Cassandra Security (al que llegué gracias a @lostinsecurity por cierto) pero no solo con carácter temporal, sino con carácter general:

1. Si no puedes decir algo agradable no digas nada en absoluto.
2. Incluso cuando sabes que sabes más o tienes más experiencia, no impidas que otros aprendan; es una falta de consideración
3. Haz más bien que daño

En definitiva, tratarnos con respecto nos ayudará a compartir nuestras ideas y nuestras experiencias de una forma más provechosa para todos...

Los secretos del desarrollo del liderazgo en las mejores compañías

Este es el título del artículo publicado por Norm Smallwood hace unos días en uno de los blogs de la Harvard Business Review. En dicho artículo se resumen los resultados del estudio que realizan cada 2 años, RBL Group y Hewitt sobre aquellas compañías que han demostrado ir más allá en el desarrollo de nuevos líderes como vía para garantizarse el futuro.

Lo que me ha llamado la atención del estudio es que, según los autores, hay 6 elementos que se repiten en esas compañías que mejor han desarrollado el liderazgo de sus empleados:

1. La gestión del talento se realiza de manera centralizada.
2. La involucración de la Alta Dirección.
3. La selección de los mejores talentos y el desarrollo del resto junto con la exposición de esas personas a experiencias que les permitan desarrollarse.
4. Hacer foco en el desarrollo del liderazgo como un elemento estratégico.
5. Construir líderes y desarrollar una cultura de integración y oportunidad.
6. Crear valor para los grupos de interés internos y externos.

Por mi propia experiencia, creo que resumen en muy pocos elementos los factores clave que marcan la capacidad de una organización de desarrollar verdaderos líderes que garanticen la continuidad de dicha organización en las mejores condiciones.

Además, estos elementos se convierten en esenciales cuando nos movemos en un entorno de pequeñas y medianas empresas (y sobre todo si son familiares).

Vía | Blog The Conversation - Harvard Business Review