Generador Aleatorio de Código WebGL y GLSLlaboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo... · y de Validación de la norma IEEE 1012-2004. En la sección 20, se modifica el

Plan de Proyecto del Trabajo Final de Carrera

de Especialización de Sistemas Embebidos

Ing. Martín Balao Alonso

Generador Aleatorio de Código WebGL y GLSL

Autor


Directores del trabajo

Esp. Ing. Pablo Ridolfi

Dr. Juan Pablo Galeotti

Jurado propuesto para el trabajo

- Esp. Ing. Pedro Martos (FIUBA) - Dr. Ing. Carlos Lombardi (UNQ) - TBD

Este plan de trabajo ha sido realizado en el marco de la asignatura Gestión de Proyectos entre octubre y diciembre de 2015.

Página 1 de 34




Tabla de contenido

Registros de cambios

Acta Constitutiva

1. Nombre del Proyecto

2. Fecha de inicio y finalización del proyecto

3. Presupuesto preliminar asignado

4. Identificación y análisis de los interesados

5. Propósito y Justificación del proyecto

6. Objetivos

7. Alcance del proyecto

8. Supuestos y restricciones del proyecto

9. Requerimientos

10. Entregables principales del proyecto

11. Desglose del trabajo en tareas

12. Análisis de factibilidad

13. Diagrama de Activity On Node

14. Diagrama de Gantt

15. Matriz de uso de recursos de materiales

16. Presupuesto detallado del proyecto

17. Matriz de asignación de responsabilidades

18. Gestión de riesgos

19. Gestión de la calidad

20. Comunicación del proyecto

21. Gestión de Compras

22. Seguimiento y control

23. Procesos de cierre

Página 2 de 34




Registros de cambios

Revisión Cambios realizados Fecha

1.0 Creación del documento 01.11.2015

1.1 Cambios basados en la revisión del Dr. Ariel Lutenberg de la la versión 1.0 en las siguientes secciones:

● Carátula del trabajo ○ Esp. Ing. Pablo Ridolfi ○ Fecha de realización del trabajo

● Acta constitutiva ○ Nombre del cliente

● 3. Presupuesto preliminar asignado ○ Los recursos materiales se mueven a las

secciones 15 y 16. ● 4. Identificación y Análisis de los Interesados

○ Auspiciante, Cliente, Impulsor y Usuario final

Se completan los puntos 8 a 17 (inclusive)

09.11.2015


● Salto de página insertado al comienzo de la sección 4 y 14.

● Definición del término fuzzear en la sección 5. ● Iteración sobre la sección 14 (Diagrama Gantt)

agregando: ○ Calendario ○ Visualización del diagrama (en partes) ○ Reordenamiento e indentación de tareas

● En las secciones 15 y 16 se amplía el ancho del cuadro para reducir su largo.

● Se elimina página en blanco entre las secciones 16 y 17.

● Se cambian todos los costos de dólares estadounidenses (USD) a pesos argentinos ($ARG).

Se agrega la biblioteca Boost (C++) al análisis de costos indirectos.

Se completan los puntos 18 a 23 (inclusive)

16.11.2015


21.11.2015

Página 3 de 34




● Jurado del Trabajo ● Fecha de finalización del Trabajo (Acta Constitutiva

y sección 2) ● Se agrega como propósito de este Proyecto la

finalización de la Especialización en Sistemas Embebidos del Ing. Martín Balao Alonso.

● Se actualiza la sección 10 para agregar como entregables:

○ Informe de Avance, ○ Memoria del Trabajo, y ○ Presentación ante el jurado.

● Se actualiza la sección 11 para agregar el Informe de Avance y la Memoria del Trabajo

● Se actualiza la sección 13 para agregar el Informe de Avance y la Memoria del Trabajo

● Se actualiza la sección 14 para agregar el Informe de Avance y la Memoria del trabajo.

● Se actualiza la sección 15 para agregar el total de horas.

● Se actualiza la sección 16 para quitar el costo total acumulado y expresar únicamente el costo total. Se actualizan los costos indirectos para contemplar el Informe de Avance y la Memoria Final del Trabajo.

● Se modifica la sección 18 para quitar de la tabla de RPN al RPN recalculado en aquellos riesgos que se decide aceptar.

● En la sección 19, se citar la definición de Verificación y de Validación de la norma IEEE 1012-2004.

● En la sección 20, se modifica el valor de la columna Audiencia, se agrega al Informe de avance, la Memoria Final y al Dr. Juan Pablo Galeotti.

● Se agrega a la sección 22 al Dr. Juan Pablo Galeotti y se actualizan las tareas del WBS.

Se incluye al Dr. Juan Pablo Galeotti como co-tutor de este Proyecto.

Se agrega al Dr. Juan Pablo Galeotti en la sección 17.

Página 4 de 34




Acta Constitutiva

Buenos Aires, 1 de noviembre de 2015

Attn Ing. Martín Balao Alonso

De mi mayor consideración

Con el fin de encontrar vulnerabilidades en el stack de renderización gráfica para plataformas

desktop y mobile (Windows, Linux, OS X, Android, etc.), se lo designa a Ud como Responsable del

proyecto “Generador Aleatorio de Código WebGL y GLSL”, con un presupuesto total estimado de

seiscientas (600) horas hombre, con fecha tentativa de inicio el 1 de noviembre de 2015 y de

finalización 30 de junio de 2016.

Se adjunta a esta acta la planificación inicial.


Carrera de Especialización en Sistemas Embebidos -

FIUBA

Dr. Juan Pablo Galeotti

Departamento de Computación - UBA Exactas

Página 5 de 34




1. Nombre del Proyecto

Generador Aleatorio de Código WebGL y GLSL

