Cita

"Those who are willing to pay a penny of security for a penny of usability will eventually have neither"

01 diciembre 2015

Ciclo de vida en la gestión de incidentes: triage

 
Vimos en el post anterior que entre los servicios reactivos de un ERI se encuentra la respuesta a incidentes. Ésta se desarrolla en varias etapas y es cíclica:
- Primero está la fase de preparación y prevención: aquí podemos incluir la formación y concienciación del personal (tanto de los implicados en la resolución de incidentes, como de los usuarios) y la puesta en marcha y revisión de los procedimientos adecuados.
- Detección y triage de incidentes: se pueden utilizar diversos mecanismos para detectar los incidentes, pero siempre habrá que comprobar en qué consisten porque pueden darse falsos positivos. Además, no todos los incidentes tendrán el mismo impacto en la organización.
- La contención: evitar que el incidente se propague, minimizando sus daños. Simultaneamente, se hará un análisis del mismo para ver qué ha ocurrido, por qué y qué implicaciones tiene.
- La recuperación: tratar de revertir en la medida de lo posible los daños y conseguir que el sistema continúe o vuelva funcionar con normalidad.

- Aprendizaje y mejora: después de todo lo anterior, debemos sacar algunas conclusiones para ver qué ha ido mal y cómo se puede mejorar en la organización; ya que la seguridad no es un producto, sino un proceso continuo. Es por ello que, realimentándose de esta fase, se inicia de nuevo la fase inicial de preparación y prevención frente a futuros incidentes.



La fase de triage es muy importante porque consiste en la clasificación y priorización de los incidentes de seguridad, para determinar la asignación de recursos. Es esencial cuando éstos son limitados, de modo que se haga una buena gestión de ellos; de este modo, los incidentes que puedan llegar a tener un mayor impacto se resolverán antes. El propósito es determinar la siguiente información: ¿se trata realmente de un incidente de seguridad?, ¿de qué tipo de incidente se trata?, ¿cuál es su gravedad?, ¿cuál es el impacto potencial?, ¿qué recursos serán necesarios para atenderlo?

Consiste en tres fases: verificación, clasificación inicial y asignación.

- En la verificación se analiza el incidente para ver si se trata o no de un falso positivo.

- Si se determina que se trata de un incidente real, se hará una clasificación inicial del mismo para determinar qué tipo de incidente es (contenido abusivo, código dañino, obtención de información, intrusiones, violación de las políticas de seguridad, denegación de servicio, confidencialidad, integridad, fraude, etc.), cuál es su gravedad, el posible impacto, origen (externo o interno), categoría de los sistemas afectados, perfiles de los usuarios afectados, si se trata de un ataque dirigido o no, etc. En un principio puede que no sea posible responder a todas esta preguntas totalmente, pero hay que hacer una estimación inicial para poder pasar a fase siguiente.

- Asignación de recursos: en función de la información anterior, se asignarán los recursos (personas, tiempos y otros) dedicados a la resolución del incidente. Los incidentes no deben resolverse según van llegando, sino que se dará prioridad a aquellos que puedan tener un mayor impacto en la seguridad del sistema, según la criticidad de los recursos afectados y teniendo en cuenta la gravedad de la amenaza implicada.


En un futuro post, explicaremos más en detalle en qué consiste la fase de análisis.


Referencias:




16 noviembre 2015

Servicios de un Equipo de Respuesta a Incidentes (ERI)






Los equipos de respuesta a incidentes existen en el ámbito nacional, pero también pueden existir dentro de una organización. Por supuesto, también hay organizaciones internacionales en las que equipos de diversos países colaboran e intercambian procedimientos e inteligencia.

Los servicios que ofrece un ERI pueden clasificarse en preventivos, reactivos y de gestión y están bastante bien descritos en el Handbook for Computer Security Incident Response Teams (CSIRTs). 2003. Moira J. West-Brown et al.

Por citar algunos ejemplos, podemos incluir entre ellos los siguientes:

- Preventivos:

1) Vigilancia tecnológica: obtener información en foros, blogs, listas de correo, etc. para ver cómo aplicarlo a la seguridad de la organización, implementando medidas a medio-largo plazo.

2)Auditorías: comprobar que la infraestructura cumple con los estándares y políticas de seguridad; encuestas y entrevistas a los usuarios y administradores para ver si conocen y siguen las buenas prácticas de seguridad; escaneos de vulnerabilidades;

- Reactivos:

3) Alertas de seguridad (aviso a los usuarios): información sobre ataques, vulnerabilidades, código malicioso, phishing, etc; con recomendaciones sobre cómo actuar.

4) Respuesta a incidentes: análisis (análisis de los sistemas, análisis forense), contención, asistencia y coordinación para la resolución de incidentes (presencial o a distancia).

5) Gestión de vulnerabilidades: análisis de vulnerabilidades de hardware y software, informe de riesgos, plan de acción.

- De gestión:

6) Análisis de riesgo: para nuevos sistemas y procesos y analizando amenazas y ataques para los existentes.

7) Plan de contingencia: cómo responder a los incidentes de manera que permita la continuidad del negocio.

8) Concienciación y formación de los usuarios y los técnicos: mediante seminarios, talleres, cursos, etc.

En próximas entradas analizaremos algunos de ellos más en detalle. También podéis leer lo que se publica al respecto en el blog de Eleven Paths.

03 noviembre 2015

OSINT y privacidad



El OSINT (Open Source INTelligence o Inteligencia de fuentes abiertas) consiste en la recopilación de información, para su posterior análisis, de fuentes de acceso público: foros, redes sociales, periódicos... En general, en lo que nos afecta como usuarios del ciberespacio, todo aquello que pongamos online y a partir de lo cual otros puedan obtener información sobre nosotros y extraer conclusiones.

