SlideShare uma empresa Scribd logo
1 de 20
Baixar para ler offline
CSTIC 2017
Be Agile, Be Digital, Be Secure
Cómo mejorar la
seguridad del software
SSDL: El Ciclo de Vida de Desarrollo de Software Seguro
Ramiro Carballo Gutiérrez
SCAMPI Lead Appraiser
Caelum Information & Quality Technologies, S. L.
CSTIC 2017
Be Agile, Be Digital, Be Secure
Quienes somos?
Partner del CMMI Institute (ISACA) en España:
CMMI DEV
CMMI SVC MODELOS NEARSHORE Y FACTORÍA DE SOFTWARE
CMMI ACQ DATA MANAGEMENT MATURITY MODEL
ESTIMACIÓN DE PROYECTOS
ISO 15504 / ISO 12207
ISO 20000 / ITIL
ISO 27.001
MAGERIT V3
ESQUEMA NACIONAL DE SEGURIDAD
CSTIC 2017
Ciclo de Vida del Software Seguro
• Ciclo de Vida:
• Secuencia de actividades de la vida de un producto desde su
concepción hasta su retirada.
• Ciclo de Vida de Desarrollo de Software:
• Etapas de la vida de una aplicación software, desde que el usuario
expone sus necesidades, hasta que se despliega en el entorno de
producción.
• Ciclo de Vida de Desarrollo de Software Seguro:
• Integración de las actividades de desarrollo de software con los puntos
de chequeo de seguridad y aquellas cuestiones que eviten que el
software entregado incorpore vulnerabilidades.
CSTIC 2017
Prácticas seguras del SSDL
• Tres prácticas del ciclo de vida de desarrollo de software seguro
(SSDL):
• Análisis de la Arquitectura del Software
• Representar la arquitectura del software con diagramas que faciliten identificar
las amenazas y los riesgos, y construir un plan para reducirlos.
• Revisiones de Código Fuente
• Utilizar herramientas de análisis de código que apliquen reglas adaptadas al
contexto de nuestras aplicaciones y hacer seguimiento de los resultados
obtenidos.
• Realización de Pruebas de Seguridad
• Detectar las vulnerabilidades introducidas durante la construcción del código,
antes de realizar la entrega de las aplicaciones software.
CSTIC 2017
Análisis de Arquitectura Software (I)
• Revisar las funcionalidades de seguridad de la arquitectura. Ej.
• Autenticación
• Control de acceso
• Criptografía
• Realizar una revisión del diseño de las aplicaciones de más alto
riesgo de la organización, detectar los defectos principales y
elaborar un plan para resolverlos.
• El grupo de Seguridad del Software (SSG) debe liderar las
revisiones de la arquitectura, con su experiencia en seguridad y
con el apoyo de los arquitectos y desarrolladores del software
revisado.
CSTIC 2017
Análisis de Arquitectura Software (II)
• Utilizar un cuestionario de riesgos para facilitar la revisión de las
funcionalidades de seguridad y el diseño de la aplicación . Ej.
• Lenguaje de programación
• Usuarios potenciales
• Entorno móvil
• El proceso de análisis de arquitectura debe estar definido para
su uso fácil incluso para técnicos ajenos al grupo de Seguridad
del Software (SSG) y así ayudar a enfocar las revisiones hacia:
• Posibles ataques
• Propiedades de seguridad
• Riesgos asociados
CSTIC 2017
Análisis de Arquitectura Software (III)
• Estandarizar la documentación de los diseños: flujos de datos,
diagramas UML, ayuda a tener una imagen clara de los activos
de información que se deben proteger.
• Que el grupo de Seguridad del Software (SSG) soporte y sea el
mentor del resto de equipos de desarrollo en la aplicación del
proceso de Análisis de Arquitectura.
• Convertir los resultados del Análisis de Arquitectura en patrones
de arquitectura estándar, en los que un Comité de Diseño de
Software Seguro se ha preocupado de evitar que se produzcan
errores similares en el futuro.
CSTIC 2017
Revisión de Seguridad del Código (I)
• Se deben realizar revisiones de código por parte del Grupo de
Seguridad del Software (SSG), para aplicaciones de alto riesgo.
• Más adelante, otros miembros del equipo de desarrollo pueden hacer
estas revisiones
• Se pueden apoyar en herramientas o ser revisiones manuales.
• Se debe evolucionar según avanza la tecnología revisada.
• Obligar a que se revise el código de todos los proyectos:
• Las entregas se bloquearán si un proyecto no se ha revisado o si el
resultado de la revisión fue negativo.
• Se puede mezclar el uso de herramientas automáticas para los
proyectos de bajo riesgo con el uso de revisiones manuales para los de
riesgo mayor.
CSTIC 2017
Revisión de Seguridad del Código (II)
• Generar informes centralizados para aprender de los resultados.
• Tener un repositorio centralizado de errores de seguridad.
• Que permita realizar informes de tendencia a nivel de organización.
• Que permita reconocer las mejoras en la seguridad global
• Los informes de revisión de código se pueden cruzar con otras
medidas del ciclo de vida del desarrollo seguro de software
relacionadas con:
• Pruebas de penetración
• Pruebas de seguridad
• Pruebas de caja negra
• Pruebas de caja blanca
CSTIC 2017
Revisión de Seguridad del Código (III)
• Objetivos para “NOTA” en la revisión de seguridad del código:
• Publicar la lista de los 10 defectos más buscados “de esta casa”.
Algunos métodos como OWASP no suele reflejar lo que más le
preocupa a una empresa en concreto.
• Montar una “factoría” de revisores – correctores de código. Con
motores de análisis estático combinado con dinámico, en un flujo
industrial de proceso de revisión.
• Automatizar la detección de código malicioso que pueden elaborar
nuestros propios desarrolladores, mediante el reconocimiento de
patrones de código, para lo que el análisis manual se queda corto.
• Reforzar el uso de estándares de codificación, de manera preventiva.
CSTIC 2017
Pruebas de Seguridad (I)
• Asegurar que las pruebas de QA analizan los valores límites de
los rangos de las condiciones:
• Es ir más allá de las pruebas puramente funcionales
• Hay que pensar como los malos y probar valores con mala intención.
• ¿Qué pasa que intentas entrar con la contraseña incorrecta una vez?
¿y otra? ¿y otra…?
• Hay que dirigir las pruebas a
• Los requisitos de seguridad: ¿puedo acceder a algo sin tener permiso?
• Y a las funcionalidades de seguridad.
• Las funciones de nuevos modelos de servicios en la nube…
CSTIC 2017
Pruebas de Seguridad (II)
• Mezclar las pruebas de calidad con las pruebas de seguridad:
• Integrando las pruebas de caja negra en el proceso de aseguramiento
de la calidad.
• Haciendo que las pruebas las ejecuten desde calidad, pero se cuente
con el Grupo de Seguridad del Software (SSG) para interpretar los
resultados.
• Compartiendo los resultados de seguridad con los equipos de calidad,
que tienen una forma de trabajar metódica y orientada a la mejora
continua.
• Incluyendo casos de prueba de seguridad dentro de la ejecución
automática de las pruebas de QA.
CSTIC 2017
Pruebas de Seguridad (III)
• Para sacar “NOTA” en las pruebas de seguridad:
• Enfocar las pruebas a lo que nos diga el análisis de riesgos:
• Según el resultado del Análisis de la Arquitectura que habíamos procedimentado.
• Priorizando sobre los componentes que presentan los riesgos más altos.
• Darle más importancia a la cobertura de las pruebas:
• Medir la cobertura de código de las pruebas de seguridad nos permite conocer la
proporción de código que no se ha probado.
• Podemos utilizar el indicador de cobertura para conseguir que las pruebas de
seguridad alcancen mayor profundidad.
• Se demuestra que las pruebas de caja negra tienen una cobertura muy baja.
CSTIC 2017
Más allá del ciclo de vida SSDL (I)
• Si nos quedamos en
• Análisis
• Diseño
• Código
• Pruebas
• Hemos dejado la seguridad en manos de los desarrolladores.
¿¡ SON LOS HÉROES DE LA SEGURIDAD DEL SOFTWARE !?
Métrica v2.1 sólo habla de ingeniería -> swCMM - Métrica v3
¿QUIERO TENER UNA EMPRESA DE HÉROES?
CSTIC 2017
Más allá del ciclo de vida SSDL (II)
• Se necesita el apoyo de toda la organización mediante:
• La entrega segura del software.
• La inteligencia relacionada con la seguridad del software:
• El gobierno de la seguridad del software.
CSTIC 2017
La entrega segura de software
• La entrega de software debe asegurar:
• Que los expertos en seguridad realizan pruebas de penetración
enfocadas en explotar vulnerabilidades de la entrega final.
• Que se realiza sobre un entorno seguro:
• Con un sistema operativo y una plataforma adecuadamente parcheada
• Con los firewalls adecuados para las aplicaciones web
• Con documentación de configuración e instalación
• Con monitorización de la disponibilidad de las aplicaciones, gestión del cambio,…
• Con gestión de la configuración y de las vulnerabilidades
• Para asegurar que la última versión no contiene una vulnerabilidad que ya
habíamos corregido.
• Con gestión de incidencias, seguimiento de defectos, control de versiones, etc.
CSTIC 2017
Inteligencia de la seguridad
• Creando modelos de ataque basando en información recogida
de cómo piensan los atacantes:
• modelado de amenazas
• desarrollo y refinamiento de casos de abuso
• clasificación de datos y
• patrones de ataque específicos de cada tecnología.
• Creando patrones de diseños y funcionalidades seguros.
• Extrayendo los requisitos de seguridad de la organización.
• Construyendo estándares sobre las funciones principales:
autenticación, validación de entradas, etc.
CSTIC 2017
Gobierno de seguridad del software
• Mediante una estrategia de mejora de la seguridad del software
en la que
• Se fijan unos objetivos de seguridad del software
• Se elabora un plan, con recursos, plazos,
• Se identifican las metas y los indicadores para seguirlos.
• Identificando los controles para asegurar el cumplimiento de
compromisos, contratos, estándares, SLAs, siguiendo una
política de seguridad del software y auditándola.
• Proporcionando formación sobre seguridad a los equipos de
desarrollo.
CSTIC 2017
Muchas gracias.
The Building Security In Maturity Model is licensed under the Creative Commons Attribution-Share Alike 3.0 License. To view a copy of this license, visit
http://creativecommons.org/licenses/by-sa/3.0/legalcode or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.
Ramiro Carballo
CMMI SCAMPI Lead Appraiser
Tlf. (+34) 639078817
e-mail: rcarballo@caelum.es
https://www.linkedin.com/in/ramirocarballo/
Twitter: @rcarballo_CMMI
CAELUM Information and Quality Technologies.
Tlf. (+34) 91 8312029
Congreso CSTIC 2017
Be Agile, Be digital, Be Secure
Organiza:

Mais conteúdo relacionado

Mais procurados

Tech Talk #5 : Code Analysis SonarQube - Lương Trọng Nghĩa
Tech Talk #5 : Code Analysis SonarQube - Lương Trọng NghĩaTech Talk #5 : Code Analysis SonarQube - Lương Trọng Nghĩa
Tech Talk #5 : Code Analysis SonarQube - Lương Trọng NghĩaNexus FrontierTech
 
Shift left - find defects earlier through automated test and deployment
Shift left - find defects earlier through automated test and deploymentShift left - find defects earlier through automated test and deployment
Shift left - find defects earlier through automated test and deploymentClaudia Ring
 
Cybernode.se: Securing the software supply chain (CRA)
Cybernode.se: Securing the software supply chain (CRA)Cybernode.se: Securing the software supply chain (CRA)
Cybernode.se: Securing the software supply chain (CRA)Olle E Johansson
 
User Acceptance Testing in the Testing Center of Excellence
User Acceptance Testing in the Testing Center of ExcellenceUser Acceptance Testing in the Testing Center of Excellence
User Acceptance Testing in the Testing Center of ExcellenceTechWell
 
Robot Framework Introduction
Robot Framework IntroductionRobot Framework Introduction
Robot Framework Introductionlaurent bristiel
 
