Security Art Work

Desde la adquisición por parte de google de la empresa Nest, empresa que diseña y crea sensores varios para el control del hogar, me planteo hasta qué punto es necesario tener tantos sensores, y no sólo esto, sino quién tiene acceso a la información que generan.

Obviamente, no critico el tener un detector de incendios en tu propia casa, critico el hecho de que un día haga frío dentro de mi casa y al día siguiente aparezca en mi correo de Gmail publicidad sobre abrigos y bufandas o pastillas para dejar de fumar, en el caso de que estos sensores detecten que fumo plácidamente en mi sofá.
[Read more…]

Es viernes por la tarde y aunque solo son las tres, iniciamos la parada de los usuarios de los sistemas centrales para lanzar los procesos de copias de seguridad, antes del horario habitual, porque vamos a realizar la instalación de una nueva versión del sistema operativo. Está todo planificado y revisado así que hacia la media noche, deberíamos tener las copias de los datos y programas en los carretes de cinta e iniciar la carga del nuevo sistema operativo. Antes ha habido que añadir el salvado de la configuración del sistema, de los perfiles de usuarios, de sus privilegios de acceso y atributos, de las colas de entrada y salida, etc. Todo ello supone un tiempo extra de copias y de recuperación en caso de tener problemas, cosa que el fabricante del sistema nos garantiza que no va a ocurrir.

Habíamos decidido instalar la nueva versión porque habían bastantes problemas de velocidad en los procesos de backup, que se comían la noche, y para poder utilizar las nuevas unidades de cintas de 8mm era necesario saltar a la versión siguiente del sistema operativo. Esperábamos que a partir de ahí, los backups se acortasen y la disponibilidad del sistema para los usuarios mejorase notablemente, como así fue finalmente, sin necesidad de cambiar la CPU, tal como sugería el proveedor, lo requería la aprobación de un presupuesto mayor para la gestión de los sistemas, que la dirección no estaba dispuesta a aprobar. Dado el riesgo que conllevan estas operaciones, habíamos advertido –por escrito- a los usuarios, durante algunos días, de que mantuvieran el control de su información escrita, por si fuese necesario trabajar manualmente en algún momento.

Hacia las once y media de la noche del viernes lanzamos la primera cinta de carga de la nueva versión del sistema. Nos fuimos a comer el bocadillo porque sabíamos por experiencia que este primer paso era bastante largo. La consola iba dando mensajes y finalmente decía “Este proceso puede durar algunas horas o más” y se quedaba tan fresco. Es una muestra de la traducción del Inglés al Español, tan habitual en la época. Hacia las dos de la mañana, a petición del sistema, pusimos la segunda cinta. Todo iba bien hasta que un llamativo mensaje de error de lectura del soporte nos hizo temblar. Tras reintentar varias veces, el proceso continuó, pero la cinta iba y venía adelante y atrás cada vez que leía un trozo y eso era muy mal síntoma, era claro que el soporte recibido estaba dañado. El caso es que a medio día del sábado, decidimos abortar la instalación y dar marcha atrás ya que el proveedor no tenía otra copia del sistema en Valencia y esta no parecía estar en condiciones de continuar instalándose.

Iniciamos la recarga de la versión anterior y pasamos el resto del sábado y la madrugada del domingo en este proceso. Por la tarde recuperamos configuración, usuarios, etc. Ya parecía que todo iba a ir bien, así que antes de terminar, hicimos algunas pruebas para asegurarnos de que en la mañana del lunes, nuestros problemas serían transparentes a los usuarios. Probamos accesos y procesos con las limitaciones que teníamos y confiamos que el entorno de producción estaría en condiciones.

El lunes por la mañana, los usuarios no podían acceder al sistema. Las autorizaciones y los perfiles parecían no trabajar adecuadamente. Iniciamos contacto con el soporte del proveedor para verificar que habíamos hecho la recuperación correctamente y así parecía ser, sin embargo no dábamos con el problema. Para no aburrir, la conclusión fue que una vez iniciada la instalación de ciertos módulos de la versión nueva del sistema, el proveedor advertía de que no podía garantizar la vuelta atrás, es más, no lo recomendaba. Sin embargo nadie lo sabía, al menos en Valencia y claro ahora habría que instalar la nueva versión cuando dispusiéramos de una cinta en condiciones y eso no sería antes del lunes al medio día. El proceso se repitió entonces y el martes a mitad de mañana todo volvió a funcionar correctamente.