2. Fecha de inicio y finalización del proyecto

Fecha de inicio del proyecto: 1 de noviembre de 2015

Fecha de finalización del proyecto: 30 de junio de 2016

3. Presupuesto preliminar asignado

El presupuesto asignado al presente proyecto consta de los siguientes componentes:

● Recursos humanos Seiscientas (600) horas de trabajo de un Ing. en Informática con más de 5 años de experiencia laboral y especializado en seguridad informática.

● Recursos financieros Mil quinientos (1500) pesos argentinos

● Licencias de software (ver sección 15. Presupuesto detallado del proyecto) ○ Microsoft Windows 7 Professional ○ Visual Studio 2015

● Recursos materiales

○ Estación de trabajo (ver sección 15. Presupuesto detallado del proyecto)

Página 6 de 34




4. Identificación y análisis de los interesados

Rol Nombre y Apellido Departamento Puesto

Auspiciante Ing. Martín Balao Alonso Carrera de Especialización

en Sistemas Embebidos -

FIUBA

Estudiante

Cliente Esp. Ing. Pablo Ridolfi Carrera de Especialización


FIUBA

Docente

Cliente Dr. Ing. Juan Pablo

Galeotti

Departamento de

Computación - UBA

Exactas

Docente

Impulsor Ing. Martín Balao Alonso Carrera de Especialización


FIUBA

Estudiante

Responsable Ing. Martín Balao Alonso Carrera de Especialización


FIUBA

Estudiante

Colaboradores Lic. Mariano González

Consultor Externo Desarrollador de

Software C++ Senior

Orientadores Andrés López

Luksenberg

Consultor Externo Investigador en

Seguridad

Informática

Equipo - - -

Opositores - - -

Usuario Final Ing. Martín Balao Alonso Carrera de Especialización


FIUBA

Estudiante

Página 7 de 34




● Colaboradores

○ Lic. Mariano González

Posee amplia experiencia en desarrollo de software de rendering gráfico. Amplio

dominio del lenguaje C++ moderno (C++11) en plataformas Windows y OS X.

○ Andrés López Luksenberg

Experimentado investigador en seguridad informática, fuzzing y SMT solvers.

5. Propósito y Justificación del proyecto

El presente proyecto se enmarca como componente fundamental en el desarrollo de un framework

para fuzzear el stack gráfico de renderizado 3D web en todas sus capas: desde el parseo del código 1

generado hasta las transiciones en la máquina de estados de WebGL y la ejecución de los opcodes GLSL

en los GPU de la tarjeta gráfica.

El propósito es detectar vulnerabilidades de software y hardware en el stack gráfico, allanando el

camino para el desarrollo de Pruebas de Concepto (POC, por sus siglas en inglés) que demuestren su

posible explotación -control del flujo de ejecución-.

La detección de estas vulnerabilidades representa un aporte significativo para la mejora del software y

hardware de forma tal de que sea garantizada la confidencialidad, integridad y disponibilidad de la

información de organizaciones e individuos globalmente.

Los navegadores web son un vector interesante para la explotación de vulnerabilidades en software

debido a que permiten el control remoto de un dispositivo -client-side exploits-, son usados

extensivamente y, por su complejidad y tamaño, tienen una amplia superficie de ataque.

El renderizado 3D en navegadores web es una tecnología emergente. Una muestra de ello es que el

navegador Internet Explorer recién agregó soporte en su versión 11 (17 de octubre de 2013). Como

tecnología emergente, es propensa a la existencia de inconvenientes de seguridad.

Además de los propósitos técnicos, este trabajo constituye el Proyecto Final en la Especialización en

Sistemas Embebidos (Carrera en Sistemas Embebidos de la Facultad de Ingeniería - Universidad de

Buenos Aires) del Ing. Martín Balao Alonso.

1 El fuzzing es un testing de caja negra que consiste en encontrar bugs de implementación en el software a partir de la inyección automática de entradas mal formadas o semi-formadas. [1]

Página 8 de 34




6. Objetivos

1. Generar randómicamente código WebGL (JavaScript) con 100% de validez sintáctica y 100% de

validez semántica sobre una cobertura del 50% de la especificación (API) en su versión 1.0.2.

2. Generar randómicamente código GLSL con 100% de validez sintáctica y 100% de validez

semántica sobre una cobertura del 50% de la especificación The OpenGL® ES Shading Language

(versión 1.00 - revisión del documento número 17).

3. Generar randómicamente la mínima cantidad de código HTML requerida para el cumplimiento

de los objetivos 1. y 2.; con 100% de validez sintáctica.

4. Alcanzar un rendimiento promedio en la generación de código medible de la siguiente forma:

un caracter de salida del generador cada 1 milisegundo.

Como resultado del cumplimiento de los objetivos 1., 2. y 3.; se generará de forma aleatoria código

HTML sintáctica y semánticamente válido. Este código podrá ser renderizado en un navegador web de

las plataformas soportadas en el alcance del proyecto.

7. Alcance del proyecto

Se encuentra dentro del proyecto la generación de código en plataformas Windows 7 Professional y

Linux Mint 16, para arquitecturas Intel x86_64; de acuerdo a lo detallado en los objetivos del presente

trabajo (ver 6. Objetivos).

No se encuentran dentro del alcance del proyecto las siguientes metas:

● generación de código en plataformas OS X, Android u otra;

● implementación de extensiones específicas de los fabricantes (de navegadores o tarjetas

gráficas) a los estándares WebGL o GLSL;

● desarrollo de un framework de automatización para el envío del código a navegadores web

(fuzzing); ● generación de código sintáctica o semánticamente inválido; y,

● detección y explotación de vulnerabilidades surgida como producto del fuzzing.

8. Supuestos y restricciones del proyecto

