jueves, 28 de octubre de 2010 3 comentarios

Guía INTECO sobre Continuidad de negocio

El Observatorio de Seguridad de la Información de INTECO comunicó ayer la publicación de una guía práctica sobre continuidad de negocio dirigida a PYMES. Este material es de lectura recomendable ( como todo lo que suele hacer INTECO) e imprescindible para aquellos que quieran iniciarse en este tema dado que han conseguido en 80 hojas sintetizar los conceptos de continuidad de negocio y todo aquello que debe contemplar un proyecto de este tipo.
Es importante destacar la importancia de tener claro cuales son primero las necesidades de recuperación de la Organización, antes de ponerse a implantar o seleccionar tecnología. Todo plan de continuidad de negocio debe responder a las preguntas ¿Qué recuperar? ¿Quién lo recupera? ¿Cuando se hace cada cosa? ¿Cómo se ejecutan las actividades de recuperación? ¿Donde podemos hacerlo? Para ello, es necesario valorar los parámetros MTD, RTO y RPO que ya expliqué hace un año cuando se puso de moda por la famosa y temida Gripe A. También en el propio blog de INTECO pude dejar un par de artículos sobre qué debiera considerarse cuando se pretende resolver esta problemática que pueden ser consultados en la categoría "Continuidad de negocio".


La Continuidad de negocio no debe ser vista solo como la protección frente a grandes catástrofes. A veces, problemas más cotidianos como una obra en tu ciudad o un problema con el mantenimiento del edificio genera caídas o pérdidas de servicio. Hace poco se publicaba un estudio sobre el coste de las caídas TI y España figura para nuestra desgracia en el Top Ten como muestra la gráfica adjunta. Tal como publica "El Economista" se estima que las empresas pierden 3.000 millones al año por las caídas de su Red. El titular así dicho llama la atención según se entienda por "caidas de red". Lo apropiado debiera ser las caídas de sus "sistemas de información" porque estos cortes no son siempre debidos a problemas de los proveedores de telecomunicaciones sino al cese de suministro de servicios TI internos. En cualquier caso, los costes de la "no seguridad" son considerables aunque la mentalidad poco preventiva de la cultura española puede justificar esta desgraciada estadística. El artículo de El Economista deja claras las reflexiones principales:
El informe Avoidable Cost of Downtime 2010, realizado por la firma de investigación independiente Coleman Parkes, pone de manifiesto que las pérdidas financieras asociadas a las interrupciones de servicio TI se disparan cuanto más tiempo tardan en resolverse. Para este estudio se han analizado 1.808 organizaciones (incluyendo 200 españolas) con más de 50 empleados y de 11 países europeos.

Los resultados indican que cada organización española registra anualmente una media de 10 horas de interrupción del servicio TI, lo que equivale a más de 90.000 horas en el conjunto de España. Durante el tiempo en el que los sistemas TI críticos para el negocio se ven interrumpidos, las organizaciones españolas estiman que su capacidad para generar ingresos queda reducida a poco más de un tercio (36%).




Enlace: Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio,
jueves, 14 de octubre de 2010 8 comentarios

Reflexiones en el octavo cumpleaños del blog

Como cada mes de octubre, este blog cumple un año más de presencia en Internet y ya van ocho. Creo importante celebrar el poder seguir sacando un hueco a la semana para compartir aquellas cosas vinculadas con la temática de la que me gusta hablar, la "seguridad de la información". No es fácil y en parte la disminución de la frecuencia de publicación tiene que ver en parte con eso. Sin embargo, este blog me proporciona como autor mucho más de lo que yo puedo dar comentando o reflexionando en voz alta. Es una potente herramienta de aprendizaje que fija e incrementa el conocimiento que voy acumulando. El leer una noticia y plantearte cosas para comentar o escribir hace, por un lado, madurar la información y por otro, reflexionar o tratar de ver otros puntos de vista que pueda extrapolar a la temática del blog.


