Asignatura Seguridad en el Software
Datos del alumno
Fecha
Apellidos: Rincón Peralta
22/09/2016
Nombre: Victor Julio
Actividades Trabajo: Comparación de ciclos de vida de desarrollo de software seguro (S-SDLC) Como actividad puntuable para el tema 1, te propongo seguir profundizando en los modelos S-SDLC, realizando un trabajo que contenga al menos el siguiente contenido: Introducción a los S-SDLC. Descripción resumida de los diferentes tipos de S-SDLC. Comparación de los diferentes S-SDLC, cubriendo al menos las siguientes características: o Actividades de Ingeniería de Requisitos. o Actividades de diseño. o Actividades de implementación. o Actividades de pruebas de verificación y validación. o Recursos. o Uso por la empresa. o Etc. Propuesta de un nuevo S-SDLC. Conclusiones. Extensión máxima de la actividad: 8 a 12 páginas, fuente Georgia 11 e interlineado 1,5. INTRODUCCION
La mayoría de vulnerabilidades se pueden solucionar en la fase de desarrollo de los procesos de desarrollo de aplicaciones por ello es importante tener en cuenta un desarrollo de software seguro ya que es de alta importancia en las compañías, debido a que hoy en día casi todas las empresas dependen altamente de sus aplicaciones como parte integral de la operación normal. Por lo anterior es necesario implementar efectivamente metodologías de desarrollo seguro que se puedan aplicar en cada fase del ciclo de vida de tal manera que la seguridad este presente desde el inicio del proceso de desarrollo. Hace tiempo la Ingeniería de Software y la Ingeniería de Seguridad se venían desarrollando de forma independiente, lo que ocasionaba que la seguridad fuese considerada como parte del proceso de desarrollo software seguro, ocasionando inconsistencias en los procesos, cosa contraria a lo que se hace hoy en día. TEMA 1 – Actividades
Asignatura Seguridad en el Software
Datos del alumno
Fecha
Apellidos: Rincón Peralta Nombre: Victor Julio
22/09/2016
Tipos de S-SDLC Microsoft Trustworthy Computing SDL Este es uno de los ciclos de vida más usados para la realización de software seguro. El esquema del S-SDLC propuesto es el siguiente:
[1] Y los pasos que se implementan son las siguientes:
Formar a los desarrolladores en seguridad para que todos los componentes se desarrollen conociendo las amenazas. Las tareas de seguridad en las actividades de requisitos son: establecer que requisitos de seguridad existen en el proyecto, para ello puede necesitarse la participación de un asesor de seguridad en la implementación del SDL. Se utilizará la figura del asesor como guía a través de los procedimientos del SDL. En este punto cada equipo de desarrollo debe tener en cuenta como requisitos las características de seguridad para cada fase. Algunos requisitos pueden aparecer a posteriori, por ejemplo, cuando se realice el modelo de amenazas. Las tareas de seguridad en las actividades de diseño son: los requisitos de diseño con sus necesidades de seguridad quedarán definidos. Se realizará documentación sobre los elementos que se encuentren en la superficie de un ataque al software, y, por último, se realizará un modelo de amenazas, dónde pueden descubrirse nuevos requisitos de seguridad. Las tareas de seguridad en las actividades de implementación son: aplicación de los estándares de desarrollo y de pruebas. Posteriormente se aplicará software que compruebe la seguridad. Además, se realizarán pruebas de code review. Las tareas de seguridad en las pruebas de verificación y validación son: análisis dinámico sobre la aplicación, revisiones de código desde el punto de vista de la seguridad y pruebas centradas en la seguridad del software. TEMA 1 – Actividades
Asignatura Seguridad en el Software
Datos del alumno
Fecha
Apellidos: Rincón Peralta Nombre: Victor Julio
22/09/2016
Se necesita generar un plan de incidentes al final del proceso, una revisión final de toda la seguridad del proceso y crear un plan ejecutivo de respuesta ante incidentes, dónde se obtendrá un feedback de todo lo que ocurre en la liberación del software.
CLASP Comprehensive LIghtweight Application Security Process, de OWASP. CLASP es un conjunto de piezas, el cual podría ser integrado en otros procesos de desarrollo de software. Tiene ciertas propiedades como son su fácil adopción a otros entornos y la eficiencia. Su fuerte es la riqueza de recursos de seguridad que dispone, lo cual deberá ser implementado en las actividades del SDLC. Tiene esta fuerza debido a que OWASP está detrás de ello. CLASP se organiza en cinco vistas: Concepts view Role-Based view. Activity-Assesment view. Activity-Implementation view. Vulnerability view. Todas las vistas se interconectan entre sí, y este detalle es importante. Los roles dentro de CLASP son muy importantes y existen siete: gerente, arquitecto, ingeniero de requisitos, diseñador, codificador, tester y auditor de seguridad. Se puede ver que la seguridad se encuentra incluida, con una figura importante, dentro del proceso. Todos los roles deben estar en cualquier proyecto, sino no se cumpliría CLASP. La vista Activity-Assesment es importante, ya que identifica 24 actividades o tareas que pueden ejecutarse. Son tareas relacionadas con la seguridad del desarrollo del software, Como por ejemplo la identificación de una política de seguridad, documentar los requisitos relevantes con la seguridad, realización de code-signing, etcétera. La vista de vulnerabilidades es la encargada de clasificar los tipos de fallos de seguridad que se puedan encontrar en el software. Consta de 5 subgrupos.[2] McGraw's Propone unas prioridades para las tareas de seguridad y de este modo saber qué cosas tenemos que proteger primero o tener en cuenta, las cuales se proponen en orden: TEMA 1 – Actividades
Asignatura
Datos del alumno
Fecha
Apellidos: Rincón Peralta
Seguridad en el Software
22/09/2016
Nombre: Victor Julio
Revisión de código (code review). Tarea de análisis de código estático, el cual debe ser teniendo
conocimientos
de
seguridad
y
buenas
prácticas
escrito
de programación. Fase de
implementación. Análisis de riesgo. Esta tarea es ejecutada en tres fases y es de vital importancia en la toma de decisiones del proceso. Fase de requisitos, análisis, diseño y testing. Test de intrusión (Pentesting). Tanto en la fase de testing como la liberación de la herramienta, este tipo de tareas pueden descubrir comportamientos anómalos en la herramienta. Fase de testing. Test de caja negra basados en riesgos. Fase de testing. Casos de abuso o fuzzing a los inputs de la herramienta para comprobar su comportamiento. Fase de testing. Requisitos de seguridad por parte de los desarrolladores. Fase de requisitos y análisis. Operaciones de seguridad. Análisis externo, no obligatorio. Durante todas las fases.
Writing Secure Code. Este modelo se divide en etapas, de las cuales tiene 13, y durante las distintas fases se van realizando etapas para conseguir que la aplicación sea segura. En la etapa inicial se habla de educación al desarrollador en términos de seguridad, esto se realiza justo antes de comenzar las actividades de diseño de la aplicación. Durante esta fase de diseño también se cumplen las etapas de cuestiones relevantes a la seguridad y la realización del modelado de amenazas. Una vez finalizada la fase de diseño se realiza una revisión del equipo de seguridad del diseño de la aplicación. En la fase de implementación se crean documentos de seguridad, se preparan herramientas y se estudia las guías de buenas prácticas y codificación segura. En la fase de pruebas se utilizan las políticas de prueba seguras, se revisan los fallos encontrados en el proceso hasta el momento y se realiza una revisión externa de la aplicación. En la fase de mantenimiento se realiza una planificación de Seguridad que indica como la empresa debe responder.
TEMA 1 – Actividades
Asignatura Seguridad en el Software
Datos del alumno
Fecha
Apellidos: Rincón Peralta Nombre: Victor Julio
22/09/2016 [3]
Oracle Software Security Assurance. Este S-SDLC está compuesto de un número de actividades que se incluyen en las fases conocidas de un SDLC para garantizar la seguridad del software de la empresa Oracle. Este S-SDLC se compone de 5 fases: Manejo de vulnerabilidades, se realiza en las fases de diseño, implementación y testing Eliminación de vulnerabilidad a través de actualizaciones críticas, se lleva a cabo durante todo el proceso, pero sobretodo en su parte final (puesta en marcha y testing). Buenas prácticas y compartición de éstas en seguridad y codificación segura, se dan a los desarrolladores en la fase de requisitos y diseño Gestión de la configuración de seguridad y herramientas de validación y verificación, se prepara al comenzar el proyecto y cubre, fase de requisitos, diseño, implementación y testing. Comunicación de fallos de seguridad, es la respuesta que pone la empresa a los usuarios, es un plan de respuesta ante incidentes cuando la aplicación se libera.
TEMA 1 – Actividades
Asignatura Seguridad en el Software
Datos del alumno
Fecha
Apellidos: Rincón Peralta Nombre: Victor Julio
22/09/2016
TSP-Secure TSP extiende lo que plantea el TSP, Team Software Process, el objetivo es conseguir un desarrollo de aplicaciones seguras mediante la intervención en el proceso de la guía ofrecida por CERT. Otro objetivo es conseguir que las organizaciones puedan mejorar su manera de construir software seguro o de calidad, y que éste sea compatible con el CMMI (Capability Maturity Model Integration). Los objetivos de TSP-Secure son: Ser capaces de detectar los fallos de seguridad en la generación de código (esto es aplicable al resto de S-SDLC estudiados en la asignatura). Ser capaces de responder rápidamente ante la inserción de nuevas amenazas en el código y promover la utilización de prácticas de seguridad para el desarrollo. Se puede visualizar el flujo de los procesos mediante la siguiente imagen: [3]
TEMA 1 – Actividades
Asignatura Seguridad en el Software
Datos del alumno
Fecha
Apellidos: Rincón Peralta Nombre: Victor Julio
22/09/2016
TSP-Secure, debe basarse durante la fase de requisitos de mínimo una norma de codificación segura. Miembros del equipo aplican pruebas de conformidad, en temas de seguridad de la aplicación, como parte del propio proceso de desarrollo, esto se va realizando en cada fase del SDLC, con el fin de verificar que el código es seguro. También dispone de planificación, procesamiento, calidad, medición y seguimiento de los marcos de TSP. Propuesta de un nuevo S-SDLC la experiencia de Microsoft es representativa, la adopción del SDL. Según la experiencia obtenida por Microsoft, las ventajas de ofrecer un software más seguro (por ejemplo, menor número de actualizaciones, mayor satisfacción de los clientes). Los productores de software deben tener en cuenta las amenazas de seguridad. La seguridad es un requisito básico para los proveedores de software, obligados por las fuerzas del mercado, dada la necesidad de proteger infraestructuras de gran importancia y crear y preservar la confiabilidad en la computación. Uno de los retos más importantes a los que se enfrentan todos los proveedores de software es crear un software más seguro que requiera menos actualizaciones y una administración de seguridad menos onerosa por eso, para mi caso elijo, Microsoft Trustworthy Computing SDL. Adicionando al modelo los siguientes pasos, se definen los roles de los participantes o desarrolladores Se hace la claridad que todos deben tener parte en la formación de seguridad por parte de personas que tengan las competencias pertinentes al tema. Debe haber en la mayoría de los casos una persona o integrante del grupo que cumpla las labores pertinentes de asegurar el producto final y su paso por las diferentes fases, el objetivo es tomar la decisión final sobre las posibles incidencias en temas de seguridad en el proyecto. Esta figura debe ser alguien experto en la materia y con la suficiente experiencia. Denominado como Security Manager realizará en paralelo con el Project Manager un seguimiento del proyecto.
En todas las fases del SDLC se realizará una feedback, es decir, desde la fase de requisitos hasta la liberación se realizará una revisión de seguridad de todo lo que se tenga hasta el momento. + Se realizarán pruebas de pentesting sobre las aplicaciones en 3 fases: + Después de implementar la fase. + Durante la de verificación de las fases. + Antes de liberar el producto, en su totalidad. TEMA 1 – Actividades
Asignatura Seguridad en el Software
Datos del alumno
Fecha
Apellidos: Rincón Peralta Nombre: Victor Julio
22/09/2016
Finalmente se debe cumplir con una prueba de intrusión. Todo esto debe ser guiado por los ingenieros arquitectos o diseñadores del software dónde se integrará un proceso de seguridad. Comparación de los diferentes tipos de S-SDLC
S-SDLC
Microsoft TrustWorth y Computing SDL
CLASP
McGraw’s
INGENIERIA DE REQUISITOS
DISEÑO
IMPLEMENTAC ION
PRUEVAS Y VERIFICACION
Valora y analiza los procesos de Ejecuta pruebas Define seguridad, trabaja para ver la aplica medidas proyecto. las posibilidad de de seguridad en Define vulnerabilidades, encontrar posibles las pruebas Limitaciones. aplica un análisis fallas. analizando la Especifica de riesgos y Realiza un calidad requisitos. ejecuta un plan de feedback y ejecuta reducción de los modificaciones mismos. Aplica análisis de amenazas, Define técnicas de Ejecuta evaluación parámetros de Aplica modelado bajo de seguridad por Seguridad. revisiones al estándares de medio de test de Estudio de código. seguridad que penetración. . amenazas. permiten revisar la fase de diseño. Ejecuta pruebas de Aplica análisis de penetración. amenazas, Análisis de riesgo. técnicas de Define análisis Test de intrusión. Aplica modelado bajo de Riesgo. Caja negra. revisiones al estándares de Requisitos de Fuzzing. código. seguridad que Seguridad. Requisitos de permiten revisar la seguridad. fase de diseño. Evaluación de seguridad.
Promueve el desarrollo seguro, define Oracle metodologías Softwar consistentes e validadas a Security cada una de Assuran las ce organizacione s haciendo un previo estudio de factibilidad TEMA 1 – Actividades
Tiene su propia normativa de seguridad para identificar vulnerabilidades, validación de datos y administración de usuarios.
Aplica un análisis Aplica un análisis dinámico, dinámico, durante durante las las fases finales del fases finales del software, dirigida a software, API’s e interfaces dirigida a API’s e por medio de interfaces por técnicas de medio de fuzzing. técnicas de fuzzing.
Asignatura Seguridad en el Software
Datos del alumno
Fecha
Apellidos: Rincón Peralta Nombre: Victor Julio
22/09/2016
Writing Secure Code
Valora Ejecuta revisión conocimientos final de seguridad. . Específica Determina criterios roles de de seguridad seguridad finales. Aplica dentro del análisis de grupo. amenazas.
Aplica soluciones de seguridad, basándose en estándares respectivos
Ejecuta pruebas de vulnerabilidades.
TPS-Secure
Proporciona un marco de trabajo Promueve el cual facilita el desarrollo de diseño y métodos software bajo organizados con la estándares de idea de generar seguridad. software de calidad.
Emplea niveles de adaptabilidad para cada una de sus fases aplicando estándares de seguridad
Establece procesos de desarrollo usando estrategias de adaptación que permiten el acoplamiento al lenguaje de programación y software final.
Fuzzing Se conoce como Fuzzing a la técnica de prueba de software que genera y envía datos secuenciales o aleatorios a una aplicación, con el objeto de detectar defectos o vulnerabilidades existentes.. Con esta técnica se consigue ver las excepciones que devuelven nuestro equipo y posibles problemas no contemplados. Por ejemplo con esta técnica se detectan algunos stackoverflow o la reacción de nuestro programa al recibir campos incorrectos como por ejemplo un float en vez de un integer. Existen proyectos que realizan este tipo de tests. como el de JBroFuzz.
Conclusiones
Luego de realizar este trabajo puedo decir que la seguridad en los sistemas de información es y seguirá siendo
una preocupación latente en todas las compañías pero sobre todo en aquellas que basan sus
estrategias de negocio en los sistemas de información. Si bien se han presentado algunas soluciones al problema, la problemática es más compleja, pues no en todas las organizaciones se hace uso de la producción de software seguro. Son muchos los aspectos que se deben tener en cuenta desde su concepción, su implantación hasta inclusive el uso cotidiano. Como también se observó que existen diferentes aspectos a tener en cuenta para poder atacar el problema y solucionar los mismos. Desafortunadamente a veces el tema de la seguridad lo dejan como como un elemento aislado, sin muchas veces notar que es un elemento TEMA 1 – Actividades
Asignatura Seguridad en el Software
Datos del alumno
Fecha
Apellidos: Rincón Peralta Nombre: Victor Julio
22/09/2016
transversal y multidimensional. En general los Ciber-delincuentes generalmente están más delante que organizaciones, si se continúa produciendo generalmente software de la manera tradicional, se seguirá explotando las vulnerabilidades podrían sido evitadas utilizando metodologías como las observadas anteriormente en este trabajo. En este trabajo presenté de manera general, los procesos desarrollo de software más usados los cuales se enfocan en la mejora de la seguridad. El uso de alguna de estas metodologías permite disminuir en cierta medida evitar los ataques a las víctimas, ocasionando pérdidas a veces irreparables. Si bien escogí una metodología, es bueno tener en cuenta que la mejor metodología es la que se adapta al producto a desarrollar específicamente, teniendo en cuenta el producto a tratar se puede escoger la metodología idónea a tener en cuenta. Bibliografia [1]http://www.flu-project.com/2014/05/ciclos-de-vida-del-software-seguros-s_29.html [2]https://www.owasp.org/index.php/CLASP_Concepts [3]http://www.flu-project.com/2014/05/ciclos-de-vida-del-software-seguros-s_27.html http://www.oracle.com/us/support/library/software-security-assurance-2293569.pdf http://recibe.cucei.udg.mx/revista/es/vol2-no3/pdf/computacion05.pdf https://es.wikipedia.org/wiki/Capability_Maturity_Model_Integration
TEMA 1 – Actividades
