(N.d.E. Nada más volver del pasado verano hicimos una analogía entre la función de la norma ISO 27001 en seguridad de la información y el cinturón de seguridad en seguridad del automóvil. En ella “prometíamos” hacer un repaso a los “anclajes” de ISO 27001, en especial al Anexo A de ISO 27002. Recuperamos dicha serie con esta primera entrada de Antonio Huerta, que habla del Dominio de Control 8: Seguridad relacionada con Recursos Humanos)

Estimados lectores, muy frecuentemente el primer pensamiento por parte de las empresas a la hora de afrontar la seguridad viene marcado por fuertes inversiones, como pueden ser costosas soluciones en infraestructura de red (IDS, Firewall), la compra de antivirus centralizados, suites de ServiceDesk, o laboriosos proyectos de consultoría. Si bien acometer dichas proyectos o compras de este tipo es un requisito para la consecución de cierto grado de seguridad empresarial, no resulta ser la panacea a la totalidad de los problemas de seguridad.

Cuántas veces han visto ustedes o incluso han empleado en presentaciones la frase: la cadena es tan fuerte como su eslabón más débil. Todos a estas alturas sabemos cuál es el activo que genera mayor riesgos a una empresa y que a menudo no contemplamos en nuestros análisis de riesgos: el empleado. De poco sirve que tengamos las medidas más sofisticadas, si mediante un simple correo electrónico cualquier empleado puede enviar informes clínicos a cualquier persona, no es consciente del problema de tirar los curricula de los candidatos descartados a un contenedor de basura cualquiera o se instala un programa P2P y comparte por descuido el contenido total del equipo. Dejando de lado problemas más graves que involucran a personal responsable o con privilegios de administración a los equipos.

Esta, entre otras, es una eterna cuestión que rodea a los datos personales y que nos da más de un dolor de cabeza: ¿es la IP un dato de carácter personal? Pues bien, todo parece apuntar, según lo que les mostraré en esta entrada, que sí. Yo, si les digo la verdad, siempre he sido un poco reacio a considerarla como tal, al menos en algunos ámbitos. Veamos un par de definiciones del Reglamento de Desarrollo de la LOPD:

Apreciados lectores, me voy a alejar un poco de la temática de mis anteriores publicaciones, más enfocadas a aspectos organizativos de la seguridad, y en esta publicación hablaré sobre el uso de sistemas proxy cache para optimizar el uso del ancho de banda de red. Como introducción a los proxys, decir que básicamente se trata de un servidor que hace de intermediario en la conexión entre un cliente e Internet. Los proxys se emplean en distintos ámbitos y con distintas funcionalidades como puede ser seguridad (filtrado) o mejora de las prestaciones de las comunicaciones, entre algunas otras. Este artículo se centrará en los servidores Proxy Cache que permiten optimizar el uso de ancho de banda, reducir latencias y por lo general hacer un uso más racional de los recursos disponibles.

El funcionamiento de un proxy cache es el siguiente: cuando un cliente realiza una petición a un servidor web, en la que genera X peticiones a todos los objetos que componen dicha web, la petición llega al proxy, que revisa su cache para comprobar si dispone de los objetos que se van solicitando. En el caso de que el objeto buscado se encuentre en cache, el proxy verifica que no ha expirado: que el objeto se corresponde con el actual, y en ese caso se produce un HIT y el sistema devuelve al cliente el objeto en cuestión. Si por el contrario el objeto buscado no se encuentra en cache o la versión encontrada no está actualizada, se produce un MISS en cache, tras lo cual el proxy descarga el elemento solicitado y lo sirve al cliente.

Hace un par de semanas tuvo lugar en Madrid el primer encuentro internacional CIIP sobre Ciberseguridad y Protección de Infraestructuras Críticas. El encuentro se desarrolló en la División de Formación y Perfeccionamiento de la Subdirección General RRHH de la DG de la Policía y la Guardia Civil con una muy alta participación tanto de gestores de Infraestructuras Críticas como de consultores que estamos trabajando en estos temas.

La inauguración oficial de las jornadas corrió a cargo del Secretario de Estado de Seguridad, D. Antonio Camacho, quien destacó la importancia que en los últimos tiempos ha tomado la seguridad para el conjunto de la sociedad y especialmente la seguridad de las infraestructuras críticas para todos los gobiernos del mundo. En su intervención lanzó una serie de datos que ponen los pelos de punta a cualquiera y que ponen de manifiesto la importancia de los temas tratados en el encuentro durante estos días. Habló, en términos generales, del ya disponible Catálogo de Infraestructuras Estratégicas de España, promovido a instancias proyecto de Directiva de la UE para la identificación y designación de infraestructuras críticas europeas (ICE) de diciembre de 2006, y desarrollado en España en base a lo establecido por del Acuerdo del Consejo de Ministros sobre Protección de Infraestructuras Críticas. Este Catálogo, tal y como se establece en el Real Decreto está considerado como material SECRETO y recoge información de unas 3.700 Infraestructuras Estratégicas en España, algunas de las cuales son Críticas. El Secretario de Estado comentó que aproximadamente el 80% de las Infraestructuras Estratégicas catalogadas están en manos privadas y que en los estudios que se han realizado en materia de seguridad sobre una población de unos 600 directivos de ICs, el 54% de las encuestadas reconocen haber sufrido ciberataques organizados.

Si recuerdan el post que publicamos hace poco más de una semana titulado OWASP Top 10 2010. Release Candidate, éste iniciaba una serie de entradas a través de las que pretendemos mostrar en qué consiste cada una de las vulnerabilidades que forman el TOP 10 de OWASP, así como ofrecer algunas indicaciones y recomendaciones sobre la mejor forma de evitar que nuestras aplicaciones sufran estas conocidas vulnerabilidades. Con algo de retraso sobre la fecha prevista, he aquí el primero.

