Hola, hola, ¿se escucha bien por ahí?

Luego de un tiempo vuelvo a compartir un punto de vista, que ha surgido a partir de cubrir el primer día del  #6enise y de un comentario posterior de mi amigo Gastón Rivadero (@derlok_epsilon) que decía más o menos algo así: "¿No te queda la sensación de que todo termina en un grupo de gente que se junta a decir más o menos lo mismo, pero nadie lo hace?"

Creo que su lectura es acertada, y es que ¿no les parece que en definitiva terminamos todos los profesionales de seguridad diciendo lo mismo? voy a destacar algunos puntos para intentar mostrarlo:

|- El ser humano es el eslabón más débil

Nada más cierto, los ataques lo demuestran, desde campañas de phishing bien absurdas hasta la más compleja de las APTs, todo termina en un usuario que sin mucho cuidado hace click en algo que aprovecha una vulnerabilidad y listo, ya estamos adentro.

Hay que concientizar (o como diría un amigo, "acojonar"), esa generalmente es la conclusión, incluso requerido por más de una ley o regulación, pero entonces, ¿por qué no se hace?

|- No se parchea

Otra gran verdad, se suele ver aún en la más crítica de las infraestructuras ausencia de parches de seguridad, así como también en los puestos de los usuarios, esto último quizás potenciado por la falta de un catálogo de software aprobado, limitación de privilegios en los usuarios, etc, etc. ¿por qué no se hace?

|- El perímetro es el usuario (sus aplicaciones y dispositivos)

Coincidimos en esto hace un tiempo, pero fue necesario que el usuario lo demuestre llevando su dispositivo al trabajo, dando lugar a una sigla bien simpática "BYOD". Ahora que justo habíamos terminado de configurar el firewall e inventariar las desktops, se les ocurre comenzar a utilizar sus propios dispositivos :S

¿por qué vamos tan atrás?

|- Es necesario un inventario

Pues que cierto que es esto, necesitamos saber qué tenemos!!

¿Por qué salimos a implementar medidas sin contar con un inventario? ¿Por qué nos preocupamos por el ROI, si antes no conocemos los riesgos, a qué activos impactan y qué valor tienen?

Debemos relevar los activos, catalogarlos, y realizar análisis de riesgos, las regulaciones lo exigen, así como varios estándares de seguridad y ahora las estrategias nacionales de ciberseguridad. ¿por qué no se hace?

NOTA: es bueno saber que ahora las telcos saben que tienen redes industriales ;)

|- Hay que gestionar los incidentes de seguridad

Otra gran verdad, sin embargo en muy pocos lugares se nota alguna preocupación por la conformación de grupos de respuesta a incidentes. En verdad, en muchos lugares todavía están definiendo cuestiones más elementales. Ya habrá tiempo para este tema, o esperaremos que nos pase. Creo que la gente de Diginotar pensaba algo así. ¿por qué no se hace?

La lista de temas sigue, y seguro coincidimos en muchos, aunque en otros tengamos alguna diferencia. Ahora bien, creo que habría que comenzar a debatir el "¿por qué no se hace?", y digo esto luego de ponerle como título al post "Hola, hola, ¿se escucha bien por ahí?", ¿acaso es un problema auditivo? creo que en realidad todos los que estamos de acuerdo en estas premisas y tantas otras, deberíamos comenzar a replantearnos las estrategias de comunicación. 

Claramente el resultado demuestra que hemos fallado, y digo esto, sin obviar que en muchos lugares las decisiones están en manos de gente irresponsable (incluyendo a nuestros políticos), pero en muchos otros lugares, seguimos preocupados por convencer a Jefe de Sistemas, Desarrollo o a nuestro propio Jefe de Seguridad, cuando en realidad nuestro público debería estar a otro nivel. En definitiva, quizás deberíamos aprender a jugar al golf :)

Contribución gracias a Mariano M. del Río

Leer más...

5 errores más frecuentes en proyectos de seguridad de la información

En esta oportunidad quería compartir con ustedes distintas situaciones que se presentan con mucha frecuencia en proyectos de seguridad de la información y que sin ser el objetivo principal, desnudan la madurez en cuanto a los temas de seguridad de la información que tiene la Organización en la cual se está ejecutando el proyecto.

A lo largo de los 5 errores más frecuentes podremos encontrar problemas de base, que producto del avance de las distintas etapas se hacen cada vez más evidentes e incluso muchas veces son determinantes para el éxito o fracaso del proyecto en cuestión.

El orden de los errores es completamente arbitrario, no representa su importancia o impacto en la Organización.

Equivocar el interlocutor

En muchos casos el líder de proyecto corresponde a un área técnica y debe llevar adelante cuestiones que lo exceden en su posición y responsabilidad. Los requerimientos se traban, la información requerida se demora y ante la falta de apoyo finalmente alguien decide sobre los temas desconociendo la problemática.
Los recursos humanos no se asignan y si se hace, el proyecto se demora dado que hay que "poner en tema" al recurso asignado, que tampoco tiene la jerarquía necesaria para tomar decisiones.

Es un problema muy difícil de resolver si nuestro interlocutor no está en condiciones de obtener la información requerida, convocar a los referentes necesarios y/o tomar alguna decisión relevante en relación al proyecto. Pero si se presentara una situación similar podríamos estar ante una Organización no muy comprometida con los temas de seguridad de la información.

Creer que únicamente con productos se resuelven los problemas

