Ensayo: Desarrollo Seguro de Aplicaciones

Asignatura: Seguridad de la Información

Por: Kelvin Ricardo Arrobo Castillo

Docente: Ing. Danilo Jaramillo
 Introducción
La seguridad es una es una responsabilidad compartida en el desarrollo de software y está
relacionada con la implementación de buenas prácticas, estándares, procesos y herramientas
durante las etapas del ciclo de vida de software. Implementar las estrategias mencionadas
previamente garantizan productos funcionales que cumplen con los objetivos de la seguridad que
son integridad confidencialidad y disponibilidad.
Por otro lado, si estos objetivos no son acatados correctamente por los ingenieros de software, sus
sistemas no podrán continuar su desarrollo del ciclo de vida ya que la seguridad introduce no sólo
características de calidad, sino también restricciones bajo las cuales el sistema debe operar (López
Álvarez, 2020).
De misma manera, desarrollar software seguro no se trata solamente de escribir código seguro.
Incluye también, la arquitectura del sistema, un ciclo de vida de desarrollo seguro, procedimientos
de análisis de vulnerabilidades, además requiere de una gestión y controles de mitigación de
riesgos.
Desarrollo
En el presente trabajo se tratará el caso de estudio de un Sistema de Gestión de Historias Clínicas
ofertado para los diferentes centros de salud de la localidad. Se presentarán las actividades de
seguridad a implementar dentro del ciclo de vida de desarrollo de software seguro (S-SDLC)
Secure Software Development Lifecycle. Las decisiones de seguridad han sido basadas en
estándares de seguridad provistos por la organización OWASP (Open Web Application Security)
fundación sin fines de lucro que trabaja para mejorar la seguridad del software, estándares y
definiciones.

El ciclo de desarrollo de software seguro (S-SDLC) es un conjunto de principios de diseño y

buenas prácticas a implantar en el SDLC, para detectar, prevenir y corregir los defectos de
seguridad en el desarrollo y adquisición de aplicaciones, de forma que se obtenga software de
confianza y robusto frente a ataques maliciosos, que realice solo las funciones para las cuales fue
diseñado, que esté libre de vulnerabilidades, ya sean intencionalmente diseñadas o accidentalmente
insertadas durante su ciclo de vida y asegure su integridad, disponibilidad y confidencialidad
(Figueroa, n.d.)

El desarrollo del sistema seguirá el siguiente proceso:

• Definición y Especificación de Requerimientos

• Diseño y Arquitectura
• Codificación
• Pruebas
• Despliegue y mantenimiento de la aplicación
Definición y Especificación de Requerimientos
Siguiendo S-SDLC en la etapa de Definición y Especificación de requerimientos se empieza por
una revisión Requisitos y Controles de seguridad. Con ayuda del estándar OWASP EVSA
(Estándar de Verificación de Seguridad en Aplicaciones) podemos identificar los requisitos de
seguridad.
Para utilizar este estándar se debe ajustar al caso de uso al nivel requerido. Cada nivel de EVSA
contiene una lista de requerimientos de seguridad. Cada uno de estos requisitos pueden también
corresponderse a funcionalidades específicas de seguridad y capacidades que deben construirse
por los desarrolladores de software (OWASP, 2017)
El nivel considerado para el caso de uso del Sistema de Gestión de Historias Clínicas es el nivel
dos, dirigido a aplicaciones que contienen datos sensibles, que requieren protección. Para ello el
estándar cuenta con una lista de requisitos de verificación entre los cuales tienen que poder
cuantificarse:
Arquitectura, diseño y modelado de amenazas, Control de Autenticación, Gestión de Sesiones,
Control de Acceso, Manejo de entrada de datos, Criptografía en el almacenamiento, gestión y
registro de errores y Protección de datos.

Diseño y Arquitectura

La siguiente fase de Diseño y Arquitectura esta alineada con la actividad de Análisis de Riesgo de
la Arquitectura, durante esta actividad se evalúan los riesgos y gestionan enfoques de mitigación.

La evaluación de riesgos arquitectónicos es un proceso de gestión de riesgos que identifica fallas

en una arquitectura de software y determina los riesgos para los activos de información empresarial
que resultan de esas fallas. A través del proceso de evaluación de riesgos arquitectónicos, se
encuentran fallas que exponen los activos de información al riesgo, los riesgos se priorizan en
función de su impacto en el negocio, se desarrollan e implementan mitigaciones para esos riesgos
y se reevalúa el software para determinar la eficacia de las mitigaciones (Peterson, Hope &
Lavenha, 2005).

Según Peterson, Hope y Lavenha (2005), la gestión de riesgos arquitectónicos barca cuatro
procesos: (1) identificación de activos, (2) análisis de riesgos, (3) mitigación de riesgos y (4)
gestión y medición de riesgos. Durante cada una de estas fases, el impacto empresarial es el factor
rector para el análisis de riesgos. El proceso de análisis de riesgo arquitectónico incluye la
identificación y evaluación de los riesgos y los impactos del riesgo y la recomendación de medidas
para reducir el riesgo.