El presente Trabajo asume los siguientes supuestos durante su realización:

● el compilador de código GLSL es capaz de compilar código conformante con el estándar y no

requiere componentes adicionales por fuera del mismo;

Página 9 de 34




● el fabricante de la tarjeta de video es capaz de ejecutar código GLSL compilado por el

desarrollador del compilador y no requiere extensiones al estándar;

● en la plataforma Windows, se asume disponibilidad del runtime de C++ para Visual Studio 2015;

● en la plataforma Linux, se asume una versión de la GLIBC igual o mayor a 2.22;

● para alcanzar los requerimientos de desempeño mencionados, no habrá en el sistema

operativo otra aplicación siendo ejecutada en paralelo al Generador Aleatorio de Código

WebGL y GLSL más allá de las que ejecutan en una instalación by default de la plataforma;

● para alcanzar los parámetros de desempeño especificados en los Objetivos de este Trabajo, se

requiere que el Generador Aleatorio de Código WebGL y GLSL tenga una política de scheduling

en el sistema operativo de máximo desempeño (Real Time en Windows y nice -20 en Linux);

● se asume una disponibilidad de memoria RAM en el sistema operativo donde ejecute el

Generador Aleatorio de Código WebGL y GLSL de al menos 1 GB.

A su vez, se manifiestan las siguientes restricciones:

● El correcto funcionamiento del código se restringe a las plataformas utilizadas durante su

desarrollo (sistema operativo, navegadores web y placa de video), pudiendo existir problemas

de compatibilidad para su ejecución en plataformas diferentes -no probadas-;

● el Generador Aleatorio de Código WebGL y GLSL no es capaz de manejar situaciones de error de

ninguna naturaleza -por ejemplo: insuficiencia de memoria en el proceso o en el stack de

alguno de sus hilos- y aborta ante la ocurrencia de la misma perdiéndose el proceso (navegador

web) y su layout de memoria; y,

● el Generador Aleatorio de Código WebGL y GLSL será multi-hilo en su implementación interna

pero no soportará múltiples llamadas concurrentes de un mismo proceso para lograr

ejecuciones en paralelo.

9. Requerimientos

1. Sistema de buildeo (compilación, linkeo y deployment) del Generador Aleatorio de Código

WebGL y GLSL multiplataforma

a. soporte de la plataforma Windows

b. soporte de la plataforma Linux

Prioridad: baja

2. Generación aleatoria de código HTML básico

a. Generación de encabezados (header y body) b. Generación de elementos Canvas (para renderear frames mediente WebGL)

c. Generación de elementos Script (para código JS/WebGL)

Página 10 de 34




Prioridad: alta

3. Generación de código WebGL (JS)

Prioridad: alta

4. Generación de código GLSL

Prioridad: alta

5. Desarrollo de un código de ejemplo para mostrar la utilización de la librería del Generador

Aleatorio de Código WebGL y GLSL

Prioridad: baja

10. Entregables principales del proyecto

1. Librería dinámica con el Generador Aleatorio de Código GLSL y WebGL compilado en modo

release (máximo desempeño) y exportados los símbolos de las funciones públicas sin manglear

(para resultar invocables desde código C)

a. DLL para sistemas operativos Windows

b. Shared Object para sistemas operativos Linux

2. Archivo header (.h) para la utilización de la librería dinámica

3. Binario ejecutable de ejemplo capaz de invocar a la librería del ítem 1

a. EXE para sistemas operativos Windows

b. ELF para sistemas operativos Linux

4. Archivo de configuración de ejemplo de la librería del ítem 1

5. Documentación sobre el uso de la librería y el archivo de configuración

6. Código fuente del Generador Aleatorio de Código GLSL y WebGL y del sistema de buildeo sin

cesión de derechos y bajo estricto acuerdo de confidencialidad (NDA)

7. Documentos de Planificación y Presentación asociados al Proyecto

8. Informe de Avance del Trabajo

9. Memoria del Trabajo

10. Presentación ante el Jurado del Trabajo

Página 11 de 34




11. Desglose del trabajo en tareas

El presente Trabajo se compone de los siguientes grupos de tareas:

1. Establecer ambiente de trabajo

1.1. Instalar máquinas virtuales con plataformas Windows y Linux

1.2. Instalar software de trabajo (Visual Studio 2015, CMake Windows, GCC, CMake Linux,

etc.)

2. Construir un sistema de buildeo multiplataforma

2.1. Organizar la estructura de directorios del Proyecto

2.2. Escribir archivos CMakeList para el buildeo y post-buildeo automatizado de la librería y

la aplicación de ejemplo que use la librería.

2.3. Probar el CMakeList en plataforma Windows

2.4. Probar el CMakeList en plataforma Linux

3. Desarrollar librería del Generador Aleatorio de Código WebGL y GLSL

3.1. Desarrollar el generador de código HTML

3.2. Desarrollar el generador de código WebGL/JS

3.3. Desarrollar el generador de código GLSL

4. Desarrollar una aplicación de ejemplo que utilice la librería

5. Documentar la librería

6. Realizar tareas de planificación, seguimiento y control del Proyecto

7. Preparar y realizar una presentación del Trabajo

7.1. Preparar Presentación del Proyecto

7.2. Preparar Informe de Avance del Trabajo

7.3. Preparar Memoria del Trabajo

7.4. Preparar Presentación Final ante el Jurado

12. Análisis de factibilidad

El fuzzing como técnica de testing automatizado de software comenzó su desarrollo en el año 1989, con

el liderazgo del profesor Barton Miler (Universidad de Wisconsin) [1].

Desde entonces, los fuzzers han ido incrementando su complejidad a la par del software que buscan

