Diseño y Desarrollo de Programas Informáticos Seguros

Indica cuál de las siguientes respuestas no es una causa de aparición de vulnerabilidades en el software: No realización de pruebas de seguridad basadas en riesgo. Cambios de requisitos del proyecto durante la etapa de especificación. Mezcla de código proveniente de varios orígenes. Tamaño excesivo y complejidad de las aplicaciones.

Indica la respuesta incorrecta. Respecto al ataque a las aplicaciones durante las diferentes fases de su ciclo de vida: Distribución e instalación. Ocurre cuando el instalador del software bastiona la plataforma en la que lo instala. Desarrollo. Un desarrollador puede alterar de forma intencionada o no el software bajo desarrollo. Operación. Cualquier software que se ejecuta en una plataforma conectada a la red tiene sus vulnerabilidades expuestas durante su funcionamiento. El nivel de exposición variará dependiendo de si la red es privada o pública, conectada o no a Internet, y si el entorno de ejecución del software ha sido configurado para minimizar sus vulnerabilidades. Mantenimiento o sostenimiento. No publicación de parches de las vulnerabilidades detectadas en el momento oportuno o incluso introducción de código malicioso por el personal de mantenimiento en las versiones actualizadas del código.

Señala la respuesta incorrecta. Las fuentes de las vulnerabilidades se deben a: Fallos provenientes de la codificación de los diseños del software realizados. Fallos provenientes de la cadena de distribución del software. Los sistemas hardware o software contienen frecuentemente fallos de diseño que pueden ser utilizados para realizar un ataque. La instalación de software por defecto implica, por lo general, la instalación de servicios que no se usan, pero que pueden presentar debilidades que comprometan la máquina.

Señala la respuesta incorrecta. Entre las técnicas y mecanismos para salvaguardar la integridad tenemos, por ejemplo: Identificación del modo de trasmisión y procesado de los datos por la aplicación. Uso de arquitecturas de alta disponibilidad, con diferentes tipos de redundancias. Uso de firma digital. Estricta gestión de sesiones.

Señala la respuesta incorrecta. Algunas de las opciones específicas de diseño del software que lo simplifican son: Favorecer procesos deterministas sobre los no deterministas. Limitar el número de estados posibles en el software. El uso de técnicas de interrupciones en lugar de sondeo. Desacoplar los componentes y procesos para minimizar las interdependencias entre ellos.

Para conseguir que el desarrollo de una aplicación posea las propiedades y principios de diseño del software seguro, se necesita que el personal de diseño y desarrollo desarrolle: Perspectiva administrador. Perspectiva defensor. Perspectiva usuario. Perspectiva atacante.

¿Cómo se define la resiliencia?. Capacidad de resistencia y tolerancia a los ataques realizados por los agentes maliciosos (malware, hackers, etc.). Capacidad que garantiza la posibilidad de imputar las acciones relacionadas en un software a la persona, entidad o proceso que la ha originado. Capacidad del software para aislar, contener y limitar los daños ocasionados por fallos causados por ataques de vulnerabilidades explotable del mismo, recuperarse lo más rápido posible de ellos y reanudar su operación en o por encima de cierto nivel mínimo predefinido de servicio aceptable en un tiempo oportuno. Capacidad del software para «tolerar» los errores y fallos que resultan de ataques con éxito y seguir funcionando como si los ataques no se hubieran producido.

¿A qué principio de diseño le corresponde la siguiente afirmación? «Estrategia de protección consistente en introducir múltiples capas de seguridad, que permitan reducir la probabilidad de compromiso en caso de que una de las capas falle y en el peor de los casos minimizar el impacto». Seguridad por defecto. Separación de privilegios. Separación de dominios. Defensa en profundidad.

Señala la práctica de seguridad a la que corresponde la siguiente afirmación: «son soluciones generales repetibles a un problema de ingeniería de software recurrente, destinadas a obtener un software menos vulnerable y un diseño más resistente y tolerante a los ataques, normalmente se limitan a funciones y controles de seguridad a nivel del sistema, comunicaciones e información». Test de penetración. Revisión de código. Casos de abuso. Patrones de diseño.

Señala la respuesta incorrecta. El cálculo de código CVSS se realiza en base a tres tipos de métricas ambientales: Métricas estadísticas. Métricas base. Métricas temporales. Métricas ambientales.

¿Qué incluye la seguridad del software?. Patrones de codificación. Principios de diseño seguro. Casos de uso. Buenas prácticas de seguridad.

