Payment Card Industry Data Security Standard v2

Buenos días,

Para empezar la semana una de evolución normativa / regulatoria. En Octubre se va a publicar la siguiente versión del estándar de seguridad de la industria de pago con tarjeta (la del dinero de plástico, vamos), algunos cambios ya se han adelantado a alto nivel, los cuales os pego por aquí. Todo ello dentro de un ciclo de vida que se ha extendido de 2 a 3 años, más acorde con los criterios de madurez en el gobierno de la información actuales:

Requirement Impact	Reason for Change	Proposed Change	Category
PCI DSS Intro	Clarify Applicability of PCI DSS and cardholder data.	Clarify that PCI DSS Requirements 3.3 and 3.4 apply only to PAN. Align language with PTS Secure Reading and Exchange of Data (SRED) module.	Clarification
Scope of Assessment	Ensure all locations of cardholder data are included in scope of PCI DSS assessments	Clarify that all locations and flows of cardholder data should be identified and documented to ensure accurate scoping of cardholder data environment.	Additional Guidance
PCI DSS Intro and various requirements	Provide guidance on virtualization.	Expanded definition of system components to include virtual components. Updated requirement 2.2.1 to clarify intent of “one primary function per server” and use of virtualization.	Additional Guidance
PCI DSS Requirement 1	Further clarification of the DMZ.	Provide clarification on secure boundaries between internet and card holder data environment.	Clarification
PCI DSS Requirement 3.2	Clarify applicability of PCI DSS to Issuers or Issuer Processors.	Recognize that Issuers have a legitimate business need to store Sensitive Authentication Data.	Clarification

PCI DSS Requirement 3.6	Clarify key management processes.	Clarify processes and increase flexibility for cryptographic key changes, retired or replaced keys, and use of split control and dual knowledge.	Clarification
PCI DSS Requirement 6.2	Apply a risk based approach for addressing vulnerabilities.	Update requirement to allow vulnerabilities to be ranked and prioritized according to risk.	Evolving Requirement
PCI DSS Requirement 6.5	Merge requirements to eliminate redundancy and Expand examples of secure coding standards to include more than OWASP.	Merge requirement 6.3.1 into 6.5 to eliminate redundancy for secure coding for internal and Web-facing applications. Include examples of additional secure coding standards, such as CWE and CERT.	Clarification
PCI DSS Requirement 12.3.10	Clarify remote copy, move, and storage of CHD.	Update requirement to allow business justification for copy, move, and storage of CHD during remote access.	Clarification
PA DSS General	Payment Applications on Hardware Terminals.	Provide further guidance on PA-DSS applicability to hardware terminals.	Additional Guidance
PA-DSS Requirement 4.4	Payment applications should facilitate centralized logging.	Add sub-requirement for payment applications to support centralized logging, in alignment with PCI DSS requirement 10.5.3.	Evolving Requirement
PA-DSS Requirements 10 & 11	Merge PA-DSS Requirements 10 and 11	Combine requirements 10 and 11 (remote update and access requirements) to remove redundancies.	Clarification

Esto se traducirá en Objetivos de Control, Controles y requisitos de seguridad. Hay cosas curiosas como no basarse solo en OWASP para los test de intrusión de aplicaciones web, gestión del ciclo de vida de claves criptográficas, mayor separación de capas y clara definición de las DMZ, etc.

Habrá que estar atentos en los próximos meses. Más información aquí.

Metricas Seguras

Cumplidas las tres primeras semanas del año en muchas empresas la cúpula directiva se sienta, prepara los proyectos del 2010 y entre otras muchas preguntas, a los que nos dedicamos a la seguridad nos dicen, “bueno, ¿cómo estamos este año?, ¿hemos mejorado en seguridad?, ¿se ha invertido suficiente?, ¿estamos mejor que la competencia?”

Desde que la seguridad dejó de ser una asignatura pendiente a convertirse en un “must do it” ya sea por requisitos legales, por que tus servicios han tenido verdaderos problemas para ofrecerse con normalidad o por que se ha visto oportunidad de negocio la inversión en la misma se ha parecido a la siguiente gráfica:

Retorno de la Inversión en Seguridad

Muy propia de aquellos campos donde la incertidumbre es alta, o dicho de otra forma, donde la madurez del gobierno de la información es baja. Más inversión solo puede significar a ojos de la dirección más seguridad o más negocio o ambas, y nunca se entenderá otra cosa (como es lógico). De ahí que ante las preguntas de ¿como estamos este año? Tengamos que presentar unos datos que si no hemos hecho los deberes parecerán magia borras. Si, estamos hablando de METRICAS DE SEGURIDAD.

When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is a meager and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely, in your thoughts, advanced to the state of science.

—William Thomson, Lord Kelvin, 1883