Desde el punto de vista de los analistas, esto es algo fantástico. Pero desde el de la persona (u organización) analizada puede no serlo tanto. Quizá estemos dando demasiada información sobre nosotros mismos o los datos relacionados puedan llevar a extraer conclusiones que, de algún modo, nos perjudiquen. Eso hace que algunos sujetos, preocupados por proteger su identidad digital, se pregunten: ¿cómo defendernos del OSINT?


Pues la realidad es que no es posible hacerlo totalmente; ya que, por muy cuidadosos que seamos, no podemos evitar que sean otros los que suban a la red información sobre nosotros. Por ejemplo: las típicas fotos de facebook y los perfiles ocultos que éste crea sobre gente que ni siquiera tiene cuenta en esa red social. Además, nunca podemos estar totalmente seguros de qué trazas estamos dejando. Éste es un mundo tan complejo, que siempre se descubren nuevos hilos.

No obstante, hay consejos que pueden ser útiles y que consisten en controlar la creación activa de la huella digital y en intentar controlar también la pasiva:

La creación activa de la huella digital es aquello que dejamos conscientemente en Internet. Y podemos controlarlo mediante el uso de:
  1. Sentido común: no poner fechas de nacimiento completas en los perfiles de usuario, no anunciar cuándo nos vamos de vacaciones, no incluir datos o fotos de menores de edad, no dejar que éstos usen las redes sociales sin la supervisión de un adulto, comprobar con los motores de búsqueda que no aparezcan más datos sobre nosotros que los deseados...
  2. Control de acceso a recursos: utilizar contraseñas fuertes, usar un doble factor de autenticación (típicamente, envío de SMS al móvil) o poner un Latch si está disponible para el recurso en cuestión, utilizar los mecanismos de privacidad proporcionados por la aplicación que estemos usando, y el uso de técnicas criptográficas son algunas de las cosas que pueden ayudarnos a evitar que un tercero tenga acceso a datos o recursos no deseados relacionados con nuestra identidad digital.
  3. Perturbación de datos: consiste en modificar los datos personales para aumentar su ambigüedad (generalización), reducir el nivel de detalle de la localización del usuario, etc. Es decir: dar los datos mínimos imprescindibles (quizá solo el nombre y no los apellidos, o el uso de un seudónimo) y no tener activada la función de geolocalización, por ejemplo.
Por otro lado, la creación pasiva de la huella digital es lo que dejamos en Internet sin ser conscientes de ello. Podemos controlarla (hasta cierto punto) mediante la utilización de canales anónimos como los siguientes:
  1. Uso de un nodo central de confianza: VPN comerciales, proxies del tipo Crowds y UUP (Useless User Profile) y remailers como Anon.penet.fi (actualmente en desuso), Cypherpunk y Nym).
  2. Mix Networks: consisten en un grupo de nodos interconectados que forman una red en la que cada uno oculta la entrada y salida de información mediante técnicas criptográficas. Las más conocidas quizá sean Mixmaster y Mixminion.
  3. TOR: red de comunicaciones distribuida de baja latencia que mantiene el anonimato de las IP origen y destino en los nodos intermedios mediante transmisiones cifradas por capas. Generalmente se combina con el uso de Privoxy en el navegador para eliminar elementos de rastreo de navegación, como huella del navegador, cookies, etc.
  4. I2P: A diferencia de TOR, en vez de utilizarse circuitos de nodos intermedios, se utilizan túneles (conjunto de nodos) unidireccionales (de entrada o de salida) efímeros: el cliente estable un túnel de salida que se comunicará con el túnel de entrada del servidor; éste enviará la respuesta utilizando su propio túnel de salida que se comunicará con el túnel de entrada del cliente. Esto puede complicarse todo lo que se quiera, utilizando varios túneles de salida en paralelo o usando el mismo túnel para comunicar con distintos clientes. Esto aumenta la velocidad y favorece la privacidad. Aunque el uso descentralizado de la base de datos de nodos puede generar otros problemas. I2P no está tan implantado y cuenta con menos ancho de banda que TOR. (www.genbeta.com/actualidad/i2p-la-nueva-generacion-de-la-deep-web)

Llegados a este punto, podríamos plantearnos si es realmente necesario defenderse del OSINT. Ser conocidos no tiene siempre por qué ser malo; ya que nos pueden llegar experiencias enriquecedoras (y quién sabe si hasta alguna oferta de trabajo interesante) gracias a que somos visibles en la red.

Podemos hacer que el OSINT obre a nuestro favor: si en vez de tratar de desaparecer totalmente de la red, intentamos que no aparezca lo que no queramos que sea conocido y tenemos cuidado de no dar una mala imagen de nosotros mismos, resaltando nuestros puntos más favorables y fomentando el intercambio de información positiva con otros internautas.

Y quizá, después de todo, veamos que el OSINT no resulte tan malo.



26 octubre 2015

La seguridad de los datos en la nube



Cada vez es más frecuente que las compañías suban sus datos a "la nube". Conviene recordar que esto no es algo etéreo, libre de problemas; sino, como suele decirse: "la nube es tan solo el ordenador de otra persona". Por ello: ¿qué medidas de seguridad es necesario contemplar en este particular entorno?

Cuando una organización lleva sus ficheros a la nube, el responsable de seguridad seguirá siendo aquel nombrado el dueño éstos. Pero aquel ahora delegará muchas de sus funciones en el personal de la compañía Cloud, dado que es ésta la que controla la infraestructura y/o las aplicaciones.