Hasta aquí un relato real, como muestra de que aún haciendo el plan perfecto, puede darse el caso de que los sistemas vitales para la gestión de la empresa, no estén disponibles. Y ¿qué hace el usuario en este caso? Yo solo hablaré de mi experiencia y puedo decir que el usuario no está preparado para que le caigan los sistemas de información y en caso de suceder esto, en un breve plazo se queda bloqueado.

¿Es que el usuario es un irresponsable o un incompetente? NO y rotundamente NO. Lo que ocurre es que conforme los sistemas de proceso de la información lo permiten, la complejidad de los mismos crece y se eliminan elementos esenciales para realizar el trabajo sin ellos, léase personal suficiente para gestionar el negocio a mano, para prevenir cada paso del mismo y documentarlo, para hacer pruebas y entrenar a la gente que procesa la información, para disponer de información alternativa en otros soportes que le permitan organizarse rápidamente y seguir atendiendo a sus clientes sin impacto importante en ellos, etc.

Cuando sucedió lo que he relatado, la dirección de la empresa me llamó para una reunión de crisis. Después de tratar de explicar en lenguaje llano los tecnicismos del problema, y probablemente sin que estuvieran convencidos de que estas cosas pasan hagas lo que hagas para evitarlas, mi pregunta fue: ¿Cuánto le cuesta a la compañía en ventas un día de parada de sistemas? La respuesta era que el impacto es poco sobre el cliente si son solo 24 horas, pero es importante a partir de ahí y crítico si llega a durar 72 horas o más. Entonces ¿debemos asegurar la disponibilidad de sistemas con un margen de parada de 24 horas? pregunté al comité de dirección. SI CLARO, eso es imprescindible, no podemos permitirnos trabajar sin sistemas más de un día entero. Recordarles mi propuesta de mejora de la seguridad y disponibilidad de los sistemas fue fácil porque la tenían hacía meses en un cajón y ahora tendrían que reconsiderarla. Se aceptó un nuevo presupuesto, se instaló un sistema redundante (MIMIX en aquella época) y se mantuvo una copia en línea de las bases de datos y librerías de programas. Desde entonces las crisis tecnológicas dejaron de tener impacto directo en la actividad de los negocios, pero el plan de recuperación de desastres empezó a figurar en la agenda de todos los departamentos ya que siempre pueden darse circunstancias en las que el usuario tendrá que tomar acciones para continuar trabajando, pues el fallo tecnológico es tan solo uno de los posibles problemas que se pueden presentar. Catástrofes naturales, incendio o inundación de locales, o hasta una enfermedad contagiada a la plantilla, son ejemplos de situaciones de riesgo en las que el día a día no permite pensar pero que pueden hacer caer las cifras de un negocio si no se ha previsto como actuar en los casos de crisis.

Los departamentos o personas responsables de la organización de las empresas deben diseñar e implementar los procedimientos necesarios para dar respuesta a las situaciones de crisis y para ello, hay metodologías cuyo uso es necesario y expertos en la materia, cuya participación es recomendable si se desea garantizar un cierto nivel de seguridad en la continuidad de los negocios. Implementar el plan de recuperación de desastres, auditarlo y probarlo periódicamente es la mejor manera de garantizarse la supervivencia ante las crisis no previstas.

Sabemos que las MIFARE Classic están totalmente rotas, como hemos podido comprobar en los posts anteriores de esta saga. Las claves de lectura y escritura de las zonas de memoria son fácilmente recuperables. Ahora nos queda enfrentarnos al último bastión de las tarjetas: el Unique Identification Number (UID).

En el Sector 0 Block 0 de la tarjeta, conocido como el Manufacturer Block es donde podemos encontrar almacenado el identificador único de la tarjeta o UID.