La vulnerabilidad más comúnmente explotada desde el año 2004 que OWASP lleva realizando esta clasificación es la inyección. Aunque la más común sea probablemente la Inyección de SQL, existen otros tipos de inyecciones que es posible que no nos resulten tan familiares: LDAP, XPath, XSLT, XML, OS injection, etc., y que al igual que la Inyección SQL se aprovechan de la sintaxis del interprete que se va a encargar de ejecutar una determinada acción. Las vulnerabilidad de inyección pueden permiten a un atacante obtener cualquier tipo de información disponible en la aplicación, pudiendo llegar a comprometer totalmente la aplicación, así como los sistemas relacionados con ésta. Y ya saben que de ahí al infinito y más allá.

El pasado 18 de enero, nuestro compañero y “alma mater” de este Blog, el ínclito Manuel Benet, nos sorprendió con una nueva entrada que titulaba “MAGERIT: ¿Sí, o no?“, donde transcribía el artículo 13 del aún por entonces no publicado Esquema Nacional de Seguridad (ENS), y sometía la cuestión a una encuesta informal.

Para los que no conozcan el tema, en España, especialmente en las Administraciones Públicas, tenemos un referente indiscutible en el ámbito de la Seguridad de la Información cuando nos planteamos la metodología de análisis y gestión de los riesgos a seguir: MAGERIT, actualmente en su versión 2.0 y elaborada por el Consejo Superior de Administración Electrónica (CSAE), órgano del Ministerio de Administraciones Públicas encargado de la preparación, elaboración, desarrollo y aplicación de la política informática del Gobierno Español.

Hace ya unos meses, en este mismo blog, comentábamos la seguridad de los procesos de negocio y de los diferentes factores de riesgo (legal, técnico…) que pueden degradar dichos procesos; hablábamos en ese post del riesgo humano, ya que las personas son un activo crítico de las organizaciones y, como tal, pueden introducir riesgos en éstas, riesgos que como siempre debemos tratar de forma adecuada. Pero el paso previo al tratamiento de riesgos es, como siempre, su análisis, y para analizar estos riesgos debemos ser capaces de determinar amenazas, probabilidades e impactos que pueden causar las pesonas en la organización.

Bajo mi punto de vista, las amenazas derivadas del factor humano son claras: todas las englobadas bajo el paraguas de amenazas corporativas (errores), las derivadas de actividades sociales (accidentes) y las derivadas de actividades antisociales (delitos); incluso rizando el rizo, podríamos hablar del factor humano en las amenazas de origen industrial y, siendo todavía más retorcidos, en las de origen natural. De la misma forma, los impactos asociados a estas amenazas también suelen estar más o menos claros, y estarán —con toda probabilidad— en la parte más alta de la escala de impactos que queramos utilizar en nuestro análisis. ¿Dónde está entonces lo que más nos interesa? En la medida de la probabilidad, como casi siempre…

Aparte de la conocida seguridad por oscuridad, o la inseguridad de sentirse seguro, podemos hablar de la “seguridad por código binario”, y me explico. Hay muchos proyectos en los que todo es auditable, inspeccionado y revisado… excepto el código binario. Es muy habitual que éste se considere como algo seguro, inescrutable y secreto, ya que se considera que la ingeniería inversa es algo así como una tarea inabordable y de demasiada complejidad para ser llevada a cabo, si acaso por superexpertos.

Como ejemplo de este tipo, hoy en día existen numerosos binarios cerrados por diversas razones como DRM, licencias de producto, aplicaciones cliente servidor, o programación cerrada en sí misma. Ni que decir tiene que la mayor parte de ellos no son a día de hoy tan cerrados como a las empresas responsables de su desarrollo les gustaría. Para desmontar esa creencia de que la ingeniería inversa es para superdotados, en este post me gustaría repasar algunas de la herramientas existentes que permiten a no tan expertos el averiguar qué y cómo lo hacen los programas cerrados.

A continuación os presentamos un reto criptográfico que ha sido publicado por OWASP con el objetivo de promover unas conferencias en Estocolmo los días 21 al 24 de Junio organizadas por los capítulos de Suecia, Noruega y Dinamarca.

¿Qué se gana con este reto? Pues el primero en resolver el reto se lleva una entrada gratuita para estas conferencias valorada en unos 300€. Según anuncian en su página web, estos retos se realizan todos los días 21 hasta la celebración de las conferencias. En este caso, el objetivo de este reto en concreto es sencillo: obtener 8 contraseñas, compuestas por 5 caracteres codificadas en alfabeto tradicional, es decir [a-zA-z].

Aunque en alguna ocasión hemos hablado de OWASP (algunos de nosotros estuvimos en el pasado meeting del pasado mayo que tuvo lugar en Barcelona), lo cierto es que hasta la fecha, no hemos profundizado demasiado sobre este proyecto. Sirva esta entrada para solventar esta (relativamente) grave carencia.

Por si alguien no lo conoce, OWASP (acrónimo de Open Web Application Security Project, es decir Proyecto de seguridad de aplicaciones web abiertas), es un proyecto de código abierto dedicado a determinar y combatir las causas que hacen que el software sea inseguro, aunque su objetivo y foco de atención principal son las aplicaciones web. La comunidad OWASP, formada por empresas, organizaciones y particulares de todo el mundo, trabaja para crear artículos, metodologías, documentación, herramientas y tecnologías que se liberan y pueden ser usadas gratuitamente por cualquiera.