Los patrones de ataque en la fase de diseño y arquitectura: Ayudan a definir el comportamiento del sistema para prevenir o reaccionar ante un tipo específico de ataque probable. Especifican debilidades aprovechadas por los ataques, orientando que técnicas o prácticas de seguridad de desarrollo evitan estas deficiencias. Proporcionan el contexto de las amenazas al que el software se va a enfrentar, de forma que permite diseñar arquitecturas seguras. Proporcionan ejemplos de ataques que no aprovechan las vulnerabilidades de la arquitectura elegida.

Respecto a los casos de uso de seguridad: Analizan y especifican los requisitos de seguridad. Analizan y especifican las amenazas a la seguridad. Analizan vulnerabilidades de activos y amenazas. Realizan el análisis forense de las actividades maliciosas.

Señala la respuesta incorrecta. Respecto a la ingeniería de requisitos de seguridad: Requisitos de software seguro. Requisitos que afectan directamente a la probabilidad de que el software sea seguro. Requisitos de software seguro. Incluye la especificación de funciones que implementan una política de seguridad, como control de acceso, autenticación, autorización, cifrado y gestión de claves. Estas funciones previenen la violación de las propiedades de seguridad del sistema o de la información que procesa, como el acceso no autorizado, modificación, denegación de servicio, etc. Los requerimientos no funcionales de seguridad deben especificar: propiedades que el software debe exhibir. Los requerimientos no funcionales de seguridad deben especificar: los controles y normas que rigen los procesos de desarrollo, implementación y operación del software.

El análisis de riesgo arquitectónico implica tres pasos básicos. ¿Cuál es el que no pertenece a ninguno de esos pasos?. Análisis de ambigüedad. Análisis de resistencia al ataque. Análisis de robustez. Análisis de debilidad.

Entre las perspectivas de las pruebas de seguridad basadas en el riesgo, se encuentra: Perspectiva gerencia. Perspectiva atacante. Perspectiva usuario. Perspectiva del analista.

El principal problema de las herramientas de análisis estático consiste en: Los falsos negativos que produce. La gran cantidad de defectos que encuentra. Las reglas de la herramienta. Los falsos positivos que produce.

Señala la respuesta incorrecta. Las herramientas de análisis estático realizan varios tipos de análisis, entre los que se encuentra: Taint propagation. Análisis puntual. Model checking. Análisis de flujo de datos.

Señala la respuesta incorrecta. Los test de penetración: En ningún caso demuestran que ningún defecto existe. Revisan el código. El entendimiento del ambiente de ejecución y de los problemas de configuración es el mejor resultado de cualquier prueba de penetración. Las conclusiones de seguridad no son repetibles a través de equipos diferentes y varían extensamente dependiendo de la habilidad y la experiencia de los probadores.

A la hora de realizar la distribución y despliegue del software desarrollado, es recomendable realizar las siguientes buenas prácticas: Distribuir el software con una configuración por defecto segura y lo más restrictiva posible. Proporcionar una herramienta de instalación automática. Cambiar los valores de configuración predeterminados durante el desarrollo. Todas las anteriores son correctas.

En este tema se presentan una serie de recomendaciones de buenas prácticas, entre las que se encuentra: Manejo de los datos con precaución. Confiar en software de terceros en operaciones críticas. Usar listas de errores. Usar en el código nombres relativos de ficheros.

¿Qué tipo de vulnerabilidad se comete en este código? String user_state = "Unknown"; try { HttpSession user_session = Init.sessions.get(tmpUser.getUser()); user_state = user_session == null ? "Unknown" : (String)user_session.getAttribute("USER_STATUS"); user_state = user_state == null ? "Available" : user_state; } ... %> <%=user_state %>. Integer overflows. Desbordamiento de buffer. Uso de datos invalidados. Use after free.

¿Qué tipo de vulnerabilidad se comete en este código? char *stringcopy(char *str1, char *str2) { while (*str2) *str1++ = *str2++; return str2; } main(int argc, char **argv) { char *buffer = (char *)malloc(16 * sizeof(char)); stringcopy(buffer, argv[1]); printf("%s\n", buffer); }. Integer overflows. Desbordamiento de buffer. Format string. Use after free.

¿Qué tipo de vulnerabilidad se comete en este código? struct hostent *hp; struct in_addr myaddr; char* tHost = "trustme.com"; myaddr.s_addr = inet_addr(ip_addr_string); hp = gethostbyaddr((char *) &myaddr, sizeof(struct in_addr), AF_INET); if (hp && !strncmp(hp->h_name, tHost, sizeof(tHost))) { trusted = true; } else { trusted = false; }. Buffer overflow. Validación límites de confianza. Validación de entrada DNS. Memory leaks.

¿El siguiente código es correcto? if (path != null && path.length() > 0 && path.length() <= MAXPATH) { fileOperation(path); }. Es correcto. Es incorrecto. No se puede determinar. Ninguna de las anteriores.