Ese UID es el número de serie de las MIFARE. Cada tarjeta tiene el suyo propio, consta de 4 bytes, y en principio es de sólo lectura.

Por eso las implementaciones que aún se basan en las MIFARE Classic confían en ese número para identificar los usuarios. Podemos fácilmente encontrar sistemas de ese estilo en puertas de acceso y en parkings por ejemplo.

[Read more…]

En esta entrada dentro de la serie de Fundamentos sobre Certificados Digitales nos vamos a centrar en uno de los requisitos fundamentales a tener en cuenta por cualquier Autoridad de Certificación (CA). Este requisito no es una opción, sino una obligación establecida para cualquier normativa o legislación aplicable relativa a la generación y tratamiento de certificados digitales. Estamos hablando de las Declaraciones de Prácticas de Certificación y de las Políticas de Certificación. Como siempre, vayamos paso a paso.

Una Declaración de Prácticas de Certificación (CPS) es un documento propio de cada CA en el que se declaran y establecen un conjunto de compromisos que adquiere la entidad respecto las prácticas para la gestión del ciclo de vida de los certificados digitales que emite, así como un conjunto de medidas de seguridad del entorno. Este documento es en sí un compromiso adquirido, que se referencia al mismo en todos los certificados emitidos en un campo establecido a tal efecto (en próximas entradas detallaremos la estructura estándar de los certificados).

Por otro lado, una Política de Certificación (CP) es del mismo modo un conjunto de compromisos adquiridos por la CA con los usuarios de sus certificados, aunque en este caso, este documento únicamente hace referencia a un tipo concreto de certificados dentro de la jerarquía. Por tanto la Política de Certificación únicamente afecta a una tipología concreta de certificado de CA Subordinada (este concepto se explica de forma detallada en otra de las entradas de esta serie, concretamente la que hace referencia a Cadena de Confianza). Este mecanismo le facilita a la CA la capacidad de establecer unas directivas de certificación globales y comunes mediante la Declaración de Prácticas de Certificación, así como la posibilidad de establecer requisitos concretos para tipos de certificado concreto cuando proceda.

Es importante destacar que en ningún caso es una obligación la implementación de Políticas de Certificación, por lo que se deja a elección de la CA su implementación en base a sus requisitos y necesidades.

El siguiente punto a abordar será, evidentemente, establecer o identificar los contenidos y requisitos que deben cumplir estos documentos. A este respecto, y comenzando por el ámbito Español, la Ley de Firma Electrónica (Ley Orgánica 59/2003) en uno de sus artículos menciona la obligación de construir y mantener publicada en un medio gratuito una Declaración de Prácticas de Certificación. Se puede obtener más información de la presente ley en pasadas entradas de esta serie Ley de Firma Electrónica I y II. Según dicho texto, el documento que debe cumplir al menos con los siguientes requisitos:

• Obligaciones del Prestador de Servicios de Certificación (CA) respecto a los datos de creación y verificación de la firma o certificados expedidos.

• Condiciones para la solicitud, expedición, uso, suspensión y extinción dela vigencia de los certificados.

• Medidas de seguridad técnica y organizativa.

• Roles y responsabilidades del personal implicado en el servicio.

• Condiciones y acceso a mecanismos de información sobre la vigencia de los certificados.

Como último punto determinante, se establece que las Declaraciones de Prácticas de Certificación tendrán validez como Documento de Seguridad en el ámbito de la Ley Orgánica de Protección de Datos de Carácter Personal (Ley Orgánica 15/1999). Sin embargo, y como a más de uno le puede haber parecido, esta especificación es muy generalista, por lo que para alguien que no tenga experiencia en la confección de este tipo de documentos dentro del ámbito de la constitución de una CA puede llegar a ser muy complicado y ambiguo.

Adicionalmente a los requisitos legales establecidos en España, a nivel internacional se han establecido distintos estándares destinados a establecer requisitos mínimos de calidad y seguridad en la implementación y operación de una Infraestructura de Clave Pública (PKI), así como del establecimiento de una CA. Para el caso que nos ocupa, la confección de una Declaración de Prácticas de Certificación, se han establecido diversos estándares, se destacan los siguientes:

• RFC 3467 y RFC 2527: Estos documentos llamados RFC, establecen una guía estricta de los puntos que debe contener una Declaración de Prácticas de Certificación. El primero de ellos, la RFC 3467, se incluye dentro del denominado “Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework”, propuesto por el “Network Working Group”. Relata con un elevado nivel de detalle los contenidos y estructura que debe tener el documento, y se considera un estándar internacional para la construcción de CPS. El segundo de ellos (RFC 2527) es una versión anterior de la RFC 3467, de los que únicamente se identifican algunas modificaciones.

• WebTrust for Certification Authorities v1 CA Business Practices Disclosure Criteria: Del mismo modo que en el caso anterior, la especifiación establece un guión cerrado para los contenidos de una Declaración de Prácticas de Certificación, aunque en este caso se ha establecido por organismos distintos. Concretamente, los responsables de esta especificación son dos organismos estatales en primer lugar el “Canadian Institute of Chartered Accountants” (CICA), y en segundo lugar el “American Institute of Certified Public Accountants” (AICPA). A su vez, es importante destacar que estos organismos son responsables del estándar Webtrust, que marca directivas para la implantación de controles en las CA que regulan desde el ciclo de vida de los certificados digitales hasta las medidas de seguridad a aplicar en su entorno; entre otros puntos.

Nos vamos a centrar en la especificación establecida por la RFC 3467, que en mi humilde opinión, es la de uso más extendido en lo que a CPS se refiere. Dado que se trata de una especificación muy detallada y concreta, se va a abordar a grandes rasgos; así como finalmente, y con el fin de completar la información de esta entrada, se propondrá la lectura (o al menos el repaso), de un ejemplo real de Declaración de Política de Certificación. La especificación de la RFC 3467 se encuentra publicada en el siguiente enlace:

http://www.ietf.org/rfc/rfc3647.txt

En la próxima entrada detallaremos a grandes rasgos el contenido de la RFC, así como mostraremos un ejemplo real de CPS. Muchas gracias por leernos.

Hace ya un tiempo que estamos pensando alguna manera de mejorar en la detección de Malware y APTs y se nos ocurrió montar una sandbox que analizara ficheros automáticamente y nos generará un informe con los datos.

Esta idea no es nueva, es más algunas de las mejores marcas del sector ya ofrecen soluciones de este tipo. También existe una solución gratuita de sandbox.

Básicamente lo que hace este tipo de sandbox es ejecutar ficheros en una máquina virtual y generar informes de los cambios y conexiones que se realizan en este sistema. Una vez ejecutado el fichero la máquina virtual vuelve al estado inicial.

A continuación vamos a ver la instalación y configuración básica de esta sandbox.

[Read more…]

En múltiples ocasiones hemos hablado en este blog de tshark como herramienta de análisis forense de red. Esta herramienta proporciona una versatilidad que se va ampliando con cada nueva versión, donde se le añaden nuevos filtros y mejoras.

Supongamos que nos encontramos analizando un incidente de seguridad en el que tenemos tráfico hacia varios servidores ubicados detrás de una misma dirección IP. Debido a esto, no se puede filtrar por dirección IP así que hay que buscar otra solución. En este artículo voy a mostrar una manera de extraer únicamente aquellos paquetes que están relacionados con un servidor (host) y no con una dirección IP.

Para ilustrar el ejemplo voy a utilizar un archivo de captura de tráfico en formato PCAP descargado desde NETRESEC de una máquina infectada con W32/Sdbot, proporcionado por Russ McRee.

Cuando estamos analizando tráfico hacia un servidor web podemos ver los paquetes enviados por el cliente utilizando el filtro “http.host==” (p.e, http.host==www.age.ne.jp):

El problema es que únicamente se muestran los enviados hacia el servidor, ya que se basa en el parámetro Host de la cabecera HTTP. En el caso en el que queramos capturar también la respuesta podremos utilizar el filtro tcp.stream pero debemos hacer un paso previo; para ello recordaremos este filtro.

El filtro “tcp.stream” es un valor que tshark asigna a los paquetes en función del flujo TCP al que pertenecen, así aquellos paquetes que formen parte de una misma conversación o flujo TCP tendrán el mismo valor.