Codificación
Los estándares de codificación segura y las mejores prácticas de desarrollo permiten a los
programadores desarrollar software de forma segura. Aunque hay varias formas de desarrollar
aplicaciones de forma segura, OWASP proporciona una lista de verificación completa de
codificación segura. Esta lista de verificación de codificación segura se centra en aplicaciones web,
pero puede emplearse como protocolo de seguridad para cada ciclo de vida de desarrollo de
software y plataforma de implementación de software para minimizar las amenazas asociadas con
las malas prácticas de codificación.
("OWASP Secure Coding Checklist", 2021) proporciona la siguiente lista de verificación de
codificación segura que tiene una serie de técnicas de prevención a través de las cuales se puede
minimizar y mitigar el daño de diferentes tipos de ataques de software:
• Validación de entrada
• Codificación de salida
• Autenticación y gestión de contraseñas
• Gestión de sesiones
• Control de acceso
• Prácticas criptográficas
• Manejo y registro de errores
• Protección de Datos
• Seguridad de la comunicación
• Configuración del sistema
• Seguridad de la base de datos
• Gestión de archivos
• Gestión de la memoria
Además de esta verificación de código seguro se realizarán revisiones por pares para asegurar un
código sin fallas lógicas que afecten el funcionamiento del sistema. Las revisiones por pares son
un método estandarizado para verificar que el código fuente sea correcto en el desarrollo de
software. Los defectos se detectan y corrigen en este método después del desarrollo del producto
(Sharma, 2021).
Además, con la utilización de herramientas de revisión de código estático integradas al repositorio
de código, se pueden detectar errores y vulnerabilidades que aporten a la identificación de
vulnerabilidades no detectadas en la revisión por pares.
Con ayuda de herramientas como SonarQube se pueden automatizar tareas de revisión de código
estático. SonarQube, es una herramienta de revisión automática de código para detectar errores,
vulnerabilidades y olores de código en su código. Puede integrarse con su flujo de trabajo existente
para permitir la inspección continua del código en las ramas de su proyecto y solicitudes de
extracción (SonarQube, n.d).
En instancia, los desarrolladores codifican y envían el código a un repositorio, la configuración de
integración continua del repositorio verifica y empaqueta el código, posteriormente se ejecutan el
análisis de código estático. Por último, se publican los resultados, desarrolladores a través de la
interfaz de SonarQube, correo electrónico y notificaciones en el repositorio.
Pruebas
Las pruebas de seguridad en la aplicación tienen como objetivo descartar la posibilidad de un
código defectuoso, estas pruebas permiten detectar cualquier error desde el principio, así mismo
ayudan a los desarrolladores, para evitar que los errores lleguen a producción.
Según Chavarri (2020) pueden categorizar en tres según el enfoque de pruebas que se realicen:
Dynamic Application Security Testing (DAST) Se analizan la aplicación en su estado dinámico,
es decir en ejecución. Esto durante las fases operativas o de prueba. DAST simula ciber ataques
contra una aplicación normalmente aplicaciones web, analizamos las respuestas de la aplicación y
determinamos las vulnerabilidades
Static Application Security Testing (SAST) Se analiza el código fuente, el bytecode o código
binario de una aplicación en busca de vulnerabilidades de seguridad. Esto generalmente en las
fases de programación y o prueba del ciclo de vida del software (SDLC).
Interactive Application Security Testing (IAST) Se combinan elementos de SAST y DAST
simultáneamente. Por lo general, se implementa como un agente dentro del entorno de ejecución
de pruebas donde observa la operación o los ataques para identificar vulnerabilidades.
En las metodologías modernas de desarrollo, se deben considerar agregar pruebas dentro de los
flujos de desarrollo. Actualmente existen varias alternativas que permiten la automatización de
estas pruebas en conjunto.
Despliegue y Mantenimiento de la aplicación
Por último, luego del despliegue de la aplicación se realizarán una serie de pruebas para detectar
vulnerabilidades del sistema. Para ello se utiliza un método conocido como Pen-testing o pruebas
de penetración.
El Pentesting es un conjunto de pruebas con un objetivo de detección de vulnerabilidades de un
sistema, teniendo en cuenta que ningún sistema es 100% seguro e inviolable. Manteniendo la
integridad de las especificaciones. (R. Guirado, 2009)
Según De Jimenez, (2017) los tipos de pentesting son:
Pruebas de penetración de caja negra: En las pruebas de penetración de caja negra, el probador
no tiene idea de los sistemas que va a probar. Está interesado en recopilar información sobre la red
o el sistema de destino. Por ejemplo, en esta prueba, un evaluador solo sabe cuál debería ser el
resultado esperado y no sabe cómo llega el resultado. No examina ningún código de programación.
Pruebas de penetración de caja blanca: Se trata de una prueba exhaustiva, ya que se le ha
proporcionado al evaluador una amplia gama de información sobre los sistemas y / o la red, como
el esquema, el código fuente, los detalles del sistema operativo, la dirección IP, etc. una fuente
interna. Las pruebas de penetración de caja blanca examinan la cobertura del código y realizan
pruebas de flujo de datos, pruebas de ruta, pruebas de bucle, etc.
Pruebas de penetración de caja gris: En este tipo de prueba, un probador generalmente
proporciona información parcial o limitada sobre los detalles internos del programa de un sistema.
Puede considerarse como un ataque de un pirata informático externo que obtuvo acceso ilegítimo
a los documentos de la infraestructura de red de una organización.
Con el lanzamiento del producto existe la posibilidad de que hayan pasado desapercibidas algunas
vulnerabilidades. Estas vulnerabilidades pueden encontrarse a nivel de codificación, pero se
encuentran cada vez más en los componentes de código abierto subyacente que componen una
aplicación o se encuentran gracias a las pruebas externas realizadas al sistema. La solución de este
tipo de problemas de producción debe planificarse y adaptarse en versiones futuras.
La Gestión de configuración del software, es un proceso encargado de identificar los artefactos y
características de tales artefactos que constituyen la configuración de un sistema y analizar dicha
configuración en distintos puntos del tiempo con el objetivo de controlar sistemáticamente los
cambios en la configuración y mantener así la integridad y trazabilidad del sistema.
El estándar IEEE 828-1998 nos provee de un plan para la gestión de la configuración las
actividades de este plan permitirán identificar los ítems (características del sistema como lenguajes
y plataformas), gestionar adecuadamente los cambios que se deban realizar, sus entregas
(versiones, parches)

