Ingeniería inversa en Bluetooth

Seguimos con temas de ingeniería inversa, descubrimiento de capacidades ocultas y esas cosas. En Introduction to Bluetooth RFCOMM Reverse Engineering algunas pistas sobre el tema.

Anuncios

Formación en Ingeniería del Software

A pesar de que me dedico a ello, en esta bitácora no suelo hablar mucho de formación y enseñanza. En todo caso, vi If You’re Going to Teach an Undergrad Intro to Software Engineering… y pensé que aunque no es un tema de mi especialidad debería guardarlo en algún sitio. ¿Cuál mejor que este?

Además, me ha interesado que varias referencias tratan sobre desarrollo de software libre, lo que me parece un plus.

Desarrollo ágil y seguridad

Ya hace algún tiempo que tenía estos enlaces. pero necesitaba un ratito para recopilarlos porque andaban dispersos por ahí. Llevamos unos años hablando de metodologías ágiles de desarrollo (en contraposición con otras metodologías más pesadas y tradicionales). Pero yo no había visto mucho de cómo introducir la seguridad en estos contextos. Hasta que encontré estos textos, que comparto aquí:

Agile Security – Requirements. En el resumen:

As a product owner you have scores of tools and processes to help you find vulnerabilities after they’ve been coded. Adopting security throughout the SDLC is cost effective, but difficult in practice to implement for agile shops. Security requirements, in particular, are difficult to prioritize or scope in early iterations. You can make the task more manageable by prioritizing requirements that prevent exploitable flaws, sorted by risk.

En Agile Security – Product Owner’s Perspective continúa, en este caso con lecturas recomendadas, motivaciones y consejos. Aunque prometen más, parece que la serie no ha seguido, siendo el último articulito uno genérico, que no habla de seguridad ágil, sino algo más genérico: Software Security Throughout the Life Cycle: 9 Steps.

Ahora ustedes podrían sentirse decepcionados por la escasez de los recursos aportados (o no). Para que eso no suceda, y como tenía más artículos recopilados, van a continuación.

En Secure software development and agile methods – notes unas notas sobre el tema, a partir de una sesión dedicada al tema en Finlandia, en la que participaba gente de Nokia (¿Nokia ágil?) y de F-Secure. Está resumida pero va bastante al grano y además se pueden descargar las presentaciones que se utilizaron.

Haciendo una búsqueda en Google encuentro el The Agile Security Forum al que habrá que echar un ojillo con más calma. Microsoft también tiene un documento en Streamline Security Practices For Agile Development donde tratan de encajarlo con su SDL (Secure Development Cycle). Finalmente (por acabar, no porque no haya más documentos sobre el tema), en Agile Security Engineering J.D. Meier también aporta su punto de vista.

Redes sociales y personas atractivas

Ya hace unos meses comentábamos en Redes sociales: los expertos también caen sobre un experimento en el que algunos expertos en seguridad eran engañados por una presunta experta en seguridad de aspecto atractivo que conseguía más contactos e información de la que debería haber sido razonable.

Por eso cuando vi El 94% de los usuarios de Facebook aceptaría una solicitud de amistad de un desconocido atractivo, según demuestra un estudio de BitDefender pensé que sería bueno nombrarlo, aunque sea como referencia y porque, además, se abundaba en el mismo tema:

El “nivel de escepticismo” vs. Intereses/trabajos de los “nuevos amigos”, reveló resultados sorprendentes: más del 86% de los usuarios crédulos que aceptaron ser amigos del perfil de prueba provienen de la industria tecnológica, el 31% de ellos trabajan en la seguridad informática. Este resultado fue inesperado, ya que casi todas las compañías de seguridad hacen hincapié en las amenazas asociadas con las redes sociales.

¡Cuidadín!

Seguridad de los productos relacionados con la seguridad

Me suena haberlo comentado alguna vez, pero no lo encuentro. En How To Secure a Security Product And Whose Bug Is It, Anyway? se comenta sobre el tema que aparece de vez en cuando por ahí: no todas las empresas que desarrollan productos de seguridad la tienen en cuenta en sus desarrollos. No es raro ver un antivirus, un cortafuegos o cualquier otra herramienta de este estilo en las bases de datos de vulnerabilidades, mostrando despistes en programadores (y sus empresas) que deberían ser más conscientes que el programador medio de los problemas que puede haber.

En el artículo se comentan las prácticas que deberían seguir estas empresas y casi acaba:

How does this arguably incomplete list differ from what other (non-security) software vendors should do? From a pure security perspective, it really doesn’t, as any product running on a computer – regardless of its declared function – can provide an entry point for attackers, although products running with higher privileges (which security products often are) are more risky. But from the business perspective, security software vendors will be smart to go an extra mile. Security is their sole functionality and their only purpose. It’s hard to convince a customer that you will secure their system if you can’t seem to be able, or willing, to secure your own product.

Seguimiento y comprensión de fallos relacionados con la seguridad

Uno de los problemas cuando nos entra la preocupación por el desarrollo seguro es integrarlo en las rutinas habituales de ingeniería del software: a los fallos y sus medidas habituales (pruebas y todo lo relacionado) se añaden los fallos de seguridad que también son fallos, con características un poco especiales. Robert Auger nos cuenta en Tracking and understanding security related defects algunas ideas sobre el tema: básicamente integrarlos en el sistema de seguimiento de fallos (bug tracking) y marcarlos adecuadamente (o además) como fallos de seguridad para que podamos hacer un seguimiento (sin olvidar que algunos fallos de seguridad no se marcarán como tales) y también hacer algo de pedagogía (proporcionando listas de fallos frecuentes, apoyo a los desarrolladores que controlen todavía mucho de estos temas, vigilancia sobre si se están tratando adecuadamente …).

Redes sociales: los expertos también caen

Social es otro de los apellidos ‘infames’ que le colocan a la Ingeniería. El otro que me viene a la cabeza y que me sabe todavía peor es el de Financiera. Parecen aplicarse a cosas complicadas y sofisticadas, difíciles de controlar para el común de los mortales y que tienen efectos negativos en la sociedad. Pero me desvío.

En el artículo [PDF] Getting In Bed with Robin Sage hablan de un experimento que consistió en crear un perfil de experta en seguridad con la foto de una chica atractiva, hacerla amiga de unos cuantos expertos ‘mediáticos’ (que, por definición, serían menos vigilantes a la hora de aceptar amistades) y, a partir de allí, ver qué pasaba.

Esencialmente, parece que algunos (no está cuantificado) de los expertos trataron de relacionarse con ella más allá de lo que sería esperable (ofreciéndole trabajo, información y quién sabe qué más…) y otros (tampoco cuantificados) detectaron rápidamente el engaño.

En la línea que ya hemos comentado otras veces de algunas empresas de seguridad de querer ganar notoriedad a base de ‘estudios’ pero con una conclusión esperable: los expertos en seguridad no gestionan mejor que los demás su ‘estancia’ en estos sitios.

En The Robin Sage experiment: Fake profile fools security pros un resumen periodístico.

Bola extra: como dicen en alguno de los comentarios y nos confirma la Wikipedia, Robin Sage es una fase del entrenamiento militar que dura cuatro semanas con ejercicios similares a los de una misión real, lo que habría de haber levantado sospechas para los expertos relacionados con las fuerzas armadas (o confianza, por manejar lenguaje interno, quién sabe) y que claramente debería haber sido identificado por algunos de ellos.

Cuidado con quién hablas

En Automated social engineering PoC successful on Facebook and IRC resumen un curioso sistema para engañar a la gente e inducirles a pinchar en enlaces maliciosos. De todos es sabido que es bastante difícil hacer un robot que mantenga una conversación normal. Los autores de Honeybot, Your Man in the Middle for Automated Social Engineering (pdf) pensaron una solución mejor: el bot contacta con dos personas y simplemente hace de intermediario de la conversación; con esto se ahorra la parte de ‘inteligencia’ necesaria para hacer creer a alguien que está hablando con una persona (porque realmente lo está haciendo) y le permite incluir enlaces, influir en el tema de conversación, alargarla …

Muy ingenioso e interesante. La prueba de concepto está hecha para el IRC pero han hecho algún experimento también en Facebook.

Métodos formales y desarrollo

No se si es mi impresión o realmente estamos volviendo a prestar atención a los métodos formales para desarrollar programas. En todo caso, un par de artículos recientes sobre el tema: Really Rethinking ‘Formal Methods’ (si no se puede descargar de ese enlace es fácil de encontrar por ahí; si no, seguro que conocen a alguien que se lo puede pasar ;) ) que se pregunta por qué los métodos conocidos no han sido adoptados y traza una panorámica. Además, Formal methods versus engineering donde se incide en que estos temas deberían formar parte de lo que aprenden los estudiantes, incluyendo las matemáticas necesarias.