En estos últimos días hemos visto en prensa las exigencias que Cesar Alierta, presidente de Telefónica, lanzaba contra los proveedores de contenido en Internet y mas particularmente contra Google. Las ISP’s empiezan a plantear una situación que ha creado gran revuelo en toda la Red y que se presume como algo que va a colear durante bastante tiempo y no solo aquí en nuestro país sino en todo el mundo. La cuestión es la siguiente, ¿deben los Google, Microsoft, Yahoo y demás pagar una ‘tasa’ a los proveedores de Internet?
El imparable crecimiento de Internet y de sus contenidos requiere una gran inversión en infraestructuras y las ISP entienden que este gasto no debe ser sufragado solo por ellas sino también por los que las utilizan para su negocio, es decir, los proveedores de contenido. Hasta aquí parece una pretensión razonable, pero la respuesta no lo es tanto.
La cuestión es bastante espinosa ya que si llegara a aprobarse el remedio podría ser peor que la enfermedad y es que se abriría la puerta a un posible control de la Red por parte de las ISP’s dejándonos a los usuarios sin lo mejor que nos ha dado Internet, la total libertad de elección. Y es que si se diera la situación que planteamos, ¿Quién nos dice que nuestro proveedor de Internet no firmaría un acuerdo con un buscador, por ejemplo, dándole todo el ancho de banda que necesita y dejando a los demás en inferioridad haciendo así que su funcionamiento no sea todo lo optimo que necesita por lo que perdería sus clientes?. ¿No estaríamos ante una total falta de libre competencia?, ya que a los grandes proveedores dinero no les falta pero, ¿y a los que quieran empezar de cero?.
Esta claro que este es un problema de gran peso y que definirá el Internet del futuro por lo que de una forma u otra habrá que andar con pies de plomo y requerirá un estudio concienzudo por parte de los estados.
¿Cómo acabara todo esto?, el tiempo nos lo dirá.
El informe desarrollado por el Software Engineering Institute (SEI) de la Universidad Carnegie Mello, presenta una taxonomía de los riesgos operativos de seguridad cibernética que trata de identificar y organizar las fuentes de riesgo operativo de seguridad cibernética en cuatro clases:
(1) Las acciones de las personas, o falta de acción, adoptado por la gente ya sea deliberadamente o accidentalmente que la seguridad cibernética
(2) sistemas y los fallos tecnológicos: fallos de hardware, software y sistemas de información
(3) procesos internos, y sus fallas: problemas en el negocio de los procesos internos que afectan la capacidad para implementar, administrar y mantener la seguridad informática, tales como el diseño de procesos, ejecución y de control
(4) eventos externos los problemas a menudo fuera del control de la organización, tales como los desastres, jurídicas cuestiones, asuntos de negocios, y las dependencias del proveedor de servicios.
Esta taxonomía se puede utilizar como una herramienta para ayudar en la identificación de todos los operativos de aplicación los riesgos de la seguridad cibernética en una organización. Con ese fin, este informe también analiza la armonización de la taxonomía de las actividades de identificación y análisis de riesgo, tales como los descritos por la Federal Information Security Management Act de 2002 [FISMA 2002], el Instituto Nacional de Estándares y Tecnología (NIST).
El informe completo se puede descargar desde Software Engineering Institute (SEI).
http://www.sei.cmu.edu/reports/10tn028.pdf
El plan de empresa de Alejandro se convirtió en realidad, pero el martes puede acabar en pesadilla. Nintendo pide para él 23 años de cárcel y 840.000 euros de indemnización por vender en su tienda de informática, Alechip.com, los módulos de carga de videojuegos para la consola DS. La multinacional japonesa del ocio electrónico, que no realizará declaraciones hasta después del juicio, considera que estos cartuchos son "ilegales", porque permiten usar sus juegos pirateados. Además, en su escrito de acusación, le culpa de violación de marca, diseño y revelación de secretos.
Alejandro Fernández, de 31 años, está tranquilo. "Por fin me podré defender", dice. El juicio empieza el martes y la fiscalía pide una pena menor: tres años y medio de prisión y 12.960 euros por dos delitos, uno contra la propiedad intelectual y otro contra la industrial. El empresario asturiano rechaza de plano todas las acusaciones. "Nunca he vendido nada pirateado sino material informático, incluido las consolas de Nintendo, sus juegos y sus accesorios originales. Pero también vendo accesorios compatibles y eso no les gusta. ¿Por qué van a por el comerciante? ¿Por qué no van a China que es donde se fabrican estos dispositivos?".
La aventura empresarial de este ingeniero electrónico asturiano empezó en 2005. Como proyecto final de carrera realizó un plan de negocio para abrir una tienda. "Como las opciones laborales eran escasas o directamente rozaban la explotación", lo convirtió en realidad.
Empezó en el garaje de sus padres a los 25 años. "Me ofrecía en los anuncios por palabras para reparar ordenadores, consolas..., que recogía por mensajería exprés". El negocio funcionó bien y seis meses después se trasladó "a un pequeño local, a la vez que abría la tienda en Internet", que después amplió.
En la Navidad de 2008 todo se torció. Nintendo empezó a bloquear en la aduana los productos -por valor de 70.000 euros- que importaba de China. "Me llamaron y dieron dos opciones: pagar 3.000 euros o ir a juicio. Las dos primeras veces pagué, una de ellas conseguí regatear a 1.500 euros, pero luego me rebelé y en ese momento comenzaron a lloverme demandas hasta que entraron por la vía penal". La primera demanda se archivó; la segunda, la ganó por la vía mercantil, pero está recurrida, explica Fernández.
El martes, cuando empiece el juicio, se contrapondrán dos teorías. Nintendo argumentará que es piratería. Cuando hace seis meses se emitió la primera sentencia que ilegalizó la venta de estos módulos de carga de videojuegos -un fallo de conformidad, porque los acusados se declararon culpables-, el subdirector de la compañía, Rafael Martínez, declaro: "España es el país más afectado por la piratería. Hay un cierto arraigo, una sensación de que está ahí para todos y no se valora la propiedad intelectual".
En el escrito de acusación, además, Nintendo añade que la demanda trasciende la venta de productos ilegales destinados a romper las barreras de seguridad de la consola, porque los cartuchos solo son válidos para la Nintendo DS. Y constituye una infracción del "diseño industrial ajeno" es decir, que se basan en el original. El fabricante también considera que hay infracción de marca, porque contienen información secreta de su propiedad, "incluida en un software o código informático". De ahí que también acusa de revelación de secretos al importador.
Fernández, en cambio, lo ve completamente al revés. "Ellos venden consolas capadas para que solo se puedan reproducir los contenidos que ellos comercializan. Estos cartuchos no están diseñados para piratear juegos, ni violar copyright ni marca alguna, sino para darles otros usos a las consolas, auténticos ordenadores, que sin ellos sería imposible realizar".
El juez estudiará el martes quién tiene razón. Fernández, en cualquier caso, está tranquilo. Confiesa que cuando empezó esta pesadilla tuvo miedo, pero ahora ya no. "Si aceptaba el chantaje me llevaban a la ruina. Si cedo, ¿con qué cara miraría a mi mujer, a mi hijo, a mis clientes y proveedores? Estoy dispuesto a llevarlo hasta el final".
Fuente: IH
Esta semana hemos tenido otro incidente de seguridad vinculado al prestador de servicios de certificación COMODO preocupante y que apunta hacia una posible futura tendencia que podrá seguir explotándose por parte del crimenware.
La noticia técnica de lo ocurrido está muy detallada en las dos noticias Una-al-día de los días 24 y 25 de este mes.
Mi reflexión se orienta más hacia la perspectiva de la "gestión de la seguridad" y la necesidad de proteger todos los eslabones de la cadena. Para ello, con carácter previo, creo conveniente explicar la lógica de la protección en la que se basan las Infraestructuras de clave pública (PKI). Tal como se expresa en Wikipedia, una infraestructura de clave publica (o, en inglés, PKI, Public Key Infrastructure) es una combinación de hardware y software, políticas y procedimientos de seguridad que permiten la ejecución con garantías de operaciones criptográficas como el cifrado, la firma digital o el no repudio de transacciones electrónicas.
Pensando en la propia seguridad del funcionamiento de una PKI hay varios "talones de Aquiles" que deben ser muy bien protegidos y controlados para garantizar la fiabilidad del proceso que serían los siguientes puntos:
- Certificado Raiz, dado que es el elemento que otorga confianza al resto de certificados al ser usado para firmar certificados generados con dicha entidad de confianza, es el corazón del sistema de confianza que se monta con una PKI.
- Autoridades de registro porque son los ojos y los verificadores reales de toda la información que posteriormente va a firmar la Autoridad de certificación. Habitualmente es el punto de control donde se coteja la información que acredita o autentica al Organismo o persona respecto de los datos que figurarán en el certificado digital que firmará la autoridad raíz. Por tanto, si esta pieza falla, se pueden generar certificados digitales que siendo validos, no se correspondan con datos veraces.
- Las CRL o Autoridades de Validación porque son el punto de chequeo en tiempo real de la validez o no de la información que se presenta en un certificado digital. Se supone que una de las importantes ventajas de las tecnologías PKI es que permiten en tiempo real las comprobaciones de veracidad de la información.
- Entidades de certificación "Juan Palomo" que ya fue objeto de un post en la entrada "Prestadores de servicios de certificación "Juan Palomo". El funcionamiento de las Entidades de certificación está avalado por la Ley 59/2003 de Firma Electrónica que establece desde el punto de vista legal quienes pueden ser "entidades de prestación de este tipo de servicios" y determinan ciertas condiciones a este tipo de Organismos que van a "generar confianza" para garantizar su fiabilidad. No se prohibe a nadie que lo sea pero "SI" se regula que deben como mínimo tener para poder dar estos servicios. Sin embargo, ha sido frecuente la instalación y uso de certificados "raíz" en sitios Web (para ahorrarse unos euros) que no están avaladas por nadie y que no aparecen dentro del conjunto de "Entidades Raiz" que por defecto vienen en los navegadores preinstalados. Algunos de estos casos también los documenté en su momento en los post "La e-Administración dando mal ejemplo aunque por suerte casi todos los casos ya se han ido solucionando (pero en su momento se podía acreditar que no era así como aparece en las capturas de pantalla del momento). La lista de prestadores autorizados figura en el Ministerio de Industria, Comercio y Consumo. Para los que en este momento se vean sorprendidos por esta afirmación, pueden acudir a la Web del Ministrrio y comprobar cómo la Ley 59/2003, de 19 de diciembre, de firma electrónica establece en su artículo 30, y disposición transitoria segunda, que los prestadores de servicios de certificación deberán comunicar al Ministerio de Industria, Turismo y Comercio, sus datos de identificación, los datos que permitan establecer comunicación con el prestador, los datos de atención al público, las características de los servicios que vayan a prestar, las certificaciones obtenidas para sus servicios y las certificaciones de los dispositivos que utilicen. Esta lista puede ser consultada en esta dirección.
- No verificación de la validez del certificado. Este es quizás el error más común y principalmente debido al modelo de negocio montado por la FNMT que en su momento, cuando todos los navegadores no hacían las comprobaciones pertinentes respecto a la validez del certificado pasaba completamente desapercibido pero que actualmente es origen de error en el acceso en casi todos los navegadores, obligando al usuario a generar una excepción. La esencia del buen funcionamiento de una PKI se basa en esa comprobación en tiempo real de la corrección del certificado. De hecho, estos mecanismos inicialmente se basaban en listas de certificados revocados que había que descargar y actualmente se implementan mediante el protocolo OCSP de verificación en tiempo real. Sin embargo, no todos los prestadores permiten el acceso a sus servidores OCSP (La FNMT no por ejemplo) y creo que cargarse eso es cargarse la mitad de los beneficios que aporta este mecanismo de seguridad y pone en riesgo la fiabilidad de estos sistemas.
De todo esto hay dos lecciones que debieran aprenderse:
- Las autoridades de registro tienen una responsabilidad altísima en el buen funcionamiento de la PKI y por tanto, debe tratarse como un punto crítico de la infraestructura. Su personal debe estar adecuadamente entrenado y debieran desplegarse las mínimas necesarias para dar un buen servicio dado que el compromiso de una de estas autoridades puede poner en peligro toda la infraestructura (Si llegado el caso no puede saberse cuales son certificados originales y cuales falsificados). Sin embargo, por lo que he podido vivir personalmente, no parece dársele la importancia que tienen por parte de las Prácticas de Certificación de muchos prestadores, cosa que no ocurre con el DNI-e que obliga a que las autoridades de registro estén en comisarías.
- Los mecanismos de validación en tiempo real deben estar accesibles y configurados por defecto para que sean utilizados. Es la manera de reducir la "ventana de exposición" una vez que hay problemas con los certificados y por tanto, cuanto más se trabaje en tiempo real menos serán los posibles agujeros a explotar. Pensar que estas entidades son también empleadas para verificar que los certificados no están caducados y que su no uso hace que tanto certificados revocados como caducados puedan seguir siendo usados (aunque originalmente no son ya legítimos).
Publicado por Javier Cao Avellaneda en Seguridad de la informaciòn.
Quizás no sea suficientemente conocido el sistema de cifrado de archivos o carpetas incluido en los sistemas Windows bajo el nombre de EFS (Encryption File System).
La manera de proceder para cifrar información contenida en una partición NTFS no puede ser más sencilla y transparente para el usuario, que ni siquiera tiene que crear o recordar una contraseña para cifrar y descifrar los archivos.
Vamos a describir primero los pasos a seguir para cifrar el contenido de una carpeta (licencias) donde guardamos una copia de archivos de licencias de software.
1. Desde el explorador de archivos seleccionamos la carpeta a cifrar (en nuestro ejemplo "licencias") y pulsamos el botón derecho.
2. Pulsamos sobre opciones avanzadas
3. Marcamos el checkbox "cifrar contenido para proteger datos"
4. Aplicamos el cambio a la carpeta seleccionada y a todos las subcarpetas y archivos que contiene.
5. Al pulsar sobre aceptar en las pantallas siguientes, la carpeta ha quedado cifrada y como referencia es mostrada en color verde.
Para el usuario, el acceso a la carpeta y a los archivos que contiene es completamente transparente y de manera automática cualquier nuevo archivo o carpeta que sea añadido a la carpeta inicial (licencias) será cifrado.
Ahora bien, algunas de las preguntas que podemos platearnos pueden ser:
• ¿Están realmente cifrados los archivos?
• Si copiamos uno de estos archivos a un pendrive o lo enviamos por correo electrónico, ¿el archivo se copia o envía cifrado?
• ¿Cómo podrá entonces descifrarlo su destinatario?
La respuesta más general a estas preguntas sería entender que en realidad el sistema EFS "no cifra el archivo en sí", y su función es proteger el acceso al archivo para cualquier otro usuario que no sea el que realizó el proceso.
Por ello es muy importante tener en cuenta que si el archivo se copia a una partición no NTFS, una memoria USB o se envía por ejemplo por correo electrónico, ¡el archivo se descifra antes de realizarse la copia o movimiento! por lo que deja de estar cifrado.
Sin embargo, si iniciamos sesión con un usuario diferente o sin iniciar sesión, montamos en otro equipo el disco duro que contiene la carpeta cifrada, ¡no podremos recuperar su contenido! y solo inciando sesión en el sistema con el mismo usuario será posible acceder a la información.
¿Y si alguien tuviera acceso a nuestro equipo (por pérdida o robo del mismo) y consiguiera iniciar sesión como administrador a través de alguna utilidad en LiveCD de restablecimiento o eliminación de la contraseña del administrador?
En esta situación cabe pensar que, una vez de tener los permisos de administrador, bastaría con resetear la contraseña del usuario que aplicó el cifrado para así poder iniciar sesión con esa cuenta de usuario y acceder de forma transparente a la carpeta cifrada ¿No?.
El sistema EFS está preparado para prevenir esta situación, de manera que si se detecta un "forzado" del cambio de la contraseña del usuario (esto es, no es el propio usuario quien ha actualizado su contraseña) !No es posible acceder a los datos cifrados por el usuario hasta que se restaure la contraseña inicial del usuario en el momento del proceso de cifrado!.
¿Cómo funciona entonces EFS?
El cifrado EFS se basa en la combinación del cifrado simétrico, utilizando una clave para cifrar y descifrar el archivo y protegiendo esta clave mediante la utilización de cifrado asimétrico (clave pública/privada) mediante la generación automática de un certificado digital emitido a nombre del usuario.
Así, la primera vez que en nuestro equipo ciframos una carpeta o archivo, se produce el proceso siguiente:
1. Se genera una clave que se utilizará para el cifrado simétrico del archivo (con algoritmo AES de 256 bits), esta clave se llama FEK (File Encryption key) y se almacena físicamente con él.
2. Esta FEK es a su vez cifrada con la clave pública del usuario.
La claves públicas y privadas del usuario se generan de forma transparente la primera vez que se cifra un archivo y son registradas en un certificado emitido a nombre del usuario y almacenado en el almacen de certificados “personal”. Los certificados registrados son accesibles desde la consola certmgr.msc
o bien desde las opciones incluidas en cualquier navegador.
Es importante tener en cuenta que es este certificado el que nos permitirá acceder a la clave simétrica generada por el sistema utilizada para cifrar/descifrar el archivo, por lo que si borramos este certificado ¡No podremos descifrar los archivos! a menos que hayamos realizado una copia de seguridad del certificado.
Este proceso de copia de seguridad del certificado puede realizarse desde la consola anterior (certmgr.msc) desde la opción “Todas las tareas-->Exportar” accesible con el menú del botón derecho sobre el certificado y seleccionando la opción “exportar clave privada”.
o a partir de Windows 7 mediante el asistente accesible desde el menú lateral de cuentas de usuario:
El fichero exportado tendrá la extensión .pfx (personal file exchange) y por seguridad lo guardaremos fuera del propio equipo (aunque su importación queda igualmente protegida por la necesidad de utilizar una contraseña definida por el usuario en el momento de la exportación).
De esta manera se protege información confidencial almacenada en nuestro equipo aplicandose el principio de SSO (Single Sign On) de forma que no sea necesario recordar otra contraseña o realizar otra segunda autenticación para descifrar los archivos, ya que simplemente por acceder al sistema con nuestra cuenta de usuario y contraseña tendremos un acceso transparente a nuestros archivos cifrados.
Una vez más debemos insistir en la importancia de seleccionar una contraseña larga y compleja para nuestra cuenta de usuario (se recomienda un mínimo de 12 caracteres que combinen letras, números y algún carácter especial), ya que esta contraseña será la única barrera para acceder al sistema y con ello a los archivos cifrados con EFS.
Juan Carlos Rodríguez
Responsable S21sec university
http://blog.s21sec.com/2011/03/tip-seguridad-3-como-proteger.html