Conclusiones
La implementación de un ciclo de desarrollo seguro permite que las aplicaciones sean liberadas en
entornos seguros garantizando su operatividad y la seguridad del sistema durante todas sus etapas.
Además, implementar actividades de seguridad al ciclo de vida de desarrollo seguro implica un
esfuerzo permanente de la organización. Que se traduce posteriormente en menores costos de
desarrollo y mantenimiento.
Con ayuda de estándares establecidos por organizaciones como OWASP se pueden alinear las
etapas del ciclo de desarrollo de software con actividades de seguridad. De manera en que se
pueden implementar medidas desde la planificación, hasta el desarrollo y posterior mantenimiento
del sistema.
En la medida que el equipo de desarrollo conozca sobre aspectos de seguridad en las aplicaciones
tendrá una mejor oportunidad de aplicar medidas preventivas y correctivas que eviten que la
aplicación sufra errores en producción.
Las herramientas que permiten la automatización de procesos de prueba e identificación pueden
ser de ayuda, pero no garantizan cubrir todos los casos de uso, por lo que es necesario también de
revisiones de código manuales.
 Bibliografía
De Jimenez, R. E. L. (2017). Pentesting on web applications using ethical - Hacking. 2016 IEEE
36th Central American and Panama Convention, CONCAPAN 2016, 503.
https://doi.org/10.1109/CONCAPAN.2016.7942364
Figueroa, V. (n.d.). Secure Software Development Life Cycle - OWASP LATAM Tour 2016.
https://owasp.org/www-pdf-archive/OWASP-LATAMTour-Patagonia-2016-rvfigueroa.pdf
López Álvarez, D. M. (2020). Método para el desarrollo de software seguro basado en la
ingeniería de software y ciberseguridad. INNOVA Research Journal, 5(3.1), 263–280.
https://doi.org/10.33890/innova.v5.n3.1.2020.1440
OWASP. (2017a). Estándar de Verificación de Seguridad en Aplicaciones.
https://owasp.org/www-pdf-
archive/Estándar_de_Verificación_de_Seguridad_en_Aplicaciones_3.0.1.pdf
OWASP. (2017b). OWASP Top 10 - 2017 Los diez riesgos más críticos en Aplicaciones.
Owasp. https://github.com/OWASP/Top10/issues
Peterson, G., Hope, P., & Lavenha, S. (2005). Architectural Risk Analysis | CISA. Retrieved 26
December 2021, from https://www.cisa.gov/uscert/bsi/articles/best-practices/architectural-
risk-analysis/architectural-risk-analysis
SonarQube Documentation. (2021). Retrieved 22 December 2021, from
https://docs.sonarqube.org/latest/
Chavarri, C., (2020). Pruebas de Seguridad de Aplicaciones (AST) SAST, DAST e IAST. [en
línea] GB Advisors. Disponible en: <https://www.gb-advisors.com/es/pruebas-de-
seguridad-de-aplicaciones-ast-sast-dast-e-iast/> [Accedido en 22 December 2021].
R. Girardo, (2009). Penetration Testing: conceptos generales y situación actual [en línea].
Disponible en: <https://docplayer.es/3891438-Penetration-testing-conceptos-generales-y-
situacion-actual-pwc.html> [Accedido en 22 December 2021].