La idea que pretendemos llevar a cabo es identificar los flujos TCP que vayan dirigidos al host que queremos para, posteriormente, extraer todos los paquetes que sean de esos flujos TCP, no sólo las peticiones HTTP.

Primero listamos el flujo TCP de los paquetes dirigidos al host:

Ahora un poquito de Kung-Fu, y listo:

Lo que se ha hecho en la captura anterior es obtener el mismo listado y realizar otra búsqueda utilizando el filtro tcp.stream con esos valores, por tanto recorremos el archivo un número de veces igual al número de flujos anterior y creamos un archivo (stream{n}.pcap) por cada uno de ellos. Finalmente, se fusionan en un único archivo PCAP con mergecap, llamado www_age_ne_jp.pcap.

Para ver que no sólo tenemos las peticiones al servidor sino también las respuestas de éste, mostramos el contenido del archivo:

Para comprobar que las peticiones son hacia el servidor que queremos mostramos únicamente los campos de dirección IP origen y destino, el host al que va dirigida la petición HTTP y el flujo TCP al que corresponden (el valor tcp.stream varia porque es relativo al propio archivo PCAP, no obstante se puede comprobar que el número de flujos es el mismo):

Por último, como nota añadida a esta manera de extraer aquellos paquetes que nos interesan, recalcar que el archivo se procesa un número de veces igual al de flujos que devuelva la operación anterior. Esto, si el archivo con el que estamos trabajando es muy pesado, puede sobrecargar el sistema.

Para evitar esto, en lugar de utilizar el filtro para un único flujo, se encadenan todos los filtros con un OR y así sólo procesamos el archivo una única vez, aunque se hagan más comprobaciones.

Mientras que el tiempo para ejecutar el comando de la primera manera es:

Quizá éste archivo no sea el mejor ejemplo ya que su tamaño es pequeño, aunque se puede apreciar que se reduce en más de una quinta parte el tiempo real de proceso.

Por experiencia propia, en una búsqueda similar en un archivo de 4 GB la diferencia está entre tres minutos para su ejecución con la primera opción, y no terminar tras más de una hora con la segunda.

Espero que os sirva para futuras búsquedas.

Como bien indica el título, existen sistemas que nos pueden hacer la vida mucho más fácil, sobre todo a la hora de administrar múltiples equipos en lugares como universidades, centros públicos etc…

Este tipo de sistemas protegen nuestra máquina obligando a que sea “autista”, esto quiere decir que todo cambio que se produzca en la máquina volverá a ser subsanado tras su reinicio de forma inmediata.

Esto puede dar muchas ventajas, pero poca libertad al usuario que está usando el equipo. Poca libertad porque no va a poder guardar ningún cambio en el equipo, pero si en una unidad de almacenamiento propia, por ejemplo un pen drive USB.

Las ventajas son varias, ya que un usuario poco experimentado puede borrar un archivo de configuración que no debe, o puede infectar la máquina con un virus porque el pen drive que ha introducido estaba infectado, porque ha abierto un correo que no debía o porque ha visitado una URL que era de carácter malicioso y en cada uno de estos casos, se podrá restaurar el sistema inmediatamente.

No hay problema porque siempre que ocurra algo así con solo reiniciar el sistema queda como al principio, es como si se clonara el disco, o discos duros, justo cuando está todo instalado y en perfecto funcionamiento y cada vez que reiniciamos esa imagen se restaurase de nuevo, pero sin esperar.

Estos sistemas se venden en el mercado y los hay de diversos tipos, ya que pueden funcionar únicamente por software, pero los hay que también funcionan por hardware.

¿Dónde es conveniente usar este tipo de sistemas? Pues en universidades, colegios, centros públicos etc…, zonas donde los ordenadores están expuestos a todo tipo de personas.

Existen productos como Custodius:

Este tipo de tarjetas, con conexión PCI, permite la restauración instantánea al reiniciarse el equipo (sólo en sistemas Windows). Para poder hacer cambios en el sistema, sólo hace falta pulsar las teclas ctrl+enter al inicio e introducir la contraseña de administración, entonces se entra en modo supervisor para poder guardar los cambios necesarios.