gestion-de-riesgos-iso-27005-completo_compress.pdf
gestion-de-riesgos-iso-27005-completo_compress.pdfgestion-de-riesgos-iso-27005-completo_compress.pdf
gestion-de-riesgos-iso-27005-completo_compress.pdfcarlosandres865046
 
ISTQB vs ISEB Certification
ISTQB vs ISEB CertificationISTQB vs ISEB Certification
ISTQB vs ISEB Certificationduke.kalra
 
PECB Webinar: Aligning ISO 25000 and CMMI for Development
PECB Webinar: Aligning ISO 25000 and CMMI for DevelopmentPECB Webinar: Aligning ISO 25000 and CMMI for Development
PECB Webinar: Aligning ISO 25000 and CMMI for DevelopmentPECB
 
Vladimir Primakov - Qa management in big agile teams
Vladimir Primakov - Qa management in big agile teamsVladimir Primakov - Qa management in big agile teams
Vladimir Primakov - Qa management in big agile teamsIevgenii Katsan
 
Devops Maturity Assessment Model - Ágiles 2019
Devops Maturity Assessment Model - Ágiles 2019Devops Maturity Assessment Model - Ágiles 2019
Devops Maturity Assessment Model - Ágiles 2019Javier Dominguez
 
Shift Left Quality Assurance: How to do it. Why it matters.
Shift Left Quality Assurance: How to do it. Why it matters.Shift Left Quality Assurance: How to do it. Why it matters.
Shift Left Quality Assurance: How to do it. Why it matters.Worksoft
 
ISACA SV Chapter: Securing Software Supply Chains
ISACA SV Chapter: Securing Software Supply ChainsISACA SV Chapter: Securing Software Supply Chains
ISACA SV Chapter: Securing Software Supply ChainsJim Bugwadia
 
Software Testing Basic Concepts
Software Testing Basic ConceptsSoftware Testing Basic Concepts
Software Testing Basic Conceptswesovi
 
Bridging the Security Testing Gap in Your CI/CD Pipeline
Bridging the Security Testing Gap in Your CI/CD PipelineBridging the Security Testing Gap in Your CI/CD Pipeline
Bridging the Security Testing Gap in Your CI/CD PipelineDevOps.com
 

Mais procurados (20)

Tech Talk #5 : Code Analysis SonarQube - Lương Trọng Nghĩa
Tech Talk #5 : Code Analysis SonarQube - Lương Trọng NghĩaTech Talk #5 : Code Analysis SonarQube - Lương Trọng Nghĩa
Tech Talk #5 : Code Analysis SonarQube - Lương Trọng Nghĩa
 
Shift left - find defects earlier through automated test and deployment
Shift left - find defects earlier through automated test and deploymentShift left - find defects earlier through automated test and deployment
Shift left - find defects earlier through automated test and deployment
 
Cybernode.se: Securing the software supply chain (CRA)
Cybernode.se: Securing the software supply chain (CRA)Cybernode.se: Securing the software supply chain (CRA)
Cybernode.se: Securing the software supply chain (CRA)
 
