Los diez mandamientos de seguridad en desarrollo de programas

En The Ten Commandments for Software Security, bastante centrados en gestión del proceso y esas cosas, según lo aprendido con BSIMM, del que ya hemos hablado en vidas anteriores, en BSIMM, SAFEcode y otros.

0. Thou shalt lead thy software security initiative (SSI) with a software security group (SSG).
1. Thou shalt rely on risk management and objective measurement using the BSIMM—not “top ten lists” and vulnerability counts—to define SSI success.
2. Thou shalt communicate with executives, directly linking SSI success to business value and comparing thy firm against its peers.
3. Thou shalt create and adopt an SSDL methodology like the Microsoft SDL or the Cigital Touchpoints that integrates security controls (including architecture risk analysis, code review, and penetration testing) and people smarter about software security than the tools they run.
4. Thou shalt not limit software security activity to only technical SDLC activities and especially not to penetration testing alone.
5. Thou shalt grow and nurture software security professionals for thy SSG (since there are not enough qualified people to go around).
6. Thou shalt consume direction from the business and intelligence from operations and incident response staff, and adjust SSI controls accordingly.
7. Thou shalt track thy data carefully and know where the data live regardless of how cloudy thy architecture gets.
8. Thou shalt not rely solely on security features and functions to build secure software as security is an emergent property of the entire system and thus relies on building and integrating all parts properly.
9. Thou shalt fix thy identified software defects: both bugs and flaws.


Una botnet de televisores

Otra más para el tema de cacharritos programables que nos pueden causar problemas: TV-based botnets? DoS attacks on your fridge? More plausible than you think.

Si se puede programar, se puede comprometer. Si puede comprometerse alguien lo hará. Alguna prueba ya hay hecha por ahí:

The TV was connected by ethernet cable to a home network, so Auriemma thought it would be funny to use a computer connected to the same network to send it a message that contained a series of custom headers. Without warning, the TV spiraled into an endless loop of restarts. For about five seconds, the device would appear to work correctly, but then would stop responding to commands entered by remote control or through the panel. A few seconds later, the TV would restart and repeat the process. Unplugging the power cord or ethernet cable did nothing. Auriemma had just stumbled upon a crippling denial-of-service attack.

En Seguridad ‘hogareña’ recopilamos en su día enlaces sobre el tema.

Sigan vigilantes.

El código peor… el que hacen los gobiernos

En Study
Confirms The Government Produces The Buggiest Software
hablan del tema
del desarrollo de aplicaciones analizando un conjunto de aplicaciones:

In a talk at the Black Hat Europe security conference in Amsterdam later this week, security researcher and chief technology officer of bug-hunting firm Veracode Chris Wysopal plans to give a talk breaking down the company’s analysis of 9,910 software applications over the second half of 2010 and 2011, automatically scanning them for errors that a hacker can be use to compromise a website or a user’s PC. And one result of that analysis is that government software developers are allowing significantly more hackable security flaws to find their way into their code than their private industry counterparts.

E inmediatamente:

According to Veracode’s analysis across industry and government, fully
eight out of ten apps failed to fully live up to the company’s security
criteria. But breaking down the results between U.S. government and private
sector software, the government programs, 80% of which were built for
federal agencies rather than state or local, came out worse. Measuring its
collection of apps against the standards of the Open Web Application
Security Project or OWASP, Veracode found that only 16% of government web
applications were secure, compared with 24% of finance industry software
and 28% of commercial software. And using criteria of the security-focused
education group SANS to gauge offline applications, the study found that
18% of government apps passed, compared with 28% of finance industry apps
and 34% of commercial software.

Como casi siempre, el diablo está en los incentivos (quién hace qué, por qué y cuáles son sus motivaciones):

Those incentives have led to government bugs persisting even as the rest of the industry starts to clean up its act, says Veracode’s Wysopal. While SQL injection and cross-site scripting vulnerabilities have have dropped off in private industry over the last two years, they’ve remained statistically flat for governments.

A mi me recuerda los estudios aquellos sober las políticas de claves en los sitios web que comentamos en Contraseñas, usabilidad y uso: los sitios web gubernamentales eran los que tenían políticas más restrictivas, sin mucha evidencia de que eso mejorara la seguridad.

¿Hay que actualizar?

En Do You Always Need to Install Software Updates? se preguntan sobre el tema. Se empieza diciendo que se considera una buena costumbre tener los programas al día pero luego habla de un resultado presentado en un congreso:

Otherwise than you might expect, the results (presented at DIMVA 2011 in Amsterdam, The Netherlands) showed there is no significant difference in the amount of malware on patched computers compared to unpatched computers.

Parece que no es así, y que no parece haber un impacto significativo desde el punto de vista de la actividad de los ordenadores de los usuarios. Lo que sí que afectaría serían las ‘prácticas de riesgo’ (visitar determinados sitios, que son fuentes sistemáticamente de infección).
El artículo también habla de los problemas de las actualizaciones (por ejemplo, los programas que dejan de funcionar).

El artículo puede descargarse de [PDF] An Assessment of Overt Malicious Activity Manifest in Residential Networks y la presentación de [PDF] An Assessment of Overt Malicious Activity Manifest in Residential Networks slides.

Hemos hablado varias veces de actualizaciones, en Las actualizaciones, o en Adobe: parches automáticos para sus productos, o La seguridad, los navegadores y las actualizaciones y varios más sobre actualizaciones.

Gestión de claves en los programas

En seguridad siempre hay que ponerse en lo peor (aunque sea difícil). Sobre todo, si es fácil evitar los problemas que podrían ocurrir. Algo que solemos comentar es que cuando se lea una clave se haga lo que sea con ella y la eliminemos de la memoria lo antes posible (para evitar problemas con escrituras a disco por diversos motivos: el ‘swapping’ del sistema operativo, volcados de memoria ante fallos, …

Son ese tipo de cosas que suenan más teóricas que realistas pero en el ‘mundo real’ ™ Passwords left in memory using SSH keyboard-interactive auth podemos ver como realmente alguien las toma en serio. En este caso, los desarrolladores de Putty.

Hacer ruido para evitar desvelar secretos

Ya hace algún tiempo hablamos del estudio aquél que decía que los dispositivos táctiles dejaban rastro del patrón utilizado para desbloquear en Dispositivos: dejando rastro. En Android and data loss protection nos dan una solución de baja tecnología para evitar el problema: marcar un pin, pasar el dedo por toda la pantalla (ayudados por ciertos patrones que se aseguran de que la recorremos -ensuciamos- toda…). Es una solución de baja tecnología en el sentido de que ni siquiera necesitaríamos el programita para hacerlo (un poco de disciplina es suficiente). Pero siendo como somos, parece una buena idea.

A mi me ha recordado, en otro orden de cosas el texto aquel de ¿Derecho al ruido 2.0?.

Sobre la difusión de gusanos y otros programas malévolos

En How to 0wn the Internet in Your Spare Time algunas cifras interesantes de difusión de diferentes gusanos y programas maliciosos y cómo algunos se quedan en la red disponibles para infectar a cualquiera que no ande protegido, incluso después de mucho tiempo:

In this paper we have examined the spread of several recent worms that infected hundreds of thousands of hosts within hours. We showed that some of these worms remain endemic on the Internet. We explained that better-engineered worms could spread in minutes or even tens of seconds rather than hours, and could be controlled, modified, and maintained indefinitely, posing an ongoing threat of use in attack on a variety of sites and infrastructures. Thus, worms represent an extremely serious threat to the safety of the Internet. We finished with a discussion of the urgent need for stronger societal institutions and technical measures to control worms, and sketched what these might look like.

Algunos se propagan en minutos o segundos.

Las cláusulas de venta

Es habitual que los programas tengan cláusulas del estilo de: ‘usa el programa según tu propio criterio. Si algo no va como esperas no es culpa nuestra’. En High Court rules software liability clause not ‘reasonable’ nos cuentan como un tribunal falló que esa cláusula no era razonable, porque la demostración del software a la hora de la venta no había sido hecha en condiciones similares a las reales:

If a software publisher wants to make a customer responsible for product choice it has to give the customer a fair chance of assessing the product, Greenbank said.

“When demonstrating a software product, select a demonstration or reference site that shows the software being used in a similar environment to your customer’s,” he said. “In this case the judge found that the demonstrations were ‘incomparable’ and failed to show the potential problems and limitations of the software and how to deal with them.