La restauración no tiene por qué ser sólo instantánea, también puede ser desde un backup o respaldo, y aquí sí que se incluyen sistemas UNIX, Linux y Windows.

La protección se puede hacer sólo de una partición o disco determinado o de todos los discos y particiones que tenga el sistema (soporta hasta 48 particiones y hasta 3 discos). Además es capaz de proteger la BIOS para que no se produzcan cambios en ella.

Obviamente toda esta protección no vale de nada si alguien con un simple destornillador puede extraer la tarjeta, por lo tanto esto tiene que ir acompañado de un sistema de sellado del equipo que impida que se abra la torre del equipo de forma sencilla.

Otra función que contempla es la de SNCOPY, donde un equipo ya configurado es capaz de funcionar conjuntamente con la tarjeta de red y clonarse en otros equipos con las mismas tarjetas, configurando así muchos equipos clonándose la configuración del anfitrión.

Otro producto de características parecidas es Deep Freeze. Funciona sólo por software y de forma parecida a Custodius, ya que al reiniciar el sistema vuelve a restaurar todo. Éste software “congela” la configuración del sistema, pero deja que los cambios por parte del usuario se produzcan por ejemplo en una unidad de red remota o en un espacio “descongelado”.

Esta empresa además presume de poder proteger el MBR (Master Boot Record), de inserciones de rootkits.

Aunque, esto no es del todo cierto, ya que según un artículo publicado en la página http://securitylabs.websense.com/ se hace un análisis sobre una variante de un malware llamado Robot Dog (malware destinado sobre todo a atacar a China y en concreto a cibercafés). Que es capaz de hacer que el software de recuperación no actúe correctamente.

El proceso es algo largo de explicar pero se puede ver en este link.

Con lo cual queda en evidencia la posible efectividad, de este tipo de herramientas que funcionan únicamente vía software, ya que pueden ser vulnerables a los kernel rootkits.

Esto surgió entre el año 2006 y 2008, se buscaron medidas para solucionar el problema en este tipo de software. Entre estas medidas están las llamadas AE: anti-execution., que en resumen vienen a decir que la responsabilidad de lo que se ejecuta en la máquina recae sobre el usuario, con lo cual estamos en las mismas.

De todas maneras este tipo de malware es efectivo si se llega a ejecutar con permisos de administrador, con lo cual es difícil que en un aula o colegio pueda suceder, ya que la mayoría de las veces se estará ejecutando con una cuenta de usuario limitada.

En el caso de tarjetas como Custodius, no deberían ser vulnerables a los kernel rootkits, pero si a los BIOS rootkits. A pesar de que en su web aseguran que protegen la BIOS, existen comentarios en foros de gente que ha actualizado la BIOS del equipo con la tarjeta puesta y que los cambios se han hecho efectivos.

La existencia de BIOS root kits es una realidad, y existen ejemplos como Mebromi (or MyBios), que ataca a BIOS AWARD (Phoenix Technologies).

A pesar de que es difícil que un equipo se infecte con este tipo de rootkit, siempre es conveniente usar sistemas reboot and restore, a modo de complemento.

Por ejemplo si el uso es en un aula universitaria, sólo el encargado del aula debe tener y usar la clave de administrador, la cual solo se usará en caso estrictamente necesario. Por otro lado, solo se usará modo supervisor en caso de necesidad absoluta de instalar un software determinado y a poder ser sin estar conectado a internet (sí en el caso de las actualizaciones de adobe, java o del propio sistema operativo), y por supuesto complementar toda esta seguridad conjuntamente con un firewall personal / antivirus. Además se deberá proteger la entrada en la BIOS mediante un password, así como la entrada en el modo supervisor de nuestro sistema de recuperación, y tener la caja del equipo totalmente sellada para impedir que nos sustraigan la tarjeta PCI o que hagan un clear CMOS.

En caso de que sea estrictamente necesario actualizar la BIOS del equipo, deberá hacerse con sumo cuidado y sólo conseguir el software de la página oficial del fabricante.