¿Qué riesgos existen en este caso? El más evidente quizá sea no tener la certeza de dónde se guardan los datos. Una compañía europea puede tener, por ejemplo, sus servidores ubicados en la India. Así, se consideraría que hay una transferencia de datos y se debe estar seguro de que se cumple con los requisitos de la LOPD: por ejemplo, comunicar dicha transferencia para que la autorice, en caso de ésta se haga hacia algún país fuera de la UE o de aquellos con nivel de seguridad equivalente (Artículos 33 y 34 de la LOPD; Artículo 29 de la Directiva 95/46/CE, en el Dictamen sobre Cloud Computing 05/2012). No sería aceptable si implica transferir los datos a una localización que no esté entre las aprobadas por la AGPD, a menos que ésta lo autorice expresamente. Lo que incluye Estados Unidos, ahora que está suspendido el Safe Harbour con ellos.

Las medidas de seguridad a implantar dependerán del tipo de nivel exigido por la naturaleza de los datos según la LOPD (alto, medio, básico); y deberán quedar fijadas en el contrato entre el responsable de seguridad y el responsable del tratamiento en la empresa de cloud (art. 12.2 de la LOPD). En cualquier caso, la nube no es muy aconsejable para aquellos datos que tengan que tener un nivel de seguridad medio o alto.

Por otra parte, si la empresa que ofrece el servicio comparte recursos con otras compañías, la información puede quedar comprometida en su confidencialidad y/o en su integridad. También podría verse comprometida la disponibilidad de los mismo si el sistema cloud se cae.

En general, son buenas prácticas, cifrar la información en la base de datos y en tránsito; además de tener un sistema de control de acceso y de autenticación de usuarios. Cifrar también las copias de seguridad y tener una replica segura de datos para que estén siempre disponibles. Se deberán incluir además pruebas sobre la base de datos que verifiquen la integridad de la misma. Y programar auditorías a realizar por un tercero debidamente certificado.

Todo eso debe completarse con acuerdos de confidencialidad que garanticen que no accederá a los datos nadie que no esté autorizado para hacerlo. Y que, al finalizar el contrato, los datos se borran y no quedan copias no autorizadas en ningún sitio. El contrato deberá incluir además una clausula de responsabilidad o algún tipo de seguro en caso de que los datos se pierdan, modifiquen indebidamente, haya alguna fuga de información o se infrinja la LOPD de algún modo. De esto modo, el responsable de seguridad, aún siendo el principal responsable al respecto, podrá repercutir también dicha responsabilidad en la empresa como responsable subsidiario.

Éstas son solo algunas de las cosas a tener en cuenta. Y surgirán más, posiblemente, a medida que la práctica se va generalizando y aparezcan situaciones que antes no se preveían.

Referencias:

- «Almacenamiento Seguro en Nubes Públicas y Privadas». Ponencia de D. Jorge Dávila, en las VII Jornadas STIC del CCN-CERT (documento de difusión limitada).

- «Informe de Utilización del Cloud Computing por los despachos de abogados y el derecho a la protección de datos de carácter personal» de la AGPD:

- «Guía para clientes que contraten servicios de Cloud Computer»:

19 octubre 2015

Seguridad de las bases de datos










Las bases de datos son el último bastión de defensa de una organización frente a los ataques del exterior. A pesar de lo cual, no siempre son percibidas como tal y no se les da la debida importancia. En las bases de datos se encuentran normalmente los activos más valiosos de una compañía: datos personales de mucha importancia, relaciones con clientes y proveedores, datos bancarios y financieros, etc. Pero se tiende a pensar que lo importante es proteger el perímetro y se olvida a veces proteger las bases de datos con el mismo cuidado. 

¿Por qué es esto así? Quizá sea porque la seguridad perimetral, primera linea de defensa, lo es de una manera más activa (filtros, alertas, etc.), mientras que la seguridad de las bases de datos depende más del diseño y cada caso es diferente. Requiere más esfuerzo diseñar pensando en la seguridad que limitarse a aplicar estándares. Esfuerzo que se incrementa si hay que estar pendientes de andar actualizando y poniendo parches cada vez que se descubren vulnerabilidades en los productos utilizados.

Podemos poner algunos ejemplos recientes en los que la seguridad de las bases de datos parece haber sido descuidada:

El primero de ellos es el famoso caso de Ashley Madison: entre los datos filtrados se encontraron documentos que muestran que la compañía era consciente de tener problemas de seguridad que debía resolver.

Otro caso más reciente es el de Patreonal parecer, el acceso y la fuga de datos pudo hacerse porque una versión de la web con un elemento de debug (werkzeug) acabó en producción, fuera del firewall.
Lo peor es que, según la compañía «Detectify», aparecen en Shodan miles de sitios web con el mismo fallo.

Viene al caso, por tanto, hacerse eco de la nota del editor del SANS NewsBites Vol. 17 Num. 077: «It is not possible to expose an application to the Internet in such a way that it cannot be compromised at some cost to the attacker. That said, applications like eBay and Patreon that owe their very existence to the Internet must be held to a higher standard of security than those for which the Internet is merely incidental to their business strategy.».

Podemos concluir diciendo que, como recuerda aquí SANS, si tu negocio es internet, debes cuidar la seguridad en ella con mayor motivo que aquellos para los que internet es solo algo marginal. Y cuidar la seguridad de tu negocio en internet implica, en gran manera, cuidar la seguridad de tus bases datos, que, de un modo u otro pueden quedar expuestas aunque las escondas bajo capas y capas de protección perimetral.

10 octubre 2015

Ciberataques: por dónde van los tiros


Con ese título tuvo lugar un encuentro de profesionales organizado por la Revista SIC , cuyo propósito era analizar la tendencias en malware e ingeniería social y ver qué podemos esperar en un futuro. Para ello, se contó con la colaboración de dos expertos en ingeniería social y malware y de representantes de distintas empresas, cuyo negocio son las herramientas de seguridad, que compartieron con el público su dilatada experiencia en la materia. Al finalizar, tuvo lugar un coloquio entre todos los participantes, al que se unieron representantes de dos CERT españoles, como son el INCIBE y el CCN-CERT.

Ingeniería social y código malicioso