Hay proyectos que se generan para desplegar un determinado producto, pero llegado el momento de la implementación comienzan a aparecer los problemas. O el producto no hace todo lo que queríamos, o requiere información que aún no hemos podido recolectar, o depende de procesos que la Organización aún no tiene implementados o con el nivel de madurez necesario.

Es muy frecuente escuchar acerca de proyectos de Data Loss Prevention (DLP) en Organizaciones que aún no tienen un inventario unificado de activos ni han clasificado su información. Finalmente para "justificar" el proyecto, la herramienta se implementa con funcionalidades mínimas para luego volver a generar algún proyecto que regularice la situación (que muchas veces no lo hace).
En organizaciones en las cuales se presente esta situación seguramente TI es la encargada de la mayoría de los temas referentes a seguridad de la información y las demás áreas no tienen ningún involucramiento al respecto. Si algo sucede en materia de seguridad "es culpa de TI".

Hacer las cosas para cumplir

Lamentablemente en reiteradas ocasiones se escucha que un determinado proyecto "se hace por PCI" o "porque me lo pide auditoria", cuando en realidad quizás no es necesario o surgió de una reunión entre gente que desconoce los problemas y el auditor confundiendo su rol hace consultoría. El resultado es conocido, surge un proyecto de remediación de un problema que quizás no existe.

Más allá de que sería ideal que los proyectos surjan de necesidades reales de la Organización, que correspondan con un objetivo claro y medible, es poco frecuente encontrarse con tal escenario. A veces se hacen para cumplir o para que los responsables de un determinado problema no asuman la responsabilidad de la falta de gestión.

En organizaciones donde se presenta el escenario comentado, es muy común encontrarse con líderes de proyecto que pretenden que el consultor tome decisiones que le corresponden a otros miembros de la Organización, que clasifique, analice, y termine decidiendo sobre temas que claramente lo exceden. Los tiempos se exceden, el proyecto cambia de alcance, queda empantanado en busca del verdadero problema o de alguien capaz de sacarlo adelante.

No acompañar al negocio

Si bien parece muy claro que TI debe brindar un servicio al negocio y acompañarlo para lograr el cumplimiento de los objetivos, es frecuente encontrarse con proyectos que no tienen ninguna relación con el rumbo que tiene el negocio. Negocios que están pensando en ir hacia la nube, en donde TI ejecuta proyectos de centralización de aplicaciones cliente/servidor o restricciones para el trabajo remoto, ambas cuestiones que muestran un camino completamente distinto entre el negocio y TI. Negocios que se despliegan sobre plataformas sociales y canales de comunicación 1 a 1 con el cliente, frente a proyectos que buscan restringir el uso de redes sociales. El resultado es conocido, siempre (o casi siempre) gana el negocio y aquello que se implementó para restringir pasa a "escuchar" sin ningún otro objetivo más que nutrir a una consola de un montón de información que nadie analizará.

No deja de ser un signo de problemas aún mayores dado que generalmente en ese tipo de organizaciones TI se considera dueña de los servidores y es frecuente que sea el usuario quien notifica los problemas dado que la "independencia" de gestión es absoluta.

Creer que los consultores conocen más la Organización que uno mismo

Si el consultor toma decisiones que debe tomar la Organización el proyecto presenta síntomas de fracaso. El valor agregado del consultor viene relacionado con la experiencia en otros proyectos, su formación, el hecho de mantenerse actualizado y de la dedicación a los temas relacionados con seguridad de la información. Ahora bien, eso no lo convierte en la persona adecuada para tomar decisiones que le corresponden a los miembros de la Organización, dado que ellos conocen el valor de la información involucrada, los objetivos de negocio de corto y mediano plazo, la historia asociada al proyecto, las idas y vueltas políticas, los intereses internos y todo aquello que es tan importante al momento de tomar decisiones.

En organizaciones en las cuales se lo espera al consultor como el gran salvador generalmente presentan más de uno de los errores que comentamos en este post y es muy probable que el resultado final de los proyectos sea un producto que nadie utilice o un proceso que luego de unos meses nadie recuerde.

Superman hay uno solo


En muchas oportunidades hemos comentado la importancia del involucramiento de los máximos referentes de la Organización en temas relacionados con seguridad de la información. Es una responsabilidad de la Dirección el estado de seguridad de su negocio, definir el nivel de protección adecuado para sus activos y asignar los recursos necesarios para lograrlo. Si esto no se presenta, es muy probable que alguien asuma una responsabilidad que lo excede y por consiguiente el propio desconocimiento del negocio haga que la estrategia de seguridad sea errónea.
El desafío para quienes deben gestionar la seguridad de la información es lograr el interés e involucramiento de los líderes, es allí en donde se debe invertir el mayor esfuerzo, para luego no dedicarle tanto tiempo y esfuerzo a reparar los errores producto de decisiones equivocadas, mal uso de los recursos y medidas desacertadas.


Los invito a realizar el ejercicio mental de pensar si estamos tomando las decisiones que están bajo nuestra responsabilidad o estamos asumiendo compromisos que realmente nos exceden.


¿Seguiremos tratando de convencer al DBA o al Desarrollador en vez de lograr el interés de la Dirección?

--------------------------------------------------------

Contribución por Maríano M. del Río

Leer más...

¿Por qué son noticia los incidentes de seguridad?

Comenzó el 2012 y en poco tiempo algunos incidentes de seguridad ya pusieron a la seguridad de la información e internet en la portada de muchos diarios y medios especializados. A lo que se sumó el cierre de Megaupload y las discusiones en torno a los derechos de autor, la privacidad y la libertad...todo eso en menos de 2 meses. El robo de código fuente de Symantec hace 6 años (si, hace 6 años) y los hackeos a Verisign durante 2010 (si, durante 2010) y en la última semana la llamada entre el FBI y Scotland Yard que pudo "interceptar" Anonymous...todo esto parece una película de ciencia ficción, pero es la realidad y así comenzó el año.

