PROBLEMA DE LA SEGURIDAD DEL SOFTWARE

De acuerdo con el informe de Klocwork 2004 se indica que las principales causas de
vulnerabilidades son las siguientes:

Tamaño excesivo y complejidad de las aplicaciones

Mezcla de código de varios orígenes

Integración de componentes de software defectuosos

Debilidades y fallos, pruebas de seguridad basadas en riesgos, falta de herramientas en

entornos adecuados, mezcla de equipos de desarrolladores, cambio de codificación.

Las aplicaciones son amenazadas y atacadas, no solo en su fase de operación, sino que también en todas las fases de su ciclo de vida

Fases del ciclo de vida de un software Seguridad de software

Vulnerabilidad de alta severidad

Desarrollo: Un programador puede alterar de forma
intencionada el software
Distribución e instalación: Ocurre cuando no se protege el
software
Operación: Cualquier software que se ejecuta en una
plataforma conectada a la red tiene sus vulnerabilidades
Mantenimiento o sostenimiento: No publicación de
parches de las vulnerabilidades detectadas en el momento
oportuno
en la
CVSS (COMMON VULNERABILITY SCORING SYSTEM) Es un conjunto de principios de diseño
y buenas prácticas a implantar en el
sistema que categoriza la severidad de una vulnerabilidad,
SDLC, para detectar, prevenir y corregir
proporcionando un estándar para comunicar las
los defectos de seguridad en el
características y el impacto de una vulnerabilidad en el
desarrollo y adquisición de
software.
aplicaciones, de forma que se obtenga
software de confianza y robustos frente
minimizar al ataques maliciosos, con el objetivo de
APD Amenazas Avanzadas Persistentes máximo los asegurar su integridad, disponibilidad y
ataques confidencialidad.
tipo sofisticado de ciberataque capa de
organizado, de rápida progresión, aplicación
diseñado específicamente para acceder y
obtener información de los sistemas de la
organización objetivo.
y, por tanto, en número de vulnerabilidades explotables, es necesario el incluir la seguridad desde principio en el ciclo de vida de desarrollo del software
(SDLC),

Vulnerabilidades y su clasificación

fallo de programación, configuración o diseño, se define

que son un subconjunto del fenómeno más grande que
constituyen los bugs (errores de programación) y flaws
(errores de diseño) del software.

Las fuentes se deben a:

Fallos de diseño
Fallos de implementación Fallos de configuración

provenientes de la Los sistemas hardware o software La instalación de software por

codificación de los diseños contienen frecuentemente fallos de defecto implica la instalación
del software realizados. diseño o debilidades (flaws) que de servicios que no se usan,
pueden ser utilizados para realizar un pero que pueden presentar
Como desbordamientos de
ataque debilidades que
búfer, formato, condiciones
comprometan la máquina
de carrera, path trasversal, Por ejemplo, TELNET no fue diseñado
cross-site scripting, inyección para su uso en entornos hostiles,
SQL, etc. para eso se implementó SSH.

Casi todos los fallos que se producen en un software provienen de fallos de implementación y diseño, pero solamente algunos resultan ser
vulnerabilidades de seguridad.
 Exploit

Instancia particular de un ataque a un sistema que se aprovecha de su

vulnerabilidad.

Se define básicamente por 5 factores:

Producto: producto a los que afecta

Dónde: componente o modulo del programa

Causa y consecuencia: fallo o técnico concreto que cometió el

programador

Impacto: gravedad de la vulnerabilidad

Vector: técnica del atacante para aprovechar la vulnerabilidad.

Ciclo de vida de una vulnerabilidad

Descubrimiento: Detección de un fallo en el software

Utilización: agentes maliciosos desarrollan el exploit para lanzar ataques

Verificación: Este proceso se da al iniciar la vulnerabilidad una vez se recibe una

notificación de error esta será aceptada para su tratamiento comprobando su
veracidad, o bien será rechazada si se comprueba que no existe.

Solución: los programadores buscan solución en entornos controlados.

Difusión: publicidad al incidente.

Medidas: las organizaciones afectadas toman medidas para mitigar las posibles
pérdidas.

Corrección y nueva verificación: Corrección de la vulnerabilidad

Búsqueda:

Actualización:
 PRINCIPIOS DE DISEÑO DE SEGURIDAD DE SOFTWARE