Otros sistemas conocidos, son por ejemplo Rollback RX PC que usa un sistema de instantáneas que se pueden recuperar en cuestión de segundos y no consumen casi recursos del sistema. Tiene la posibilidad de cifrar estas instantáneas con cifrado AES 256, para que en caso de robo del equipo, protegernos de que un extraño pueda hacer una restauración.

Otra herramienta conocida es Shadow Defender, que ejecuta el sistema en modo “Shadow mode”, que básicamente lo que hace es virtualizar parte del sistema, justo donde se realizan cambios. En caso de querer volver a un estado anterior, basta con reiniciar el sistema.

Otra opción interesante es Sandboxie actúa de forma parecida a los anteriores, es un sistema tipo sandbox que hace algo parecido a la virtualización por aislamiento, pero en este caso se crea “un contenedor”, donde se ejecutan los programas de aplicación. Además evita la inyección en el kernel de Windows.

En este enlace de YouTube se pueden ver diversas pruebas con varios de los programas mencionados antes, donde se ponen a prueba con virus de diversa índole.

Hoy vamos a hablar de una herramienta gratuita que puede servirnos de alternativa al conocido Splunk para realizar análisis de logs de forma rápida y sencilla.

Logstash es una aplicación de Java que podemos lanzar en cualquier equipo con una versión actual de Java, y que gracias al servidor de búsqueda ElasticSearch que incorpora, puede ampliarse y desplegarse en infraestructuras complejas con múltiples nodos trabajando en paralelo.

Para mostrar su funcionamiento no necesitamos hacer un despliegue tan complejo, y vamos a aprovechar la funcionalidad autocontenida en el paquete descargable, para analizar un conjunto de ficheros de Apache en busca de patrones sospechosos.

[Read more…]

Si los mecanismos de seguridad son complejos de usar, pierden su efectividad, ya que nadie los usará. Si se fuerza su uso, se intentarán otros canales para conseguir la misma funcionalidad.

La ciberseguridad ha sido, desde sus comienzos, una auténtica carrera armamentística. Si la entendemos como la protección de la información que una organización mantiene, tanto en su custodia como durante su transmisión, podemos incluir desde los primeros intentos de ocultar mensajes secretos a ojos de los no autorizados, cifrándolos u ocultándolos, hasta los mecanismos de los gobiernos para espiar las transmisiones de los enemigos, tanto en la guerra como en la paz.

Así, siempre que un cerebro humano ha pensado en una forma de proteger una información, otro cerebro igualmente inteligente, ha sido capaz de encontrar el medio de saltarse la protección. Al final, se trata de una cuestión de economía, como casi todo. ¿Vale la información que se puede robar el esfuerzo necesario para romper los mecanismos que la protegen? Este hecho económico básico es, a veces, intuitivamente engañoso. Muchas personas piensan que su información tiene poco valor (cosa en la que, normalmente, aciertan) y que, dado que la protección utilizada requiere un esfuerzo no trivial para romperla, están a salvo del acceso no autorizado.

Pues bien, probablemente, no valga la pena hacer el esfuerzo para romper el mecanismo que protege esa información, pero, como resulta que el mismo mecanismo (relativamente débil) es utilizado por muchas personas, el coste unitario se reduce a niveles risibles y, por poco que sea el provecho obtenido, el rendimiento obtenido es alto.

Así pues, ¿debemos usar mecanismos más complejos? Sin duda, si nos importa algo la información protegida. Ahora bien, si estos mecanismos no se hacen más fáciles de usar, pueden pasar dos cosas:

Una: que no se utilicen, con el consiguiente riesgo que, seguro, acabará materializándose y reducirá fuertemente la confianza en las transacciones en la red.

Dos: que, al ser incómodo, sólo se usen para casos muy especiales, con lo que disminuye drásticamente la funcionalidad de Internet, reduciéndolo casi a un sistema de consulta de información y compartición de información banal.

En resumen, si queremos que Internet permita un amplio conjunto de funcionalidades y transacciones, de manera segura, que realmente facilite nuestra vida, tenemos que diseñar mecanismos de protección tan usables como eficaces.

Es preciso acabar con la creencia de que la seguridad está reñida con la funcionalidad.