Este post no intenta profundizar en cada uno de los casos mencionados, dado que hay mucha información al respecto, sino abrir el debate en relación a ¿por qué son noticia los incidentes de seguridad?

Al leer sobre cada caso y comenzar a conocer la información que, a cuenta gotas se deja conocer, generalmente no nos encontramos con el "ataque sin precedentes" como el año pasado se encargó de comunicar Sony relacionado con los incidentes recurrentes de la PlayStation Network, de todas formas en este caso se presentó algo que se está convirtiendo en una costumbre en las organizaciones "víctimas" de los ataques y tiene que ver con la falta de comunicación acerca del impacto del incidente, sobre todo si están involucrados datos de los clientes (algo que comentamos en un post anterior).

De todas maneras, resulta interesante que en la mayoría de los casos se hayan aprovechado de la ausencia de controles básicos relacionados con la seguridad de la información: debilidades asociadas con la gestión de parches, ausencia de una correcta separación de ambientes, falta de aplicación del principio de mínimos privilegios, segmentación de redes, ausencia de hardening en los dispositivos, codificación insegura de aplicaciones, falta de controles de seguridad relacionados con los recursos humanos, falta de protección contra código malicioso (si, falta de antivirus), ausencia de logs de auditoria, utilización de cuentas genéricas y un extenso etcétera. Realmente con este panorama, ¿quién necesita el ataque sin precedentes? Quizás los únicos que lo necesitan son los que no están haciendo su trabajo en materia de seguridad de la información :)

Si algo podía empeorar la situación es que se está convirtiendo en una mala costumbre ocultar los incidentes, pero ahora no sólo a los clientes (algo de por sí grave), sino que se está conociendo que en algunos casos el incidente se oculta puertas adentro de la Organización y es el Directorio quien desconoce la situación. 

¿Imaginan a los Directivos de una Organización ajenos de tal situación? 

¿Si el incidente se le oculta al Directorio, puede el usuario final tener la esperanza de ser notificado?

Pues es lo que está sucediendo, la negligencia se está superando día a día y ahora no solo se le ocultan los incidentes a los clientes, sino que también se le ocultan a los Directivos.