En esta primera parte, Carlos Fragoso y Andrés Tarascó compartieron con nosotros algunas ideas y anécdotas interesantes sobre la manera que tienen los atacantes de aproximarse al objetivo. Por ejemplo, el caso de un alto mando de defensa de Estados Unidos que recibió un correo urgente fingiendo venir de la escuela de su hija, comunicándole un problema (más información adjunta, por supuesto, y en el adjunto ya os podéis imaginar). Un modo ingenioso de llegar a un objetivo protegido, por un camino lateral. Algo que también puede hacer vulnerable a una organización es que se difundan su puntos débiles (por sabotaje o sin percatarse de ello). Carlos ha visto de todo y por eso, no le extraña saber que, además de las personas, otras vías de ataque pueden ser: el propio hardware o el firmware, la virtualización o el uso de estaciones 3G falsas en eventos importantes, entre muchos otros.

No sorprende entonces que Andrés dijera que cada tres meses borra todo su ordenador y lo instala de nuevo. Algo menos precavida es una empresa que reconoció saber que el 100% de las startups que había adquirido estaban comprometidas. Y es que, si tu organización o empresa absorbe a otras, te llevas también en el paquete el desgaste de seguridad de éstas tuvieran. Y si no, que se lo digan a Experian, pensé, recordando este artículo de Krebs

Sus consejos finales fueron: hay que concienciar a los usuarios en un lenguaje sin tecnicismos, "de tú a tú" y "cuidado con el todo gratis" (las cosas gratuitas a veces encierran grandes peligros).



Hallazgos y previsiones de la industria antimalware

Representantes de Blue Coat, FireEye, Fortinet, Kaspersky Lab, Palo Alto, Panda y Trend Micro nos explicaron cómo trabajan sus equipos para compartir inteligencia de ciberseguridad con la comunidad. El juego de la seguridad no consiste solo en comprar "cacharritos": las organizaciones necesitan una estrategia de inteligencia para saber, no solo que está siendo atacada, sino por quién y cómo responder; ya que el malware, por si solo, sin información de contexto, no aporta mucha inteligencia. Pero los expertos son difíciles de encontrar y caros de conservar. Como las muestras de malware van cambiando, es mucho más importante investigar y detener a la gente que hay detrás, cosa que hacen posible estos equipos, mediante su colaboración con las fuerzas del orden de los distintos países.

También nos explicaron algunas de las amenazas y tendencias que han visto en sus investigaciones y lo que piensan que pueda desarrollarse el próximo año. Por ejemplo:

Mucho del malware viene por los anuncios (web ads), con backdoors incluidas en el sitio web que se ejecutan sin conocimiento del administrador del mismo. Ni siquiera hace falta que el usuario haga click en ningún enlace. Solo por aparecer el anuncio, ya te infectas. (Un ejemplo que me viene a la cabeza es el de los sitios de descargas de pelis, infectados con un ransomware que está haciendo estragos en España). El ransomware en general está aumentando y seguirá llegando por fuentes varias. Kaspersky ha puesto a disposición de la comunidad una herramienta fruto de su colaboración con la policía holandesa: https://noransom.kaspersky.com

El 95% de las APTs empiezan por el phishing, con ejemplares que son de diseño a veces muy básico, pero eficaces y que pasan desapercibidos para los antivirus.

Qué podemos esperar: más ingeniería social (dado que funciona), aumento de ataques por el Internet of Things, aprovechamiendo de vulnerabilidades en el software de seguridad, más arrestos de cibercriminales, más ataques a pagos móviles, otro país europeo se añadirá a la lista de los "pillados in fraganti" espiando, se mantendrá la tendencia vista en Sony y Ashley Maddison de entrar a robar datos y diseminarlos para intentar destruir totalmente una compañía.

¿Se cumplirán sus predicciones?

Debate


Recomendaciones realistas de los expertos para que nos preparemos para lo que viene: concienciación continua de los usuarios, pero sin dejarles toda la responsabilidad a ellos; a la concienciación hay que añadir el forzar unas políticas de uso seguro, como tener puestos de trabajo con privilegios mínimos; el concepto de "zero trust" (en español: no te fies ni de tu padre) y asumir que no somos autosuficientes y que hay que compartir inteligencia. Y por encima de todo: asumir que, por mucho que hagamos para protegernos, lo inevitable va a ocurrir y tenemos que estar preparados para reaccionar al respecto, teniendo unos procedimientos bien establecidos y guardando todos los logs necesarios. Un problema habitual es que cuando se va a investigar un incidente, se encuentra uno con que no hay bastantes logs o que se ha limpiado el equipo sin hacer antes una imagen.

Esperemos que todas estas ideas y buenos consejos puedan ayudarnos durante el próximo año a defendernos de los ciberataques que nos esperan.

Fue un placer desvirtualizar a algunos de mis seguridores y volver a charlar con Carlos, a quien tuve el gusto de tener como profe en mi último curso.

Muchas gracias a la Revista SIC por invitarnos a tan interesante iniciativa. ¡Y por guardarme el paraguas olvidado! ;)

Nos vemos en la próxima. Stay safe.



20 septiembre 2015

La propiedad intelectual de las bases de datos



El Texto Refundido de la Ley de Propiedad Intelectual (TRLPI) establece un doble sistema de protección legal para las bases de datos:
Por una parte, se protege (en el Libro I) el derecho de autor de la base de datos como una creación consistente en colección de datos. Es decir: la estructura en la que se almacenan los mismos. Esta protección no abarca el contenido de la misma (aunque éste pueda estar a su vez protegido, como veremos después). Esto queda claramente reflejado en el art. 12, que otorga a “las bases de datos que por la selección o disposición de sus contenidos constituyan creaciones intelectuales” una protección que “se refiere únicamente a su estructura en cuanto a forma de expresión de la selección o disposición de sus contenidos, no siendo extensiva a éstos”.

