Resumen: Metodologías para desarrollar software seguro

 Resumen: Metodologías para desarrollar software seguro


SEGURIDAD EN EL CICLO DE VIDA DEL DESARROLLO DE SOFTWARE


Introducción


Actualmente la mayoría de los procesos de desarrollo de software no incluyen seguridad, o bien solo la incluyen en la etapa del testing, al final.


  • El costo de solucionar vulnerabilidades es mayor cuanto más tarde en detectarse.




Mitos alrededor de la seguridad en el desarrollo.


  1. La seguridad es responsabilidad del programador

  2. Si no saben cómo funciona, no debería ser atacada.

  3. Si no se han encontrado vulnerabilidades hasta ahora …

  4. Por qué a alguien le interesaría atacar la aplicación

  5. Ya es lo suficientemente segura con el Firewall

  6. Si usa información encriptada es segura

  7. Solo tiene un usuario - Admin / Root

  8. No tiene exploits

  9. No hay tiempo para incluir seguridad


Tendencia Actual

Se recomienda incluir los procesos de la seguridad informática, desde el comienzo del desarrollo y a través de todas sus etapas.


  • Análisis

  • Diseño

  • Codificación

  • Testing

  • Deployment


Seguridad en el análisis de requerimientos


En esta etapa se pueden identificar diversas características que derivarán en los requerimientos de seguridad del software


Ejemplo


  • Arquitectura de la aplicación => Cliente / Servidor o Desktop

  • En qué plataforma correrá la app => PC, celular, …

  • Qué tipo de datos se almacenan y transfieren => Confidenciales o públicos

  • Qué requerimientos de compliance con normativas y marcos regulatorios tiene.

  • Qué tipos de registro debe generar el sistema => Acceso a recursos, uso de privilegios, etc

  • Perfiles de usuario necesarios para  la aplicación => Admin, editor, basic, …

  • Qué tipo de acceso a datos tiene cada usuario => lectura, escritura, modificación, agregar, borrar, etc.

  • Qué acciones sobre el sistema puede hacer cada perfil => Puede cambiar la configuración ? Puede arrancar o detener servicios?

  • Qué tipos de autenticación tiene => Contraseñas, tokens, … 1 factor, 2 factores, …


Seguridad en el diseño


Muchas de las vulnerabilidades encontradas en aplicaciones tuvieron su orígen en errores de diseño.


Casos reales

Aplicación Home Banking (WEB)

  • Incluía el número de cuenta en el request de transferencias

  • No validaba que la cuenta de orígen perteneciera al usuario logueado

  • Vulnerabilidad: transferencias desde cuentas ajenas


Aplicación de Admin y finanzas (Consola Unix)

  • Tomaba el usuario de una variable de entorno.

  • Permitía que el usuario escapara a un shell

  • Vulnerabilidad: se puede establecer un usuario arbitrario.


Buenas prácticas en el diseño de una aplicación segura.


  • Reducir la superficie de ataque: Reducir la superficie expuesta a ataques significa proteger los dispositivos y la red de su organización, lo que deja a los atacantes con menos formas de realizar ataques.

  • Criterio del menor privilegio (PoLP): se da a un usuario los niveles (o permisos) de acceso mínimos necesarios para desempeñar sus funciones laborales.

  • Fallar de manera segura: Debemos darnos cuenta de que el fracaso es inevitable y de que las aplicaciones fallarán. Esto permite asegurar el entorno y estar preparados. Tenemos que asegurarnos que cuando nuestro software falle, no comiencen a ofrecer datos sensibles en el proceso.


cuando un cajero automático falla, se apaga; no arrojan dinero por la ranura


  • Criterio de defensa en profundidad (DiD): estrategia de ciberseguridad que utiliza múltiples productos y prácticas de seguridad para proteger la red, las propiedades web y los recursos de una organización. El principio básico de una estrategia de defensa en profundidad es la idea de que un solo producto de seguridad no puede proteger del todo una red de todos los ataques a los que pueda enfrentarse. Sin embargo, la implementación de múltiples productos y prácticas de seguridad puede ayudar a detectar y prevenir los ataques a medida que van surgiendo.

  • Diseño seguro de mensajes de error: la existencia de una manejo inseguro de errores deficiente supone y muestra debilidad por parte de la aplicación, por ejemplo, una respuesta incorrecta que termine mostrando información interna a personal no autorizado.

  • Diseño seguro de autenticación

  • Separación de privilegios: definir los roles y permisos asociados a estos, a diferentes usuarios; dividiendo con ello la capacidad y responsabilidad de tomar acciones sobre el tema.

  • Interacción amigable con Firewalls e IDSs:

  • Administración segura de información sensible:

  • Diseño de auditoría y login:

  • Análisis de riesgo:



Análisis de riesgo . Threat Modelling

Técnica formal, estructurada y repetible que permite determinar y ponderar los riesgos, y amenazas a los que estará expuesta la aplicación


Esta técnica consta de las siguientes etapas:


  1. conformar un grupo de análisis de riesgos

  2. descomponer la aplicación e identificar componentes clave.

  3. Determinar las amenazas a cada componente de la aplicación.

  4. Asignar un valor a cada una de las amenazas.

  5. Decidir cómo responder a las amenazas

  6. identificar las técnicas y tecnologías necesarias para mitigar los riesgos identificados.


Método STREAD

Ayuda a identificar las amenazas en los componentes del sistema


  • Spoofing identity: suplantar la identidad de otro usuario o servicio

  • Tampering with data: modificar maliciosamente datos almacenados

  • Repudiation: imposibilidad de identificar el autor de una acción

  • Information disclosure: divulgar información a usuarios no autorizados

  • Denial of service: provocar que un servicio deje de funcionar

  • Elevation of privilege: conseguir privilegios mayores a los asignados.


Árboles de ataque



Método DREAD

Ayuda a ponderar las amenazas identificadas.


  • Damage potential: qué tan importante es el daño

  • Reproducibility: qué tan reproducible es la vulnerabilidad

  • Exploitability: qué tan fácil de explotar es

  • Affected users: qué usuarios y qué cantidad se verían afectados

  • Discoverability: cuán fácil de descubrir la vulnerabilidad es.


Seguridad en la codificación


La falta de controles adecuados en la codificación muchas veces deriva en vulnerabilidades que pueden comprometer a la aplicación o a los datos de la misma.


Los tipos de vulnerabilidades más comunes son:


  • stack buffer overflows: vulnerabilidad causada por la inserción de datos con tamaño superior al esperado por una aplicación, lo que provoca la sobrescritura de espacios adyacentes en la memoria.

  • heap buffer overflows: es un tipo de desbordamiento del buffer de  una computadora en el heap (Montículo) de datos, este montículo normalmente contiene código que se ejecuta directamente por los sistemas operativos y aplicaciones para priorizar  ejecución de procesos de datos.

  • SQL injections:vulnerabilidad que permite al atacante enviar o “inyectar” instrucciones SQL de forma maliciosa y malintencionada dentro del código SQL programado para la manipulación de bases de datos, de esta forma todos los datos almacenados estarían en peligro.

  • Cross site scripting (XSS): ataque en el cual actores maliciosos logran inyectar un script malicioso en un sitio web para luego ser procesado y ejecutado. Comúnmente, este proceso que se basa en la confianza que tiene el sitio sobre la entrada de los datos, consiste en enviar la URL con el payload precargado al usuario víctima con un objetivo determinado: robar datos personales del usuario, cookies de sesión, implementar técnicas de ingeniería social, entre otras.

  • Directory traversal: vulnerabilidad informática que ocurre cuando no existe suficiente seguridad en cuanto a la validación de un usuario, permitiéndole acceder a cualquier tipo de directorio superior (padre) sin ningún control.

  • Otros: authentication bypass, information disclosure, escalamiento de privilegios, manejo inseguro de sesiones, denegación de servicio.


Buenas prácticas para una codificación segura


  1. Validar siempre los datos de entrada antes procesarlos

  2. Nunca confiar en que los datos recibidos sean correctos

  3. Realizar la validación de datos en todas las capas

  4. Usar siempre el criterio de “White List”

  5. Controlar el tamaño y tipo de datos

  6. Sanitizar los valores de entrada y salida

  7. Eliminar o escapear caracteres especiales

  8. Transformar los datos de entrada a un encoding establecido

  9. Reemplazar sentencias SQL dinámicas por store procedures

  10. evitar generar código con valores ingresados por el usuario

  11. No mezclar datos con código

  12. Capturar errores de capas inferiores y no mostrarlos al usuario.


Testing de seguridad


Comentarios

Entradas populares de este blog

La historia de nuestra institución

Diseño de una Base de Datos Orientada a Objetos (BDOO)