Sin embargo si intentamos tener una visión positiva de la realidad, no es que está todo perdido, sino todo lo contrario. Es lógico que sean vulneradas las empresas dado que no consideran relevante a la seguridad de la información, es lo más lógico que está sucediendo. No es lógico que se oculten los incidentes, pero sí lo es que se presenten, dado que se están haciendo las cosas muy mal. Esto último es lo más esperanzador, porque quizás recién ahora  dejemos de escuchar, "nosotros no somos un banco" o "pero si venimos trabajando así y nunca nos pasó nada", quizás a partir de este momento se comience a gestionar verdaderamente la seguridad de la información. Lo que no debería suceder es que los negligentes de siempre encuentren excusas en los incidentes comentados para seguir leyendo el diario, pero sabemos que podríamos encontrar personajes como esos :(

De todas formas estamos ante una oportunidad de que nos escuche quién debe escucharnos, hace un tiempo lo comentaba en un antiguo post referido a quién le debería importar la seguridad de la información? Sin dudas a los Directivos de las organizaciones, son ellos los máximos responsables, y aunque se les oculte la información, no dejan de ser responsables de lo que sucede. Son los responsables de contratar gente competente y responsable, de mantenerlos capacitados y otorgarles los recursos requeridos para realizar su trabajo. Si esto no se presenta es muy probable que sigamos escuchando a diario acerca de las distintas fugas de información, ataques y demás variantes.

Por otro lado, los usuarios deberían comenzar a requerir seguridad al mismo nivel o aún superior que alguna otra característica al contratar un servicio o comprar un producto. Es lamentable ver como se entregan datos personales, gustos y hábitos por algunos GB de disco en la nube o una cuenta premium en algún servicio 2.0. Quizás recién una vez que los usuarios elijan un servicio seguro por sobre uno inseguro los Directivos comiencen a darle importancia a la seguridad y todo comience a girar...hasta tanto no se de...sólo nos queda escuchar como noticia los incidentes de seguridad.

--------------------------

Artículo cortesía de Mariano M. del Río @mmdelrio

Leer más...

De Don Quijote a Oficial de Seguridad

Este post surge a raíz del testimonio más frecuente de aquellos que tienen a cargo áreas de seguridad, donde el común denominador es la decepción por no lograr el nivel de seguridad que ellos consideran que deben tener sus Organizaciones.

Del párrafo anterior surgen algunos aspectos importantes, uno relacionado con el "nivel de seguridad que ellos esperan" y lo otro referido a "sus Organizaciones".

Es muy común que quien se desempeña en un área de seguridad, o mejor dicho en temas de seguridad, aunque no tenga un área (que no es un tema menor), suela decepcionarse ante algunas cuestiones que se presentan en la Organización, donde pueden llegar incluso hasta enfrentarse con los usuarios y ponerse en el rol de "autorizo o no autorizo" lo que podría confundirlos en una lectura rápida con un Dueño de Datos :P

Podría ser un factor común en estas personas el hecho de llevar adelante iniciativas de seguridad no porque sean requeridas desde los negocios o en el mejor de los casos desde la Alta Dirección, sino porque o el departamento de sistemas decide encarar un determinado tema, o ellos desde el área de seguridad consideran que la seguridad en la Organización debería ser otra.

Si uno busca casos exitosos de gobierno de la seguridad es muy probable que los encuentre en aquellas organizaciones que consideran a la seguridad un aspecto fundamental y por tal motivo la Alta Dirección se encuentra involucrada. También es probable que en estas empresas nos encontremos con un Oficial de Seguridad, mientras que en las otras nos encontremos con "Don Quijote" luchando contra los molinos de viento.

Y aquí es donde queríamos llegar, aquellos "Don Quijote" que niegan accesos, bajan servicios, desinstalan programas, en definitiva cubren una serie de roles, menos el del Oficial de Seguridad. Ahora bien, ¿qué debería hacer un Oficial de Seguridad? en principio podríamos decir que su función principal es acompañar al negocio identificando los riesgos asociados a la actividad que se lleve a cabo, ofreciendo recomendaciones para el tratamiento oportuno de los mismos y en todo caso realizando el advisor necesario para que aquel que tome las decisiones cuente con toda la información requerida. Como se puede identificar, el rol es principalmente de asesor, de acompañamiento al negocio.

Teniendo en cuenta esto último, podríamos decir que entonces las distintas medidas de seguridad que se implementen, de acuerdo al tratamiento oportuno de los riesgos, no las estaría determinando el Oficial de Seguridad, sino el Dueño de los Datos involucrados. Lo que si estaría haciendo el Oficial de Seguridad es describir las alternativas que se podrían implementar con el objetivo de dar el tratamiento requerido por el Dueño de Datos. Nuevamente en un rol de asesoramiento a quien toma las decisiones. Finalmente producto de las decisiones de quien está a cargo de la gestión del riesgo, se realizarán las acciones que se consideren oportunas. Si en todo caso, la decisión ha sido asumir el riesgo identificado, es el Oficial de Seguridad quien deberá documentar la situación obteniendo la conformidad del Dueño de Datos, pero no para librar una batalla y convencerlo de que podría estar equivocado, sino para documentar el caso y continuar con sus otras actividades.

Si retornamos al escenario inicial donde la persona de seguridad estaba luchando contra la Organización, en este caso el Oficial de Seguridad ha documentado una decisión de negocio y continuará con sus actividades, dado que ha cumplido su rol de asesor para la toma de decisiones. En todo caso si la decisión por parte del Dueño de Datos ha sido errónea, la Organización pagará por tal equivocación y el Oficial de Seguridad deberá demostrar su "Debida Diligencia" habiendo realizado el "advisor" a quien ha tomado las decisiones, incluso evidenciando su disconformidad con las mismas.

Obviamente la Organización debería tener un grado de madurez en el cual se interpreten los distintos roles y las limitaciones de cada uno, dado que en otro escenario se intentaría culpar al Oficial de Seguridad por la equivocación del Dueño de Datos. Este tipo de organizaciones podría corresponder con aquellas donde el interés por la seguridad no cuenta con el apoyo de la Alta Dirección, sino que las iniciativas son generadas desde distintas áreas de staff.

Es aquí donde se podría identificar quizás el desafío más importante para un Oficial de Seguridad, y no es el hecho de capacitar a los usuarios, lograr que los desarrolladores contemplen cuestiones de seguridad, o que las áreas de IT documenten su trabajo. El desafío principal que podría enfrentar un Oficial de Seguridad es despertar el interés y compromiso por la Seguridad de la Información en la Alta Dirección o el Management de la Organización. Logrando esto último, todo lo anterior se podría realizar sin mayor conflicto, simplemente porque lo exige la Dirección.

Para lograr el establecimiento del escenario descripto, se deben conjugar una serie de cuestiones, tanto de las características personales y las competencias de quienes ocupen los distintos roles, como también de aquellas cuestiones culturales propias de la Organización.

Finalmente cabe destacar que los distintos roles descritos corresponden a lo establecido por las buenas prácticas y lo que se recomienda para el establecimiento del Gobierno de la Seguridad de la Información, donde dicho Gobierno claramente no depende de una persona o de un rol, sino de las distintas decisiones que tome el negocio, con el acompañamiento de los especialistas, pero limitando claramente la responsabilidad por el resultado final que determinará el grado de exposición de la Organización.

-------------------------

Contribución por Mariano M. del Río

Leer más...

Deficiencias más comunes en los SGSI basados en ISO27001

En este artículo se comparte con los lectores algunas de las deficiencias más frecuentes que se encuentran al momento de llevar a cabo revisiones del estilo “Análisis de brechas sobre ISO/IEC 27001:2005”.

Como sabrán el estándar ISO/IEC 27001:2005 es el marco de referencia asociado a la implementación de sistemas de gestión de la seguridad de la información. Además, es el documento más recomendado al momento de llevar a cabo proyectos de seguridad para el cumplimiento de las principales leyes y regulaciones en materia de seguridad de la información.

Las Organizaciones al momento de encarar proyectos asociados a la implementación de un SGSI, en primer lugar suelen requerir un “Análisis de Brecha” para conocer “Cómo están” y así poder identificar el esfuerzo, tiempo y recursos que deberán invertir para lograr su implementación y posterior certificación (si es requerido). Es en esta etapa en la cual se identifican las principales debilidades que se detallan a continuación y que resumen la postura de seguridad de una importante cantidad de empresas:

1. Falta de Compromiso de la Alta Dirección
2. Ausencia de una adecuada Gestión de Riesgos.
3. Debilidades en la Gestión de Activos.
4. Falta de Recursos
5. Ausencia de Documentación
6. Ausencia de Roles y Responsabilidades
7. Resistencia al Cambio

La numeración establecida no significa el orden de importancia de los distintos tópicos, dado que todos en mayor o menor medida impactan negativamente en la implantación de un Sistema de Gestión de la Seguridad de la Información.

Principales Deficiencias

Falta de Compromiso de la Alta Dirección (Req. 5)

El estándar ISO/IEC 27001:2005 es un documento que principalmente establece la necesidad de compromiso por parte de la Alta Dirección para la adecuada definición de Alcance, Limitaciones, definición de los Roles y Responsabilidades en materia de seguridad y la Asignación de los Recursos requeridos. La formación, toma de conciencia y competencia del personal son otras responsabilidades de la Alta Dirección, junto con la participación en la revisión de la eficacia y eficiencia del Sistema de Gestión implantado. Todos estos aspectos en muchos casos, son difíciles de encontrar en las empresas. ¿Será éste el principal problema?

“Cuando el proyecto lo impulsa únicamente TI o Seguridad, podríamos estar ante una Organización donde es muy probable que la Alta Dirección no esté comprometida”

Ausencia de una adecuada Gestión de Riesgos (Req. 4.2.1)

Otro tema fundamental al momento de implementar un Sistema de Gestión de la Seguridad es conocer los riesgos a los cuales se encuentra expuesta la Organización, y a través del análisis de los mismos establecer el tratamiento que se considere el más adecuado. Si bien es uno de los requisitos del estándar, es poco frecuente encontrar que hayan realizado alguna vez un análisis de riesgos. En algunos se encuentra por el tipo de actividad de la Organización, pero en muchos otros casos no se realiza. También se pueden encontrar casos en donde la Organización describe un “análisis de riesgos” y en realidad sólo han evaluado subjetivamente algunas pocas amenazas sobre los activos que más conocen, sin tener una idea clara de su valor y por otro lado sin conformar la totalidad de los activos de la Organización o al menos del proceso evaluado.

“Saber qué nos podría pasar y el impacto que nos generaría es un elemento clave al momento de definir la estrategia de seguridad”

Debilidades en la Gestión de Activos (A. 7.1.1)

Un aspecto que resulta clave al momento de implantar un SGSI es el referido a los Activos de Información y el tratamiento que la Organización le da a los mismos. En principio el factor principal es contar con los activos de información más relevantes (o al menos los incluidos en el proceso que queramos analizar), algo que no es fácil de lograr y que en pocas ocasiones se encuentra. En algunos casos no existe tal inventario o es el resultado de varios inventarios, cada uno con distinto nivel de falta de información y actualización. En este sentido es importante contar con un único inventario, completo y actualizado. Algunos de los controles que se deberían realizar sobre la gestión tienen que ver con: A.7.1.2 Propiedad de los Activos, A.7.1.3 Uso Aceptable de los Activos.

“Saber qué tenemos, para conocer qué nos podría pasar y en base al impacto que esto podría ocasionar, tomar las acciones que sean adecuadas”.

Falta de Recursos (Req. 5.2.1)

La provisión de recursos, aspecto fundamental para cualquier iniciativa que se quiera llevar adelante, pero en temas asociados con un SGSI resulta fundamental, y es tan importante que el estándar lo describe directamente en el punto asociado a las “Responsabilidades de la Dirección”. Esto es claramente así, si no contamos con los recursos necesarios, resultará muy difícil implantar el SGSI y luego llevar a cabo las actividades asociadas al mantenimiento y mejora del mismo. Es la Dirección la encargada de brindar los recursos necesarios. Para lograr el interés de la Dirección las áreas involucradas en los proyectos de SGSI recurren a distintos métodos, entre los que se pueden encontrar: charlas, talleres, relevamientos de seguridad, auditorias, etc. En muchos casos el interés (y los recursos) surge una vez que la Organización debe cumplir una determinada ley o regulación, como puede ser Sarbanes Oxley (SOX), PCI-DSS o lo referido con el cuidado de los Datos de Carácter Personal (Ley 25326 en Argentina o LOPD en España).

“En Organizaciones donde la Dirección no está comprometida con la Seguridad de la Información, es frecuente encontrar muchas dificultades para la obtención de los recursos necesarios para el SGSI”.

Ausencia de Documentación (Req 4.3.1)

Si bien el estándar específica un apartado exclusivo orientado a los requisitos de documentación es poco frecuente encontrar que la Organización haya documentado en principio lo mínimo requerido por el estándar y además lo requerido para el correcto desarrollo de las actividades de negocio. En este sentido, en las Organizaciones que se encuentra mayor documentación es en aquellas que han tenido experiencias asociadas a la implementación de otros Sistemas de Gestión, como pueden ser de la Calidad o de cuidado del Medio Ambiente o también en aquellas que deben cumplir alguna regulación que exige la existencia de procedimientos operativos documentados (en un todo de acuerdo con lo requerido también en ISO/IEC 27001), por ej: PCI-DSS.

Generalmente, la documentación se asocia con cuestiones burocráticas o de “pérdida de tiempo” y no con un estado de madurez superior al promedio, en el cual la Cía ha logrado identificar sus procesos y ha documentado las actividades principales de forma tal de lograr un mismo resultado sin que sea excluyente, en principio, el recurso humano que ejecuta la actividad. Es indiscutible que el orden y la visión en procesos en cualquier actividad, facilita la ejecución de controles que establecen un escenario con menor probabilidades de incidentes, errores y/o fallas. Pero a pesar de esto suele ser poco frecuente encontrarse con documentación asociada a cuestiones de seguridad en las Organizaciones.

“La documentación de actividades o procesos clave genera la independencia requerida para no depender de quién realiza la actividad y a su vez es una herramienta que facilita la mejora”

Ausencia de Roles y Responsabilidades (Req 5.2.2)

Las personas que integran una Organización deben tener claro qué deben hacer para ayudar al logro de los objetivos de negocio establecidos. Esto parece ser algo muy fácil de lograr e identificar, pero en temas asociados a seguridad de la información es un aspecto difícil de encontrar con el mismo nivel de madurez que en otras posiciones. Muchas personas que trabajan en áreas de seguridad o sistemas no tienen claro que deben hacer para ayudar al logro de los objetivos de la Organización. Esto es una responsabilidad de la Dirección y el estándar lo identifica claramente en el requisito 5.2.2. Recursos Humanos es el área responsable de definir las descripciones de puesto en conjunto con los referentes de área que correspondan, pero es esta área la que debe documentar el puesto y describir claramente las responsabilidades en materia de seguridad tanto de este puesto como de cualquier otro puesto en la Organización. Esto último no se encuentra con frecuencia en las Organizaciones, sino que las personas entienden que la seguridad depende de un área específica o “de sistemas”, y no es frecuente que se identifique como una responsabilidad de todos los miembros de la Organización. En los casos en los cuales se encuentra un nivel de madurez superior es en aquellas industrias con fuerte regulación al respecto, como puede ser la industria financiera.

“Las personas tienen que saber claramente cuáles son sus responsabilidades para el logro de los objetivos en materia de seguridad de la información”.

Resistencia al Cambio

Las personas se resisten a los cambios, esto no es una novedad, y obviamente no está fuera de las dificultades que vamos a enfrentar al momento de implantar un Sistema de Gestión de la Seguridad de la Información. Para ello debemos identificar los agentes del cambio que servirán de facilitadores para convertir la Política de Seguridad definida en algo tangible y objetivos cumplibles y evidenciables. Frases como “esto se viene haciendo así”, “no somos un banco”, “ya sabíamos esto” y un centenar de frases más, no son más que ejemplos de resistencia al cambio. Es importante tener en cuenta que la resistencia al cambio se debe reducir desde la Dirección de la Organización, es más, podríamos definirla en este artículo como una nueva "responsabilidad de la dirección", dado que es ésta la que tiene que marcar el camino, brindar los recursos y apoyar cada una de las iniciativas que permitan establecer el programa de seguridad que permita llevar a la realidad la Política de Seguridad de la Información.

-----------------------

Contribución por Mariano M. del Río

Leer más...

Qué no hacer al gestionar incidentes de seguridad

En los últimos tiempos se han presentado distintos incidentes de seguridad que han puesto al mundo en alerta, a las compañías involucradas en la mira y a los datos personales y la privacidad en jaque. Gigantes de la Tecnología y el Entretenimiento se han visto afectados, datos personales robados, tus gustos, intereses y hábitos al descubierto.

El objetivo de presente artículo es analizar distintas acciones que se han llevado a cabo en alguno de los incidentes de las empresas descritas, para identificar en base a estas experiencias, ¿qué cosas no debemos hacer si tenemos que gestionar un incidente de seguridad en nuestra Organización?

1) Ocultar el incidente a los clientes