User Acceptance Testing in the Testing Center of Excellence
User Acceptance Testing in the Testing Center of ExcellenceUser Acceptance Testing in the Testing Center of Excellence
User Acceptance Testing in the Testing Center of Excellence
 
Sqa ejemplo
Sqa ejemploSqa ejemplo
Sqa ejemplo
 
Robot Framework Introduction
Robot Framework IntroductionRobot Framework Introduction
Robot Framework Introduction
 
QA Best Practices in Agile World_new
QA Best Practices in Agile World_newQA Best Practices in Agile World_new
QA Best Practices in Agile World_new
 
gestion-de-riesgos-iso-27005-completo_compress.pdf
gestion-de-riesgos-iso-27005-completo_compress.pdfgestion-de-riesgos-iso-27005-completo_compress.pdf
gestion-de-riesgos-iso-27005-completo_compress.pdf
 
ISTQB vs ISEB Certification
ISTQB vs ISEB CertificationISTQB vs ISEB Certification
ISTQB vs ISEB Certification
 
PECB Webinar: Aligning ISO 25000 and CMMI for Development
PECB Webinar: Aligning ISO 25000 and CMMI for DevelopmentPECB Webinar: Aligning ISO 25000 and CMMI for Development
PECB Webinar: Aligning ISO 25000 and CMMI for Development
 
Vladimir Primakov - Qa management in big agile teams
Vladimir Primakov - Qa management in big agile teamsVladimir Primakov - Qa management in big agile teams
Vladimir Primakov - Qa management in big agile teams
 
API Management in Azure
API Management in AzureAPI Management in Azure
API Management in Azure
 
Devops Maturity Assessment Model - Ágiles 2019
Devops Maturity Assessment Model - Ágiles 2019Devops Maturity Assessment Model - Ágiles 2019
Devops Maturity Assessment Model - Ágiles 2019
 
Shift Left Quality Assurance: How to do it. Why it matters.
Shift Left Quality Assurance: How to do it. Why it matters.Shift Left Quality Assurance: How to do it. Why it matters.
Shift Left Quality Assurance: How to do it. Why it matters.
 
ISACA SV Chapter: Securing Software Supply Chains
ISACA SV Chapter: Securing Software Supply ChainsISACA SV Chapter: Securing Software Supply Chains
ISACA SV Chapter: Securing Software Supply Chains
 
Software Testing Basic Concepts
Software Testing Basic ConceptsSoftware Testing Basic Concepts
Software Testing Basic Concepts
 
TCoE
TCoETCoE
TCoE
 
ISTQB Test Process
ISTQB Test ProcessISTQB Test Process
ISTQB Test Process
 
Bridging the Security Testing Gap in Your CI/CD Pipeline
Bridging the Security Testing Gap in Your CI/CD PipelineBridging the Security Testing Gap in Your CI/CD Pipeline
Bridging the Security Testing Gap in Your CI/CD Pipeline
 
SonarQube
SonarQubeSonarQube
SonarQube
 

Semelhante a Cómo mejorar la seguridad del software - Secure Software Development Lifecycle

Devsecops superstar un movimiento masivo
Devsecops superstar un movimiento masivoDevsecops superstar un movimiento masivo
Devsecops superstar un movimiento masivoLuciano Moreira da Cruz
 
Integración de Mecanismos de Seguridad en la arquitectura de Aplicaciones Sof...
Integración de Mecanismos de Seguridad en la arquitectura de Aplicaciones Sof...Integración de Mecanismos de Seguridad en la arquitectura de Aplicaciones Sof...
Integración de Mecanismos de Seguridad en la arquitectura de Aplicaciones Sof...eccutpl
 
Calidad y Seguridad en Procesos de Desarrollo de Software
Calidad y Seguridad en Procesos de Desarrollo de SoftwareCalidad y Seguridad en Procesos de Desarrollo de Software
Calidad y Seguridad en Procesos de Desarrollo de SoftwareConferencias FIST
 
Ingenieria en software
Ingenieria en softwareIngenieria en software
Ingenieria en softwareEl Tory
 
Ingeniería de software Definicion,inicion,importancia y utilidad
Ingeniería de software Definicion,inicion,importancia y utilidadIngeniería de software Definicion,inicion,importancia y utilidad
Ingeniería de software Definicion,inicion,importancia y utilidadXKWDX
 
QA and Security Testing in the SDLC
QA and Security Testing in the SDLCQA and Security Testing in the SDLC
QA and Security Testing in the SDLCRoger CARHUATOCTO
 
Modelo de madurez de aseguramiento de software
Modelo de madurez de aseguramiento de softwareModelo de madurez de aseguramiento de software
Modelo de madurez de aseguramiento de softwareSoftware Guru
 
KronOps - Perfil Corporativo
KronOps - Perfil CorporativoKronOps - Perfil Corporativo
KronOps - Perfil CorporativoKronOps
 
Ra semana 16
Ra semana 16Ra semana 16
Ra semana 16victdiazm
 
Guía de implementación, integración de la seguridad en el ciclo de vida del s...
Guía de implementación, integración de la seguridad en el ciclo de vida del s...Guía de implementación, integración de la seguridad en el ciclo de vida del s...
Guía de implementación, integración de la seguridad en el ciclo de vida del s...Internet Security Auditors
 