Esta acertada frase de William Thomson (quien por cierto, jamás vio un ordenador) viene a decirnos, si tu conocimiento sobre una materia es tal que lo puedes expresar en cifras, entonces es que sabes algo, pero si no puedes medir aquello de lo que estás hablando entonces te queda mucho por aprender,,, perfecto. ¿Como medimos un concepto tan abstracto como la seguridad?, ¿por número de ataques?, ¿por número de incidentes de seguridad?, ¿como sabrá nuestra dirección si está invirtiendo bien? Es necesario caracterizar nuestras métricas:

1.- ¿Cuál es el objeto a medir? → Nivel de conformidad LOPD (atributo) de un sistema (objeto), grado de riesgo de mis sistemas, etc.

2.- ¿Por qué quiero medir ese objeto?, ¿cuál es la necesidad? → Tenemos un mayor control sobre mis servicios, mejorar la gestión de la seguridad, etc.

3.- ¿Con respecto a qué voy a medir? → Toda métrica necesita de un objeto contra el que comparar, por ejemplo, un estándar de buenas prácticas, los controles de mi Normativa, etc.

Es imprescindible que lo que se mida sea importante, y no solo eso, sino que los datos que nos muestren las mediciones sean significativos, teniendo claros estos principios y una vez identificados los tres puntos básicos, podemos abordar otros asuntos propios del proceso, qué método voy a utilizar para obtener esos datos (entrevistas, auditorías, obtención de logs, etc.), cada cuanto tiempo voy a recoger los datos (muchos datos pueden generar ruido, pocos datos inexactos), responsables de proporcionar los datos, personal involucrado, etc.

Como veis, una tarea cuanto menos ardua. Es parte imprescindible de un Sistema de Gestión de la Seguridad de la Información (SGSI) disponer de esta serie de datos (indicadores) que te diga como estás en lo que a seguridad se refiere, hasta hace unos años esto no estaba siquiera regulado, por suerte con la serie 27000 de ISO apareció la 27004. Este será nuestro cuaderno de consulta obligatorio si este año no hemos hecho los deberes y tenemos que decir, ¡estamos mejor que el año pasado! Mientras cruzamos los dedos por detrás y esperamos que no pase nada y haber sido convincentes :-p

Una vez que empezamos a recoger esos valiosos indicadores, sabemos el grado en que vamos cumpliendo con los objetivos estratégicos surge el concepto de “Cuadro de Mando”, que no es más que una herramienta para poder tener en todo momento una foto del estado de la seguridad y del grado de cumplimiento con respecto a los objetivos a medio y largo plazo.

Esta entrada es un pequeño resumen y recordatorio de lo que hace 3 años se homologó y regularizó dentro de la serie 27000, curiosamente en la actualidad surge con fuerzas renovadas dada la necesidad imperiosa de producir con eficiencia. Nuestros jefes, gerentes y directores ya saben que hay que invertir en seguridad (lo ven en las noticias a diario), pero también quieren saber que lo están haciendo bien.

Sin duda un campo muy interesante.

Salu2!

Beautiful Security

Lo primero es lo primero, bienvenidos 1 añito después a todo es seguro (all is sec, como dicen mis colegas), espero que al igual que yo estéis descansados y con ganas de leer cositas interesantes, desde aquí trataré de aportar mi granito de arena.

Comenzamos esta nueva temporada con un libro, y no va a ser el único ya que inauguro una nueva categoría, “Libros Seguros”, donde os contaré un poquito lo que aporta la literatura de la Seguridad Informática (de ayer y hoy) y qué libros son “must read” y cuales no tanto.

Beautiful Security no es un libro para hackers, ni siquiera puede serlo para consultores de seguridad o informáticos. Es un libro para quien puede estar dudando sobre si trabajar en Seguridad de la Información (¿merece la pena, no la merece?, ¿me dedico a otras áreas?) o para aquel que trabajando dentro de Seguridad (como consultor, auditor, hacker, comercial, etc.) se encuentra desencantado y siente que su trabajo es duro, agotador, que tapa un agujero y le salen 10 más, que discute y discute con otras áreas tratando de concienciar en vano. Es un libro bonito, que ayudará a ver a través de otros ojos la belleza de esta profesión. Un must read.

El libro se divide en 16 capítulos, el orden no tiene mucho sentido ya que son independientes, cada uno está escrito por un experto distinto en seguridad que va desde los creadores de PGP o L0pthcrack hasta profesores de Harvard y cada uno aborda un tema distinto explicando brevemente el estado del arte, qué no funciona, qué habría que mejorar y hacia donde avanza la Seguridad en ese campo, casi todos los capítulos aportan alguna idea refrescante donde muchas veces diréis, ¡ey!, esto no se me había ocurrido:

1.- Psychological Security Traps: El nombre es muy descriptivo, el creador de L0pthcrack cuenta como se le ocurrió la idea, cómo se revolucionó el gobierno americano y cómo pasó a estar sentado con los principales responsables de seguridad del estado tras hacer esta herramienta.