Por otra parte, el Libro II, en su Título VIII, explica cómo aplica el derecho “sui generisa las bases de datos. El art. 133, en su punto 1, dice que este derecho “protege la inversión sustancial, evaluada cualitativa o cuantitativamente, que realiza su fabricante ya sea de medios financieros, empleo de tiempo, esfuerzo, energía u otros de similar naturaleza, para la obtención, verificación o presentación de su contenido”. Así, en este caso, lo que se protege es la inversión (del tipo que sea) que haya hecho aquel que ha dotado de contenido a la base de datos. Este derecho comprende la falcultad de «prohibir la extracción y/o reutilización de la totalidad o de una parte sustancial del contenido de ésta», siempre que ello represente «una inversión sustancial». El fabricante es, según el punto 3.a, «la persona natural o jurídica que toma la iniciativa y asume el riesgo de efectuar las inversiones sustanciales orientadas a la obtención, verificación o presentación de su contenido». Es decir: que corresponde al fabricante la facultad de extraer los datos a otro soporte. Y dicho derecho se aplicará con independencia de que la propia base de datos esté protegida por el derecho de autor (art. 133.4).


Pongamos un ejemplo para entenderlo mejor:

Una discográfica contrata a una empresa de software para que diseñe una base de datos documental en la que poder almacenar información sobre los distintos discos que ha ido publicando, sus autores, etc.
En ese caso, el titular del derecho de autor sobre la base de datos en sí sería la empresa de software que la ha diseñado. Pero el titular del derecho «sui generis» es la discográfica, puesto que es la que ha invertido recursos para dotarla de contenido. Y, por lo tanto, es esta última la que, como fabricante, tiene el derecho de llevarse lo datos a otra base de datos, si así lo desea. Y, además, este derecho la protege frente a terceros que quieran copiar su contenido, siempre que una parte sustancial del mismo esté implicada.

De todos modos, es un tema un poco complejo y aconsejo acudir a la fuente legislativa y consultar con un abogado en caso de duda.





14 septiembre 2015

Correos electrónicos y privacidad

He aquí algunas cosas que no se pueden hacer con los correos electrónicos por ir contra la ley, al violar la privacidad de un sujeto.

Ejemplo nº 1: Espiar los correos de tu pareja (aunque creas que te está engañando o que su cuenta haya aparecido en el dump de Ashley Madison). Es un delito contra la intimidad, según el artículo 197 del Código Penal («descubrimiento y revelación de secretos»), que en su apartado  1 dice «el que, para descubrir los secretos o vulnerar la intimidad de otro, sin su consentimiento […] intercepte sus telecomunicaciones […] será castigado con las penas de prisión de uno a cuatro años y multa de doce a veinticuatro meses».


Los requisitos para que haya delito son que se haga sin el consentimiento del otro y que sea para vulnerar su intimidad. Las penas se aplican en su mitad superior si existen los agravantes de:

- Difundirlos a terceros (apartado 4): por ejemplo, si se los pasas a un detective para que lo investigue.
- Afectar a la vida sexual de la otra persona (apartado 5).
- Tratarse del cónyuge (apartado 7).



Ejemplo nº 2: Instalar un píxel de rastreo en los correos publicitarios para saber si el destinatario lo ha leído. Independientemente de si es legítimo mandarle el correo (si previamente manifestó por escrito su conformidad sobre el envío de publicidad). Este elemento de rastreo se considera una cookie afectada por el artículo 22.2 de la Ley de Servicios de la Sociedad de la Información (LSSI) de la que ya hablamos en otro post.

Tampoco valdría un sistema opt-out consistente en enviarle un correo antes, informándole de que los correos que se le vayan enviando a continuación van a ser rastreados. La razón es que el afectado no ha dado su consentimiento inequívoco para ello, como marca el citado artículo. Para ello se requeriría un sistema opt-in, en el que se mandara un correo preguntándole si le importa ser rastreado y, solo en caso de que responda afirmativamente, hacerlo. Además, habría que informarle el medio para revocar dicho consentimiento, en armonía con el art. 51 del RDLOPD.





24 agosto 2015

¡"A Penny of Security" tiene cookies!



Los que accedéis a este blog desde algún país de la Unión Europea, os habréis dado cuenta que ahora, cuando entráis, aparece un mensaje avisando del uso de cookies. Es un mensaje que pone Blogger (Google) en todos sus blogs para cumplir con la normativa española y europea.

Una cookie es un tipo de archivo que se descarga en el terminal de un usuario, normalmente cuando navega por una web, con el propósito de almacenar datos que podrán ser utilizados con distintas finalidades; por ejemplo, que el sitio web "recuerde" información sobre la visita del usuario (como sus preferencias de idioma); también se utilizan a menudo con fines publicitarios.

De acuerdo con el art 22.2 de la LSSI: "Los prestadores de servicios podrán utilizar dispositivos de almacenamiento y recuperación de datos en equipos terminales de los destinatarios, a condición de que los mismos hayan dado su consentimiento después de que se les haya facilitado información clara y completa sobre su utilización, en particular, sobre los fines del tratamiento de los datos, con arreglo a lo dispuesto en la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal."

Como la casuística es variada y algunas cookies están exentas de la obligación de avisar, la Agencia de Protección de Datos ha publicado una guía sobre el uso de las mismas. Según ésta, están exentas aquellas cookies cuya caducidad esté relacionada con su finalidad. Por ejemplo: las cookies de sesión (que se utilizan para que el usuario no tenga que logarse a cada vez mientras navega por las distintas páginas del sitio web), ya que, una vez cerrada la sesión, desaparecen del dispositivo. También están exentas las cookies de tipo "carrito de la compra", que sirven para guardar los artículos que va seleccionando en una tienda online. Esto es así porque son necesarias para poder prestar un servicio solicitado expresamente por el usuario (hacer la compra). Todavía hay algunas más que quedarían exentas, pero no quiero extenderme demasiado en ello. Podéis leer el texto completo en la referencia.

