Source: http://coversec.blogspot.com/
Timestamp: 2016-12-11 04:02:41+00:00

Document:
Pues parece que había algo más que bichos raros detrás de esto de la "Gestión de Riesgos de la Seguridad de la Información"....La publicación bajo BSI de la norma BS 7799-3:2006 "Information security management systems. Guidelines for information security risk management" es un espaldarazo a quienes pensamos que la Gestión del Riesgo es la piedra angular de la gestión de la Seguridad de la Información, la herramienta imprescindible, primera y primaria para reducir el abismo entre "techies" y "gestores". Si la dirección empieza a oir hablar de cosas que entienda, mejor para todos....La necesidad de la norma se apoyaba en el hecho de que, a pesar de la norma ISO/IEC 27001:2005 (para orientarse en este embrollo, se recomienda una visita a las FAQ'S de BSI) no se sabía muy bien cómo desarrollar de manera práctica todo el ciclo de análisis y gestión de Riesgos. En definitiva, orienta sobre cómo identificar, evaluar el riesgo y, posteriormente, implementar controles o salvaguardas para mitigar/reducir los mismos, así como los mecanismos de revisión, monitorización y mejora continua del sistema de control basado en riesgo.Otra buena noticia para la estandarización de actividades de un Sistema de Gestión de la Seguridad de la Información (SGSI) es el anuncio del nuevo proyecto de norma ISO 27006 “Guidelines for information and communications technology disaster recovery services”, cuya publicación se espera para noviembre del 2007.
posted by Fernando Aparicio @ 11:22 PM 4 comments
El proceso de reinterpretación de la normativa de protección de datos al que se ve obligado la Agencia Española de Protección de Datos ha encontrado una buena piedra de toque en el tratamiento de la subcontratación internacional, toda vez que es una situación cada vez más presente en los procesos de negocio de las empresas españolas; sólo hay que pensar en ISP's que externalizan sus servicios de hosting y housing en países de menores costes, en agencias de marketing que utilizan plataformas ASP gestionadas desde, por ejemplo, Sudáfrica, o clientes cuyo servidor de correo o copias de seguridad remotas se encuentran alojadas, en realidad, en EE.UU aunque la empresa que me facture tenga CIF español. Por no hablar de corporaciones multinacionales donde empresas matrices y filiales se prestan servicios recíprocamente (por ejemplo, aplicación de RR.HH alojada en la casa matriz de Dinamarca y "alimentada" desde Internet por todas sus filiales sitas dentro y fuera de la Unión Europea).El problema empieza desde el artículo 12.2 de la Ley Orgánica 15/1999, que establece, al tratar la figura del encargado del tratamiento (la empresa subcontratada, para entendernos), que éste "no comunicará los datos, ni siquiera para su conservación, a otras personas”. La justificación de este artículo se fundamenta en el poder de disposición que tiene todo usuario (afectado, según la curiosa denominación legal) sobre la información que le concierne, lo que obliga a que, si la ley admite la posibilidad de que los datos puedan ser tratados por un tercero (cualquier servicio de subcontratación que se nos ocurra), será preciso que la empresa que ha contratado el servicio (Responsable a todas luces en caso de incumplimiento, con, además, mayor grado de responsabilidad que la empresa subcontratada) conozca en cada momento qué entidades acceden a dichos datos, a fin de "vigilar al vigilante" y garantizar al usuario que sus datos están siendo controlados según el tratamiento que éste mismo ha autorizado. Esto, por desgracia, no suele ser la norma en la vida empresarial, donde es muy habitual que las empresas subcontratadas jueguen al escondite y subcontraten, a su vez y sin conocimiento de la empresa contratante, con terceras entidades, formando una cadena que, según el razonamiento anterior, contraviene la normativa, ya que cualquier subcontratación posterior debería ser puesto en conocimiento de la empresa subcontrante, entre otras cosas, para que ésta pudiera atender cualquier reclamación efectuada por el afectado y para conocer en cada momento quién tiene acceso a esos datos. Luz y taquígrafos que aporten la transparencia necesaria para garantizar la trazabilidad de los datos y, en su caso, poder depurar responsabilidades en caso de incumplimiento.Pues bien, hacer posible que un segundo subcontratista pudiera tratar los datos (según la propia interpretación de la Agencia) se logra bien mediante su participación directa en el contrato con la empresa contratante (contrato a tres bandas, en este caso), bien mediante un apoderamiento otorgado al primer subcontratista para que éste actué en el nombre y por cuenta del contratante, o bien haciéndose constar expresamente en el contrato firmado entre el responsable y el primer encargado la propia circunstancia de la subcontratación.Pero, ¿qué sucede si para prestar ese segundo servicio de subcontratación fuera necesaria una transferencia internacional de datos a un tercer Estado que, según la Comisión Europea, no ofrece un nivel adecuado de protección de datos, como, pongamos, Sudáfrica?. Hemos visto que si yo como cliente contrato, por ejemplo, el mantenimiento de copias de seguridad remotas a un proveedor sudafricano deberé incluir en el contrato correspondiente lo dispuesto en el artículo 12, así como las cláusulas contenidas en la Decisión 2002/16/CE, mediante las que se adopten las adecuadas garantías de protección de datos que permitan la autorización de la transferencia internacional. Otro caso sería que yo contratara este servicio a un ISP español que, a su vez, hubiera subcontratado dicho servicio con el proveedor sudafricano. En este caso, a día de hoy no existen mecanismos para establecer las adecuadas garantías que permitan vincular directamente a dos encargados del tratamiento (el ISP español y el proveedor sudafricano). Es decir, los supuestos planteados hasta ahora, tanto en España (ver Instrucción 1/2000) como en la Comisión Europea (Decisiones 2001/497/CE, 2004/915/CE, y Decisión 2002/16/CE, ya citada), contemplan situaciones de transferencias bien entre Responsables del Fichero (por ejemplo, cesiones de datos entre dos empresas con fines de marketing o publicidad) o bien entre responsable y encargado, pero no entre dos encargados del tratamiento. Es decir, que si al ISP del ejemplo le da por subcontratar en un país extracomunitario, simplemente, no podría hacerlo salvo que sus clientes firmaran directamente un contrato con el proveedor sudafricano, con arreglo a los requisitos descritos en las normas citadas anteriormente.En fin, que....el panorama se complica. Y no sé por qué me da que a muchas empresas intermediarias no les va a hacer mucha gracia dar visibilidad al resto de los eslabones de la cadena, por aquello de que sus clientes empiecen a plantearse cual es el valor añadido en cada eslabón. Por lo pronto, esperemos que la Agencia y/o la Unión Europea pergeñen alguna solución a un problema que afecta y afectará cada vez más a las empresas españolas....y a las internacionales con interés en el mercado español.Uff, que post más pestiño. Parece que el espíritu de la Semana Santa me anima a la flagelación propia y ajena....
En el prolijo arte que supone la interpretación de la normativa de protección de datos, siempre han existido dudas razonables sobre el grado de concreción que exigía la Agencia Española de Protección de Datos para el cumplimiento de los principios de información y consentimiento. A la habitual leyenda-todo-vale-y-te-cuelo-todo-lo-que-pueda-si-no-te-quejas parece que se le agota el crédito y alguna de las recientes interpretaciones de la Agencia (ver procedimiento sancionador contra Grupo Pelayo) aprieta las tuercas en cuanto a la precisión requerida en términos tan comodín como "información comercial"...Cada vez se exigirán, por tanto, "finalidades determinadas y explícitas" a las que se vinculará el tratamiento de datos, requiriendo un esfuerzo de concreción cuyos límites siguen sin estar claros; sectores como el de telecomunicaciones, financiero y asegurador han utilizado masivamente las denominaciones genéricas, como "publicidad"o "información comercial" por razones a caballo entre el interés marketiniano y el puro pragmatismo. Pues bien, parece que pintan bastos para la inconcreción premeditada y las entidades deberán hilar más fino en la definición de sus finalidades publicitarias. Otro tanto sucede con la comunicación de datos a terceras empresas, donde el cómodo recurso a la inclusión de la información sobre la cesión a "las empresas del grupo" correrá la misma suerte...A la ya exigible concreción de la finalidad de la cesión, deberá seguir el nombre de las empresas a las que se ceden dichos datos. Entonces, ¿nos encontraremos ante claúsulas de varias páginas, en los que se recojan todas las empresas de, pongamos, la corporación de un grupo bancario? O recurriremos a la remisión a la página web del responsable del fichero, donde supuestamente aparecerán todas las empresas del grupo, en curiosa sintonía con el requisito de información web exigible por el artículo 10 de la LSSI? Todo por informar correctamente al usuario. Información es poder; o, al menos, disminución del riesgo de sanción....
Uno de los cuellos de botella de la gestión actual de los sistemas de información es la resolución de conflictos entre las partes implicadas. La oficial vía judicial sigue resultando en exceso lenta, carente de la suficiente especialización y demasiado proclive a las tácticas dilatorias. La falta de organismos jurisdiccionales específicos en el ámbito de los sistemas de información tampoco ayuda a enjuiciar lo correcto en determinadas situaciones. Por ello, la resolución por un tercero imparcial (una vez más nos encontramos con la figura del tercero de confianza), que establece bajo un criterio y una experiencia profesional determinados quién de las partes tiene razón ante una determinada controversia, va cobrando fuerza por momentos. Su filosofía alude a la necesidad de que verdaderos expertos sean los encargados de dilucidar el fondo del asunto con criterios de alta competencia técnica.Los sistemas arbitrales, muy extendidos en otras actividades globalizadas como el comercio exterior, se postulan como alternativa buena, bonita y barata para la resolución de conflictos en el ámbito de los sistemas de información. Esta figura extrajudicial consiste en que las partes implicadas en cualquier negocio jurídico deciden, de forma voluntaria, someter las discrepancias nacidas de la relación contractual a un tercero o terceros que actúan en concepto de árbitro/s de la contienda. Mediante un acuerdo o convenio se regulan las normas en que se desarrollara dicho arbitraje y se declara el sometimiento expreso al laudo (equivalente a la sentencia) que decidirá los términos de la controversia, siendo de obligado cumplimiento para las partes, de carácter confidencial y con todas las garantías de ejecución real e inmediata que el ordenamiento jurídico presta al laudo dictado. La extensión a posibles controversias supranacionales es otro rasgo de interés del arbitraje, en tiempos donde la prestación de servicios se internacionaliza como consecuencia del masivo uso de Internet. El modelo on demand permite que mi CRM se provea desde EE.UU, mi gestor de campañas de email marketing desde Sudáfrica y mis copias de seguridad automáticas desde Francia. Las posibles (y previsibles) controversias no deben verse lastradas por la pereza, teñida de desesperación, consustancial a la decisión de meterse en el jardín judicial internacional con escasas posibilidades de quedar satisfecho en mi reclamación. El ejemplo más preclaro de uso del arbitraje lo constituyó en su día la ICANN, organización responsable de la gestión de los dominios de nivel superior genéricos como .com, .net y .org, al necesitar encontrar con urgencia una solución al problema de las controversias. Descartando la vía del tratado internacional por lenta y la promulgación de leyes nacionales, por la posibilidad de que fueran divergentes en exceso, se designó, entre otros, a la Organización Mundial de la Propiedad Intelectual (OMPI) como proveedor de servicios de solución de controversias bajo la fórmula en la que un “árbitro”, “mediador” o experto (de una lista de cerca de 200 profesionales independientes facultados para tomar decisiones en ese tipo de casos) examinaba la controversia y tomaba una decisión al respecto. Todo ello a precios razonables y en periodos habitualmente no superiores a dos meses. El nuevo Plan de dominios .es acaba de estrenar el sistema de resolución extrajudicial de conflictos, donde una serie de proveedores acreditados atienden las reclamaciones sobre posibles dominios especulativos. Asociaciones como ACAM, AEADE o ARBITEC, entre otras, impulsan las ventajas del arbitraje en el mundo empresarial, demostrando que resoluciones sobre proyectos informáticos fallidos, análisis funcionales incompletos, conflictos sobre propiedad intelectual, incumplimientos de los niveles de servicio incluidos en un SLA, irregularidades en la prestación de servicios online, etc, tienen perfecta cabida dentro del esquema de resolución arbitral de conflictos. posted by Fernando Aparicio @ 8:38 PM 2 comments
Como si de una peli de serie B se tratase, parece que aquel escenario resumen de múltiples incidentes de seguridad que utilizo como caso práctico en mis clases, se hace realidad por obra y gracia de la noticia aparecida en ComputerWorld y comentada por Enrique Dans en su blog (gracias por citarme, compañero). Ni Pigmalión lo hubiera hecho mejor.Lo que está claro es que nada como perder un portátil y salir en los medios para despertar el alma dormida; lo curioso es que los americanos ya llevan bastantes años y han dedicado bastantes esfuerzos en obligar a que los incidentes de seguridad se tomen en serio. La propia ley de la que habla el artículo (Financial Data Protection Act) es un ejemplo de contramedidas correctoras, tal y como figura en otro post del blog. Entre otras propone:Compromiso de creación de un estándar nacional de seguridad de la información.Obligación de que las empresas objeto de un ataque notifiquen a sus usuarios/consumidores que su información personal y su identidad digital han sido comprometidasLa organización atacada tendrá la obligación de proveer de un servicio gratuito durante seis meses que monitorice (perdón por el anglicismo, ahora mismo no se me ocurre ninguno más adecuado) la información financiera del usuario que ha sido comprometida para prevenir cualquier fraude mediante el uso de esa identidad robada.La ley, aunque muy criticada por el amplio margen de interpretación que da a la organización atacada de lo que considera un "riesgo razonable para el usuario", es un híbrido de imaginación y experiencias previas que viene precedida por iniciativas legislativas como la californiana Security Breach 1386 que, ya con ámbito de aplicación nacional en la práctica, obliga a las organizaciones a que cualquier incidente en el que se tenga constancia de que se ha comprometido la seguridad de determinados datos personales (sobre todo, financieros) sea notificado a los titulares de los datos "en el menor plazo posible y sin mediar retraso no razonable". Ya por pedir....no estaría de más que la ley exigiera algún informe (aunque fuera anónimo) de cualquier incidente, por aquello de ir construyendo estadísticas fiables para saber de qué orden de magnitud estamos hablando realmente y facilitar así el cálculo actuarial que necesitan las entidades aseguradores para el diseño de productos especializados en la cobertura de riesgo.Y ¿en España?...Un poquito de Documento de Seguridad, con procedimientos de corta y pega, y vamos que nos matamos. Eso sí, actualizado y difundido al mismo nivel que los incunables de la Biblioteca Nacional. Los pocos que lo tienen lo mantienen impoluto, pero por el escaso uso. Nos harán falta unos cuantos casos como el de Fidelity. Al tiempo.
Según determina un reciente estudio realizado por IBM, un 30% de las empresas españolas manifiesta no sentirse protegida frente a las amenazas que circulan por Internet. Ninguna novedad (bajo el porcentaje, me parece), habida cuenta del estado exuberante de troyanos, phishing, pharming y demás malware cada vez pergeñado con mayor sofisticación (para asustarse de verdad, sólo hay que echar un vistazo al magnífico archivo del Anti Phishing Working Group) . Las conclusiones reflejan la preocupación de las empresas por que estas amenazas cristalicen en perdidas de negocio/financieras, pérdidas en los activos de propiedad intelectual y, cada vez con mayor presencia, en daños a la imagen de marca o, lo que es lo mismo, pérdida de la confianza de tus clientes.El asunto es especialmente grave en sectores como la banca online, donde el más mínimo "fallo técnico" desincentiva a los reacios a la transacción online para dar el paso definitivo y abandonar las visitas a la sucursal de turno. Bueno, pues parece que la nueva generación de ataques DOS tienen el siguiente objetivo en los DNS ; siguiendo la lógica de ataques distribuidos por medio de PCs infectados convertidos en zombies inconscientes (y, por tanto, potencialmente responsables, ojo) del daño que pueden causar, los hackers usan ahora sus zombies para enviar peticiones a sus DNS pero usando la dirección del objetivo del ataque (un sitio de banca online, pongamos) como dirección de respuesta a la petición al DNS. Lo que significa que el DNS se convierte en atacante cada vez que responde a una petición maliciosa. Y si ya desde la defensa del banco es difícil discernir en un DDOS "normal" cuales son peticiones legítimas y cuales no, si se añaden las del DNS (no olvidemos, encargadas de traducir legítimamente los dominios a direcciones IP), el ataque se hará mucho más difícil de bloquear, y, sobre todo, más caro (lo que puede suponer un problema de supervivencia para todo aquellas organizaciones que no dispongan de un presupuesto holgado de seguridad).Me pregunto que responderá en estos casos el Servicio de Atención al Cliente ante la agria reclamación del usuario....
Un interesante artículo de Out-Law ilustra la tendencia creciente en grandes bancos europeos (UK, Holanda, Suecia, etc) a distribuir entre sus clientes (de forma gratuita o de pago, según los casos) un dispositivo hardware (token, OTP, o tarjeta inteligente) que complementa los sistemas actuales de autenticación basados en usuario y contraseña. La lucha contra el phishing obliga a las entidades bancarias a elevar el listón de sus exigencias en materia de seguridad; la idea es que , en el uso de banca online, el usuario conecte el token, introduzca su nombre de usuario, y presione un botón, recibiendo a continuación un código aleatorio de seis cifras, único para esa sesión, que actuará a modo de sustituto o complemento del password. Un segundo código aleatorio se puede generar para autorizar las transacciones habituales de la banca online, sustituyendo la (mal llamada por algunos bancos españoles) firma eletrónica, que no es más que un segundo password añadido al primero. Todo lo que abunde en no emplear las castigadas neuronas de los usuarios en recordar enrevesadas contraseñas parece un paso en la dirección adecuada. Se impone la filosofía de sumar "algo que yo sé" (mi usuario y password habituales) con "algo que tengo" (el dispositivo hardware de turno o, incluso, el propio móvil). Mismo principio que inspira al famoso DNI electrónico. Dos mejor que uno.Los contras de estos sistemas son, sin embargo, varios: en principio, parece que necesitaré tantos dispositivos como bancos online en los que tenga contratados servicios, lo que incrementa el engorro para el usuario, por no hablar de las dificultades de accesibilidad para discapacitados o el coste de estas soluciones, que puede llegar a ser disuasorio si hablamos de distribuciones masivas.¿Mayor seguridad? Sí. Pero también incremento de la dificultad de uso (factor absolutamente disuasorio para el usuario medio), aumento del coste y reducción de su universalidad al existir una gran variedad de soluciones y estándares. Parece que, una vez más, procede saber si el valor de lo que intento proteger es superior a los controles establecidos para su protección. Para que no me cueste más el mango que el mazo, vamos.

References: artículo 12
 artículo 12
 artículo 10
 resolución 
 resolución 
 resolución 
 resolución 
 resolución