Como el resto de cumpleaños, toca valorar la evolución del mercado de la seguridad de la información. La crisis obviamente no está dejando títere con cabeza. Sin embargo, nuestra área de conocimiento parece en continua expansión siendo cada vez más relevante su presencia dentro del organigrama de toda Organización importante. No es tanto mérito de la propia seguridad sino de la relevancia que van adquiriendo los sistemas de información y su vital papel en el buen desempeño para proporcionar productos o servicios. De igual forma que la gestión de la tecnología empieza a formalizarse y a definir una serie de actividades para ser un área similar a las demás, con objetivos, métricas e indicadores de desempeño, procedimientos y tareas, el área de la seguridad es más relevante dado que representa el papel de la persona que debe velar por garantizar que todo funcione de forma normal. Y parece que el escenario profesional podrá mejorar gracias a la aparición de nueva legislación que establece cada vez más requisitos sobre seguridad para hacer que las cosas se tomen más en serio de lo que venía siendo tradicional ver en todos los sectores. La noticia que se publicaba a principios de mes sobre  El Decreto sobre seguridad de infraestructuras críticas revela la ausencia de expertos en esta materia y las necesidades de mejorar la oferta formativa para cubrir una demanda incipiente de expertos que con la nueva regulación será de presencia obligada en ciertos sectores. La aparición del R.D. 3/2010 del Esquema Nacional de Seguridad también eleva las necesidades de personal dentro de las Administraciones Públicas aunque en este caso, la carencia tendrá que ser cubierta por profesionales que ya perteneciendo a la propia Administración vayan profundizando en este nuevo área hasta que aparezcan las primeras oposiciones específicas para la figura del responsable de seguridad.

Personalmente creo que todas estas regulaciones son muy buenas noticias para el sector y para aquellos que llevamos cierto tiempo en él dado que nos ha permitido acumular experiencia suficiente para estar perfectamente capacitados para transformarnos de asesores o consultores a capitanes del barco. Recuerdo mis comienzos hace 11 años donde el primer y único empujón que desde la regulación se proporcionó a la seguridad fue la normativa en materia de protección de datos y todos sabemos en qué situación se encuentra todavía el cumplimiento de esta normativa dentro del ámbito público y privado. La aparición en aquel momento de Magerit 1.0 fue un auténtico soplo de aire fresco al enfoque tradicional de seguridad pero ha tardado casi 10 años en calar esta forma de trabajar y sobre todo "gestionar la seguridad". Sin embargo, la nueva normativa asociada a servicios críticos o a sedes electrónicas son cosas mucho más serias y relevantes dado que no solo comprometen la privacidad de ciudadanos sino que pudieran acabar poniéndose en peligro vidas y eso supone siempre que las cosas se tomen mucho más en serio. 
La oportunidad de haber podido participar en todo tipo de proyectos relacionados con el diseño y construcción del área de seguridad, sobre todo en las fases más estratégicas da herramientas suficientes para poder asumir sin problemas la Dirección del área de seguridad de la información. En particular, varios de los últimos proyectos están precisamente relacionados con la dirección de oficinas de seguridad que son "proyectos-bastón" para la creación de un área de seguridad en Organizaciones que parten de cero. Y es muy gratificante ver cómo partiendo de un terreno fértil pero desierto, empiezan a crecer los primeros brotes de seguridad y sobre todo, como se empiezan a modificar tendencias y estadísticas negativas que revelaban carencias e incidencias continuas que se van apagando con las decisiones tomadas para reconducir el problema. Cualquiera que vaya a asumir la Dirección de la Seguridad de la Información desde cero, tendrá que trabajar en construir su departamento desde dos puntos de vista opuestos pero complementarios. Como si fuera una pirámide, habrá que volcar esfuerzos en mitigar los problemas del día a día relacionados con la problemática malware, el control de acceso de usuarios y la monitorización del uso de los recursos de la Organización porque es lo que genera incidencias todos los días. Sin embargo, al mismo tiempo, deberá empezar a crear un marco de trabajo que permita definir la estrategia de la Organización tratando de sintonizar el nuevo área con las necesidades de protección que tiene la Organización. El área de seguridad tiene su sentido como herramienta al servicio del resto de la empresa u organización. Por tanto, tenemos que luchar día a día por hacerle la vida más sencilla al resto de los departamentos. Para ello, es vital partir de una foto estática que permita saber de tu organización qué importa, por qué importa y qué riesgos debemos empezar a gestionar de forma prioritaria. Con esta información, ya se puede desplegar un plan mucho más táctico para poder aterrizar esas necesidades y transformarlas en acciones o proyectos que vayan a medio y largo plazo logrando mejorar los resultados en materia de seguridad.Nunca pueden vernos como un enemigo sino como un aliado que lucha con ellos en la misma batalla frente a un enemigo común. Por tanto, los criterios impuestos y autoritarios, sin razonamiento previo son contraproducentes. Lo que hagamos, sea lo restrictivo que sea, deberá estar muy bien justificado por el riesgo, por ser una obligación legal o por ser necesidades de la Organización