Los avisos de las cookies se deben hacer utilizando el "sistema de información por capas", que  consiste en informar del uso de cookies en dos fases:
- Al entrar en la web se informa del uso de cookies (propias y/o de terceros), de la finalidad de éstas y cómo el usuario presta su consentimiento (por ejemplo, al seguir navegando). En el caso de este blog, es el mensaje que podéis ver nada más entrar y si pulsáis "ENTENDIDO", significa que aceptáis las cookies. Junto a este primer mensaje, se debe, además, incluir un enlace a la segunda capa de información. En este blog accedéis a ella cuando pulsáis sobre "MÁS INFORMACIÓN".
- En esta segunda capa aparecen datos sobre: la definición y función de cookies, el tipo de cookies utilizadas y su finalidad, quién utiliza la información recogida con ellas, y la forma de desactivarlas o eliminarlas.

Por otra parte, habréis observado que han desaparecido el enlace al periódico y a los tuits. Esto es así porque no puedo estar segura de que los complementos que utilizo para enlazarlos no estén usando también algún tipo de cookie, lo cual me obligaría a modificar el mensaje de Blogger para avisarlo. He preferido no jugármela. Incumplir con la obligación de avisar del uso de cookies se considera una infracción leve, según el art. 38.4 de la LSSI. Y con la ley no se juega.


Más información:

 

15 agosto 2015

Auge y caída del Hotel Hilbert


Buenas,

He estado una temporada alejada de las redes y pantallas debido a una conjuntivitis vírica que me ha hecho sufrir bastante (tanto lidiar con los virus y al final me cae uno en el ojo). Para terminar de recuperarme, me fui de vacaciones, aunque no me alojé el en Hotel Hilbert, sino en otro hotel. Más que nada, porque eso de tener que andar cambiándose de habitación cada vez que llega alguien nuevo al hotel, como que no...

Pero es que, además, el Hotel Hilbert no pasa por sus mejores momentos. Si recordáis, en mi último post os decía que el personal del hotel se vio en un aprieto cuando llegaron unos turistas a los que no pudo dar acomodo. ¿Cómo pudo ser esto? Bueno, pues resulta que los turistas provenientes de Enterolandia comenzaron a contar a diestro y siniestro las maravillas del hotel. Esto lo hicieron no sólo los de su capital, Naturalandia, sino todos los otros que, a pesar de ser bastante negativos, no dejaban de hablar bien del hotel: total, en ningún otro sitio los habían tratado tan bien, acostumbrados ellos como estaban a que les miraran mal en todas partes (especialmente en los balances de cuentas, donde siempre los ponían colorados). Y así, sucedió que, por el boca a boca, la fama del hotel se extendió más allá de las fronteras de Enterolandia, llegando a los oídos de todos los números reales, particularmente de aquellos con decimales, que decidieron también visitar el hotel.

Como avanzadilla, se acercaron primero los números mayores que 0 y menores que 1. Y si la cosa pintaba bien, ya vendrían todos los demás. Pues resulta que se encontraron con la sorpresa de que ni siquiera ellos entraban en el hotel. ¿Por qué? 

La razón es muy sencilla: al intentar asignar a cada uno de esos números una habitación, estamos intentando establecer una correspondencia biunívoca entre algo que es contable (las habitaciones) y algo que no lo es: todos los números con decimales, donde siempre habrá números más pequeños que uno dado. En los casos anteriores era distinto: los números naturales, y los enteros en general, los podemos contar (otra cosa es que nunca acabemos de hacerlo) y podemos decir en qué posición (o habitación) va cada uno: 1 en la 1, el 2 en la 2 (o primero el 1, luego el -1, luego el 2, luego el -2, etc). En el hotel, sería como si el recepcionista dijera "vayan pasando". Pero ¿cómo se puede decir que vayan pasando los números con decimales? ¿Quién pasará primero? ¿el 0,1? pues parece que nos hemos olvidado del 0,01 (entre otros). Si queremos que pase ése primero, resulta que el 0,001 le dirá que se está colando.

Imaginemos que intentamos asignarles habitaciones con el siguiente método: asignaremos en cada habitación al número que tenga como dígito decimal en esa posición un 0. Así ya nos estaríamos dejando a todos aquellos que en esa posición tengan cualquiera de los dígitos de 1 a 9. Pero eso, la gerencia del hotel lo resolvió fácilmente haciendo obras y construyendo más plantas. Lástima que no les sirviera de nada. Al intentar asignar, por ejemplo la habitación número 4 de la 5ª planta a aquel número que tuviera un 5 en el 4ª dígito decimal, se encontraron con que había infinitos números que cumplían esa condición.

Total, un desastre. Los números con decimales se marcharon cabizbajos y contaron el fracaso a sus compañeros, que cancelaron las vacaciones previstas y se dedicaron a otras cosas: pi se fue de viaje a Egipto, donde ya lo conocían hace muchos años, e se puso a hacer logaritmos, phi se dedicó a los girasoles y las conchas y el resto de números dejó de considerar el Hotel Hilbert como un sitio cool y nunca más quiso volver. El hotel no puedo hacer frente a las deudas (que eran infinitas), entró en pérdidas y tuvo que cerrar.

Y es que, como decía Cantor, hay varios tipos de infinitos, unos más grandes que otros. (Por cierto: lo tomaron por loco). Aquella mítica frase de Buzz Lightyear (entrañable personaje de Toy Story) de "Hasta el infinito... ¡y más allá!" no tiene mucho sentido, porque lo que hay más allá del infinito sigue siendo el infinito. Habría quizá que cambiarla por "Hasta el infinito... ¡y aún más grande!". Pues más grande que un infinito (alef-0) es otro infinito (alef-1). 