Implementando owasp samm en latam
Implementando owasp samm en latamImplementando owasp samm en latam
Implementando owasp samm en latamMateo Martinez
 
Herramientas y entornos de implementacion de software
Herramientas y entornos de implementacion de softwareHerramientas y entornos de implementacion de software
Herramientas y entornos de implementacion de softwareMiguel Sanchez
 
La necesidad de construir software seguro. IBM Software Summit #Start013
La necesidad de construir software seguro. IBM Software Summit #Start013La necesidad de construir software seguro. IBM Software Summit #Start013
La necesidad de construir software seguro. IBM Software Summit #Start013Internet Security Auditors
 
Fundamentos_de_ingenieria_de_software.pptx
Fundamentos_de_ingenieria_de_software.pptxFundamentos_de_ingenieria_de_software.pptx
Fundamentos_de_ingenieria_de_software.pptxmateoaramedi
 

Semelhante a Cómo mejorar la seguridad del software - Secure Software Development Lifecycle (20)

Devsecops superstar un movimiento masivo
Devsecops superstar un movimiento masivoDevsecops superstar un movimiento masivo
Devsecops superstar un movimiento masivo
 
Integración de Mecanismos de Seguridad en la arquitectura de Aplicaciones Sof...
Integración de Mecanismos de Seguridad en la arquitectura de Aplicaciones Sof...Integración de Mecanismos de Seguridad en la arquitectura de Aplicaciones Sof...
Integración de Mecanismos de Seguridad en la arquitectura de Aplicaciones Sof...
 
Calidad y Seguridad en Procesos de Desarrollo de Software
Calidad y Seguridad en Procesos de Desarrollo de SoftwareCalidad y Seguridad en Procesos de Desarrollo de Software
Calidad y Seguridad en Procesos de Desarrollo de Software
 
Ingenieria en software
Ingenieria en softwareIngenieria en software
Ingenieria en software
 
Ingeniería de software Definicion,inicion,importancia y utilidad
Ingeniería de software Definicion,inicion,importancia y utilidadIngeniería de software Definicion,inicion,importancia y utilidad
Ingeniería de software Definicion,inicion,importancia y utilidad
 
Ciberseguridad - IBM
Ciberseguridad - IBMCiberseguridad - IBM
Ciberseguridad - IBM
 
QA and Security Testing in the SDLC
QA and Security Testing in the SDLCQA and Security Testing in the SDLC
QA and Security Testing in the SDLC
 
Ciclo de Vida y roles
Ciclo de Vida y roles Ciclo de Vida y roles
Ciclo de Vida y roles
 
S1-CDSQA.pptx
S1-CDSQA.pptxS1-CDSQA.pptx
S1-CDSQA.pptx
 
Modelo de madurez de aseguramiento de software
Modelo de madurez de aseguramiento de softwareModelo de madurez de aseguramiento de software
Modelo de madurez de aseguramiento de software
 
KronOps - Perfil Corporativo
KronOps - Perfil CorporativoKronOps - Perfil Corporativo
KronOps - Perfil Corporativo
 
Ra semana 16
Ra semana 16Ra semana 16
Ra semana 16
 
Guía de implementación, integración de la seguridad en el ciclo de vida del s...
Guía de implementación, integración de la seguridad en el ciclo de vida del s...Guía de implementación, integración de la seguridad en el ciclo de vida del s...
Guía de implementación, integración de la seguridad en el ciclo de vida del s...
 
Calidad software
Calidad softwareCalidad software
Calidad software
 
Aplicaciones seguras
Aplicaciones seguras Aplicaciones seguras
Aplicaciones seguras
 
Implementando owasp samm en latam
Implementando owasp samm en latamImplementando owasp samm en latam
Implementando owasp samm en latam
 
Herramientas y entornos de implementacion de software
Herramientas y entornos de implementacion de softwareHerramientas y entornos de implementacion de software
Herramientas y entornos de implementacion de software
 
La necesidad de construir software seguro. IBM Software Summit #Start013
La necesidad de construir software seguro. IBM Software Summit #Start013La necesidad de construir software seguro. IBM Software Summit #Start013
La necesidad de construir software seguro. IBM Software Summit #Start013
 
Modelos de desarrollo seguro de software
Modelos de desarrollo seguro de softwareModelos de desarrollo seguro de software
Modelos de desarrollo seguro de software
 
Fundamentos_de_ingenieria_de_software.pptx
Fundamentos_de_ingenieria_de_software.pptxFundamentos_de_ingenieria_de_software.pptx
Fundamentos_de_ingenieria_de_software.pptx
 

Último

03 - RUP_Elaboracion_Construccion_1_2024.pdf
03 - RUP_Elaboracion_Construccion_1_2024.pdf03 - RUP_Elaboracion_Construccion_1_2024.pdf
03 - RUP_Elaboracion_Construccion_1_2024.pdfRodrigo Cerón
 
Virus -Josue Cabascango _20240322_194349_0000.pdf
Virus -Josue Cabascango _20240322_194349_0000.pdfVirus -Josue Cabascango _20240322_194349_0000.pdf
Virus -Josue Cabascango _20240322_194349_0000.pdfMiSpotify
 