2.- Wireless Networking: Fertile Ground for Social Engineering: Probablemente estéis aburridos de seguridad wifi, en este capítulo se puede ver como un problema de seguridad inalámbrica originó el mayor robo de tarjetas de crédito de la historia (en un principio 30 millones, hoy se estima que fueron más de 100), el caso de TJX.

3.- Beautifull Security Metrics: Un soplo de aire fresco en el siempre complicado mundo de las métricas de seguridad, una analogía con la sanidad nos muestra que no somos los únicos con ese problema y como ellos lo resolvieron.

4.- The underground economy of security breaches: Aquí veremos con cifras y letras lo que mueve la industria del mal, la complejidad de las botnets, etc.

5.- Beautiful Trade: Rethinking E-Commerce Security: Análisis de los sistemas de comercio electrónico actuales y las operaciones que implica comprar por internet, propone un sistema de comercio electrónico alternativo.

6.- Securing Online Advertising: Rustlers and Sheriffs in the New Wild West. ¿Qué ocurre en ese mundo que sustenta Internet, llamado publicidad?, ¿podemos fiarnos?, ¿pueden infectarnos?, ¿es legal la publicidad engañosa? Aquí responderemos todas estas cuestiones.

7.- The Evolution of PGP's: Web Of Trust. El creador de PGP nos cuenta como funciona y qué aspectos siguen siendo problemáticos. Por ejemplo, la caducidad de las firma de una clave.

8.- Open Source Honeyclient: Proactive Detection of Client-side exploits. El creador del primer honeyclient cuenta como se le ocurrió la idea y cómo utilizó este software junto con tripware para evaluar la seguridad de visitar una página web.

9.- Tomorrow's Security Cogs and Levers: Este capítulo aborda la seguridad en la nube y los webservices. Quizás uno de los más flojos del libro.

10.- Security by Design: Todos sabemos que abordar la seguridad en las fases tempranas de un proyecto supone un importante ahorro con respecto a futuros cambios y vulnerabilidades.

11.- Forcing Firms to Focus: Is Secure Software in Your Future. ¡Un sistema debe ser seguro igual que una hamburguesa debe estar caliente! Esa frase creo que explica muchas cosas, aunque aquí viene otra de impacto: “Los mejores desarrolladores del mundo crean código vulnerable” Este capítulo es una continuación del anterior, se muestra el caso de una empresa de desarrollo (de nombre ficticio ACME) que realmente incorporó este atributo y de cómo ahorró tiempo y dinero aumentando la calidad de sus productos.

12.- Oh No, Here Come the Infosecurity Lawyers. Los abogados junto con la alta dirección son los mejores amigos de un experto en Seguridad, en este capítulo muestra leyes americanas, si las sustituimos por las españolas (o las que os apliquen) veremos como obtener un fuerte respaldo a nuestros requisitos.

13.- Beautifull Log Handling. El sistema de logs puede ser un auténtico problema, crear logs que proporcionen datos importantes, que sean válidos, que no den demasiada información ni tampoco eliminen la necesaria puede ser un quebradero de cabeza. La falta de estándares al respecto es un verdadero problema, pero incluso con el se pueden realizar análisis forenses con éxito.

14.- Incident Detection: Finding the other 68%. Este capítulo no me convenció mucho, asume que solo el 32% de las amenazas y ataques son detectados por nuestros antivirus, IDS, etc. y da ciertas soluciones para aumentar ese ratio. Nada nuevo para los tiempos que corren.

15.- Doing Real Work Without Real Data: Este capítulo presenta el caso de las bases de datos translúcidas, un interesante concepto sobre el que habrá que profundizar. Must read.

16.- Casting Spells: PC Security Theater. Un análisis de las tradicionales soluciones de seguridad y sus fallos, muestra la tendencia actual a unificar sandboxes (virtualización) + chequeo de firma antivirus + análisis de amenaza por inteligencia artificial.

Y con esto cerramos Beautiful Security, 300 páginas para refrescar tu visión de la Seguridad Informática :)

Salu2!

Trusted Network Connect

Cuando a principios de Octubre hablamos de Trusted Execution / Trusted Plataform dentro del marco de arquitectura de procesadores segura dimos alguna pincelada de un término que a día de hoy es crucial en toda corporación, Trusted Network Connect.

Actualmente la ubicación del puesto de trabajo es dinámica, y cada vez lo es mucho más. Nuestro personal está sentado en sus oficinas, pero también está desplazado en un cliente y requiere conectividad contra servicios y recursos que tiene en su puesto de trabajo, también viaja y probablemente tanga una BlackBerry o similares con la que necesita revisar el correo corporativo, esto es solo la punta del iceberg: No todos los empleados son iguales, hay desarrolladores, gente de sistemas, comerciales, jefes, gerentes y directores. Becarios recién contratados y externos, muchos externos, ya que también hacemos Outsourcing. Este personal ajeno también necesita conectividad para dar su servicio, es más, probablemente lo hará todo desde sus propias oficinas o quizás tengamos un hueco para ellos en nuestra empresa.

