1. Desarrollo de software seguro
Medidas a tomar en cuenta.
Unas de las grandes necesidades en el desarrollo de software web/desktop es la
falta de seguridad. La seguridad en un software es clave principal para la
sostenibilidad y ciclo de vida del mismo pues nadie confía en las inseguridades que
nos ofrecen.
En esta guía vamos a resumir los principales puntos y herramientas necesarias para
el desarrollo de un software seguro tanto para el ambiente web como para
aplicaciones de escritorio y/o aplicaciones de software libre, todo esto guiado a un
entorno empresarial, administrativo y de madurez.
Algunas preguntas que debemos hacernos cuando vamos a construir un software
seguro.
• ¿Diseñado, construido y probado para su seguridad?
• ¿Continúa ejecutándose correctamente bajo ataque?
• ¿Diseñado con el fallo en mente?
¿Qué debemos conseguir para crear un software seguro?
• Adoptar un modelo de madurez de desarrollo de software
• Debemos considerar la seguridad del software desde el principio hasta el final
Todas estas preguntas nos guían a un solo camino, Modelos de seguridad y me refiero en
plural a este porque no solo nos debemos guiar por un solo modelo sino que debemos
explorar los mejores modelos para saber cuál es el que más se ajusta a nuestras
necesidades para hacer una buena práctica del desarrollo de software seguro.
2. S-SDLC (Secure Software Development Life Cycle) Como clave de para el desarrollo
de software seguro.
¿Qué es S-SDLC?
Ciclo de Vida de Desarrollo de Software seguro describe las fases del ciclo del software y el
orden en que esas fases se ejecutan de acuerdo a los requerimientos del negocio. Con el
fin de implementar las aplicaciones que se requieren para proporcionar un procesamiento
seguro.
Esquema SDLC
3. Otras Iniciativas de seguridad en el desarrollo de software
Microsoft SDL
El modelo de optimización de SDL está estructurado en torno a cinco áreas de capacidades
que, en líneas generales, se corresponden con las fases del ciclo de vida de desarrollo de
software:
1) Formación, directivas y capacidades organizativas
2) Requisitos y diseño
3) Implementación
4) Comprobación
5) Lanzamiento y respuesta
¿Donde aplicar SDL?
1) Aplicaciones implementadas en un entorno empresarial
2) Aplicaciones que procesan información de identificación personal
3) Aplicaciones que se comunican frecuentemente a través de Internet u otras redes
OWASP CLASP
Open Web Application Security Project (Proyecto abierto de seguridad de aplicaciones web
),
Es un proyecto de código abierto dedicado a determinar y combatir las causas que hacen
que el software sea inseguro
¿Qué nos ofrece OWASP?
• Búsqueda y lucha contra las causas de software inseguro
• Creación de herramientas, documentación y estándares
• Conferencias
• Recursos gratuitos y de código abierto
• www.owasp.org
4. Medidas estándar que debemos tomar para el desarrollo de software seguro
1. Para desarrollar una aplicación segura debemos considerar los siguientes aspectos
Control de la entrada: validar todas las entradas.
Gestión de memoria: desbordamiento de buffers.
Estructura interna y diseño del programa.
Llamadas a recursos externos: bibliotecas, scripts.
Control de la salida: formato, restricciones.
Problemas de los lenguajes de programación.
Otros: algoritmos criptográficos, de autentificación.
2. Control de la entrada
Hay que validar todas las entradas que vienen de fuentes no fiables.
Se debe determinar qué es legal y rechazar lo que no lo sea.
Siempre se debe verificar que algo es legal, la aproximación contraria (detección de
entradas erróneas) puede fallar.
El sistema se debe verificar generando entradas erróneas desconocidas.
Hay que limitar la longitud máxima de la entrada
3. Vigilar caracteres especiales
Caracteres de control.
Caracteres especiales para el Shell, SQL, etc.
Delimitadores (p. ej. tabuladores, comas,:, etc.).
Verificar la codificación y decodificación de URLs y la validez de los juegos de
caracteres.
Minimizar las decodificaciones; no decodificar más de una vez de modo
inndecesario.
Números: verificar máximos, mínimos y ceros.
4. Validación de otros tipos de datos
5. Direcciones de correo: ver RFC 2822 y 822.
Nombres de fichero: Omitir caracteres especiales (/, 'n', '”', ...), omitir '../'.
Expresiones regulares.
Cookies: comprobar dominios.
HTML/XML: prevenir cross-posting.
URI/URL: validar antes de procesar.