lunes, 4 de octubre de 2010 2 comentarios

Google, malware y el ciclo de gestión de los incidentes de seguridad

Aunque ya lo comenté vía Twitter hace unos días, es de destacar esta inteligente iniciativa del gran buscador por perseguir la lacra del malware. Para ello, han decidido utilizar sus potentes motores que avisan al usuario cuando accede a contenidos maliciosos para notificar al administrador de red responsable de la IP que sirve el contenido de estos hechos. Ello obviamente no va a afectar a aquellos que tienen como parte de su actividad de negocio ser proveedores de contenidos ilícitos pero si va a contribuir a limpiar aquellos equipos donde se ignora que existe malware y el administrador de red también lo desconoce.

El servicio ha sido puesto a disposición de los administradores de sistemas autónomos y requiere previamente el registro en la URL http://safebrowsingalerts.googlelabs.com.

De esta forma ya no pasará desapercibido para aquellos administradores de red que quieran conocer qué tipo de contenidos alojan bajo su direccionamiento qué esconde cada equipo según el examen de seguridad de Google.

Ello enlaza también con otro texto que quería comentar que trata sobre el ciclo de gestión de incidentes. En España todavía las empresas no destinan equipos especiales para la respuesta frente a incidentes y sólo algunas subcontratan este tipo de servicios en los Security Operations Center.

El presente gráfico trata de representar las fases del ciclo de gestión de incidentes y los grupos de atención que deben tratarlo en cada fase. A estas alturas a nadie le sorprenderá ver un ciclo parecido al de Demming (Plan-Do-Check-Act) como eje central de las tareas.

Las distintas fases del ciclo son:
  • Plan: La organización se prepara para defender su infraestructura de TI y los datos mediante la evaluación de sus riesgos y su estado de seguridad. Se trata de entender cuales son las posibles amenazas y si somos o no vulnerables a ellas. El chequeo de vulnerabilidades y los test de intrusión pueden ser actividades de esta fase dado que sirven para evitar la detección ajena del fallo siendo nosotros mismos quienes nos preocupemos por hallar agujeros en nuestra infraestructura. La fase de planificación permite a la organización diseñar una arquitectura de seguridad de la información más robusta frente a los ataques comunes o más triviales. Permite que la Organización no quede al descubierto con los continuos escaneos de vulnerabilidades que se realizan ya a diario a través de Internet buscando potenciales víctimas fáciles.
  • Resistir: Después de haber planeado sus tácticas de defensa y estrategias, e implementar los componentes apropiados de su arquitectura de seguridad, la organización debe resistir los ataques. Esto implica el uso de tecnologías de protección perimetral que hacen de primera barrera y muro de contención frente a ataques ya dirigidos. Los detectores de intrusos y las herramientas más proactivas como los IPS pueden eliminar también mucho ruido de ataques automatizados utilizando herramientas más sofisticadas. Filtrar el tráfico de red no deseado en ambas direcciones entrantes y salientes, las infecciones de malware (en la medida de lo posible), establecer mecanismos de control de acceso a los datos y aplicaciones basadas en métodos de autenticación robustos, etc. Nótese el uso en esta fase del término "resistir", donde ya suponemos que nos toca responder frente a una agresión intencionada.
  • Detectar: Dado que es ingenuo esperar que la organización será capaz de resistir todos los intentos de intrusión, hay que dedicar esfuerzos a detectar los indicios de penetración en nuestros sistemas. Esto implica tener visibilidad y monitorización en todos los niveles de la infraestructura (redes, aplicaciones, datos, etc) y herramientas de detección de intrusos basadas en patrones de uso anómalos mediante la extrusión, la realización de la detección de cambios, la recolección y revisión de los registros, y así sucesivamente. Los datos recogidos en la fase de detección son  fundamentales para investigar el alcance de la intrusión de una vez han sido descubierta. Muchas organizaciones no implementan esta fase correctamente y no recogen evidencias digitales que luego les permita emprender acciones legales si la gravedad del asunto lo requiere.
  • Actuar: Una vez que el incidente ha sido detectado, la organización se moviliza para responder a la intrusión. Este proceso generalmente implica entender el alcance del incidente, la situación y su resolución. El análisis de los hechos una vez resuelto el conflicto debe servir para aprender de los errores y debe contribuir a mejorar la fase de planificación inicial de protecciones del nuevo ciclo que comienza.
Lo que es básico e imprescindible es aprender de los errores. Un incidente no queda solucionado cuando acaba el ataque sino cuando se mitiga cualquier remota posibilidad de que los hechos puedan repetirse. El hombre es el único animal que tropieza dos veces en la misma piedra. Sin embargo, una buena gestión del ciclo de vida de un incidente debe evitar precisamente ese segundo tropiezo. La herramienta que Google pone a disposición de los administradores de red mejorará la fase de detección y por tanto, servirá para hacer que se actúe y fortaleza el organismo frente a los ataques ya detectados.  No se trata de creer que se está seguro sino de tener constancia y datos que lo objetiven. Mantener a cero el marcador de buenos frente a malos es el objetivo. El único problema es que el partido tiene hora de inicio pero nunca hora de fin. Hay que mantener la tensión siempre... porque los malos no llaman a la puerta y buscarán el mínimo descuido para entrar.Existe una enorme desproporción entre el esfuerzo del defensor y del atacante. 



domingo, 3 de octubre de 2010 5 comentarios

¿Qué debemos pedirle a una herramienta de análisis y gestión del riesgo?

Hasta hace un par de años, las herramientas de análisis y gestión del riesgo (en adelante AGR) no abundaban en el mercado, solían ser extranjeras y eran excesivamente caras. En el panorama español el rey era EAR/PILAR basada en la metodología MAGERIT. Sin embargo, con la extensión y patrocinio de los SGSI han aparecido nuevas herramientas que enriquecen el escenario y generan dudas respecto a cual elegir. Este post no es un análisis comparativo de productos sino una reflexión en voz alta basada en mi experiencia profesional sobre que debemos pedir a estas herramientas y qué objetivos deben cumplir.

Lo primero que hay que destacar es que existen dos tendencias claras dentro de las herramientas de apoyo a los SGSI: las que vienen del mundo de la calidad orientadas a dar soporte al ciclo PDCA y las que vienen del mundo de la seguridad orientadas a realizar un estudio preciso de las necesidades de seguridad en base al riesgo.
  • Herramientas del mundo de la calidad: sus puntos fuertes son que permiten de forma cómoda la gestión de los procesos generales del SGSI relacionados con la gestión de no conformidades, acciones preventivas y correctivas, gestión de las auditorías y de los resultados de la revisión del sistema por la Dirección. Este tipo de herramientas podríamos decir que son gestores documentales especializados para un SGSI. En estas herramientas el análisis y gestión del riesgo deja mucho que desear porque implantan metodologías que tienen una capacidad nula para modelar la seguridad.
  • Herramientas del mundo de la seguridad: sus puntos fuertes son que permiten realizar análisis de riesgos muy detallados y completos pero carecen de actividades de apoyo para la gestión de los procesos del SGSI, por tanto no tienen funcionalidad orientadas a la gestión y mantenimiento de los registros de operación del SGSI (No conformidades, auditorías, revisión del sistema por la Dirección, planificación de auditorías, de acciones formativas, etc). Son herramientas centradas en la seguridad y modelar la realidad para obtener una foto nítida del mapa de riesgos de la organización y posteriormente poder establecer los planes de tratamiento mas adecuados.
  • Herramientas mixtas: tienen lo mejor de ambas opciones y por tanto, son las más completas.

Yo personalmente prefiero las herramientas que modelan bien la seguridad frente a las que gestiona bien los registros del SGSI por una sencilla razón: estas tareas pueden ser hechas de forma manual porque no son complejas y te puedes arreglar con una gestión basada en documentos ofimáticos y carpetas en un servidor. Es más tedioso pero tampoco hay tanta carga de trabajo en este aspecto como para balancearme hacia las herramientas del mundo de la calidad.