El perímetro de la organización es maleable y se corre el riesgo de que no se puede dar una solución de acceso a sistemas y servicios segura y robusta. En definitiva, un problemón para los arquitectos de red y el personal de seguridad que requiere de soluciones. Es aquí cuando entran en juego los accesos de confianza.

El Trusted Computing Group da una serie de directrices genéricas independientes de la tecnología para orientarnos un poco en como deben ser esos accesos.

Network Access Control

Este concepto simplificado al extremo trata de que un “cualquiera” que llegue a tu organización no sea capaz de enchufarse a tu red bien, por que ahí hay una roseta vacía o bien por que la Wifi está abierta a invitados. Esto hoy en día es sencillamente intolerable, pero el NAC va mucho más allá definiéndose como un conjunto de medidas de seguridad que nos aseguren que solo accederá a nuestra red aquel que tenga los correspondientes permisos y cumpla con un mínimo de políticas de seguridad, NAC es:

• 802.1X
• DHCP
• VPN
• Cumplimiento GpO.
• Actualizaciones y parches del Sistema Operativo.
• Antivirus actualizado y homologado.

Pero esto no es todo, debemos ser capaces de proveer u

na infraestructura de acceso que a parte de cumplir con todo lo anterior sea capaz de dar acceso a los recursos necesarios según el perfil / rol del usuario, esto se debe apoyar de forma indudable en una arquitectura de red segura (con todo lo que implica a nivel de VLANs, firewall, routing, etc.). Además los permisos de acceso deben ir alineados con los recursos accedidos, probablemente una persona de desarrollo necesite ser administrador en su equipo y trabajar en un entorno aislado alejado de producción, de igual forma se debe evitar que un administrador de BBDD sea capaz de modificar los datos que gestiona, siendo esta capacidad exclusiva de sus usuarios (esto creo que lo llamaban segregación de funciones).

Ahora bien, todo esto no es nuevo, las conexiones de confianza pueden llegar mucho más lejos y alcanzar a todos los dispositivos de mi red, impresoras, telefonía VoIP, cámaras de seguridad, etc. cuya actividad también deberá estar regulada. De manera adicional se instalarán sondas, IDS/IPS que controlen y detecten la actividad de los dispositivos / usuarios en la red, aquí es cuando surge un elemento adicional, el IF-MAP (Interface Metadata Access Point) Para no perdernos echemos un ojo a la siguiente imagen:

En la misma tenemos nuestros clientes “de confianza”, seguridad a nivel de red 802.1x, switches, routers, radius, firewalls, Policy Decision Point y, como capa adicional antes de llegar a los controles de seguridad aparece IF-MAP, ¿Qué es esto?, Con IF-MAP tenemos un protocolo cliente – servidor basado en XML y que utiliza SOAP + HTTPS. Su misión principal es recolectar datos de los dispositivos de red, metadatos que nos den una idea de quien es, a qué accede, que está solicitando y haciendo, etc. La estructura de los mensajes que maneja es la siguiente:

• ip-adddress (v4 or v6)
• mac-address
• identity aik-name:

1. dns-name
2. email-address
3. kerberos-principal
4. trusted-platform-module
5. username
6. sip-uri
7. tel-uri
8. other (vendor defined)

• access-request
• device

Como imagináis esto abre un abanico de posibilidades a la hora de controlar los accesos a la red que delega en el Metadata Access Point controles de seguridad que en tiempo real detectan accesos inapropiados, dispositivos que tratan de acceder a recursos que no deben, alarmas (falsas o no) alineadas con el resto de dispositivos, etc. No han sido pocos los fabricantes que se han subido al carro del IF-MAP, en esta pequeña diapositiva se pueden ver algunos de ellos.

El paradigma de acceso a la red seguro con un servicio de confianza está cambiando continuamente, hay mucha tela para cortar aquí ya que estamos hablando de confianza extremo a extremo, multitud de capas de acceso, ingeniería de conocimiento y redes bayesianas para decidir cómo actuar sobre un dispositivo, etc. Por suerte hay mucha información disponible en la red, herramientas Open Source como FreeRadius, OpenSea 802.1X, el proyecto libTNC, etc.

Precaución, amigo conductor (happy bridge).

Salu2!

La experiencia puede ser un riesgo

Disclaimer: Esta entrada es fruto exclusivo de las divagaciones personales del autor, no dispone de base científica y las opiniones vertidas no son siquiera demostrables, si piensas que el título de la entrada es un disparate quizás no debas seguir leyendo.

Tengo un colega dedicado al comercio de combustible, empresario él conoce todos los factores que pueden afectar a su negocio, que márgenes y umbrales son aceptables en sus negociaciones o cual es la tendencia actual del mercado. Como yo no tengo ni idea de por qué el gasoleo sube cuando hay un puente, o por qué si un día se enfada Chavez, al otro baja el barril de brent (o no) le propuse lo siguiente:

Quiero que me digas a cuanto va a estar el barril de petróleo mañana, dentro de una semana y dentro de un mes. Otros dos amigos míos tan ignorantes como yo hicieron sus apuestas, quedando el Excel de la siguiente forma:

	Clark	Use	Pablo	GigA	Real
28-oct	77.93	77.86	77.22	76	77.74
04-nov	79.50	80.15	78.24	70	80.27
28-nov	82.69	85.06	77.77	85

El experto se aloja bajo el pseudónimo de Clark, hay que decir que ninguno de nosotros sabíamos las predicciones que el resto iban a hacer (si no estaríamos condicionados y Clark sería nuestra referencia). A día de hoy el brent ha bajado de nuevo a los 79$ el barril y salvo sorpresa no se prevé que se anime tanto como para llegar a los 85$ (mi apuesta). Hasta ahora nuestro experto (Clark) ha acertado 2 previsiones, igual que ha hecho Use, Pablo acertó 1 y yo (nunca fui bueno en las apuestas) ninguna. Sin embargo tenemos ya una conclusión: el experto no parece que vaya a acertar mucho más que el resto de ignorantes, en el mejor caso puede acertar todo (Use 2, Pablo1, yo 0), en el peor puede acertar menos que Use y 1 más que Pablo y que yo, en el normal Pablo Use y Clark tendrán 2 aciertos y yo ninguno.

Estaréis conmigo en que la muestra es pequeña, el valor real del experto quizás se podría apreciar mejor conforme pasa el tiempo, a 2 meses, 3 meses, 1 año, ¿verdad? Pues en opinión del experto esto no es así, la incertidumbre se dispara a futuro y el pasado cada vez es una referencia menos válida, si bien para el precio del crudo las variables económicas que interfieren son bien conocidas, podríamos decir que ocurre lo mismo exactamente en otros mercados como la Bolsa, el precio del Oro, el valor de las pipas o la posibilidad de que mi empresa cierre el año que viene.

Día a día me enfrento en el trabajo a análisis de riesgos, se detectan las amenazas sobre un sistema (que cubre una necesidad de negocio), se acotan, se mapean unas medidas compensatorias, se establecen controles de seguridad, se ofrecen indicadores sobre los controles, etc. Cuando has revisado 30 arquitecturas distintas riesgos, medidas, controles, etc. te van saliendo como churros. TODO ES SEGURO.

Mientras tanto el sol sigue saliendo por las mañanas, con un poco de suerte nuestra nómina va engordando poquito a poco, asumimos que todo va más o menos bien, hay Seguridad, la vamos manteniendo, los procesos de negocio se van ofreciendo con confianza, el barco avanza viento en popa a toda vela. Entonces un día algo hace “crack”, estalla la guerra en Pakistán, el precio del petroleo sube a 200 $ por barril (como vaticinaba cierto presidente 1 mes antes de comenzar la crisis), o quizás un miembro del Cuerpo Directivo ha estado aprovechando sus poderes para manejar cientos de millones en la sombra hacia ciertas áreas de interés, también es posible que nuestro Active Directory se infecte por un virus y tengamos cientos de usuarios que no pueden trabajar, además como ese virus es muy maligno se replica a servidores, puestos de trabajo, etc. Mierda, y el plan de continuidad de negocio desfasado, ¿Qué hacemos, a quien llamamos?, ¿Dónde estaremos mañana?

Yo no se vosotros pero yo veo muy relacionado el precio del barril de crudo, la economía de Mongolia y que mi CPD no se caiga, llámalo efecto mariposa, llámalo Cisne Negro:

Pero la realidad es que todo va bien, exactamente igual que un pavo estamos 300 días seguidos siendo alimentados 3 veces al día, sin sospechar que el día 301 es el “Thanks Giving Day” entonces nuestro cuello es cortado, nos rellenan de Dios sabe qué y “al horno”. Es muy oportuno hablar de estos cambios en “tiempos de crisis”, cuando hace 18 meses no había Crisis (por activa y por pasiva) y hoy en día todos corren por salir los primeros de ella, los analistas hacen sus estimaciones económicas a 1 año (se equivocan), los Directivos establecen su plan de negocio para los siguientes 2 – 3 años (se vuelven a equivocar) y los más ávidos se imaginan como serán su negocio dentro de 5 años o estiman que la jubilación en el 2030 será a los 67 años por que la economía no será sostenible para entonces (supongo que por que ahora si es sostenible). Todos se equivocan y no pasa nada, ¡nadie puede predecir el futuro!, y es verdad, nosotros no somos una excepción. Estamos hechos para pensar de pasado a presente, en base a ello definir un futuro “probable” o no. Pasábamos el relajado verano de 2008 viendo cómo Kaminsky anunciaba una vulnerabilidad en los DNS a todo el mundo, y todos estuvimos esperando que los fabricantes sacaran los respectivos parches y auditando si éramos vulnerables (efectivamente, lo éramos), quizás el verano que viene se publique una nueva que comprometa seriamente (aun más) el HTTP – SSL, y veremos que tenemos que tocar todos nuestros servidores web o cambiar el paradigma de seguridad en los frontend ya que nos hacen un deface (en el mejor de los casos) día si y día también. Pero estos serían casos menores, es posible que el CPD de google se hunda por que han decidido dejarlo en alta mar y llegó un maremoto, un avión se puede estrellar contra nuestros edificios o la Gripe A que ya a nadie preocupa ha mutado y no vamos a quedar nadie para contarlo, ¿quien sabe?