Defensa en profundidad: considerada como una estrategia de protección, consiste en introducir múltiples capas de seguridad, que permiten reducir el
impacto, o que el sistema se vea comprometido.

Las medidas de seguridad en el modelo osi son:

Aplicación:

amenaza debilidad del diseño, errores de programación, malware, intrusiones.F

Controles: cortafuegos, ids, ips, análisis estático de código, validación de entrada, política de contraseñas.

Presentación:

Amenazas: fuga de información, divulgación de contenido.

Controles: cifrado de datos sensibles, sistema de prevención de perdida de datos (DLP), RBAC

Sesión:

Amenazas: bypass de autenticación, spoofing, robo de credenciales, divulgación de datos, ataques de fuerza bruta.

Controles: control de acceso, sesión única y aleatoria, generación de ID, cifrado de transmisión y almacenamiento, niveles de bloqueo de cuentas.

Transporte:

Amenazas: perdida de paquetes, fingerprinting, enumeración, apertura de puertos

Controles: TLS, monitorización de puertos, control flujo

Red:

Amenazas: spoofing en las rutas y direcciones ip

Controles: cortafuegos de filtrado de paquetes, acl, kerberos, ssh, idp,ips, ipsec, siem , monitoreo de trafico de red (broadcast)

Enlace:
Amenazas: spoofing de dirección mac, bypass de vlan, errores de spanning tree, ataques inalámbricos

Controles: filtrado mac, firewalls, segmentación de vlan, Wireless con autentificación y cifrado fuertes.

Físico:

Amenazas: accidentes naturales, robo e intrusiones físicas m keyloggers

Controles: virtualización, alta disponibilidad en red de datos y alimentación eléctrica, cctv, ids, sistema de prevención contra incendios.

Normativa:

Amenazas: ataques a la confidencialidad, ingeniería social.

Controles: políticas de seguridad de la información, organización de la seguridad, procedimientos y estándares, formación y conciencia en seguridad.

Verificación de la cadena de suministros mediante la comprobación del hash, código de firma, aplicados al código ejecutable mediante la validación de la
integridad de está en el momento de la entrega, la instalación o en tiempo de ejecución, para determinar:

Si el código se originó a partir de una fuente de confianza.

Si la integridad del código de se ha visto comprometida.

Simplicidad del diseño:

Su objetivo es reducir la complejidad del diseño para minimizar el número de vulnerabilidades.

Las opciones específicas de diseño del software que lo simplifican son:

Limitar el número de estados posibles en el software favorecer procesos deterministas sobre los no deterministas, evitar funcionalidades innecesarias,
técnicas de sondeo en lugar de interrupciones., desacoplar los componentes y procesos para minimizar las interdependencias, no implementar
características o funciones innecesarias.

Mínimo privilegio.

principio en el que se le concede a un usuario, equipo o proceso un conjunto de restricciones o privilegios para el desempeño de sus tareas autorizadas.
La programación modular ayuda a implementar menos privilegios, además de hacer que el código sea más legible, reutilizable y fácil de mantener

Ejemplo de errores comunes:

Aplicación de derechos de administrador

Instalación de aplicaciones y servicios con el usuario administrador

Usuarios con derecho de administrador

Servicios y procesos con privilegios en tiempo indefinido.

Separación de privilegios:

Asignación de un subconjunto de funciones o tareas de todos los que ofrece el sistema, acceso a los datos necesarios, evitando de esta forma que todas las
entidades sean capaces de acceder a la totalidad o llevar a cabo todas las funciones de superususario.

Servidor web: el usuario final solo requiere la capacidad de leer el contenido publicado e introducir datos en los formularios HTML. El administrador, por el
contrario, tiene que ser capaz de leer, escribir y eliminar contenido y modificar el código de los formularios HTML.

Separación de dominios.

Minimizar la probabilidad de que actores maliciosos obtengan fácilmente acceso a las ubicaciones de memoria u objetos de datos del sistema.

Llevando a cabo técnicas como:

Sistema operativo confiable, Máquinas virtuales, funciones sandboxing, sistemas unix, trusted processor modules (TPM): es el nombre de una especificación
publicada que detalla un criptoprocesador seguro que puede almacenar claves de cifrado para proteger información.

Separación código, ejecutables y datos configuración y programa.

pretende reducir la probabilidad de que un ciberatacante que haya accedido a los datos del programa fácilmente pueda localizar y acceder a los archivos
ejecutables y datos de configuración de este.