Y colorín, colorado, este cuento se ha acabado. Deseo que os haya gustado este entretenimiento veraniego, un poco surrealista. Y para la vuelta al cole volveré ya con cosas más relacionadas con el mundillo este de la seguridad. Espero publicar cosas interesantes y que sigamos aprendiendo juntos.

Gracias por leerme.

Más información sobre los infinitos:


11 mayo 2015

Bienvenidos al Hotel Hilbert


Hoy vengo a hablaros del infinito. A lo mejor no tiene mucho que ver con la seguridad porque parte de la seguridad criptográfica se basa en la aritmética modular, que recuerda más a la cosmovisión de la antigua Grecia y el mito del eterno retorno (recuperado por los filósofos modernos y por Mátrix). Pero el caso es que me apetecía. Así es que, si me permitís el excurso (u off-topic, como dicen los anglos):

El infinito puede que no aparezca en criptografía, pero se encuentra en otras cosas (incluso en el corazón). A Einstein se le atribuye aquella frase de que "hay dos cosas infinitas: el universo y la estupidez humana; y no estoy seguro de la primera". Pero de lo que sí que estamos seguros es de que no existe un hotel infinito, con infinitas habitaciones. Salvo en la mente de Hilbert...

La circunstancia que me animó a contar esta historia se remonta a una conversación de café en la que (ya no recuerdo cómo ni por qué) dos de los contertulios empezaron a hablar del hotel de Hilbert, como de un hotel donde siempre cabe más gente. Y de pronto me vi con mi babi y mis coletas, frente a un encerado donde alguien, con una tiza en la mano, decía lo mismo. ¡Es que a mí esa historia ya me la había contado antes! Pero mi memoria no es infinita y las cosas del colegio ya se me han olvidado mucho. Así es que me puse a tratar de averiguar por mi cuenta de qué iba aquello. Y ésta es la historia, que aquí resumo. Herr Hilbert os da la bienvenida a su hotel:

El hotel tiene infinitas habitaciones, ocupadas por infinitos huéspedes. Entonces, llega un un turista más, preguntando si hay habitación para él. ¡Pues claro! le responde el recepcionista. Solo tienen cambiarse todos los huéspedes a la habitación siguiente a la que ocupan, dejando así libre la primera. ¿A dónde va el de la última habitación? Es que no hay última habitación. En un hotel infinito siempre habrá una habitación más.

El hotel Hilber se hace tan famoso por sus muchas comodidades (seguro que hasta tiene wifi) que pronto llega un autocar entero lleno de... infinitos turistas. ¿Cómo harán para alojarlos a todos? Muy fácil: todos los huéspedes tienen que cambiarse a una habitación cuyo número sea el doble de la que ocupan. Así solo estarán ocupadas las habitaciones pares y los recién llegados podrán alojarse en las impares.

Pero la fama del hotel sigue creciendo y a la siguiente temporada llega una excursión compuesta por infinitos autocares, llenos a su vez de infinitos turistas. Con el método anterior solo se podrían colocar los huéspedes de un autocar; y, como nunca se terminaría, no podrían empezar con el siguiente. Y si quisieran vaciar todos los autocares a la vez, en cada habitación de las que quedaran libres, tendrían que alojarse infinitos turistas (cosa que no podía ser, porque ninguno quería compartir habitación). La solución pasa por pedir a los huéspedes que ocupaban una habitación cuyo número sea potencia de un primo (esto de los primos ya recuerda algo a la criptografía) que se muden la habitación cuyo número corresponda con 2 elevado a la suya (así dejamos libres las impares otra vez). Luego, para repartir las habitaciones, se procede de la siguiente manera: numeramos los autocares utilizando números primos (que también son infinitos) y a cada turista dentro de ellos les asignamos un número impar. La habitación asignada a cada turista es la que lleva el número del autocar elevado al número del turista en cuestión. Así, por ejemplo, el turista nº 3 del autocar 5 irá a la habitación 125, que ya se habrá quedado previamente vacía por haberse mudado su huésped a la 2^125.

Hay otro método, que me parece más eficiente, explicado en el blog de microsiervos. No salen números tan grandes de habitación. Aunque, es verdad que, en un hotel infinito, ¿a quién pude importarle mucho eso?

Si no os ha quedado del todo claro, podéis ver el siguiente vídeo tan simpático:



Quiero dar también las gracias a FJV por prestarme el libro "Los secretos del infinito. 150 respuestas al enigma" que me ayudó a refrescar la memoria.

Pero no creáis que aquí termina la historia. Podéis pensar que menudo chollazo de hotel, que siempre cabe más gente. Pero la verdad es que, cuando llegó la siguiente excursión, el personal del Hotel Hilbert se vio en un aprieto porque fue incapaz de darles acomodo. Y es que, incluso dentro del infinito, todavía hay clases. Pero eso mejor os lo cuento otro día...



28 marzo 2015

Control de accesos


Con el control de acceso, dada una petición de recursos, se permite o deniega el acceso según ciertas políticas. Incluye mecanismos de autenticación, autorización y auditoría. Las políticas de acceso son un conjunto de reglas que determinan las acciones que un sujeto puede hacer sobre un objeto (lectura, escritura, modificación, borrado, ejecución).

Los tipos de control de acceso son: control de acceso obligatorio, control de acceso discrecional, control de acceso basado en roles y control de acceso basado en atributos.

En el control de acceso obligatorio o Mandatory Access Control (MAC) las políticas son evaluadas de forma centraliza (por ejemplo, en el núcleo del sistema) y el acceso a un determinado objeto dependerá de la sensibilidad de la información contenida en él y de la autorización formal que tenga el sujeto para acceder a ese nivel de sensibilidad.

El control de acceso discrecional o Discretionary Access Control (DAO) consiste en un conjunto de reglas de acceso que son definidas por los propietarios de los objetos. Entonces, las políticas lo que regulan son los procesos de gestión de privilegios entre los sujetos. Los privilegios se pueden representar mediante tablas de autorización, listas de control de acceso (ACL) o listas de capacidades.