Los sucesos inesperados a la par que improbables son (vaya paradoja) periódicos, esto también ocurre en nuestro mundo acotado a protocolos y tecnologías, sin embargo se olvida. No se si a vosotros os pasa pero a mi sí, se comienzan a suponer cosas, el SSL cifra muy bien, las VPN nos proporcionan acceso seguro a través de redes inseguras, mis certificados no caducan hasta el 2020 así que no hay prisa, al final es todo SOTA, CABALLO y REY. Entonces surge el riesgo (muy pocas veces materializado) de que aparezca el JOKER y se ría de nosotros, puede tener cualquier cara (es un JOKER) y no nos lo esperaremos, pero cuando se haga realidad su impacto negativo será enorme. También es posible que ocurra al revés, que un día os hagáis en vuestra casa una herramienta para hablar con vuestros colegas, no se, algo como “Facebook”, y resulta que empieza a extenderse como un reguero de pólvora y en 4 años estás tomando copas con Larry Page , Bill Gates, Linus Torvalds y Chad Harley (curiosa fiesta).

En fin, este es un tema sobre el que me gusta debatir mucho, la experiencia es sin duda un buen aliado pero nunca podemos suponer en exceso, siempre hay gente por ahí que se olvida de todo lo que hay y crea algo nuevo, que nadie preveía, ese alguien podemos ser nosotros, y ese algo puede ser maravilloso, pero también puede ser terrible.

¿Y vosotros, os arriesgáis por vuestra experiencia?

Salu2

PD: ¿A cuanto estará el brent el 28/11?

reCAPTCHA

Creo que la medida de seguridad que hoy voy a presentar a pesar de ser bien conocida -a la par que odidada en algunas ocasiones- añadirá un puntito adicional a su favor que otras soluciones parecidas no disponen: bajo coste y robustez. Hablábamos hace un par de entradas de “encuestas seguras”, su cada vez mayor presencia y relevancia en los medios de comunicación que pueden (y no es erróneo decirlo) engañar a la opinión pública. Pues bien, una aplicación práctica de reCAPTCHA es la protección contra ataques por repetición en las encuestas. Claro está a alguno le puede parecer exagerado para una encuesta, es solo un ejemplo, seguro que se os ocurren otras muchas aplicaciones.

Entrando en detalle, reCAPTCHA es un servicio que puede incrustarse de forma gratuita en cualquier aplicación web, incluye 2 palabras distintas que deben escribirse separadas, lo cual añade un puntito más de robustez. Además incluye compatibilidad para discapacitados permitiendo la emisión de CAPTCHAs en forma de sonido. Para instalarlo es necesario darse de alta en el sistema con el dominio que se vaya a utilizar, con esto se nos proporcionarán dos claves, una pública y una privada. Al incrustar el siguiente código javascript en nuestro frontal web:

Se hará una llamada a los servidores de recaptcha y se incrustará el desafío en el frontal, lo que vayamos a hacer con él ya es nuestra decisión. Ahora bien dependiendo del lenguaje de nuestra aplicación web deberemos acudir aquí para obtener los recursos que analicen y verifiquen el CAPTCHA, por ejemplo en ASP deberemos añadir una librería a nuestro proyecto que contiene una serie de llamadas para verificar el CAPTCHA, este proceso se realiza nuevamente contra servidores externos, para mayor claridad:

Es decir, en 1) el usuario carga la página web que tiene incrustado el CAPTCHA, en 2) el browser solicita a los servidores de reCAPTCHA el reto, esta petición la hace con la clave publica del servidor. Después en 3) el usuario soluciona el reto y esa solución es enviada al servidor de aplicaciones (o el frontal web dependiendo de la arquitectura), en 4) este servidor contacta con el API Server, aquí es cuando se utiliza la clave privada para verificar que efectivamente la petición no ha sido manipulada en su recorrido, el API server devuelve el resultado del desafio, esto lo recogerá el servidor de aplicaciones proporcionando una respuesta dependiendo de si se ha superado el desafió o no.