La primera medida que generalmente se encuentra asociada a un incidente de seguridad es el ocultamiento. Nada peor que esta acción si queremos demostrar que hemos sido diligentes con nuestros datos y con los datos de nuestros clientes. Debemos tener presente que los datos personales son de las personas, no son nuestros y que están a nuestro resguardo.

En algunos casos la situación podría tomar una gravedad extrema en la cual el nivel de exposición deje muy claro que no se estaban cumpliendo regulaciones o cuestiones legales, por ejemplo PCIDSS si dentro de la brecha están incluidos datos de medios de pago que se encontraban en plano.

2) Aumentar las cualidades del atacante

Otra situación que se está presentando frecuentemente es buscar de todas maneras omitir los errores que se hayan cometido por falta de diligencia, conocimiento o cualquier otro motivo. Cuando esto sucede lo primero que se busca es centrar la atención en las hipotéticas características que poseía el atacante, siempre haciéndolo mucho más sofisticado de lo que realmente ha sido. Es decir, aumentar el skill del atacante para minimizar nuestros errores. “Hemos sido víctimas de un ataque jamás visto”, “El atacante poseía conocimientos muy sofisticados”, “Fue Anonymous” etc, etc.

3) Describir medidas de seguridad básicas como "sofisticados" planes de mejora a raíz del incidente

