Please enable JavaScript.
Coggle requires JavaScript to display documents.
Seguridad en el software - Tema 1, maisfloro, Las aplicaciones son…
Seguridad en el software - Tema 1
El problema de la seguridad en el software
Tamaño excesivo y complejidad de las aplicaciones
Mezcla de código proveniente de varios orígenes
Integración de los componentes del software defectuosa, defectuosa, estableciendo relaciones de confianza inadecuadas entre ellos, etc.
Debilidades y fallos en la especificación de requisitos y diseño no basados en valoraciones de riesgo y amenazas.
No realización de pruebas seguridad basadas en riesgo.
Uso entornos de ejecución con componentes que contienen vulnerabilidades o código malicioso embebido.
Falta de herramientas y un entorno de pruebas adecuados que simule adecuadamente el real de ejecución.
Cambios de requisitos del proyecto durante la etapa de codificación.
Mezcla de equipos de desarrolladores.
Falta de conocimiento de prácticas de programación segura de los desarrolladores.
No control de la cadena de suministro del software.
No seguimiento, por los desarrolladores, de guías de normalizadas de estilo en la codificación.
Fechas límite de entrega de proyectos inamovibles.
Cambio en la codificación en base al requerimiento de nuevas funcionalidades.
Tolerancia a los defectos.
No tener actualizadas las aplicaciones en producción.
CICLO DE VIDA
MANTENIMIENTO O SOSTENIMIENTO
DESARROLLO
OPERACION
DISTRIBUCION E INSTALACION
SEGURIDAD DEL SOFTWARE
Nace el concepto en el documento de referencia SAFECode - 2011
DEFINICION:
. La confianza que el software,hardware y servicios están libres de vulnerabilidades intencionadas o no intencionadasy que funcionan conforme a lo especificado y deseado
El Departamento de Defensa de los Estados Unidos (DoD)
DEFINICION:
El nivel deconfianza de que el software funciona según lo previsto y está libre de vulnerabilidades,ya sean intencionada o no, diseñada o insertada en el marco de su ciclo de vida dedesarrollo.
DEFINICION FINAL
El conjunto de principios de diseño y buenas prácticas a implantar en el SDLC,para detectar, prevenir y corregir los defectos de seguridad en el desarrollo y adquisición de aplicaciones, de forma que se obtenga software de confianza y robusto frente ataques maliciosos, que realice solo las funciones para las que fue diseñado, que esté libre de vulnerabilidades, ya sean intencionalmente diseñadas o accidentalmente insertadas durante su ciclo de vida y se asegure su integridad, disponibilidad y confidencialidad
VULNERABILIDADES Y SU CLASIFICACION
Tipos
Fallos de
implementación
Provenientes de la codificación del diseño de sw realizado.
Fallos de
diseño
Los sistemas de HW / SW tienen dallos de diseño/debilidades para realizar un ataque.
Fallos de
configuración
Se instalan generalmente servicios que no se usan. Ojo que aquí se pueden tener vulnerabilidades
Una vulnerabilidad se define
PRODUCTO:
Productos a los que afecta.
DÓNDE:
Componente del programa
CAUSA:
Fallo técnico concreto
IMPACTO:
Define la gravedad
VECTOR:
Técnica del ataque
Ciclo de vida
1.
Descubrir
2.
Utilización
3.
Verificación
4.
Solución
5.
Difusión
6.
Medidas
7.
Corrección
8.
Búsqueda
9.
Actualizar
GESTION DE VULNERABILIDADES
CVE
[Common Vulnerabilities and Exposures]
Diccionario/catálogo público de vulnerabilidades, administrado por MITRE. Normaliza la descripción y la organiza desde diferentes tipos de vista (Vulnerabilidades Web, de diseño, de implementación, etc)
Cada identificador incluye
Identificador CVE, seguido del año en el que se asignó el codigo a la vulnerabilidad + Número de cuatro cifras que identifica la vulnerabilidad en el año
:check:
CVE-2012-4212
Breve descripción de la vulnerabilidad
Referencias
CVSS
[Common Vulnerability Scoring System]
Escalona la severidad de una vulnerabilidad a través de formulas, proporcionando un estandar para comunicad las caracteristicas y el impacto de una vulnerabilidad identificada con su código
CVE
Permite organizar la priorización de las actividades de remediación o parcheo de las vulnerabilidades
El cálculo se realiza en base a 3 tipos de métricas base, temporales y ambientales (Las 2 ultimas opcionales)
Métricas base
Explotabilidad:
Vectores de acceso, complejidad de acceso y autenticación
Impacto:
Confidencialidad, Integridad, Disponibilidad
CVRF
[Common Vulnerability Reporting Framework]
Es un formato XML que permite compartir información crítica sobre vulnerabilidades en un esquema abierto y legible por cualquier equipo.
La disponibilidad de CVRF acelera el intercambio y procesamiento de información entre distintas plataformas.
NVD
[National Vulnerability Database]
BD de gobierno estadounidense que permite la automatización de la gestión de vulnerabilidades y la medición del nivel del riesgo.
Incluye BD con listas de comprobación de configuraciones de seguridad de productos, defectos de seguridad del sw relacionados, nombres de producto y metricas de impacto.
CWE
[Common Weakness Enumeration]
Estandar internacional y de libre uso que ofrece conjunto de debilidades unificadas o defectos del sw medible.
Objetivos
Proporcionar un lenguaje común para describir los defectos y debilidades de seguridad de software en su arquitectura, diseño y codificación.
Proporcionar un estándar de comparación de herramientas de auditoría seguridad de software.
Proporcionar una línea base para la identificación de vulnerabilidades, sumitigación y los esfuerzos de prevención.
Debilidades
Desbordamiento del buffer
Formato de cadenas
Estructura y problemas de validación
Errores de ruta
Interfaz de usuario
Autenticación
Gestión de recursos
Manipulación de datos
Verificación de datos
Inyección de código
Cada identificador incluye
Nombre del tipo de la debilidad
Descripción del tipo
Terminos alternativos para la debilidad
Descripción del comportamiento de la debilidad
Probabilidad de explotar la debilidad
Descripción de las consecuencias de la explotación
Posibles mitigaciones
Otras debilidades relacionadas
Taxonomias de las fuentes
Ejemplos de código para los lenguajes/arquitectura
Identificadores de vulnerabilidades CVE para las que ese tipo de debilidad existe
Referencias
CLASIFICACION DE LAS VULNERABILIDADES
MITRE Top 25
Contiene los mayores errores de programación que pueden causar vulnerabilidades en el software. Es una herramienta destinada a ayudar a los programadores y auditores de seguridad del software, para prevenir este tipo de vulnerabilidades queafectan a la industria de las TIC.
SANS Top 20
Es una lista de vulnerabilidades que requieren solución inmediata.
OWASP Top 10
Su objetivo es crear conciencia sobre la seguridad de las aplicaciones web mediante la identificación de algunos de los riesgos más críticosque enfrentan las organizaciones.
WASC Threat Clasification v2.0
Crear un lenguaje consistente y las definiciones de los problemas de seguridad relacionados con las aplicaciones web.
maisfloro
Propiedades del software seguro
[FUNDAMENTALES]
Disponibilidad
Capacidad que garantiza que el software es operativo y accesible por personas, entidades o procesos autorizados de forma que se puedaacceder a la información y a los recursos o servicios que la manejan, conforme a las especificaciones de los mismos. Entre las técnicas y mecanismos que se tienen parasalvaguardar la disponibilidad, tenemos, por ejemplo:
Usar arquitecturas HA y con redundancia
Sistemas distribuidos con replocas de información entre ellos
Analizar servicios e información critica
Uso de recuperación a través de imagenes, virtualización, etc.
Confidencialidad
Capacidad de preservar que cualquiera de sus características, activos manejados están ocultos a usuarios no autorizados, de forma que se garantice que solo las personas, entidades o procesos autorizados pueden acceder a la información.
Tráfico de relleno
Técnicas de control de acceso a sistemas basado en roles
Clasificación de las aplicaciones y servicios con base en su criticidad
Cifrado de información y comunicaciones
Integridad
Capacidad que garantiza que el código, activos manejados,configuraciones y comportamiento no pueda ser o no haya sido modificado oa lterado por personas, entidades o procesos no autorizados tanto durante lafase de desarrollo como en la fase de operación. Entre las modificacionesq ue se pueden realizar tenemos sobreescritura, inclusión de puertas traseras,borrado, corrupción de datos, etc. Como ejemplo de técnicas y mecanismos que setienen para salvaguardar la integridad, tenemos:
Gestión estricta de sesiones
Monitorización de la integridad
Uso de tecnicas de cifrado
Uso de firma digital
Identificación de modo de transmisión y procesado de datos por la app
Transmisión cifrada de los datos
Propiedades del software seguro
[COMPLEMENTARIAS]
Trazabilidad
Robustez
Autenticación
Resiliencia
Capacidad de aislar, contener y limitar los daños causados por la explotación de una vulnerabilidad del mismo y recuperarse reanundando su operación en el tiempo oportuno.
Fiabilidad
Tolerancia
[Factores] - Consistencia de las propiedades del software
Componentes adquiridos
Configuraciones desplegadas
Herramientas de desarrollo
Ambiente de operación
Principios de diseño y buenas practicas de desarrollo
Conocimiento profesional
Principios de diseño de seguridad del software
Entorno de producción o ejecución inseguro
Validación de entradas:
Parametros linea de comandos
Variables de entorno
Localizadores de recursos universales (URI - URL)
Referencias a nombres de archivo
Subida contenida de archivos
Importaciones de archivos planos
Cabeceras HTTP
Parametros HTTP GET
Campos de formulario
Listas de selección/desplegables
Cookies
Comunicaciones mediante java applets
Centralizar la logica de validacion de entradas.
Que la validación de entradas no pueda ser evitada.
Confiar en whitelist y filtrar las blacklist
Rechazar todos los contenidos ejecutables de fuentes no autorizadas.
Validar datos de salida antes de enseñarselos al usuario o redirigirlos.
Registro de eventos de seguridad
Separación código, ejecutables y datos configuración y programa
Establecer permisos de escritura y lectura de los datos de programa y sus metadatos al programa que los creó.
Los datos de configuración del programa solo deben ser leidos y modificados por el administrador.
Los datos utilizados en scrips (Servidor web) deben ser colocados fuera del arbol de documentos del mismo.
Prohibir a los programas escribir en otros directorios (enjaulamiento)
Cifrar archivos ejecutables.
Clonado de sistemas como medida de recuperación.
Fallas de forma segura
Temporizadores tipo "watchdog"
Implementar una logica de control de excepciones
El sw debe iniciar y terminar su ejecución en un estado seguro.
Evitar problemas de sincronización y secuenciación.
Separación de dominios/privilegios
Diseño de software resistente (Monitoreo, redundancia)
Minimo privilegio
La seguridad por oscuridad es un error
Mecanismo de defensa que consiste en ocultar información sobre la aplicación de forma que sea difícil de obtener
Error:
Guardar información en archivos binarios
Carpetas ocultas en un servidor web.
Falsa sensación de seguridad.
Criptografia privada
Cambio del nombre del usuario «administrador»
Simplicidad del diseño
Limitar el número de estados
Favorecer procesos deterministas
Una sola tarea en lugar de realizar multiples tareas
Tecnicas de sondeo
Software con conjunto minimo de caracteristicas y capacidades
Descomposición de subsistemas o componentes de un programa deberia adaptarse a su descomposición funcional
Desacoplar procesos y componentes para minimizar las interdependencias
No implementar caracteristicas o funciones innecesarias
Seguridad por defecto
Defensa en profundidad (entorno aislado)
Capa de aplicación:
FW, proxy, encriptación, control de acceso, auth, bastiones.
Capa de transporte:
SSL o TLS
Capa de red:
IDS/IPS, SIEM
Capa física:
Aislamiento (Sandbox), sistemas de incendios, humedad, control de acceso.
Las aplicaciones son amenazadas y atacadas en todas las fases