¿Sencillo? A mi me parece que sí, como detalle final añadir que el API Server detecta las IP de los clientes que solucionan “muchos” CAPTCHA en pocos minutos, evitando así que en caso de que el desafío se haya visto comprometido se realicen ataques por repetición bloqueando la IP origen temporalmente.

Bueno, bonito y barato, lo ideal para comenzar la semana :)

Salu2

PD: Entrada relacionada de Breaking CAPTCHAS.

Sello Europeo de Privacidad

El proyecto para definir un programa de certificación de productos en lo que a seguridad y protección de datos a nivel europeo se refiere está a punto de terminar. A grandes rasgos este proyecto establece un proceso de certificación para que cualquier entidad que trabaje con sistemas o servicios que traten datos de carácter personal pueda certificar los mismos (sea una aplicación, sea un producto hardware, etc.), con un sello de confianza reconocido dentro de la Unión Europea, este proceso de certificación incluye:

- Evaluación del producto por expertos jurídicos.
- Auditoría del producto por expertos TI.
- Informe de conformidad con los criterios de evaluación del catálogo de criterios europeos.
- Aceptación del producto bajo el sello de privacidad europeo.

Como os podeis imaginar la definición y puesta en vigor del European Privacy Seal (Europrise) supondrá un valor añadido al que muchas empresas querrán subirse para certificar sus productos y servicios, exactamente igual como ya ocurrió con la ISO 9000 de calidad. En España el informe de auditoría y evaluación del producto técnica y legal será revisado por la Agencia de Protección de Datos de la Comunidad de Madrid, quien por ahora es la única entidad nacional que puede homologar el Europrise.

En la llamada "Sociedad de la Información" donde la penetración de las tecnologías en los ciudadanos es cada vez mayor, es absolutamente necesario la presencia de un producto como este que proporcione confianza a los ciudadanos en el uso de las TIC. Por si a alguien le quedan dudas por aquí tenéis el último barómetro de la Agencia Española de Protección de Datos de Septiembre 2009, en el figuran los siguientes datos:

- El 46% no conoce de la existencia de la AEPD.

- El 43% le preocupa bastane la protección de datos y el uso por terceras personas, al 30% mucho.

- El 56% considera que la privacidad de sus datos en Internet es baja o muy baja.

- Al 77% le da poca seguridad dar su número de tarjeta de crédito por Internet para hacer sus compras.

Contra estas cifras iniciativas como el Europrise son de agradecer, no obstante nunca podemos dejar las necesarias campañas de Sensibilización y Formación al ciudadano en lo que al buen uso y seguridad de Internet se refiere.

Si queréis profundizar en este tema el 3 de Noviembre se va a dar un seminario en la Casa de Correos en Madrid, la entrada es gratuita, solo limitada al número de plazas.

Buen fin de semana :)

¿Es tu procesador más seguro que el mío?

¿Qué pregunta más absurda, verdad? Hasta hace bien poco lo único que diferenciaba a los grandes fabricantes de procesadores, léase Intel y AMD, era el precio, la carrera por subir los ciclos de reloj de sus procesadores, y los primeros juegos de instrucciones "dedicados" (¿alguien se acuerda del pentium MMX?) a las actividades más frecuentes de sistema operativo y usuarios, donde por cierto AMD siempre iba un poco por detrás, esto también ocurría en la fiabilidad de los procesadores, muy cuestionada al principio de los tiempos:

¿Cuanto dinero perdió AMD con este vídeo?

Pero AMD solucionó esos problemas volviendo a ganarse la confianza de los consumidores, innovó la arquitectura x86 y saltó hacia los 64 bits hace ya varios años, demostrando que ellos también hacían I+D. En ese caso le tocó a Intel hacer ingeniería inversa y clonar su idea, que fue rápidamente adaptada por Microsoft (& cia) sacando sistemas operativos de 64 bits en sus familias XP, Vista y, dentro de unos días, Windows 7. Así la carrera entre estos dos gigantes ha seguido año tras año, dejó de ser una buena idea subir los ciclos a los procesadores sin comprometer la alimentación y la temperatura y surgieron las arquitecturas basadas en los multiprocesadores que ahora todos conocemos, 2, 4, 8, 16 núcleos (AMD se atrevió con 3), etc.

Mientras tanto,,, ¿Qué pasó con la Seguridad, tenía cabida a nivel procesador? Con este brevísimo repaso a la historia de los procesadores y sus dos grandes fabricantes os pongo en antecedentes de la idea que hoy quiero tratar con vosotros: hay procesadores más seguros que otros, y lo que es peor, no lo aprovechamos. Los fabricantes se han hecho eco de la conocida como “trusted computing” y han incluido mejoras de seguridad y protección a nivel hardware.

Intel Trusted Execution Technology

La arquitectura de ejecución de confianza que ha generado Intel para sus últimos procesadores es cuanto menos interesante, implanta aislación entre procesos, almacenamiento cifrado, protección de los dispositivos de entrada/salida (desde el teclado, hasta la tarjeta grafica), entornos protegidos para los procesos más importantes del sistema, etc. Todo ello a nivel hardware, ¿interesante, verdad? Estamos dejando que el procesador asuma ciertas tareas que históricamente han sido responsabilidad de los sistemas operativos, veamos la arquitectura:

Como veis procesador, chipset y BIOS trabajan en colaboración para ofrecer al sistema operativo y software que corre en el PC particiones protegidas (de forma parecida a como los sistemas operativos lo hacen con su estructura en anillo) donde solo se almacenarán las instrucciones del software crítico, como por ejemplo el kernel de nuestro S.O. o los datos críticos como la clave privada de una infraestructura PKI, impidiendo así que el software no autorizado tenga acceso a esas regiones de memoria o que un dispositivo con DMA intente leer, el procesador impedirá todo. Pero esto puede llegar más lejos, ¿se acabaron los keyloggers?, al menos la tecnología ITET permite que no tengamos que preocuparnos por los que son software, cifrando los datos cuando llegan al procesador y haciendo que no puedan ser interpretados, lo mismo para eventos del ratón, información que se manda a una impresora, etc. Eso sí, recordemos que es protección a nivel procesador, basada en tecnología hardware pero que protege de ataques software, no es la panacea claro está, pero es una gran ayuda.

Características adicionales son la protección contra ataques conocidos (¡buffer overflow!) y los dominios de confianza, a los que se asignan particiones para servicios, sistemas operativos virtuales, procesos, etc. estas pueden ser estándar o protegidas, esta imagen lo ilustra muy bien:

Virtualizar a nivel hardware, ¿es virtualizar?

Finalmente un detalle acerca de él cifrado, la tecnología “Trusted Execution” dispone de su propia infraestructura PKI, en ella la clave privada nunca abandona el “Trusted Protection Module”, es la clave publica la que se comparte y utiliza, así las aplicaciones pueden aprovecharse de esta característica para realizar el cifrado. Esto se extiende de sobremanera, un “domain manager” puede generar un par de claves (con un password que el usuario especifica por software, habría que ver el software claro) y desplegar agentes sobre varios sistemas de confianza, estos agentes pueden verificar una serie de condiciones para saber si el equipo en que se ejecutan son de confianza, si no lo es avisará al “domain manager”, esto se puede hacer a nivel de un procesador y sus entornos virtuales o a nivel de red, lo que es una enorme ventaja para los administradores que podrán aprovechar esta capacidad de la CPU para reparar en tiempo real equipos donde el sistema operativo se ha bloqueado, resetear parámetros de la BIOS, administrar recursos (un volcado de emergencia, por ejemplo), con el consiguiente e importante ahorro en microinformática, ¿merece la pena?, apuesto que sí.

ITDirector para clientes, tráfico ICMP cifrado, se entiende ;-)

AMD Trusted Platform Module y AMD Virtualization

¿Se ha quedado AMD atrás en esta tecnología? Quizás, pero a día de hoy su plataforma de confianza ofrece prácticamente las mismas posibilidades que la de Intel, al menos a nivel local del procesador:

- Autenticación.
- Protección de datos / cifrado.
- Identidad y gestión de acceso.
- Gestión de Password.
- Network Access Control.
- Seguridad en capas

- Virtualización de entornos

Todo ello basado en los estándares reconocidos por el Trusted Computing Group, que parece ser son los que el mercado está aceptando de facto tanto para el Trusted Computing como para el Trusted Network Connect. La única pega que ahora mismo veo (y no he podido comprobar) es que las soluciones de administración remota de PC’s y servidores (conocidas como DASH y SMASH) no incluyen el concepto de “dominio de confianza” que permita al igual que en Intel comprobar si, por ejemplo, un sistema ha dejado de ser de confianza, o llegar a administrar a nivel BIOS, o generar un par de claves para ese sistema. Quizás sea por desconocimiento pero yo no lo he encontrado.

¿Es tu procesador más seguro que el mío?

La respuesta es "depende", la tecnología hardware está ahí, y se puede aprovechar muy bien para hacer hardening al nivel más bajo, si conocemos estas posibilidades y las aprovechamos podremos hacer que los sistemas de nuestros puestos de trabajo y servidores sean más seguros, no es la panacea es verdad, pero es una capa adicional que podemos aprovechar y encima, ¡ahorrando dinero! Estas cuestiones se nos plantearán en la próxima renovación del parqué informático y, como no, tenemos que ponerlas sobre la mesa.

Y esto es todo por hoy, la verdad que tenía pensado hablar de Análisis Forense o de ECC, pero al final me pareció este un tema más interesante. Me voy unos días de puente, intentaremos volver la semana que viene.

Portaros bien y cuidado en la carretera.

Salu2

Info adicional:

Intel Trusted Execution Technology Architectural Overview (PDF)
IT Director
Intel System Defense Utility
Guide to Hardware Based EndPoint Security
Trusted Platform Module Research