Se presenta frecuentemente el hecho de nombrar como planes de acción asociados al incidente la implementación de medidas de seguridad que ya deberían haber implementado con anterioridad, y que son realmente básicas, por ejemplo: “Implementaremos un sistema de gestión de la seguridad basado en ISO/IEC 27001”, “Utilizaremos técnicas de encripción para los datos de carácter personal”, “Entrenaremos a todo nuestro personal para brindar respuesta a incidentes”. Respuestas de este estilo se pueden encontrar en los comunicados que publican las empresas afectadas, lo que no hace más que evidenciar las debilidades de seguridad y negligencia de quienes debían tomar otras acciones y en otros momentos. Está claro que cualquier Organización que deba cumplir leyes o regulaciones como PCIDSS, SOX, u otra similar, ya debía contar con este tipo de medidas de seguridad.

4) No aceptar las equivocaciones

Algo que parece tan simple no se da frecuentemente, lo que el cliente espera más allá de excusas, ocultamiento, mentiras e hipótesis falsas, es que la organización que tuvo el incidente, lo comunique a tiempo, en forma sincera y aceptando los errores que pudiera haber cometido. Es así, “No supimos cuidar sus datos, hemos cometido errores, les pedimos perdón y tenemos todos nuestros recursos a su disposición para cubrir el error y mantenerlo como cliente”. ¿Cuántas empresas están dispuestas a comunicar esto a sus clientes?