¿Qué tipo de vulnerabilidad se comete en este código? u_int nresp; nresp = packet_get_int(); if (nresp > 0) { response = xmalloc(nresp*sizeof(char*)); for (i = 0; i < nresp; i++) response[i] = packet_get_string(NULL); }. Integer overflows. Desbordamiento de buffer. Format string. Use after free.

¿Qué tipo de vulnerabilidad se comete en este código? while (fgets(buf, sizeof buf, f)) { lreply(200, buf); ... } void lreply(int n, char *fmt, ...) { char buf[BUFSIZ]; ... vsnprintf(buf, sizeof buf, fmt, ap); ... }. Integer overflows. Desbordamiento de buffer. Format string. Use after free.

Con respecto a los errores y excepciones: Si un método declara que lanza una excepción checked, todos los objetos que lo utilizan deben o manejar la excepción o declarar que lo lanzan también. Los compiladores de Java no hacen cumplir las reglas en cuanto a excepciones checked. Todas las excepciones en C++ son checked. Las excepciones unchecked no tienen que ser declaradas o manejadas.

¿Qué tipo de vulnerabilidad se comete en este código? public ResultSet execSQL(Connection conn, String sql) { Statement stmt = null; ResultSet rs = null; try { stmt = conn.createStatement(); rs = stmt.executeQuery(sql); } catch (SQLException sqe) { logger.log(Level.WARNING, "error executing: " + sql, sqe); } finally { close(stmt); } return rs; }. Integer overflows. Desbordamiento de buffer. Format string. Manipulación de información privada.

Se tienen dos opciones para crear archivos temporales de forma segura: Almacenar los archivos temporales bajo un directorio que no es públicamente accesible, eliminando así toda la discusión con respecto a ataques. Generar los nombres de archivo temporales que sean difíciles de adivinar usando un generador de números criptográficamente seguros pseudoaleatorios (PRNG) para crear un elemento aleatorio en cada nombre del archivo temporal. Generar los nombres de archivo temporales que sean difíciles de adivinar usando un generador de números criptográficamente seguros pseudoaleatorios (PRNG) para crear un elemento aleatorio en cada nombre del archivo temporal. Almacenar los archivos temporales bajo un directorio que no es públicamente accesible, eliminando así toda la discusión con respecto a ataques. Almacenar los archivos temporales bajo un directorio que es públicamente accesible, eliminando así toda la discusión con respecto a ataques. Generar los nombres de archivo temporales que sean difíciles de adivinar usando un generador de números para crear un elemento en cada nombre del archivo temporal.

¿Cuál de los siguientes no es un beneficio del análisis de malware?. Descubrir otras máquinas que han sido afectadas por el mismo malware. Identificar la vulnerabilidad que fue aprovechada por el malware, para obtener la actualización del software que la mitigue si está disponible. Obtener los datos necesarios para poder implementar defensas. Determinar el nivel de expansión del malware.

Entre los siguientes pasos de la metodología de análisis de malware, hay uno incorrecto. ¿Cuál es?. Actividades iniciales. Clasificación. Análisis heurístico. Análisis dinámico.

¿Cuál de las siguientes no es una acción que el malware suele realizar sobre la máquina víctima?. Modificación de archivos. Envío de correos personales. Degradación del rendimiento. Inestabilidad del sistema.

Señala cuál de los siguientes no es un mecanismo de propagación del malware. File dropper. Integración en espacios vacíos de ficheros. Puertas traseras. Gusanos.

Señala cuál de los siguientes no es un vector de infección. File dropper. Correos electrónicos. Redes Peer-To-Peer (P2P). Servicios de red vulnerables.

Señala cuál de los siguientes no es un ejemplo de troyano. Back Orifice. NetBus. SaranWrap. Titan Rain.

Señala cuál de los siguientes no es un componente del Malware Attribute Enumeration and Characterization (MAEC): Estructura de datos. Vocabulario. Esquema de definición. Formato de salida estándar.

¿Cuál no es un mecanismo de obtención del malware?. Bajarlo de páginas de Internet. Capturarlo en una honeynet. Comprarlo a una empresa de prestigio internacional. Capturarlo en una máquina infectada.

Señala la respuesta incorrecta. Los honeypot de baja iteracción: Son servicios reales, sistemas operativos o aplicaciones reales. Son servicios reales, sistemas operativos o aplicaciones reales. Capturan mucha información. Dependen de su sistema de clasificación y análisis para evaluarlo. Suponen un menor riesgo.

¿En qué fase se debe realizar un hash MD5 de todas las herramientas que van a utilizarse para verificar la integridad de estas?. Análisis estático. Análisis dinámico. Acciones iniciales. Clasificación.