02 - RUP_Introduccion_Definicion.pdf
02 - RUP_Introduccion_Definicion.pdf02 - RUP_Introduccion_Definicion.pdf
02 - RUP_Introduccion_Definicion.pdfRodrigo Cerón
 
Herramientas de Mantenimiento_Soporte Técnico_David Andrade.pdf
Herramientas de Mantenimiento_Soporte Técnico_David Andrade.pdfHerramientas de Mantenimiento_Soporte Técnico_David Andrade.pdf
Herramientas de Mantenimiento_Soporte Técnico_David Andrade.pdfdaa100407
 
Diseño de Algoritmos Paralelos. Mejorando la eficiencia computacional aprovec...
Diseño de Algoritmos Paralelos. Mejorando la eficiencia computacional aprovec...Diseño de Algoritmos Paralelos. Mejorando la eficiencia computacional aprovec...
Diseño de Algoritmos Paralelos. Mejorando la eficiencia computacional aprovec...AlexaRamirez39
 
Formato de práctica reflexiva ante una problemática social.docx.pdf
Formato de práctica reflexiva ante una problemática social.docx.pdfFormato de práctica reflexiva ante una problemática social.docx.pdf
Formato de práctica reflexiva ante una problemática social.docx.pdfjuanrubenc78
 
Los mejores simuladores electrónicos que se pueden utilizar
Los mejores simuladores electrónicos que se pueden utilizarLos mejores simuladores electrónicos que se pueden utilizar
Los mejores simuladores electrónicos que se pueden utilizarjosuesj13
 
Algoritmos Paralelos - Actividad 14 - UNIBE.pdf
Algoritmos Paralelos - Actividad 14 - UNIBE.pdfAlgoritmos Paralelos - Actividad 14 - UNIBE.pdf
Algoritmos Paralelos - Actividad 14 - UNIBE.pdfdarosario3d
 
Simuladores de circuitos electrónicos.pdf
Simuladores de circuitos electrónicos.pdfSimuladores de circuitos electrónicos.pdf
Simuladores de circuitos electrónicos.pdfLeonardoOa4
 

Último (9)

03 - RUP_Elaboracion_Construccion_1_2024.pdf
03 - RUP_Elaboracion_Construccion_1_2024.pdf03 - RUP_Elaboracion_Construccion_1_2024.pdf
03 - RUP_Elaboracion_Construccion_1_2024.pdf
 
Virus -Josue Cabascango _20240322_194349_0000.pdf
Virus -Josue Cabascango _20240322_194349_0000.pdfVirus -Josue Cabascango _20240322_194349_0000.pdf
Virus -Josue Cabascango _20240322_194349_0000.pdf
 
02 - RUP_Introduccion_Definicion.pdf
02 - RUP_Introduccion_Definicion.pdf02 - RUP_Introduccion_Definicion.pdf
02 - RUP_Introduccion_Definicion.pdf
 
Herramientas de Mantenimiento_Soporte Técnico_David Andrade.pdf
Herramientas de Mantenimiento_Soporte Técnico_David Andrade.pdfHerramientas de Mantenimiento_Soporte Técnico_David Andrade.pdf
Herramientas de Mantenimiento_Soporte Técnico_David Andrade.pdf
 
Diseño de Algoritmos Paralelos. Mejorando la eficiencia computacional aprovec...
Diseño de Algoritmos Paralelos. Mejorando la eficiencia computacional aprovec...Diseño de Algoritmos Paralelos. Mejorando la eficiencia computacional aprovec...
Diseño de Algoritmos Paralelos. Mejorando la eficiencia computacional aprovec...
 
Formato de práctica reflexiva ante una problemática social.docx.pdf
Formato de práctica reflexiva ante una problemática social.docx.pdfFormato de práctica reflexiva ante una problemática social.docx.pdf
Formato de práctica reflexiva ante una problemática social.docx.pdf
 
Los mejores simuladores electrónicos que se pueden utilizar
Los mejores simuladores electrónicos que se pueden utilizarLos mejores simuladores electrónicos que se pueden utilizar
Los mejores simuladores electrónicos que se pueden utilizar
 
Algoritmos Paralelos - Actividad 14 - UNIBE.pdf
Algoritmos Paralelos - Actividad 14 - UNIBE.pdfAlgoritmos Paralelos - Actividad 14 - UNIBE.pdf
Algoritmos Paralelos - Actividad 14 - UNIBE.pdf
 
Simuladores de circuitos electrónicos.pdf
Simuladores de circuitos electrónicos.pdfSimuladores de circuitos electrónicos.pdf
Simuladores de circuitos electrónicos.pdf
 

