Secure software development

Introducción.

• Contrato de licencia Vs. contrato de desarrollo.

• Licencia: contrato de adhesión, ¿responsabilidad del licenciante?, usos restringidos.

• Desarrollo: negociación entre las partes: ¿titularidad? ¿licencia?

1. Perspectiva de los derechos de autor.

• Artículo 29, Ley 23/82: obra por encargo.

– Por cuenta y riesgo del contratante.

– Remuneración del autor: honorarios, no regalías.

– Derechos morales del autor.

– Derechos patrimoniales cedidos en virtud de la ley.

– Registro, para fines de publicidad y oponibilidad frente a terceros.

• Titularidad: contractualmente, y de hecho, debe ser claro que el contratante corre con gastos y riesgo.

• Garantías: punto clave en negociación: ¿obligación del contratista es de medio o de resultado? ¿Cuánto tiempo de soporte post venta?

• Entrega del código fuente.

2. Aspectos de seguridad.

“An external attacker’s first measure of success is to gain the credentials of internal, legitimate users.”

“Today, the path of least resistance to this goal is not the network gear, not crypto-mathematics, nor bribery; it is application software.”

-- Germanow et all

• Ataques dirigidos contra errores de programación en las aplicaciones son causa del 90% de los incidentes de seguridad.

• Al software defectuoso se debe el 75% de todas las vulnerabilidades.

• Intel aplicó 2.4 millones de parches a sus redes.

• Un scan de 470 máquinas demostró que se necesitaban 8,000 parches.

• Una organización con 100,000 IPs podría recibir 2.3 millones de vulnerability probes por día.

• El Aberdeen Group estimó que el costo total de administración de vulnerabilidades en empresas americanas en 2002 fue de US$3.5 billones.

• Qué es una vulnerabilidad?

• CERT/CC:

• Usualmente provocada por un defecto de software.

• Viola política de seguridad.

• Defectos similares son clasificados como la misma vulnerabilidad.

• Suele provocar comportamientos inesperados.

• Gracias a ellas existen los troyanos (attachments maliciosos), virus y worms y las herramientas de intrusión (scanners, rootkits).

• Ejemplos de defectos:

– Errores de autenticación de usuarios.

– Errores al cifrar o proteger datos sensibles.

• Buffer overflow (escritura de datos por encima de los límites de memoria localizada para una estructura de datos): causado con o sin intención.

• Herramientas de análisis de código:

• RATS .

• Flawfinder.

• ITS4.

• ESC/Java.

• Project Fluid.

• ¿Cuál será la plataforma? ¿Por cuánto tiempo aún será soportada por el fabricante?

• Personnel background check.

• Principios de diseño de herramientas:

• Economía: tan simple y pequeño como sea posible.

• Decisiones sobre acceso basadas en permisos, no en exclusión.

• Cada acceso a cada objeto debe tener chequeo de autorizaciones.

• El diseño no debe ser secreto.

• Separación de privilegios: doble llave de acceso (no una sola).

• Principios de diseño de herramientas:

• Cada miembro del equipo debe tener la menor cantidad posible de privilegios para completar la labor.

• Aceptación subjetiva: interfaz amigable para que los usuarios, rutinariamente, apliquen correctamente los mecanismos de seguridad

Noopur Davis

Carnegie Mellon University/2004

Conclusiones

• Titularidad del programa? Código fuente?

• Realizar tests e inspecciones, usar herramientas de análisis de código, aplicar los principios de diseño y administrar el riesgo.

• Contratante debe exigir, según sus necesidades, niveles de seguridad apropiados; requisito: estudio de riesgo previo.

• ¿Obligaciones de resultado?