probar. Para ser efectivo, se requiere que la entrada producida por un fuzzer pase pruebas elementales

de consistencia [2]. Esto es, para un fuzzer de un intérprete o compilador de lenguaje de programación,

tener validez semántica.

LangFuzzer ha demostrado, en el año 2012, ser capaz de generar código de lenguajes como JavaScript y

PHP a partir de gramáticas del lenguaje. En este sentido, ha logrado encontrar significativas

Página 12 de 34




vulnerabilidades en navegadores web; 105 calificadas como severas en el intérprete de Javascript

utilizado por el navegador de la fundación Mozilla.

El Generador Aleatorio de código WebGL y GLSL tendrá las reglas de validez sintáctica y semántica

incorporadas en su diseño (algoritmos de generación y modelado de datos). Por lo tanto, la lógica de

generación se encuentra relacionada estrechamente a un lenguaje (GLSL) y a una máquina de estados

en particular (WebGL).

Si bien esto reduce la cantidad de software que se puede fuzzear -en contraposición a un fuzzer

genérico como LangFuzzer-, permite profundizar en la lógica de generación (“inteligencia” del fuzzer).

A diferencia de fuzzers basados en parseo de un subconjunto de entradas existentes, el Generador

Aleatorio de código WebGL y GLSL se basa únicamente en su modelado y la aleatoriedad: son

potencialmente generables como salida la totalidad de los elementos, construcciones e interacciones

permitidos en el lenguaje.

Otro caso de éxito que vale mencionar, a nivel de fuzzers de lenguajes de programación, es CSmith

(https://embed.cs.utah.edu/csmith). Este proyecto, desarrollado por la Universidad de Utah, ha

logrado encontrar más de 400 bugs desconocidos en compiladores de lenguaje C.

Vulnerabilidades como CVE-2012-3967 y CVE-2012-3968 demustran que los stacks de rendering

gráficos, así como el software en su conjunto, no son infalibles.

El conjunto de factores descripto hacen suponer la factibilidad técnica y la probabilidad de éxito del

presente Proyecto.

Página 13 de 34




13. Diagrama de Activity On Node

Notas:

● los tiempos se encuentran expresados en horas; y,

● el camino crítico se encuentra indicado con las flechas gruesas.

Página 14 de 34




14. Diagrama de Gantt

Página 15 de 34




Diagrama Gannt en el período Noviembre 2015 - Diciembre 2015

Diagrama Gannt en el período Febrero 2016 - Marzo 2016

Página 16 de 34




Diagrama Gannt en el período Abril 2016 - Mayo 2016

Diagrama Gannt en el período Junio 2016

Página 17 de 34




15. Matriz de uso de recursos de materiales

● Recursos materiales

○ Estación de trabajo para el desarrollo con tajeta gráfica NVIDIA Quadro K2000M

■ Capacidad de crear entornos virtualizados de desarrollo ○ Impresora blanco y negro

Código WBS

Nombre de la tarea

Recursos requeridos (horas)

Estación de Trabajo

Impresora

1.1 Instalar máquinas virtuales con plataformas Windows y

Linux

4 0

1.2 Instalar software de trabajo (Visual Studio 2015, CMake

Windows, GCC, CMake Linux, etc.)

5 0

2.1 Organizar la estructura de directorios del Proyecto 2 0

2.2 Escribir archivos CMakeList para el buildeo y post-buildeo

automatizado de la librería y la aplicación de ejemplo que

use la librería.

10 0

2.3 Probar el CMakeList en plataforma Windows 3 0

2.4 Probar el CMakeList en plataforma Linux 3 0

3.1 Desarrollar el generador de código HTML 80 0

3.2 Desarrollar el generador de código WebGL/JS 130 0

3.3 Desarrollar el generador de código GLSL 200 0

4 Desarrollar una aplicación de ejemplo que utilice la

librería

8 0

5 Documentar la librería 25

6 Realizar tareas de planificación, seguimiento y control del

Proyecto

20 1

Página 18 de 34




7.1 Preparar Presentación del Proyecto 20 1

7.2 Preparar Informe de Avance del Trabajo 15 1

7.3 Preparar Memoria Final del Trabajo 50 1

7.4 Preparar Presentación Final del Proyecto ante Jurado 10 1

Total: 585 5

16. Presupuesto detallado del proyecto

● Análisis de costos directos

○ Costo/hora de un desarrollador: 120 $ARG (incluyendo cargas sociales e impuestos)

Código WBS

Nombre de la tarea

Horas de

Trabajo

Costo por tarea

1.1 Instalar máquinas virtuales con plataformas Windows y

Linux

4 480

1.2 Instalar software de trabajo (Visual Studio 2015, CMake

Windows, GCC, CMake Linux, etc.)

5 600

2.1 Organizar la estructura de directorios del Proyecto 2 240

2.2 Escribir archivos CMakeList para el buildeo y post-buildeo

automatizado de la librería y la aplicación de ejemplo que

use la librería.

10 1200

2.3 Probar el CMakeList en plataforma Windows 3 360

2.4 Probar el CMakeList en plataforma Linux 3 360

3.1 Desarrollar el generador de código HTML 80 9600

3.2 Desarrollar el generador de código WebGL/JS 130 15600

Página 19 de 34




3.3 Desarrollar el generador de código GLSL 200 24000

4 Desarrollar una aplicación de ejemplo que utilice la librería 8 960

5 Documentar la librería 25 3000

6 Realizar tareas de planificación, seguimiento y control del

Proyecto

20 2400

7.1 Preparar Presentación del Proyecto 20 2400

7.2 Preparar Informe de Avance del Trabajo 15 1800

7.3 Preparar Memoria del Trabajo 50 6000

7.4 Preparar Presentación Final ante el Jurado 10 1200

Costos directos totales: $ARG 70200

● Análisis de costos indirectos en licencias de software (estos costos ya se encuentran cubiertos al momento de iniciar este Proyecto)

○ Hipervisores ■ Virtual Box 5.0 - $ARG 0

○ Sistemas Operativos

■ Windows 7 Professional (64 bits) - $ARG 0 (se paga el costo por suscripción a MSDN y eso está considerado en el costo de la licencia del Visual Studio 2015)

■ Linux Mint 16 (64 bits) - $ARG 0

○ Compiladores ■ Visual Studio Professional 2015 - $ARG 11000 ■ GCC 5.1 - $ARG 0

○ Navegadores

■ Chrome 46 - $ARG 0

○ Otros ■ CMake 3.1.2 - $ARG 0 ■ Boost (biblioteca C++) - $ARG 0

Página 20 de 34




● Otros costos indirectos

○ Costos de impresión: $ARG 300

Costos totales del proyecto (costos directos + costos indirectos): $ARG 70500.

Página 21 de 34




17. Matriz de asignación de responsabilidades

Código WBS

Título de la tarea

Listar todos los nombres y apellidos y el rol definidos en el proyecto

Ing. Martín Balao

Alonso Aupiciante /

Impulsor Responsable / Usuario

final


Cliente

Dr. Juan Pablo

Galeotti

Lic. Marian

o Gonzále

z Colabor

ador

Andrés López

Luksenberg Orientador

1.1 Instalar máquinas virtuales con

plataformas Windows y Linux

P

1.2 Instalar software de trabajo

(Visual Studio 2015, CMake

Windows, GCC, CMake Linux,

etc.)

P

2.1 Organizar la estructura de

directorios del Proyecto

P C

2.2 Escribir archivos CMakeList

para el buildeo y post-buildeo

automatizado de la librería y la

aplicación de ejemplo que use

la librería.

P S

2.3 Probar el CMakeList en

plataforma Windows

P I I I

2.4 Probar el CMakeList en

plataforma Linux

P I I I

3.1 Desarrollar el generador de

código HTML

P A / I A / I C


código WebGL/JS

P A / I A / I C


código GLSL

P A / I A / I C

Página 22 de 34




4 Desarrollar una aplicación de

ejemplo que utilice la librería

P I I

5 Documentar la librería P A / I A / I

6 Realizar tareas de planificación,

seguimiento y control del

Proyecto

P A / I A / I

7.1 Preparar Presentación del

Proyecto

P A / I A / I

7.2 Preparar Informe de Avance del

Trabajo

P A / I A / I

7.3 Preparar Memoria del Trabajo P A / I A / I

7.4 Preparar Presentación Final

ante el Jurado

P A / I A / I

Referencias: P = Responsabilidad Primaria S = Responsabilidad Secundaria A = Aprobación I = Informado C = Consultado

18. Gestión de riesgos a) Identificación de los riesgos (al menos cinco) y estimación de sus consecuencias:

● Riesgo 1: se pierde el código del Generador Aleatorio de Código de WebGL y GLSL ○ Severidad (S): 10 - el código es uno de los entregables más importantes del Proyecto.

Sin el código, no se puede construir la librería. ○ Probabilidad de ocurrencia (O): 4 - los escenarios en los que sería más probable que

esto ocurriera serían los de robo del medio digital donde el código está contenido. Como menos probable aparece un desperfecto en el medio de almacenamiento digital.

○ Tasa de no detección (D): 2 - al trabajar diariamente sobre el código, este tipo de riesgo sería detectado de inmediato -entre 1 y 3 días-.

● Riesgo 2: al ser el equipo de trabajo de una única persona, cualquier inconveniente que pudiera ocurrirle paralizaría totalmente el avance del Proyecto

○ Severidad (S): 10 - la paralización del proyecto es total y esto puede ocurrir en una ventana de tiempo mayo a 6 meses.

Página 23 de 34




○ Probabilidad de ocurrencia (O): 3 - no es un hecho común basados en la disponibilidad del equipo de trabajo en anteriores Proyectos. Lo más probable podrían ser 3 o 4 días de ausencia por enfermedad durante la totalidad del período en el cual se desarrolla el Proyecto.

○ Tasa de no detección (D): 1 - la detección de este riesgo es inmediata: como máximo 1 día.

● Riesgo 3: se cancela el servicio gratuito online de repositorio GIT ○ Severidad (S): 5 - si bien se interrumpiría la sincronización de archivos con el repositorio

online, el equipo de trabajo podría continuar trabajando de forma local. Al ser el equipo de trabajo de una sola persona, no es necesaria la sincronización a nivel de código fuente u otros documentos versionados a través de GIT.

○ Probabilidad de ocurrencia (O): 3 - el servicio que se utilizará (BitBucket.org) ha demostrado en los últimos años ser estable y mantener la suscripción gratuita.

○ Tasa de no detección (D): 2 - la detección de este hecho es inmediata -entre 1 y 3 días- ya que se va a sincronizar con el repositorio online al menos una vez por jornada de trabajo en el código o en archivos versionados.

● Riesgo 4: se daña o roba la estación de trabajo ○ Severidad (S): 8 - paraliza temporalmente al Proyecto e implica re-instalar en otro

equipo los ambientes virtualizados de trabajo (sistema operativo y herramientas) ○ Probabilidad de ocurrencia (O): 3 - no es habitual que este tipo de hecho suceda. De

hecho, en los 2 años que tiene la estación de trabajo, hubo 100% de disponibilidad. ○ Tasa de no detección (D): 2 - la detección de este hecho es inmediata -entre 1 y 2 días-

ya que para trabajar en el Proyecto se requiere de la estación de trabajo.

● Riesgo 5: el equipo de trabajo pierde la motivación en el proyecto, reduciendo su productividad.

○ Severidad (S): 6 - los plazos y alcance del proyecto pueden verse severamente afectados por este hecho.

○ Probabilidad de ocurrencia (O): 1 - la iniciativa de realizar este Proyecto fue del equipo de trabajo, que ha estado desde hace más de 5 años interesado en la seguridad informática.

○ Tasa de no detección (D): 5 - determinar que se trata de un problema motivacional puede llevar tiempo, dependiendo de la comunicación y expresividad de los integrantes del equipo de trabajo.

b) Tabla de gestión de riesgos:

Riesgo Severidad Ocurren. Detección RPN Severidad* Ocurren.*

Detecc * RPN*

1 10 4 2 80 1 1 2 2

2 10 3 1 30 - - - -

3 5 3 2 30 - - - -

Página 24 de 34




4 8 3 2 48 6 3 2 36

5 6 1 5 30 - - - -

Criterio adoptado: - Se tomarán medidas de mitigación en los riesgos cuyos números de RPN sean estrictamente mayores a 40. Nota: - Los valores marcados con (*) en la tabla corresponden luego de haber aplicado la mitigación. c) Plan de mitigación de los riesgos que originalmente excedían el PRN máximo establecido:

● Riesgo 1: se utilizará como respaldo del código generado un repositorio GIT online en donde se realizará una sincronización con la copia local al menos una vez al día (por cada día en el cual existan modificaciones en el código)

○ Severidad (S): 1 - de perderse el código en la copia local, debería realizarse una clonación del repositorio GIT online. Por las dimensiones del Proyecto, esta clonación se realizaría en pocos segundos.

○ Probabilidad de ocurrencia (O): 1 - para que este riesgo se concrete, debería perderse el código simultáneamente en la copia local y en el repositorio GIT online -ambos localizados en sitios geográficos diferentes-.

○ Tasa de no detección (D): 2 - de concretarse el riesgo, se detectaría inmdiatamente. El plan de mitigación no modifica la tasa de detección de este riesgo.

● Riesgo 4: se respaldan en un medio de almacenamiento externo las máquinas virtuales que se utilizan para el desarrollo del proyecto.

○ Severidad (S): 6 - sería necesario adquirir o conseguir una nueva estación de trabajo y mover las máquinas virtuales desde la copia de respaldo.

○ Probabilidad de ocurrencia (O): 3 - el plan de mitigación no modifica la probabilidad de ocurrencia sino que atenúa su impacto en el Proyecto.

○ Tasa de no detección (D): 2 - el plan de mitigación no modifica la tasa de detección de este riesgo.

Página 25 de 34




19. Gestión de la calidad Según la norma IEEE 10122004, en su apartado 1.1 Scope, los términos verificación y validación de software refieren a lo siguiente: El proceso de verificación provee evidencia objetiva de si el software y sus productos y procesos asociados

A. Conforman a los requerimientos (ej. correctitud, completitud, consistencia, precisión) para todas las actividades del ciclo de vida durante cada proceso del ciclo de vida (adquisión, provisión, desarrollo, operación y mantenimiento)

B. Satisfacen los estándares, prácticas y convenciones durante los procesos del ciclo de vida C. Satisfactoriamente completan cada actividad del ciclo de vida y satisfacen todos los criterios para

inicializar las actividades del ciclo de vida sucesivas (ej. construir el software correctamente) El proceso de validación provee evidencia de si el software y sus productos asociados

A. Satisfacen los requerimientos del sistema asignados al software al final de cada actividad del ciclo de vida

B. Soluciona el problema correcto (ej. correctamente se modelan las leyes físicas, implementan las reglas de negocio, se usan correctamente los supuestos del sistema)

C. Satisface el uso intencionado y las necesidades del usuario. Utilizaremos la definición previamente citada en esta sección del documento de Planificación para cada requerimiento. Requerimientos

● Sistema de buildeo (compilación, linkeo y deployment) del Generador Aleatorio de Código

WebGL y GLSL multiplataforma

a. soporte de la plataforma Windows

b. soporte de la plataforma Linux

Calidad: el sistema de buildeo es capaz de compilar, linkear y deployar el Generador Aleatorio

de Código WebGL y GLSL en plataformas Windows y Linux

Grado de calidad: el sistema de buildeo permite que se agreguen archivos de código fuente al

Proyecto sin necesidad de modificar los archivos de configuración

Costo de conformidad: 16 horas de trabajo

Costo de no-conformidad: se pierde tiempo buildeando manualmente el proyecto mediante

comandos escritos en archivos de texto. Los comandos para buildear son dependientes de cada

plataforma y pueden llegar a ser complejos de escribir.

Validación: todo proyecto profesional de software tiene un sistema de buildeo automatizado.

Se valida con el cliente si el sistema de buildeo satisface su expectativa y si, una vez terminado, él es

capaz de utilizarlo en su propio ambiente. Los responsables de validar este requerimiento son el

Responsable del Proyecto y el Cliente.

Página 26 de 34




Verificación: al ejecutar el sistema de buildeo, se comprueba que se haya generado la librería y

la aplicación de ejemplo tanto en plataformas Windows como Linux (se puede observar la fecha de

creación de los archivos binarios para estar seguros de que fueron regenerados). El responsable de

verificar la implementación de este requerimiento es el Responsable del Proyecto.

● Generación aleatoria de código HTML básico

c. Generación de encabezados (header y body) d. Generación de elementos Canvas (para renderear frames mediente WebGL)

e. Generación de elementos Script (para código JS/WebGL)

Calidad: se generan los elementos HTML básicos mencionados en el requerimiento, siguiendo

las reglas sintácticas del lenguaje y siendo aleatorizados tanto su ordenamiento como cantidad de

elementos hijos.

Grado de calidad: para el elemento canvas (elemento HTML más relevante), se generan todos

los atributos posibles del elemento de forma aleatoria.


Costo de no-conformidad: el proyecto es inviable: los códigos WebGL y GLSL generados no

pueden operar sobre ningún elemento canvas y el parser del navegador web descarta la entrada

rápidamente (sin ser probadas las diferentes capas del stack de rendering gráfico ni la máquina de

estados de WebGL). No se puede cumplir con el 100% de los objetivos del Proyecto.

Validación: se validará con el cliente el enfoque utilizado en este Proyecto: no se está

fuzzeando al parser de HTML del navegador web sino que se está generando el código mínimo

necesario para poder operar sobre la máquina de estados de WebGL y el rendering gráfico. Los

responsables de validar este requerimiento son el Responsable del Proyecto y el Cliente.

Verificación: se verifica la correctitud del código HTML generado rendereando el mismo en un

navegador web. El responsable de verificar la implementación de este requerimiento es el Responsable

del Proyecto.

● Generación de código WebGL (JS)

Calidad: el código WebGL generado tiene 100% de validez sintáctica, 100% de validez

semántica y alcanza el 50% de la especificación de acuerdo a los objetivos trazados en este Proyecto.

Grado de calidad: la cobertura del estándar seleccionada permite que los elementos gráficos

sean rendereados (visibles) en el navegador, más allá de exitar la máquina de estados de WebGL.

Costo de conformidad: 130 horas de trabajo.

Página 27 de 34




Costo de no-conformidad: el proyecto es inviable: no se puede cumplir con 75% de los

objetivos del Proyecto.

Validación: se validará con el Cliente su expectativa de fuzzear la máquina de estados de

WebGL en el navegador web. Los responsables de validar este requerimiento son el Responsable del

Proyecto y el Cliente.

Verificación: se verificará que a nivel JS, se ejecuta la totalidad del código generado (en lugar de

existir un error en el intérprete). El responsable de verificar la implementación de este requerimiento

es el Responsable del Proyecto.

● Generación de código GLSL

Calidad: el código GLSL generado tiene 100% de validez sintáctica, 100% de validez semántica y

alcanza el 50% de la especificación de acuerdo a los objetivos trazados en este Proyecto.

Grado de calidad: la cobertura del estándar seleccionada permite que los elementos gráficos

sean rendereados (visibles) en el navegador, más allá de exitar al compilador de GLSL.

Costo de conformidad: 200 horas de trabajo.

Costo de no-conformidad: el proyecto es inviable: no se puede cumplir con 75% de los

objetivos del Proyecto.

Validación: se validará con el Cliente su expectativa de fuzzear el compilador de código GLSL y

el stack de rendering gráfico. Los responsables de validar este requerimiento son el Responsable del

Proyecto y el Cliente.

Verificación: se verificará que el compilador de GLSL es capaz de compilar el código generado.

El responsable de verificar la implementación de este requerimiento es el Responsable del Proyecto.

● Desarrollo de un código de ejemplo para mostrar la utilización de la librería del Generador

Aleatorio de Código WebGL y GLSL

Calidad: la aplicación de ejemplo utiliza toda la funcionalidad pública expuesta por la librería

del Generador Aleatorio de Código WebGL y GLSL.

Grado de calidad: la aplicación de ejemplo se encuentra bien documentada y utiliza las

interfaces C y C++ de la librería del Generador Aleatorio de Código WebGL y GLSL.


Costo de no-conformidad: el Cliente puede tener dudas sobre cómo utilizar la librería del

Generador Aleatorio de Código WebGL y GLSL: cómo compilar, linkear, cuál es la interfaz pública de la

librería y cómo usarla. El código de ejemplo resultará esclarecedor para el Cliente, ahorrará consultas y

mejorará su satisfacción con el Proyecto.

Página 28 de 34




Validación: se validará con el Cliente la conveniencia de realizar una aplicación de ejemplo y

que el Cliente haya sido capaz de ejecutar correctamente la aplicación de ejemplo una vez que sea

entregada. Los responsables de validar este requerimiento son el Responsable del Proyecto y el Cliente.

Verificación: se verificará que la aplicación de ejemplo es capaz de utilizar toda la funcionalidad

expuesta por la librería del Generador Aleatorio de Código WebGL y GLSL, a través de una invocación a

la misma y la verificación de la salida (código HTML con WebGL y GLSL). El responsable de verificar la

implementación de este requerimiento es el Responsable del Proyecto.

20. Comunicación del proyecto El plan de comunicación del proyecto es el siguiente:

PLAN DE COMUNICACIÓN DEL PROYECTO

¿Qué comunicar?

Audiencia Propósito Frecuencia Método de comunicac.

Responsable

Avance del Proyecto

Esp. Ing. Pablo Ridolfi, Dr. Juan Pablo Galeotti

Recibir feedback del Cliente para asegurar que

los requerimientos del Proyecto y

su implementación satisfacen las

expectativas (pudiendo

tomar acciones correctivas a

tiempo en caso de ameritarlo)

Cada 2 semanas

Email Ing. Martín Balao Alonso

Presentación inicial del

Proyecto

Esp. Ing. Pablo Ridolfi, Dr. Juan Pablo Galeotti

Presentar la Planificación del Proyecto para recibir

feedback público sobre

el mismo y realizar los ajustes que

sean pertinentes

(reduciendo el

1 vez en todo el Proyecto

Exposición oral con

diapositivas de apoyo


Página 29 de 34




costo de realizar los ajustes en

etapas tardías)

Informe de Avance del

Trabajo

Esp. Ing. Pablo Ridolfi, Dr. Juan Pablo Galeotti,

Jurado

Recibir feedback del

Jurado acerca de la alineación del Proyecto a los objetivos

trazados


Documento impreso


Memoria Final del Trabajo


Jurado

Recibir una evaluación final

del Jurado sobre el

cumplimiento de los objetivos trazados en el Proyecto y su aprobación


Documento impreso


Presentación Final del Proyecto


Jurado

Presentar el Proyecto

terminado para que el Jurado

pueda evaluarlo


Exposición oral con

diapositivas de apoyo


21. Gestión de Compras Criterio para la selección de proveedores de licencias de software:

● se contratará la licencia directamente al desarrollador del producto de software. Se abonará la misma con tarjeta de crédito internacional en el caso de que se trate de un proveedor ubicado en el extranjero y que no tenga representación local en Argentina. Si el proveedor tuviera representación oficial o partners en Argentina, se contratará de forma directa y se abonará en efectivo con moneda local (pesos argentinos).

Criterio para la selección de proveedores de servicios de impresión:

Página 30 de 34




● se elegirá un proveedor ubicado en la Ciudad Autónoma de Buenos Aires que cumpla los siguientes requerimientos:

○ precio máximo por página (blanco y negro): $ARG 1 ○ tiempo máximo de entrega para la impresión: 24 horas hábiles

Durante la realización de este Proyecto, no se sub-contratan servicios de terceros.

22. Seguimiento y control

SEGUIMIENTO DE AVANCE

Tarea del WBS

Indicador de avance

Frecuencia de reporte

Responsable de seguimiento

Persona a ser informada

Método de comunicac.

1.1 Cantidad de máquinas virtuales

configuradas sobre un total

de 2

Al finalizar la tarea


- Email

1.2 Cantidad de software

configurado sobre un total

de 2 por plataforma (Windows y

Linux)



- Email

2.1 Grupos de directorios

creados sobre un total de 3: 1. 3rd parties, 2. librería y 3. aplicación de

ejemplo



- Email

2.2 Cantidad de archivos

CMake lists escritos (sobre un total de 3)



- Email

Página 31 de 34




para buildear: 1. 3rd parties del proyecto, 2. librería y 3. aplicación de

ejemplo

2.3 El proyecto (con archivos de ejemplo)

puede ser buildeado

correctamente



Lic. Mariano González /


/ Dr. Juan Pablo

Galeotti

Email

2.4 El proyecto (con archivos de ejemplo)

puede ser buildeado

correctamente



Lic. Mariano González /


/ Dr. Juan Pablo

Galeotti

Email

3.1 Cantidad de tipos de

elementos HTML

generados sobre un total

de 6: 1. Doctype, 2.

HTML, 3. HEAD, 4. BODY, 5. META, 6. CANVAS

Cada 2 semanas Ing. Martín Balao Alonso


/ Dr. Juan Pablo

Galeotti

Email

3.2 Porcentaje de invocaciones a funciones de WebGL sobre

el total de funciones

especificadas por la versión

1.00 del estándar



/ Dr. Juan Pablo

Galeotti

Email / Skype / Presencial

Página 32 de 34




3.3 Porcentaje de implementaci

ón del estándar GLSL



/ Dr. Juan Pablo

Galeotti

Email / Skype / Presencial

4 Existencia de una aplicación

de ejemplo




/ Dr. Juan Pablo

Galeotti

Email

5 Existencia de documentación de la librería




/ Dr. Juan Pablo

Galeotti

Email

6 Se genera al menos una

iteración (actualización)

del documento de

Planificación cada 4

semanas



/ Dr. Juan Pablo

Galeotti

Email

7.1 Proyecto presentado




/ Dr. Juan Pablo

Galeotti

Email

7.2 Informe de Avance escrito




/ Dr. Juan Pablo

Galeotti

Email

7.3 Memoria del Trabajo escrita




/ Dr. Juan Pablo

Galeotti

Email

7.4 Proyecto presentado




Email

Página 33 de 34




/ Dr. Juan Pablo

Galeotti

23. Procesos de cierre

● El Auspiciante, Ing. Martín Balao Alonso, será el encargado de agradecer al Cliente, al equipo de trabajo y a los colaboradores del Proyecto a través de una reunión final de cierre. El Auspiciante financiará los gastos de dicha reunión (catering).

● En la reunión de cierre, el Ing. Martín Balao Alonso en su calidad de Responsable del Proyecto y encargado de las actividades de planificación, seguimiento y control, liderará un análisis de post-mortem sobre el Proyecto con el fin de extraer las soluciones encontradas a problemas relevantes, las lecciones aprendidas durante el mismo y las oportunidades de mejora futura. El Cliente, el equipo de trabajo y los colaboradores expondrán sus puntos de vista y se buscará llegar a un consenso. A partir de este consenso, el Responsable del Proyecto elaborará una nota de reunión con las lecciones aprendidas que se distribuirá por email a todos los participantes.

● Como parte del intercambio anterior -y documentado en una sub-sección de la notas de reunión-, se realizará una evaluación sobre la alineación del proyecto con la Planificación establecida, incluyendo:

○ desviaciones sobre el plan original; ○ seguimiento de dichas desviaciones; ○ cumplimiento de los plazos establecidos; y, ○ cumplimiento de los objetivos establecidos.

24. Bibliografía [1] - OWASP - https://www.owasp.org/index.php/Fuzzing - 11.11.2015 [2] - Fuzzing with Code Fragments - Holler, C; Herzig, K; Zeller, A. - 2012

Página 34 de 34

Documents

Generador Aleatorio de Código WebGL y GLSLlaboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo... · y de Validación de la norma IEEE 1012-2004. En la sección 20, se modifica el