Con el control de acceso basado en roles o Role-Based Access Control (RBAC) la gestión se simplifica, ya que, una vez asignados los permisos a roles, después solo habrá que asignar correctamente los roles a los distintos usuarios que se vayan incorporando al sistema. Aunque es el más utilizado actualmente, tiene algunas limitaciones que son solventadas por el control de acceso basado en atributos. Por lo que lo más probable es que este último se acabe imponiendo.

La ventaja del control de acceso basado en atributos o Attribute Based Access Control (ABAC) con respecto a los anteriores es que, además del rol, toma en cuenta otros atributos más dinámicos, como pueden ser: la relación de los usuarios con las distintas fuentes de información, el momento del acceso (fecha/hora), o la IP de origen. La políticas de acceso se definen estableciendo relaciones entre varios atributos. Este modelo refleja mejor la realidad, que puede ser cambiante.

Relacionado con ABAC está XACML, un estandar basado en XML que describe un access control framework y que proporciona un lenguaje para definir las políticas de acceso, el diálogo mantenido durante el control de acceso y la arquitectura formada por los diversos componentes que lo forman.

Más información:


Picadillo y sal para la seguridad de tus contraseñas


 


Hoy voy a explicar algunas maneras de proteger las contraseñas almacenadas y los métodos de ataque más frecuentes.
 
Un sistema que use «shadow passwords» (típicamente, Linux) no almacena la contraseña en el /etc/passwd, sino que guarda un hash de la misma en el /etc/shadow. En el primer fichero se almacerán datos como el nombre de usuario, su grupo, etc. Y tendrán acceso en modo lectura todos los usuarios. Mientras que al segundo podrán acceder solo los usuarios con más privilegios.

El hash, o resumen, es el resultado de aplicar a la contraseña una función unidireccional (MD5, blowfish, SHA256 i SHA512); de manera que a partir de la contraseña se puede calcular el resumen, para comprobar que la contraseña de acceso al sistema introducida es la correcta; però la inversa no es posible; por lo que aunque un atacante se hiciera con el /etc/shadow no podría (en teoría) obtener a partir de él las contraseñas. 

Pero el caso es que estas funciones, aunque unidireccionales, son deterministas: la misma entrada da siempre la misma salida; por lo que se podría hacer un ataque utilizando una lookup table: una tabla con hashes precalculados a partir de palabras de diccionario. El atacante que consiga acceso al shadow solo tendría que buscar en la lookup table a qué contraseña corresponde cada hash. La ventaja que tiene esta técnica es que las búsquedas son rápidas porque los cálculos ya están hechos. Pero la tabla ocupa mucho espacio en disco. 

Para solucionar los problemas de almacenamiento, se usan las rainbow tables. En ellas se guarda un conjunto reducido de palabras y, para cada una se calcula la palabra final que le corresponde, según el siguiente método:

Se calcula el hash de la palabra. Aplicando a dicho hash una función de reducción, se obtiene otra palabra distinta, de la que a su vez se calcula el hash. Y así hasta unas 40.000 veces, hasta que se obtine l'última palabra. El par primera palabra, última palabra, forma una fila de la tabla (los valores intermedios no se almacenan). Para cada una de las palabras escogidas, se hará lo mismo.

Ahora, una vez que se ha construido la tabla siguiendo el método anterior, podemos intentar calcular la contraseña correspondiente a un hash dado, de la siguiente manera:

Al hash se le aplica la función de reducción, si la palabra obtenida corresponde con alguno de los elementos finales de la tabla, ya hemos terminado. Si no, calcularemos el hash de dicha palabra, para aplicarle la función de reducción. El cálculo para cuando encontremos la palabra que coincida con el elemento final de alguna fila (no siempre se encuentra). En ese punto sabremos que, repidiendo el proceso tomando como partida la palabra incial de la final, obtendremos en algún momento nuestro hash. La palabra a partir de la la cual lo hayamos encontrado será la contraseña buscada.

Es importante recordar que la función de reducción NO es la inversa de la función hash (que ya decíamos que es unidireccional), pero una misma función de reducción, a partir del mismo hash, siempre produce la misma palabra. Para entenderlo mejor, podéis ver un ejemplo en la Wikipedia.

Fuente: Wikipedia


Como a cada contraseña le corresponde siempre el mismo hash, si dos usuarios tienen la misma contraseña tendrán también el mismo hash. Para complicar la cosa y hacer menos efectivas las tables, lo que se suele hacer es "saltear" las contraseñas: añadirles un salt aleatorio, distinto para cada una, antes de calcular el hash. Para que el método sea efectivo, hay que poner cuidado en no usar dos veces el mismo salt y que éstos sean lo suficientemente largos.

En resumen: las contraseñas no deben guardarse nunca en texto plano, sino "salteadas" y "hasheadas". La pregunta es si todos los sitios en los que nos registramos lo harán así.


09 marzo 2015

Mi experiencia en la #Rooted2015

HTTP 303 See other

Location: www.securitybydefault.com

Tranquilos, no le pasa nada al blog. Ese 303 lo he puesto yo para indicaros, de una manera original, que este año, la crónica podéis leerla en otro blog.

Los chicos de "Security by Default" me han pedido que escribiera en su blog la crónica de la Rooted2015. Así que, aunque podría repetirlo aquí (ellos solo quieren la primicia), mejor os redirijo a su blog para que lo leáis allí.

Espero que os guste. Y a SbD, reiterarles mi agradecimiento por darme la oportunidad de escribir en un blog tan prestigioso como el suyo y que llevo leyendo desde que me inicié en esto de la seguridad.

http://www.securitybydefault.com/2015/03/mi-experiencia-en-rootedcon-2015.html