Y seguimos con ataques de fuerza bruta al SSH. En este caso nos lo cuentan en El extraño caso del SSH y el ataque de fuerza bruta donde se cuenta otra batallita de intentos de acceso por SSH, uso de un equipo para lo que no se debe y el tiempo perdido tratando de encontrar el problema.
Me entero de una noticia de (más o menos) actualidad, para variar. INTECO presenta el Estudio y la Guía sobre tecnologías biométricas aplicadas a la seguridad.
Se pueden descargar tanto el estudio como la guía y pueden ser un buen
resumen sobre estos temas.
Dicha investigación se centra en los usos, beneficios, riesgos y buenas prácticas recomendadas en el uso de la biometría aplicadas al control de identidades y control de accesos. El objetivo es dar a conocer a las empresas y los usuarios el nivel de desarrollo y confianza de las tecnologías biométricas y asegurar que su implantación se realice respetando plenamente la seguridad de la información y la privacidad de los ciudadanos.
Yo, por completar, añadiría estos enlaces (seguramente están comentadas estas ideas en los informes, no los he leído aún):
Y un par de vídeos:
¿Soy contrario a la biometría? No, pero hay que hacer estas cosas con cuidado. A veces, entran más bien en el Security Theater.
Estas listas siempre tienen sus defectos. Fundamentalmente, muestran los sesgos de los que las hacen. No obstante, también nos dan una idea de por dónde van los tiros en cada momento. En The ABZs of Cybersecurity el punto de vista de Pete Herzog. El foco en:
As you will see, we put a lot of stress in responsibility and accountability rather than just listing bad things that can happen to them. This type of treatment has had great success in helping people with bad habits and phobias. The benefit of this is to help them to control things they can control yet not completely give up most the things they enjoy doing. That means changing how they do the things they do instead of what they do. Since a person’s nature is hard (impossible?) to actually change, we just want them to be aware of what the consequences are and how to avoid them even if just partially.
Trazabilidad, responsabilidad, contabilidad…
Ya hace algún tiempo (y en otro lugar) hablábamos de la Computación parásita. También de Leech Computing. Esencialmente, utilizar los recursos de un ordenador que se conecta al nuestro para hacer cálculos u operaciones.
En How Wikipedia could make the world an even better place volvían a traernos esas ideas, aprovechando la ingente cantidad de visitantes que tienen las páginas de esta enciclopedia.
En Browser-based distributed evolutionary computation: performance and scaling behavior publicamos algunos resultados alrededor del tema.
En ¿Me prestas unos ciclos? Hacia el supercomputador sigiloso una charla más divulgativa sobre el tema, por si a alguien le interesa.
En [PDF] “These Aren’t the Droids You’re Looking For”: Retroffiting Android to Protect Data from Imperious Applications un estudio bastante interesante sobre aplicaciones Android para los teléfonos y su ‘hambre’ de datos.
First, we provide the deepest study to date (to our knowledge) of information exposure by Android applications in terms of types of information investigated, forms of exposure including encryption, and exposure patterns to advertisign and analytics servers
De las 110 aplicaciones estudiadas, 31 envían el IMEI del dispositivo. De ellas 14 lo envían a servidores de analítica y publicitarios.
Como resultado de la investigación, también ofrecen AppFence: Protecting User Data from Android Applications, una aplicación que sustituye datos sensibles por otros para que las aplicaciones los envíen y, además, bloquea transmisiones de red que contienen datos del usuario que han sido marcados como de uso exclusivo por el usuario en el dispositivo.
No la he probado.
Interesante trabajo de Zhaoguang Wang y otros de la Universidad de Michigan y también de Microsoft: diseñaron un app para teléfonos móviles que medía algunos parámetros de red, con el objetivo de conocer si las telefoneras lo alteran o adaptan de alguna forma y la conclusión es que, en general, lo hacen. Primero, una justificación de por qué puede ser y los problemas que pueden introducirse:
To better utilize their limited network resources while securing the network and protecting client devices, the carriers have already deployed various network policies that influence traffic behavior. Today, these policies are mostly opaque, though they directly impact application designs and may even introduce network vulnerabilities.
Tantas veces hemos visto eso… Por necesidades propias, o incluso en nuestro beneficio, terminan perjudicándonos.
Algún ejemplo:
… in more than 100 cellular ISPs, we identified the key NAT and firewall policies which have direct implications on performance, energy, and security. For example, NAT boxes and firewalls set timeouts for idle TCP connections, which sometimes cause significant energy waste on mobile devices. Although most carriers today deploy sophisticated firewalls, they are still vulnerable to various attacks such as battery draining and denial of service.
Pero hay bastantes más ‘actividades’.
Vale la pena echarle un ojo en [PDF] An Untold Story of Middleboxes in Cellular Networks o echarle un ojo al resumen que puede verse en el material utilizado en la presentación [PDF] An Untold Story of Middleboxes in Cellular Networks (slides).,
Ya habíamos hablado del proyecto AppSensor, de OWASP (en Sensores en aplicaciones: detección de problemas y respuestas) así que cuando vi el artículo [PDF] Creating Attack-Aware Software Applications with Real-Time Defenses pensé que a lo mejor había algo de código para entender mejor el proyecto. No es así, pero sí que es un artículo más explicando las ideas que hay detrás de esta aproximación a la seguridad en aplicaciones.
En NoSQL, But Even Less Security, un resumen de este tipo de bases de datos de lsa que tanto se habla últimamente.
También se puede ver la presentación en [PDF] NoSQL, But Even Less Security.
Revisando el baúl de los recuerdos (esas lecturas que se quedan en el kindle pendientes de algo) rescato este informe del INTECO: [PDF] Seguridad en sitios web con consejos a tres niveles:
- Detección de los ataques
- Minimizar los daños producidos por un ataque
- Puesta en marcha de medidas preventivas para evitar que un sistema llegue a estar comprometido