La mayoría de las técnicas de separación de los datos de programa, configuración y archivos ejecutables se realizan en la plataforma de ejecución
(procesador más sistema operativo).
Utilizar plataformas con arquitectura Harvard

Permisos de lectura y escritura de los datos del programa.

Datos utilizados por un script en un servidor web deben ser colocados fuera de árbol de documentos de este.

Prohibir a los programas y scripts escribir archivos en directorios escribibles como el de UNIX/TMP.

Almacenar los archivos de datos, configuración y programas ejecutables en los directorios separados del sistema de archivos.

Cifrar archivos ejecutables

Incluir técnicas de cifrado de archivos

Implantar clonado de sistemas

Entorno de producción o ejecución inseguro.

Su objetivo es evitar vulnerabilidades aplicando una serie de principios de validación de las entradas.

Los tipos de aplicaciones que más probabilidad presenten de sufrir este tipo de ataques son las del tipo cliente-servidor, portales web y agentes proxy.

Los ataques que se pueden dar en la carencia de la comprobación de los datos son: desbordamiento de buffer, revelación de información, inyección de
comandos, inyección de código SSI, contenido mal formados, servicios web.

Para evitar este tipo de vulnerabilidades en la validación de entradas se considera: centralizar la lógica de validación de las entradas, asegurarse que la
validación de la entrada no puede ser evitada, confiar en listas blancas y filtras listas negras, validar todas las entradas de usuario, rechazar los contenidos
ejecutables en las entradas provenientes de fuentes no autorizadas, Verificar que los programas que solicitan las llamadas tienen derecho, Validar los datos
de salida.

Registro de eventos de seguridad.

Su objetivo es generar eventos (logs) de seguridad, para garantizar las acciones realizadas por un ciberatacante se observan y registran.

Fallar de forma segura.

Su objetivo es reducir la probabilidad de que un fallo en el software pueda saltarse los mecanismos de seguridad de la aplicación, dejándolo en un modo de
fallo inseguro vulnerable a los ataques.

Se puede minimizar la probabilidad de que un software pase a estado inseguro implementando:

 Temporizadores tipo watchdog

 lógica de control de excepciones
 el software siempre debe comenzar y terminar su ejecución en un estado seguro
 evitar problemas de sincronización y secuenciación.

Diseño de software resistente.

Su objetivo es reducir al mínimo la cantidad de tiempo que el componente de un software defectuoso o fallido sigue siendo incapaz de protegerse de los
ataques.

Seguridad por oscuridad es un error.

Su objetivo es concienciarse de que la seguridad por oscuridad es un mecanismo de defensa

que puede proporcionar a un agente malicioso información para comprometer la seguridad
de una aplicación.

Seguridad por defecto

Su objetivo es reducir la superficie de ataque de una aplicación o sistema.

 Tipos de S-SDLC

Buenas prácticas de seguridad en el proceso de desarrollo del software.

SDLC casi inmediatamente perciben una mejora en su capacidad para detectar y eliminar errores de codificación y
debilidades de diseño en el software que producen, antes de que entren en un proceso de distribución e instalación

elementos mcgraw

Hitos de control McGraw (2005) propone un modelo de S-SDLC (cascada o iterativo),

se centra en la incorporación de las siguientes prácticas.
Principios y practicas
seguras de software 1. Revisión de código.

Requisitos adecuados  Análisis de riesgo arquitectónico.

Codificación segura  Pruebas de penetración.

Sostenimiento seguro  Pruebas de seguridad basados en riesgo.

Herramientas de apoyo  Casos de abuso.

Despliegue y  Requisitos de seguridad.

distribución segura.
 Operaciones de seguridad.
Gestión de configuración de
sistemas y procesos.  Revisión externa.

Además de las siete prácticas se identifica una octava, el análisis

externo, en el que un equipo de analistas externos a la organización,
realiza revisiones de seguridad independientes, evaluaciones y
pruebas del diseño del software y la implementación.
 Conforme se descubren nuevas amenazas y vulnerabilidades, se tienen nuevos riesgos que dan lugar a un nuevo caso de abuso y un nuevo análisis
de riesgos.

 Cambios en el sistema con nuevos componentes de software o hardware, implica el rehacer el análisis de riesgos y revisar el código de los nuevos
componentes software.

 Nuevos defectos de implementación que modifican las especificaciones o del sistema implican nuevas revisiones de código y as pruebas de
seguridad.