5) Ofrecer compensaciones que no están a la altura del incidente

A todo lo que venimos comentando habría que agregar que en varios casos se han presentado planes de compensación para los clientes que realmente parecen una burla, “Welcome Again” “Free Content for Ever”, “Membership Gold”, etc. Al momento de establecer dichos planes se debe priorizar al cliente, no se debe seguir especulando sabiendo que no hicimos lo que debíamos y sumado a esto ofrecer lo que más cómodo nos queda para “mostrar” que estamos preocupados. Debemos estar preocupados y debemos ofrecer un plan de compensación que realmente esté a la altura del impacto provocado.

6) Seguir pensando que la Gestión de Incidentes es un tema menor o que corresponde sólo a IT

Las Organizaciones que mantienen esta postura son aquellas en las cuáles los Directivos aún no han interpretado que la Seguridad de la Información es una prioridad y les compete a ellos por la función que ocupan, gestionar el riesgo y conocer en todo momento la postura de seguridad de su Organización, en definitiva de su negocio.

De este tipo de Organizaciones podríamos recibir “acciones de mejora” tales como “Hemos nombrado un nuevo CSO (Chief Security Officer) que reportará al CIO (Chief Information Officer)”. Lo que demuestra errores conceptuales profundos y que afectan los principios básicos de la seguridad y el control interno.

¿Alguien puede seguir pensando luego de la brecha de la PlayStation Network que la gestión de incidentes es un tema netamente técnico y de IT?

¿Y las tarjetas de pago?

Otra cuestión que también llama la atención es que las Compañías involucradas en forma indirecta, como por ejemplo V1S4, M4st3rC4rd, 4m3r1c4n 3xpr3ss, etc. no emitan ninguna comunicación al respecto.

¿Acaso PCIDSS no surgió debido a las distintas brechas de seguridad que han involucrado datos de tarjetas de pago?

¿Acaso cumplir PCIDSS no hubiera minimizado el impacto de la brecha en el caso de 50NY?

¿Cómo se deberían tomar los incidentes?

A día de hoy, los incidentes se deberían tomar como algo que en algún momento va a suceder, no sigue siendo válido pensar que lo que hacemos o lo que haremos es para no tener incidentes, eso es imposible. Se presentarán incidentes y lo que debemos hacer es establecer los mecanismos, procesos y medidas de seguridad para dar respuesta en forma oportuna y diligente. Esa respuesta a incidentes no la dará únicamente ITOrganización. Así como se aprende de un error o equivocación en la vida cotidiana (o al menos deberíamos), en el caso de los incidentes es fundamental aprender y mejorar.

"Un incidente no se puede presentar 2 veces, sin haber hecho algo al respecto”.

La implementación de un sistema de gestión de la seguridad basado en los riesgos a los que está expuesta la Organización, contemplando en todo momento los requerimientos legales y regulatorios, podría ser el camino a seguir para iniciar la gestión continua y diligente que como Organización debemos brindar a la información propia al igual que la de los clientes.

"La Gestión de la Seguridad no es de única vez o porque debo cumplir, es un proceso contínuo”.

Referencias (no es necesario reinventar la rueda):

• NIST: SP800-100 Information Security Handbook - A Guide For Managers
• ENISA: Good Practice Guide for Incident Management
• NIST: SP800-61 Computer Security Incident Handling Guide: 
• CERT: Handbook for Computer Security Incident Response Teams (CSIRTs)
• Information Security Cheat Sheet
• PrivacyRights: Algunas de las brechas de los últimos años

--------------------------

Contribución gracias a Mariano del Río

Leer más...

Fundamentos para la Protección de Servicios Esenciales

Hace tiempo se viene comentando la importancia y necesidad de proteger aquellas infraestructuras que dan soporte o están involucradas en la prestación de servicios esenciales para la población y las naciones, como pueden ser la electricidad, el agua, el transporte, entre otros. Cuando se comentan las cuestiones que deben tenerse en cuenta para implementar seguridad, se cuenta la necesidad de conocer qué tenemos, donde está y qué valor tiene, a partir de esto y del análisis correspondiente se identifican aquellas infraestructuras críticas para esos servicios esenciales y se avanza en uno o más planes de seguridad.

En dichos planes se determinan lineamientos básicos de seguridad, como por ejemplo qué servicios deben estar activos, la definición de roles para el control de accesos, los lineamientos de auditoria, la responsabilidad sobre el activo, entre otros.

¿No resultan conocidas todas estas iniciativas?, es más, ¿no son las mismas que se llevan a cabo a nivel corporativo proteger la información?

A continuación se detallan algunos puntos claves al momento de implementar seguridad en servicios esenciales:

• Saber qué tenemos: activos involucrados en el servicio a proteger, su identificación, ubicación, clasificación, configuración, persona responsable, y toda aquella información que aporte valor para el análisis de riesgos posterior.
  
  
• De qué lo debemos proteger (y que debemos cumplir): A través del análisis de riesgo se debe identificar el grado de exposición de cada uno de los activos, conformando de esta manera el grado de exposición ante amenazas del servicio en sí. Se deben identificar adicionalmente, el grado de alineamiento con aquellas regulaciones que deba cumplir, o en su defecto, qué aspectos se deberían remediar.
  
  
  
• Cómo lo debemos proteger: Una vez que hemos definido el grado de exposición de cada activo, se deben definir los planes de acción asociados con la gestión del riesgo que se haya llevado a cabo. Para aquellos riesgos que se deban minimizar se deberán tomar medidas en tal sentido, y así con las distintas decisiones que el "Responsable del Activo o del Servicio" haya determinado. Esto podría significar, establecer medidas técnicas, implantar determinados procesos de seguridad, contratar un seguro, etc.
  
  
  
• Medir para poder mejorar: Para gestionar y tomar decisiones se debe obtener información que así lo permita, una fuente de información por excelencia son las métricas, que debería/n tener el/los procesos que se haya/n implementado. En este sentido, a través de la implantación de estas mediciones se podrá evaluar la efectividad de los controles y realizar las acciones que sean necesarias con el fin de mantener el riesgo en el nivel aceptado, garantizando la gestión de seguridad a través de la mejora contínua.
  
  
  
• Educación: Si en el ámbito corporativo es claro que se debe educar y entrenar a los usuarios en materia de seguridad, buen uso de activos y respuesta ante incidentes, es indiscutible que dichas acciones deban realizar sistemáticamente para toda la población al hablar de servicios esenciales. La definición de programas integrales de educación en los cuáles intervenga el ámbito público y privado son la herramienta principal para el logro de los objetivos. La seguridad de los servicios esenciales garantiza el bienestar de toda la población y el funcionamiento de las Naciones. El compromiso de los ciudadanos es un aspecto clave a lograr.
  
  
  

Ahora bien, los puntos antes mencionados son necesarios al momento de implantar un sistema de gestión de seguridad, pero al hablar de servicios esenciales surgen otros aspectos que a continuación podríamos enumerar:

• Propiedad de los Servicios Esenciales: En este sentido, en muchos países los servicios esenciales son prestados por entidades privadas, que son las que operan las infraestructuras y servicios. Sobre estos recae la responsabilidad de la implantación de las medidas de seguridad que sean oportunas. En tal sentido, el desafío se presenta al momento de tener que garantizar desde el que opera hacia el que controla, la implantación de dichas medidas. Por otro lado, el dilema de la propiedad de los activos debería definirse a nivel contractual dado que podrían presentarse situaciones en las que los intereses de ambas partes no sean coincidentes y la propiedad sobre los activos sea un punto de inflexión en este aspecto.
• Control sobre la prestación de los servicios: En contrapartida, el Gobierno generalmente es quien controla la prestación de estos servicios esenciales para la población. Una forma de garantizarse la protección de los servicios esenciales e infraestructura asociada es a través de la sanción de leyes o regulaciones que establezcan los lineamientos de seguridad clave. De esta forma no estaría únicamente del lado de quién opera la decisión de los lineamientos básicos de seguridad. Quién deba controlar debería contar con los elementos que permitan verificar objetivamente el cumplimiento de dichos lineamientos.
• Intercambio de Información: El intercambio de información entre quien opera y quién controla dicha operación es un tema sumamente importante. Para ello se deben establecer reglas claras que permitan a quien controla poder obtener información de primera línea y llevar adelante su rol. Es responsabilidad de quién opera garantizar el acceso y transparencia de la información y es responsabilidad de quién controla garantizar a quién opera la confidencialidad de dicha información y el tratamiento objetivo de la misma.
• Trabajo en Equipo: Así como en el ámbito privado debe ejercitarse la respuesta a incidentes de seguridad, a través de la maduración en la gestión de seguridad y la educación de los usuarios. En el ámbito de los servicios esenciales se presenta el desafío de la interrelación de distintos sectores ante situaciones similares, que podrían poner en riesgo no sólo al servicio, sino a la población. El entrenamiento toma mayor relevancia cuando el activo a proteger puede afectar la vida de las personas, por ello es excluyente contar con planes de respuesta a incidentes dentro de un programa de gestión de incidentes, que brinde los lineamientos a llevar a cabo ante aquellas situaciones que pudieran presentarse.

Algunos Desafíos

En aquellos países donde la protección de los servicios esenciales ya lleva unos años, se han presentado algunos puntos que deberían tenerse en cuenta al momento de iniciar un Plan de Protección de Servicios Esenciales:

• Se debe legislar convocando a los sectores que serán impactados por la legislación.
• Quién controle debe garantizar el manejo ético e independiente de la información provista por quién opera los servicios.
• Para que el ciudadano participe, los distintos participantes (quien opera y quien controla) deben generar confianza y brindar transparencia.
• Es fundamental contar con un repositorio único de información en el cual se registren los activos, los incidentes, los cambios y todo dato que sea relevante al control.
• La protección de los servicios esenciales debe ser una política de estado.

Algunas Referencias

• 21 Steps to Improve Cyber Security of SCADA Networks
• SP800-50 Building an Information Security Awareness and Training Program
• SP800-53 Security Controls for Federal Information Systems and Organizations
• SP800-55 Performance Measurement Guide for Information Security
• SP800-61 Computer Security Incident Handling Guide
• SP800-100 An Introduction to Information Security: The NIST Handbook
• Canada´s Cyber Security Strategy [1] y [2]
• Open Scada Security Project
• Defining Incident Management Processes for CSIRTs: A Work in Progress
• Centro Nacional para la Protección de las Infraestructuras Críticas

Contribución por Mariano del Río (@mmdelrio)

Leer más...