Respecto a las herramientas del mundo de la seguridad, ¿Qué cosas son esenciales para mi?
  • Deben respetar los conceptos establecidos por ISO 27005 que es la norma que establece el marco de trabajo de toda metodología de análisis y gestión del riesgo. Deben permitir realizar todas las fases establecidas por esta norma y representar correctamente los conceptos que esta norma establece como marco en el que deben desenvolverse estas metodologías.
  • Deben tener unas matemáticas claras a la hora de calcular el riesgo. Todos sabemos que riesgo es una función del impacto que puede sufrir un activo debido a una amenaza y la vulnerabilidad de dicho activo frente a dicha amenaza. Las funciones sirven para establecer el abanico de riesgos a utilizar pero deben equilibrar los resultados de forma que los valores sean proporcionales para riesgos altos, medios o bajos según los rangos numéricos que vayamos a utilizar. Ello garantiza a priori una distribución homogénea de resultados impacto x vulnerabilidad para los riesgos. En cualquier caso, es imprescindible que los resultados sean sencillamente reproducibles conociendo los valores de impacto y vulnerabilidad pensando sobre todo en el cliente final que debe entender de donde salen los riesgos.
  • Deben tratar las dimensiones de seguridad como se merecen. No se pueden mezclar churras con meninas y las amenazas afectan de forma diferente a las diferentes características de la seguridad. Por tanto, el valor del riesgo debe estar condicionado a una amenaza sobre un activo que afecta a una o mas dimensiones. Cuando una herramienta indica que se tiene un nivel de riesgo X pero no indica en que dimensión, es complicado después en el tratamiento del mismo saber que hacer. Las estrategias de las medidas de seguridad están condicionadas al tipo de daño del que pretender preservar al activo, por tanto es muy relevante conocer la dimensión dañada. Si una herramienta toma como riesgo el máximo valor del daño recibido en cualquiera de sus dimensiones, deja ciego al técnico que luego debe pensar en que hacer para solventarlas. Es como ir al médico y cuando te pregunta que síntomas tienes, sólo le dices que estas enfermo. Mal diagnóstico puedes dar con tan poca información. Hay que pensar una cosa, todo lo que no hagamos bien en la fase de análisis del riesgo, complicará y dificultará la fase de tratamiento que es realmente lo importante de todo este proceso. No se trata de poder hacer un análisis estupendo que revele las carencias sino de definir qué hacer, en qué plazos y con qué objetivos para remediar esa situación. Por tanto, hay dos aspectos muy importantes a tener en cuenta: que permita modelar bien el problema de seguridad para dar un diagnóstico certero pero a su vez, que esté orientado a establecer un plan de tratamiento para poder poner fin a dicha situación.
  • Deben considerar las particularidades de la dimensión de la disponibilidad. Cuando hablamos de incidentes de seguridad no se suele considerar el factor tiempo porque en la mayoría de los casos, el daño no es proporcional al tiempo, excepto para la disponibilidad. Si una información confidencial es revelada a terceros, el impacto ya se ha producido. Sin embargo, cuando hablamos de una pérdida de un servicio, el tiempo es un factor determinante para calcular los daños. No tiene las mismas consecuencias están sin servicio una hora que estarlo durante una semana. Por tanto, esta dimensión debe ser tratada de forma especial. Además, de hacerlo así, estamos recogiendo información que es muy necesaria en los estudios de impacto en el negocio para cuando abordemos la continuidad de negocio. Se puede simultanear la recogida de información para el análisis del riesgo y para el estudio de impacto en el negocio (Business Impact Analyisis o BIA).

A modo de conclusión, lo que yo espero de este tipo de aplicaciones es que sean una especie de sistema experto que contengan conocimiento en relación a amenazas y soluciones, de manera que conforme vamos incorporando a ellas información, sean capaces de asesorar y establecer las mejores opciones de gestión y tratamiento de los riesgos detectados. Para mi es más importante lo que me proporcionan en la fase de gestión que en la fase de análisis dado que donde más conocimiento se debe tener es a la hora de poner el tratamiento que mitigue los riesgos. Eso sí, requiere previamente de haber realizado el diagnóstico correcto. Espero haber proporcionado algo de criterio a la hora de poder evaluar y comparar ahora los productos del mercado.
 
;