Cómo mejorar la seguridad del software - Secure Software Development Lifecycle

  • 1. CSTIC 2017 Be Agile, Be Digital, Be Secure Cómo mejorar la seguridad del software SSDL: El Ciclo de Vida de Desarrollo de Software Seguro Ramiro Carballo Gutiérrez SCAMPI Lead Appraiser Caelum Information & Quality Technologies, S. L.
  • 2. CSTIC 2017 Be Agile, Be Digital, Be Secure Quienes somos? Partner del CMMI Institute (ISACA) en España: CMMI DEV CMMI SVC MODELOS NEARSHORE Y FACTORÍA DE SOFTWARE CMMI ACQ DATA MANAGEMENT MATURITY MODEL ESTIMACIÓN DE PROYECTOS ISO 15504 / ISO 12207 ISO 20000 / ITIL ISO 27.001 MAGERIT V3 ESQUEMA NACIONAL DE SEGURIDAD
  • 3. CSTIC 2017 Ciclo de Vida del Software Seguro • Ciclo de Vida: • Secuencia de actividades de la vida de un producto desde su concepción hasta su retirada. • Ciclo de Vida de Desarrollo de Software: • Etapas de la vida de una aplicación software, desde que el usuario expone sus necesidades, hasta que se despliega en el entorno de producción. • Ciclo de Vida de Desarrollo de Software Seguro: • Integración de las actividades de desarrollo de software con los puntos de chequeo de seguridad y aquellas cuestiones que eviten que el software entregado incorpore vulnerabilidades.
  • 4. CSTIC 2017 Prácticas seguras del SSDL • Tres prácticas del ciclo de vida de desarrollo de software seguro (SSDL): • Análisis de la Arquitectura del Software • Representar la arquitectura del software con diagramas que faciliten identificar las amenazas y los riesgos, y construir un plan para reducirlos. • Revisiones de Código Fuente • Utilizar herramientas de análisis de código que apliquen reglas adaptadas al contexto de nuestras aplicaciones y hacer seguimiento de los resultados obtenidos. • Realización de Pruebas de Seguridad • Detectar las vulnerabilidades introducidas durante la construcción del código, antes de realizar la entrega de las aplicaciones software.
  • 5. CSTIC 2017 Análisis de Arquitectura Software (I) • Revisar las funcionalidades de seguridad de la arquitectura. Ej. • Autenticación • Control de acceso • Criptografía • Realizar una revisión del diseño de las aplicaciones de más alto riesgo de la organización, detectar los defectos principales y elaborar un plan para resolverlos. • El grupo de Seguridad del Software (SSG) debe liderar las revisiones de la arquitectura, con su experiencia en seguridad y con el apoyo de los arquitectos y desarrolladores del software revisado.
  • 6. CSTIC 2017 Análisis de Arquitectura Software (II) • Utilizar un cuestionario de riesgos para facilitar la revisión de las funcionalidades de seguridad y el diseño de la aplicación . Ej. • Lenguaje de programación • Usuarios potenciales • Entorno móvil • El proceso de análisis de arquitectura debe estar definido para su uso fácil incluso para técnicos ajenos al grupo de Seguridad del Software (SSG) y así ayudar a enfocar las revisiones hacia: • Posibles ataques • Propiedades de seguridad • Riesgos asociados
  • 7. CSTIC 2017 Análisis de Arquitectura Software (III) • Estandarizar la documentación de los diseños: flujos de datos, diagramas UML, ayuda a tener una imagen clara de los activos de información que se deben proteger. • Que el grupo de Seguridad del Software (SSG) soporte y sea el mentor del resto de equipos de desarrollo en la aplicación del proceso de Análisis de Arquitectura. • Convertir los resultados del Análisis de Arquitectura en patrones de arquitectura estándar, en los que un Comité de Diseño de Software Seguro se ha preocupado de evitar que se produzcan errores similares en el futuro.
  • 8. CSTIC 2017 Revisión de Seguridad del Código (I) • Se deben realizar revisiones de código por parte del Grupo de Seguridad del Software (SSG), para aplicaciones de alto riesgo. • Más adelante, otros miembros del equipo de desarrollo pueden hacer estas revisiones • Se pueden apoyar en herramientas o ser revisiones manuales. • Se debe evolucionar según avanza la tecnología revisada. • Obligar a que se revise el código de todos los proyectos: • Las entregas se bloquearán si un proyecto no se ha revisado o si el resultado de la revisión fue negativo. • Se puede mezclar el uso de herramientas automáticas para los proyectos de bajo riesgo con el uso de revisiones manuales para los de riesgo mayor.
  • 9. CSTIC 2017 Revisión de Seguridad del Código (II) • Generar informes centralizados para aprender de los resultados. • Tener un repositorio centralizado de errores de seguridad. • Que permita realizar informes de tendencia a nivel de organización. • Que permita reconocer las mejoras en la seguridad global • Los informes de revisión de código se pueden cruzar con otras medidas del ciclo de vida del desarrollo seguro de software relacionadas con: • Pruebas de penetración • Pruebas de seguridad • Pruebas de caja negra • Pruebas de caja blanca
  • 10. CSTIC 2017 Revisión de Seguridad del Código (III) • Objetivos para “NOTA” en la revisión de seguridad del código: • Publicar la lista de los 10 defectos más buscados “de esta casa”. Algunos métodos como OWASP no suele reflejar lo que más le preocupa a una empresa en concreto. • Montar una “factoría” de revisores – correctores de código. Con motores de análisis estático combinado con dinámico, en un flujo industrial de proceso de revisión. • Automatizar la detección de código malicioso que pueden elaborar nuestros propios desarrolladores, mediante el reconocimiento de patrones de código, para lo que el análisis manual se queda corto. • Reforzar el uso de estándares de codificación, de manera preventiva.
  • 11. CSTIC 2017 Pruebas de Seguridad (I) • Asegurar que las pruebas de QA analizan los valores límites de los rangos de las condiciones: • Es ir más allá de las pruebas puramente funcionales • Hay que pensar como los malos y probar valores con mala intención. • ¿Qué pasa que intentas entrar con la contraseña incorrecta una vez? ¿y otra? ¿y otra…? • Hay que dirigir las pruebas a • Los requisitos de seguridad: ¿puedo acceder a algo sin tener permiso? • Y a las funcionalidades de seguridad. • Las funciones de nuevos modelos de servicios en la nube…
  • 12. CSTIC 2017 Pruebas de Seguridad (II) • Mezclar las pruebas de calidad con las pruebas de seguridad: • Integrando las pruebas de caja negra en el proceso de aseguramiento de la calidad. • Haciendo que las pruebas las ejecuten desde calidad, pero se cuente con el Grupo de Seguridad del Software (SSG) para interpretar los resultados. • Compartiendo los resultados de seguridad con los equipos de calidad, que tienen una forma de trabajar metódica y orientada a la mejora continua. • Incluyendo casos de prueba de seguridad dentro de la ejecución automática de las pruebas de QA.
  • 13. CSTIC 2017 Pruebas de Seguridad (III) • Para sacar “NOTA” en las pruebas de seguridad: • Enfocar las pruebas a lo que nos diga el análisis de riesgos: • Según el resultado del Análisis de la Arquitectura que habíamos procedimentado. • Priorizando sobre los componentes que presentan los riesgos más altos. • Darle más importancia a la cobertura de las pruebas: • Medir la cobertura de código de las pruebas de seguridad nos permite conocer la proporción de código que no se ha probado. • Podemos utilizar el indicador de cobertura para conseguir que las pruebas de seguridad alcancen mayor profundidad. • Se demuestra que las pruebas de caja negra tienen una cobertura muy baja.
  • 14. CSTIC 2017 Más allá del ciclo de vida SSDL (I) • Si nos quedamos en • Análisis • Diseño • Código • Pruebas • Hemos dejado la seguridad en manos de los desarrolladores. ¿¡ SON LOS HÉROES DE LA SEGURIDAD DEL SOFTWARE !? Métrica v2.1 sólo habla de ingeniería -> swCMM - Métrica v3 ¿QUIERO TENER UNA EMPRESA DE HÉROES?
  • 15. CSTIC 2017 Más allá del ciclo de vida SSDL (II) • Se necesita el apoyo de toda la organización mediante: • La entrega segura del software. • La inteligencia relacionada con la seguridad del software: • El gobierno de la seguridad del software.
  • 16. CSTIC 2017 La entrega segura de software • La entrega de software debe asegurar: • Que los expertos en seguridad realizan pruebas de penetración enfocadas en explotar vulnerabilidades de la entrega final. • Que se realiza sobre un entorno seguro: • Con un sistema operativo y una plataforma adecuadamente parcheada • Con los firewalls adecuados para las aplicaciones web • Con documentación de configuración e instalación • Con monitorización de la disponibilidad de las aplicaciones, gestión del cambio,… • Con gestión de la configuración y de las vulnerabilidades • Para asegurar que la última versión no contiene una vulnerabilidad que ya habíamos corregido. • Con gestión de incidencias, seguimiento de defectos, control de versiones, etc.
  • 17. CSTIC 2017 Inteligencia de la seguridad • Creando modelos de ataque basando en información recogida de cómo piensan los atacantes: • modelado de amenazas • desarrollo y refinamiento de casos de abuso • clasificación de datos y • patrones de ataque específicos de cada tecnología. • Creando patrones de diseños y funcionalidades seguros. • Extrayendo los requisitos de seguridad de la organización. • Construyendo estándares sobre las funciones principales: autenticación, validación de entradas, etc.
  • 18. CSTIC 2017 Gobierno de seguridad del software • Mediante una estrategia de mejora de la seguridad del software en la que • Se fijan unos objetivos de seguridad del software • Se elabora un plan, con recursos, plazos, • Se identifican las metas y los indicadores para seguirlos. • Identificando los controles para asegurar el cumplimiento de compromisos, contratos, estándares, SLAs, siguiendo una política de seguridad del software y auditándola. • Proporcionando formación sobre seguridad a los equipos de desarrollo.
  • 19. CSTIC 2017 Muchas gracias. The Building Security In Maturity Model is licensed under the Creative Commons Attribution-Share Alike 3.0 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/legalcode or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA. Ramiro Carballo CMMI SCAMPI Lead Appraiser Tlf. (+34) 639078817 e-mail: rcarballo@caelum.es https://www.linkedin.com/in/ramirocarballo/ Twitter: @rcarballo_CMMI CAELUM Information and Quality Technologies. Tlf. (+34) 91 8312029
  • 20. Congreso CSTIC 2017 Be Agile, Be digital, Be Secure Organiza: